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

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

[ori]

> maybe i brought this notion with me from unix, but i was pretty sure at
> least some plan 9 programs check for $editor in the environment.

I don't think it's currently a widespread convention, but
I'd like it to be. I'm in support of documenting it and
patching programs to use it.

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

[hiro]

what if you want it to open in your already open editor and not in
some new window? what's the problem with using the plumber? i must be
misunderstanding something?

On 3/12/20, ori@eigenstate.org <ori@eigenstate.org> wrote:
>> maybe i brought this notion with me from unix, but i was pretty sure at
>> least some plan 9 programs check for $editor in the environment.
>
> I don't think it's currently a widespread convention, but
> I'd like it to be. I'm in support of documenting it and
> patching programs to use it.
>
>

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

[Stanley Lieber]

On March 13, 2020 12:30:18 PM EDT, hiro <23hiro@gmail.com> wrote:
>what if you want it to open in your already open editor and not in
>some new window? what's the problem with using the plumber? i must be
>misunderstanding something?
>
>On 3/12/20, ori@eigenstate.org <ori@eigenstate.org> wrote:
>>> maybe i brought this notion with me from unix, but i was pretty sure
>at
>>> least some plan 9 programs check for $editor in the environment.
>>
>> I don't think it's currently a widespread convention, but
>> I'd like it to be. I'm in support of documenting it and
>> patching programs to use it.
>>
>>

assume graphics is not running. how does someone use ipso?

sl

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

[hiro]

i would make a little plumber queuee that ipso (or your script that
runs ipso) would access.

On 3/13/20, Stanley Lieber <sl@stanleylieber.com> wrote:
> On March 13, 2020 12:30:18 PM EDT, hiro <23hiro@gmail.com> wrote:
>>what if you want it to open in your already open editor and not in
>>some new window? what's the problem with using the plumber? i must be
>>misunderstanding something?
>>
>>On 3/12/20, ori@eigenstate.org <ori@eigenstate.org> wrote:
>>>> maybe i brought this notion with me from unix, but i was pretty sure
>>at
>>>> least some plan 9 programs check for $editor in the environment.
>>>
>>> I don't think it's currently a widespread convention, but
>>> I'd like it to be. I'm in support of documenting it and
>>> patching programs to use it.
>>>
>>>
>
> assume graphics is not running. how does someone use ipso?
>
> sl
>

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

[Steve Simon]

i was suggesting the plumber use $editor rather than having its own private view of the users editor of choice.

however i think sl is saying $editor does not exist on plan9, but only on *nux.

the problem with using the plumber is that ipso starts ramfs to keep the editors temporary buffers safe and private. it also keeps the extracted factotum secrets file there. if you use the plumber then the secrets are/may be  more exposed; particularly if you run it on a cpu server - though that has its own problems.

-Steve


> On 13 Mar 2020, at 4:31 pm, hiro <23hiro@gmail.com> wrote:
> 
> what if you want it to open in your already open editor and not in
> some new window? what's the problem with using the plumber? i must be
> misunderstanding something?
> 
> On 3/12/20, ori@eigenstate.org <ori@eigenstate.org> wrote:
>>> maybe i brought this notion with me from unix, but i was pretty sure at
>>> least some plan 9 programs check for $editor in the environment.
>> 
>> I don't think it's currently a widespread convention, but
>> I'd like it to be. I'm in support of documenting it and
>> patching programs to use it.
>> 
>> 

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

[hiro]

ah, then ipso as it is now is likely the wrong program for these kinds
of customizations.
it seems particularly made not for usuability but security.

