[9fans] non-captive user-interfaces: some ramblings; Plan 9 possibilities

[Ethan Gardener <eekee57@fastmail.fm>]

On Fri, Nov 30, 2018, at 3:53 AM, Mayuresh Kathe wrote:
> non-captive user-interface

There's a term for what I've been looking for!  Lately I've been wanting to implement basically everything with non-captive interfaces.  I've been having trouble designing the programs because of my poor memory and other issues.

On the other hand, now I realise that a program I've heard of repeatedly over the last 20 years has the type of interface I'm looking for, I'm wondering why I didn't use it, if there's something wrong with the concept, something I felt but couldn't quantify.  I think maybe a general malaise when using the unix command line, probably initially due to trying to learn by reading init scripts of Red Hat 5.2; a source of brain damage almost on a par with BASIC!  Poor documentation in the 90s and tremendous option bloat obviously contributed to my malaise.  I did try hard at times.

I think netpbm was what finally put me off.  Inconsistent cryptic options, view-updating only by manual means, state-keeping also manual; I think those were the problems.  Ah, not netpbm; Plan 9's image tools are far more consistent, but the other two problems remain.  I guess both are worse in editing (text or images) than in mail.

I'm thinking of a two-pane view, one being a REPL of some sort, the other a display of what you're editing, obviously keeping state, and having an undo facility.  Obviously different display programs for text or images.  This could actually be scripted in Plan 9, especially in 9front where rio's text files are writable.  A minor catch is that you want the filters to operate on the displayed data rather than stdio.  This could be worked around by piping, or by a clever shell inserting redirects if none are specified.  (A wrapper around rc could do it.)  The display programs could (probably should) handle the case of `prog <dispfile >dispfile`.  Now I'm wondering if, when editing text, all output on stdout should go into the displayed text.  I guess that's reasonable, there is always undo, but I'm running out of functioning brain cells, lol.