Re: [9front] ipso(1) $editor

["Ethan Gardener" <eekee57@fastmail.fm>]

On Mon, Apr 13, 2020, at 2:13 AM, ori@eigenstate.org wrote:
> > How about using the universal editor:
> >     /bin/B
> > ;)
> 
> So, I revisited this,
> 
> The problem with B is that many programs which start an editor
> also need to know when editing is finished. We have 'E' for this,
> but the method it uses is unbelievably janky: it waits for the
> file mtime to change.
> 
> Since my muscle memory leads to saving the file I'm working on
> fairly often, this is not a good solution.

same here. i'm rather opposed to programs which pop up an editor at all, i prefer to prepare things up front and leave the job to run, but that's beside the point. your changes seem workable to me, (modulo details,) but i have a philosophical objection: all this is added complexity to work around a design problem.

how does this look in other systems? when tty/console programs want the user to edit something, they can start an editor and wait for it to finish. gui programs can incorporate an editable text field from the same toolkit they get everything else, and block further interaction until the user signals it's done. the tty case is very simple. the gui case is also very simple with a good toolkit. also, in both cases, the text appears for editing in the place the user is already looking at. this solution proposed for plan 9 is none of these things. it's not *very* complex, but it is unnecessary complexity which moves plan 9 another step further from the simple system it pretends to be.

can plan 9 programs start $editor like tty programs? let's see...

@{
	rfork n
	unmount /mnt/plumb
	$editor $file
}
what could go wrong if a text-only program does this? if editor = ed or sam -d, nothing; it'll be fine. (caveat: i haven't actually tested it. ;) if editor = sam, the user will have to manually select the file to edit; an annoyance and it hides information which may be present in the file. (in certain moods, i wouldn't know why sam was suddenly running.) options such as -a could be set too. if editor = acme, then you really want editor = (acme -c1), at minimum. this is all right if you don't rely on the plumber to start acme. instead, start it at login with a different -c option. summary: it's fine if you don't rely on $editor to start your system-wide editor, or maybe even if you do.

what about graphical programs under plan 9? if they can stop reading and writing cons kbd and draw until the editor is finished, and if editor = sam or acme, they can do exactly the same as text-only programs. i'm not sure whether ed or sam -d would work or not. i think they will but the window will look ugly. maybe there's a way around it.

then there's the possibility of an all-singing, all-dancing gui program emulating rio to host sam or acme in a portion of its own window. that might be a bit much. :)

in all cases, if $editor is suitable, i can't foresee any problems. maybe there's something i've forgotten.