On 3/13/20, Steve Simon <steve@quintile.net> wrote:
>
> i was suggesting the plumber use $editor rather than having its own private
> view of the users editor of choice.
>
> however i think sl is saying $editor does not exist on plan9, but only on
> *nux.
>
> the problem with using the plumber is that ipso starts ramfs to keep the
> editors temporary buffers safe and private. it also keeps the extracted
> factotum secrets file there. if you use the plumber then the secrets are/may
> be  more exposed; particularly if you run it on a cpu server - though that
> has its own problems.
>
> -Steve
>
>
>> On 13 Mar 2020, at 4:31 pm, hiro <23hiro@gmail.com> wrote:
>>
>> what if you want it to open in your already open editor and not in
>> some new window? what's the problem with using the plumber? i must be
>> misunderstanding something?
>>
>> On 3/12/20, ori@eigenstate.org <ori@eigenstate.org> wrote:
>>>> maybe i brought this notion with me from unix, but i was pretty sure at
>>>> least some plan 9 programs check for $editor in the environment.
>>>
>>> I don't think it's currently a widespread convention, but
>>> I'd like it to be. I'm in support of documenting it and
>>> patching programs to use it.
>>>
>>>
>
>

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

[Silas McCroskey]

On Fri, Mar 13, 2020 at 10:19 AM Steve Simon <steve@quintile.net> wrote:
>
>
> i was suggesting the plumber use $editor rather than having its own private view of the users editor of choice.
>
> however i think sl is saying $editor does not exist on plan9, but only on *nux.
>
> the problem with using the plumber is that ipso starts ramfs to keep the editors temporary buffers safe and private. it also keeps the extracted factotum secrets file there. if you use the plumber then the secrets are/may be  more exposed; particularly if you run it on a cpu server - though that has its own problems.
>
> -Steve

The plumber also would access $editor from its own environment rather
than from the program that had called it.

The use case in question probably looks like 'editor=foo ipso' -- ipso
would have to forward that env var to the plumber, which brings us
back to modifying ipso anyways.

- sam-d

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

[Stanley Lieber]

On March 13, 2020 5:23:19 PM EDT, Silas McCroskey <inkswinc@gmail.com> wrote:
>On Fri, Mar 13, 2020 at 10:19 AM Steve Simon <steve@quintile.net>
>wrote:
>>
>>
>> i was suggesting the plumber use $editor rather than having its own
>private view of the users editor of choice.
>>
>> however i think sl is saying $editor does not exist on plan9, but
>only on *nux.
>>
>> the problem with using the plumber is that ipso starts ramfs to keep
>the editors temporary buffers safe and private. it also keeps the
>extracted factotum secrets file there. if you use the plumber then the
>secrets are/may be  more exposed; particularly if you run it on a cpu
>server - though that has its own problems.
>>
>> -Steve
>
>The plumber also would access $editor from its own environment rather
>than from the program that had called it.
>
>The use case in question probably looks like 'editor=foo ipso' -- ipso
>would have to forward that env var to the plumber, which brings us
>back to modifying ipso anyways.
>
>- sam-d

i'm not married to any specific solution, i just think ipso should somehow be functional by default even if graphics isn't running.

sl

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

[Ethan Gardener]

On Fri, Mar 13, 2020, at 10:04 PM, Stanley Lieber wrote:
> 
> i'm not married to any specific solution, i just think ipso should 
> somehow be functional by default even if graphics isn't running.

- editor = (acme -c1)
+ if(test -e /dev/draw)
+ 	editor = (acme -c1)
+ if not
+ 	editor = ed

NOTE: i have no idea if the test will work. i don't use drawterm (with or without -G), so i can't check it.

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

[Stanley Lieber]

On March 13, 2020 7:44:37 PM EDT, Ethan Gardener <eekee57@fastmail.fm> wrote:
>On Fri, Mar 13, 2020, at 10:04 PM, Stanley Lieber wrote:
>> 
>> i'm not married to any specific solution, i just think ipso should 
>> somehow be functional by default even if graphics isn't running.
>
>- editor = (acme -c1)
>+ if(test -e /dev/draw)
>+ 	editor = (acme -c1)
>+ if not
>+ 	editor = ed
>
>NOTE: i have no idea if the test will work. i don't use drawterm (with
>or without -G), so i can't check it.

why don't we just add a check for $editor before the existing checks?

sl

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

[Ethan Gardener]

