[9fans] Acme 3-1

[9fans] Acme 3-1

[rob pike, esq.]

3-1 and 2-1 are already defined: they cancel button 3 and button 2 actions.
I would object to giving them another meaning.

-rob

Re: [9fans] Acme 3-1

[paurea]

> 3-1 and 2-1 are already defined: they cancel button 3 and button 2 actions.
> I would object to giving them another meaning.
>


I agree. But anyway it would be good to have a smooth way to browse directories.
Maybe ctrl-3 or a property of the window like Noscroll/Scroll, maybe Browse/Nobrowse...
When I browse a directory with acme I keep Deleting windows...


									Gorka

Re: [9fans] Acme 3-1

[Sam]

In an effort to toss out other suggestions,
how about keeping with 3-1, but if you want
to stay in the current window, you should
have previously highlighted `.'.  This both
keeps with the notion of button one being used
to dictate arguments for an action and would
permit keeping 3-1 sans input as a cancel shortcut.

Moreover, it seems that on 2-1 if there's nothing
highlighted for use as argument, the exec
ought not occur.  We have a button for exec
w/o arguments and chords are precious (even
if they're reclaimed to do nothing).

Cheers,

Sam


On Tue, 18 Feb 2003
paurea@plan9.escet.urjc.es wrote:

> > 3-1 and 2-1 are already defined: they cancel button 3 and button 2 actions.
> > I would object to giving them another meaning.
> >
>
>
> I agree. But anyway it would be good to have a smooth way to browse directories.
> Maybe ctrl-3 or a property of the window like Noscroll/Scroll, maybe Browse/Nobrowse...
> When I browse a directory with acme I keep Deleting windows...
>
>
> 									Gorka
>

Re: [9fans] Acme 3-1

[okamoto]

> that's why i thought it might be nice to have it go automatically to
> the window you've most recently interacted with
                                     ^^^^^^^^^^^^^^^^^^^^^^^
I prefer this interface.

> it doesn't look hard to do in the code.  i'll experiment with it.

Wow!
I hope you'll get success!

Kenji

Re: [9fans] Acme 3-1

[rog]

> Of course, you could take a tip from plumbing's relatives in
> other systems and provide a UI for selecting where it goes,
> but 99% of plumbing's value is its automation.

that's why i thought it might be nice to have it go automatically to
the window you've most recently interacted with (or some approximation
thereof).

the rule could also specify fan-out or not (e.g.  "plumb toall edit")

then you'd have your UI for selecting whether it fans out (plumb
/mnt/plumb/rules).

it doesn't look hard to do in the code.  i'll experiment with it.

Re: [9fans] Acme 3-1

[rob pike, esq.]

Russ summarized pretty well how we came to have fan-out.
The main issue was unicast was: who gets it?  Or, to put it
another way, Damn, it went to the wrong program.

I was surprised to discover I liked fan-out, especially when
debugging new rules.

Of course, you could take a tip from plumbing's relatives in
other systems and provide a UI for selecting where it goes,
but 99% of plumbing's value is its automation.

-rob

Re: [9fans] Acme 3-1

[Russ Cox]

> i don't think the broadcast nature of plumbing is what's wanted in
> most cases, but perhaps others disagree?

when it happened, the consensus seemed to be (i was
watching from afar) that neither broadcast nor unicast
was really a perfect answer, but broadcast was easier
all around.  the plumber doesn't really know where
messages are coming from, so you'd have to add something
for that, and you'd have to add some way to change where
the unicasts were going.  some way to associate incoming
messages with outgoing fids.  it gets ugly quickly.

another possibility is to round-robin unicast
readers when you get the same message over and over
again, you would 3-click the same thing
multiple times to get it to appear in the right window.
this combined with a broadcast attribute would probably
work reasonably.  i'm still not sure -- there are rarely
times when i would actually use such functionality.

i just added

fn sam {
	if(~ $1 -*)
		exec /bin/sam $*
	@{
		rfork n
		plumber
		exec /bin/sam $*
	}
}

to my profile, which nicely fixes the one time when i
wish plumbing weren't there.  (i use sam instances
when i'm using a lot of the command language on a
fixed set of files, and literally never want to plumb
new files into the sams.)

Re: [9fans] Acme 3-1

[rog]

> faces and Mail depend on both getting announcements
> about new messages from upas/fs via the plumber to
> work correctly.

oh yes, i'd forgotten about that.

however, mail could serve a file that informed readers of updates to
the mailbox; or the plumber could recognise a "broadcast" attribute,
so plumb clients could cause a message to be sent to all listeners.

i don't think the broadcast nature of plumbing is what's wanted in
most cases, but perhaps others disagree?

Re: [9fans] Acme 3-1

[Russ Cox]

> what currently depends on the fan-out behaviour of plumbing?
> (mail/fs, i guess, when messages are deleted, but that's very slow,
> and works without plumbing anyway).

faces and Mail depend on both getting announcements
about new messages from upas/fs via the plumber to
work correctly.

Re: [9fans] Acme 3-1

[rog]

> 3-1 and 2-1 are already defined: they cancel button 3 and button 2 actions.
> I would object to giving them another meaning.

i thought 2-1 appended the most recently selected text as an argument
to the executed command (and 2-3 cancels the b2 action).  i use this
for Edit commands (and was confused a moment ago because it doesn't
work in Mail windows).

as far as i can see 3-1 is the only button chord that's currently
redundant (has the same meaning as 3-2):

	1	select
	2	execute
	3	look
	1-2	cut
	1-3	paste
	2-1	execute with args
	2-3	cancel execute
	3-1	cancel look
	3-2	cancel look

that's not an argument for giving it a new meaning!

i do sometimes wish for a way to express plumbing preferences
dynamically (e.g.  when starting a new copy of acme and wishing that
a) text files would open in the new copy and b) that other plumbing
would still work).

i wondered if perhaps it might make sense for an application to be
able to write a "priority" message to the plumbing "send" file -
plumbing messages would be then routed to that app in preference to
others (a plumbing message would be sent to only one app, rather than
fanning out as currently).

an application could send the "priority" message when its window was
raised.  this might provide behaviour that seemed reasonably natural.

what currently depends on the fan-out behaviour of plumbing?
(mail/fs, i guess, when messages are deleted, but that's very slow,
and works without plumbing anyway).

[9fans] Acme 3-1

[peter a. cejchan]

[-- Attachment #1: Type: text/plain, Size: 240 bytes --]

>  3-1 and 2-1 are already defined: they cancel button 3 and button 2 actions.
>  I would object to giving them another meaning.

>  -robI was always perceiving this like a bit wasting... wouldn't e.g., <esc> do? Just my opinion...++pac.

[-- Attachment #2: Type: text/html, Size: 618 bytes --]