On Sat, Mar 14, 2020, at 12:55 AM, Stanley Lieber wrote:
> On March 13, 2020 7:44:37 PM EDT, Ethan Gardener <eekee57@fastmail.fm> wrote:
> >On Fri, Mar 13, 2020, at 10:04 PM, Stanley Lieber wrote:
> >> 
> >> i'm not married to any specific solution, i just think ipso should 
> >> somehow be functional by default even if graphics isn't running.
> >
> >- editor = (acme -c1)
> >+ if(test -e /dev/draw)
> >+ 	editor = (acme -c1)
> >+ if not
> >+ 	editor = ed
> >
> >NOTE: i have no idea if the test will work. i don't use drawterm (with
> >or without -G), so i can't check it.
> 
> why don't we just add a check for $editor before the existing checks?

Makes sense to me, I was surprised to find it doesn't have such a check already.

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

[ori]

> what if you want it to open in your already open editor and not in
> some new window? what's the problem with using the plumber? i must be
> misunderstanding something?

When plumbing, there's no signal that editing is done.
Scripts often need some way to edit a file and proceed
on the edited contents.

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

[Ethan Gardener]

On Fri, Mar 13, 2020, at 5:35 PM, ori@eigenstate.org wrote:
> 
> When plumbing, there's no signal that editing is done.
> Scripts often need some way to edit a file and proceed
> on the edited contents.

There is /bin/E for this purpose. It's a little crude, returning after the file is first saved. (It doesn't cover ipso's security concerns.)

This all reminds me I have found the plumber to be a little bit inconvenient on occasion because it acts all Proper GUI: it sends the document to the Appropriate Application instead of opening it near where I'm looking. I've never entirely liked that. Back in the early 00s I had a powerful Emacs setup but abandoned it because I always wanted to start the editor in the terminal I was already looking at. Starting Emacs just took too long. I never did come up with the perfect solution, but subrios with their own plumer instances can help.

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

[Trevor Higgins]

On 03/12/2020 02:49 PM, sl@stanleylieber.com wrote:
>> i added the code to ipso to look at the plumbing rules.  at that time
>> there was no $editor.  if 9front has a $editor i would suggest you use
>> it and modify the plumber to respect it too (it it doesn't already).
What is it with all these environment variables ?, is this Unix?
Its bad enough to have $path (how embarrassing), then there is $font and 
now $editor
Whats next /usr/bin, /usr/local/sbin.

How about using the universal editor:
      /bin/editor

Works everywhere there is a namespace.

-- 
We need another plan

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

[sl]

> What is it with all these environment variables ?, is this Unix?

i think you mean environment lists!

sl

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

[Ethan Gardener]

On Thu, Mar 12, 2020, at 2:24 AM, Trevor Higgins wrote:
> 
> How about using the universal editor:
>       /bin/editor
> 
> Works everywhere there is a namespace.

How about using the universal editor:
    /bin/B
;)

Actually, I really don't see what the problem is with changing the plumbing rules when the display is different; I think that's how it should be done. See also the initial $home/lib/profile where con is a separate case from terminal or cpu.

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

[hiro]

makes sense, yeah.
i'd even want to extend plumbing further. so that it can be used while
i'm not at the PC :)

On 3/13/20, Ethan Gardener <eekee57@fastmail.fm> wrote:
> On Thu, Mar 12, 2020, at 2:24 AM, Trevor Higgins wrote:
>>
>> How about using the universal editor:
>>       /bin/editor
>>
>> Works everywhere there is a namespace.
>
> How about using the universal editor:
>     /bin/B
> ;)
>
> Actually, I really don't see what the problem is with changing the plumbing
> rules when the display is different; I think that's how it should be done.
> See also the initial $home/lib/profile where con is a separate case from
> terminal or cpu.
>

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

[Ethan Gardener]

On Fri, Mar 13, 2020, at 5:04 PM, hiro wrote:
> makes sense, yeah.
> i'd even want to extend plumbing further. so that it can be used while
> i'm not at the PC :)

I'd suggest mycroftiv's gridplumb, except the way he's got it set up, whenever one person on the grid plumbs something, it gets plumbed to the local plumbers of every machine on the grid. I'm surprised it's still in use... ^.^;

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

[hiro]

it's actually been decoupled in the meantime bec. of this risk of misuse :P

On 3/13/20, Ethan Gardener <eekee57@fastmail.fm> wrote:
> On Fri, Mar 13, 2020, at 5:04 PM, hiro wrote:
>> makes sense, yeah.
>> i'd even want to extend plumbing further. so that it can be used while
>> i'm not at the PC :)
>
> I'd suggest mycroftiv's gridplumb, except the way he's got it set up,
> whenever one person on the grid plumbs something, it gets plumbed to the
> local plumbers of every machine on the grid. I'm surprised it's still in
> use... ^.^;
>

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

[Ethan Gardener]

On Fri, Mar 13, 2020, at 5:12 PM, hiro wrote:
> it's actually been decoupled in the meantime bec. of this risk of misuse :P

Haha! Well, it wasn't me (this time)

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

[ori]

> 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.

I revisited this, and sketched out 95% of a solution. That
solution comes in 3 parts:

plumb: I added a '-r' flag to plumb to read a plumb message
       from a specified port, allowing us to recieve plumb
       messages from shell scripts. I think this is useful
       independent of whether we adopt my changes to 'E'

sam:   I added a plumb message -- 'editdone' -- that gets
       sent when an editing window is closed. Right now it's
       a bit janky about the wdir parameter, and this will
       probably need polishing before committing.

E:     it uses the above two changes to figure out when
       it should be done. Right now, it just matches on the
       basename of the file due to the aforementioned sam
       jankiness.

Do we want this? Do we need to change sam to be aware of the
path to the file it's editing? Does someone want to step up
and do this to Acme too?

Code below:

diff -r d0d202a26d24 rc/bin/E
--- a/rc/bin/E	Sun Apr 12 16:12:41 2020 +0200
+++ b/rc/bin/E	Sun Apr 12 18:13:15 2020 -0700
@@ -5,12 +5,16 @@
 	echo usage: $0 file >[1=2]
 	exit usage
 }
-if (! test -e $1) {
-	echo $0: $1: no such file >[1=2]
-	exit no-file
+file=`{basename $1}
+dir=`{basename -d $1}
+B $1
+fn closedfile{
+	msg=`"{plumb -r editdone}
+	echo $msg
+	f=`{echo $"msg | awk '/^data/{gsub(/^data /, "", $0); print $0}'}
+	~ `{basename $f} $file
 }
-otm = `{mtime $1 | awk '{print $1}'}
-B $1
-while (~ $otm `{mtime $1 | awk '{print $1}'})
-	sleep 1
+
+while (! closedfile){
+}
 exit ''
diff -r d0d202a26d24 sys/src/cmd/plumb/plumb.c
--- a/sys/src/cmd/plumb/plumb.c	Sun Apr 12 16:12:41 2020 +0200
+++ b/sys/src/cmd/plumb/plumb.c	Sun Apr 12 18:13:15 2020 -0700
@@ -35,59 +35,77 @@
 	}
 }
 
+int
+matchmsg(Plumbmsg *m, Plumbmsg *pat)
+{
+	Plumbattr *a;
+	char *v;
+
+	if(pat->src && strcmp(m->src, pat->src) != 0)
+		return 0;
+	if(pat->dst && strcmp(m->dst, pat->dst) != 0)
+		return 0;
+	if(pat->wdir && strcmp(m->wdir, pat->wdir) != 0)
+		return 0;
+	if(pat->type && strcmp(m->type, pat->type) != 0)
+		return 0;
+	for(a = m->attr; a != nil; a = a->next){
+		v = plumblookup(pat->attr, a->name);
+		if(v != nil && strcmp(a->value, v) != 0)
+			return 0;
+	}
+	return 1;
+}
+
 void
 main(int argc, char *argv[])
 {
-	char buf[1024], *p;
+	char buf[1024], *p, *readport;
 	int fd, i, input;
+	Plumbmsg *rmsg;
+	Plumbattr *a;
 
 	input = 0;
-	m.src = "plumb";
+	readport = nil;
+	m.src = nil;
 	m.dst = nil;
-	m.wdir = getwd(buf, sizeof buf);
+	m.wdir = nil;
 	m.type = "text";
 	m.attr = nil;
 	ARGBEGIN{
 	case 'a':
-		p = ARGF();
-		if(p == nil)
-			usage();
+		p = EARGF(usage());
 		m.attr = plumbaddattr(m.attr, plumbunpackattr(p));
 		break;
 	case 'd':
-		m.dst = ARGF();
-		if(m.dst == nil)
-			usage();
+		m.dst = EARGF(usage());
 		break;
 	case 'i':
 		input++;
 		break;
 	case 't':
 	case 'k':	/* for backwards compatibility */
-		m.type = ARGF();
-		if(m.type == nil)
-			usage();
+		m.type = EARGF(usage());
 		break;
 	case 'p':
-		plumbfile = ARGF();
-		if(plumbfile == nil)
-			usage();
+		plumbfile = EARGF(usage());
 		break;
 	case 's':
-		m.src = ARGF();
-		if(m.src == nil)
-			usage();
+		m.src = EARGF(usage());
 		break;
 	case 'w':
-		m.wdir = ARGF();
-		if(m.wdir == nil)
-			usage();
+		m.wdir = EARGF(usage());
+		break;
+	case 'r':
+		readport = EARGF(usage());
 		break;
 	}ARGEND
 
-	if((input && argc>0) || (!input && argc<1))
+	if((input && argc>0) || (!input && argc<1) && readport == nil)
 		usage();
-	if(plumbfile != nil)
+	if(readport != nil)
+		fd = plumbopen(readport, OREAD);
+	else if(plumbfile != nil)
 		fd = open(plumbfile, OWRITE);
 	else
 		fd = plumbopen("send", OWRITE);
@@ -95,6 +113,30 @@
 		fprint(2, "plumb: can't open plumb file: %r\n");
 		exits("open");
 	}
+	if(readport != nil){
+again:
+		rmsg = plumbrecv(fd);
+		if(rmsg == nil){
+			fprint(2, "plumb: receive failed: %r\n");
+			exits("recv");
+		}
+		print("got message, matching\n");
+		if(!matchmsg(rmsg, &m))
+			goto again;
+		print("src %s\n", rmsg->src);
+		print("dst %s\n", rmsg->dst);
+		print("wdir %s\n", rmsg->wdir);
+		print("type %s\n", rmsg->type);
+		print("data %.*s\n", rmsg->ndata, rmsg->data);
+		for(a = rmsg->attr; a; a = a->next)
+			print("attr %s=%s\n", a->name, a->value);
+		plumbfree(rmsg);
+		exits(nil);
+	}
+	if(m.src == nil)
+		m.src = "plumb";
+	if(m.wdir == nil)
+		m.wdir = getwd(buf, sizeof buf);
 	if(input){
 		gather();
 		if(plumblookup(m.attr, "action") == nil)
diff -r d0d202a26d24 sys/src/cmd/samterm/menu.c
--- a/sys/src/cmd/samterm/menu.c	Sun Apr 12 16:12:41 2020 +0200
+++ b/sys/src/cmd/samterm/menu.c	Sun Apr 12 18:13:15 2020 -0700
@@ -5,6 +5,7 @@
 #include <cursor.h>
 #include <mouse.h>
 #include <keyboard.h>
+#include <plumb.h>
 #include <frame.h>
 #include "flayer.h"
 #include "samterm.h"
@@ -265,6 +266,7 @@
 void
 menudel(int n)
 {
+	char wdir[1024];
 	int i;
 
 	if(nname==0 || n>=nname || text[n])
diff -r d0d202a26d24 sys/src/cmd/samterm/mesg.c
--- a/sys/src/cmd/samterm/mesg.c	Sun Apr 12 16:12:41 2020 +0200
+++ b/sys/src/cmd/samterm/mesg.c	Sun Apr 12 18:13:15 2020 -0700
@@ -94,6 +94,21 @@
 }
 
 void
+plumbdelname(char *name)
+{
+	char wdir[1024];
+
+	if(plumbfd == -1)
+		return;
+	if(name[0] == '/'){
+		snprint(wdir, sizeof(wdir), "%s", name);
+		*strrchr(wdir, '/') = 0;
+	}else if(getwd(wdir, sizeof(wdir)) == nil)
+			return;
+	plumbsendtext(plumbfd, "sam", "editdone", wdir, name);
+}
+
+void
 inmesg(Hmesg type, int count)
 {
 	Text *t;
@@ -255,8 +270,10 @@
 		break;
 
 	case Hdelname:
-		if((m=whichmenu(m)) >= 0)
+		if((m=whichmenu(m)) >= 0){
+			plumbdelname((char*)name[m]);
 			menudel(m);
+		}
 		break;
 
 	case Hcut:

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

[hiro]

i like where this is going!

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

[Anthony Martin]

ori@eigenstate.org once said:
> plumb: I added a '-r' flag to plumb to read a plumb message
>        from a specified port, allowing us to recieve plumb
>        messages from shell scripts. I think this is useful
>        independent of whether we adopt my changes to 'E'
> 
> sam:   I added a plumb message -- 'editdone' -- that gets
>        sent when an editing window is closed. Right now it's
>        a bit janky about the wdir parameter, and this will
>        probably need polishing before committing.

These two changes sound good, especially the first.

> E:     it uses the above two changes to figure out when
>        it should be done. Right now, it just matches on the
>        basename of the file due to the aforementioned sam
>        jankiness.

Please don't change E. Choose another name for this since it's
completely different semantics. E simply runs B and waits for
the file to change before exiting. That is quite useful.

Of course, what it means for a file to change should probably
be strengthened. Plan9port compares the output of 'ls -l' but
'ls -lq' might be better.

  Anthony

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

[ori]

> E simply runs B and waits for
> the file to change before exiting. That is quite useful.

Hm. When have you used it?

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

[ori]

>> E simply runs B and waits for
>> the file to change before exiting. That is quite useful.
> 
> Hm. When have you used it?

Or more accurately: What have you relied on that behavior for?

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

[Ethan Gardener]

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.

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

[Steve Simon]

i guess the plan9 way of doing something like E is to use hold mode in rio, like mail does. this wont work for everything but its good enough for mail, and perhaps commit messages to git.

ipso is a rather a-typical example imho and its fair it works a bit differently.

-Steve


> On 16 Apr 2020, at 12:19 pm, Ethan Gardener <eekee57@fastmail.fm> wrote:
> 
> 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.

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

[ori]

> i guess the plan9 way of doing something like E is to use hold mode in rio, like mail does.
> this wont work for everything but its good enough for mail, and perhaps commit messages to git.
> 
> ipso is a rather a-typical example imho and its fair it works a bit differently.

Yes; that's what I'm currently doing in git9, but I think I'd appreciate having the
edited text pop up in sam instead. In any case, I agree that ipso is special becuase
it wants to keep the passwords from escaping its environment.

Regardless of what ends up happening here, I like `plumb -r` as an idea.

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

[Ethan Gardener]

On Thu, Apr 16, 2020, at 5:05 PM, Steve Simon wrote:
> i guess the plan9 way of doing something like E is to use hold mode in 
> rio, like mail does. this wont work for everything but its good enough 
> for mail, and perhaps commit messages to git.

what? you have powerful editors which could work just fine with a tiny bit of tweaking, if that, but you want to use the lowest common denominator? what if i want to pipe my mail message into spell? what if i want to reformat the code i'm pasting? hold mode is handy for tiny ad-hoc scripts and for pasting, but in this usage it's equivalent to the nastiness of 80s GUI, denying the user all convenience and trying to make out that's the right thing.

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

[hiro]

i wanted to add some idea i had in my head for a while, before i lose
interest (bec. i like ori's idea more)...

you could reverse the error scenario, by creating a special ramfs fork
which will detect when the file got a close(), then it will exits(),
and if some client still has the file open and try to write into it
you will get sufficient warning for this edge-case through a write (or
really an open()) error!.

On 4/18/20, Ethan Gardener <eekee57@fastmail.fm> wrote:
> On Thu, Apr 16, 2020, at 5:05 PM, Steve Simon wrote:
>> i guess the plan9 way of doing something like E is to use hold mode in
>> rio, like mail does. this wont work for everything but its good enough
>> for mail, and perhaps commit messages to git.
>
> what? you have powerful editors which could work just fine with a tiny bit
> of tweaking, if that, but you want to use the lowest common denominator?
> what if i want to pipe my mail message into spell? what if i want to
> reformat the code i'm pasting? hold mode is handy for tiny ad-hoc scripts
> and for pasting, but in this usage it's equivalent to the nastiness of 80s
> GUI, denying the user all convenience and trying to make out that's the
> right thing.
>

ipso(1) $editor

[Stanley Lieber]

is there a reason why ipso(1) doesn't just honor $editor, instead of convoluted tricks to prise it out of the plumber rules, or waving flags(!)? sometimes i'd like to run it with no graphics enabled. i could modify my plumber rules every time, but just defaulting to $editor seems more sensible.

sl

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

[Steve Simon]

i added the code to ipso to look at the plumbing rules. at that time there was no $editor. if 9front has a $editor i would suggest you use it and modify the plumber to respect it too (it it doesn't already).

-Steve


> On 11 Mar 2020, at 3:23 pm, Stanley Lieber <sl@stanleylieber.com> wrote:
> 
> is there a reason why ipso(1) doesn't just honor $editor, instead of convoluted tricks to prise it out of the plumber rules, or waving flags(!)? sometimes i'd like to run it with no graphics enabled. i could modify my plumber rules every time, but just defaulting to $editor seems more sensible.
> 
> sl

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

[sl]

> i added the code to ipso to look at the plumbing rules.  at that time
> there was no $editor.  if 9front has a $editor i would suggest you use
> it and modify the plumber to respect it too (it it doesn't already).

maybe i brought this notion with me from unix, but i was pretty sure at
least some plan 9 programs check for $editor in the environment.

haha:

mars2; cd /sys/src/cmd
mars2; grep editor */*
abaco/plumbing:editor = acme
acme/dat.h:	Buffer	*elogbuf;	/* log of pending editor changes */
dict/movie.c:	ED,	/* editor */
dict/oed.c:	Ed,		/* editor's comments (in [...]) */
hg/hgeditor:# If you want to pass your favourite editor some other parameters
hg/hgeditor:HGTMP="${TMPDIR-/tmp}/hgeditor.$RANDOM.$RANDOM.$RANDOM.$$"
postscript/README:  LDFLGS    common link editor options - used to build LDFLAGS in the
postscript/postscript.mk:#     LDFLGS	common link editor options - used to build LDFLAGS in the
spell/list:coeditor	n
spell/list:creditor	n
spell/list:editor	n
spell/list:editorial	n,a,na
spell/list:expeditor	n
mars2; cd /rc/bin
mars2; grep editor *
ipso:editor = (acme -c1)
ipso:edexp=`{grep '^editor=' /mnt/plumb/rules >[2]/dev/null}
ipso:		editor = sam
ipso:	Warning: The editor will display the secret contents of
ipso:if(~ $edit yes) $editor `{for(i in $files) basename $i}
newt:if(~ $#editor 0)
newt:	editor=hold
newt:	eval $editor /tmp/post
newt:		echo editor: $editor
mars2; 

sl