[9fans] acme: some thoughts about design

[9fans] acme: some thoughts about design

[cej]

Hi, there!

First... I love Acme's design: chording, no-menus, etc... Nothing pops up, or falls at me, etc,etc...

The thing I don't like [very much] is taglines [as a place for commands]:
they waste screen space, show redundant info (same commands all the time)
couldn't we have a *single* command 'window'[==acme's frame, not rio window]
which would behave much like tagline: show current window's tag plus list of predefined/pasted commands
this would save space on screen, and [IMHO] would bemore elegant solution.
Another frame with [sorted] listing of window tags could ease navigation...

would love also to have acme as an optional universal glue for programs,
eg., Edit functions could move outside to [something like a commandline]Sam (enhanced sed) that would 
then use Acme's frame to display files...

Just a prick in a wasp's nest, I feel, but I would love 
to hear from you, even if [especially if] I missed the point! Don't shoot me.

No need to say that implementation is far, far beyond my skills :-(((


Sincerely yours,
++pac.

Re: [9fans] acme: some thoughts about design

[Matthias Teege]

> The thing I don't like [very much] is taglines [as a place for commands]:
> they waste screen space, show redundant info (same commands all the time)
> couldn't we have a *single* command 'window'[==acme's frame, not rio window]

A "command window" introduce a mode. It's better If you can
input a command in any place and execute it with a "execute key" like
acme does.

Matthias

Re: Re: [9fans] acme: some thoughts about design

[Russ Cox]

> > The thing I don't like [very much] is taglines [as a place for commands]:

if you don't want to use the taglines for commands, don't.

the taglines are necessary -- how else would you know
which file was which?  putting extra stuff in them that can
be ignored seems like an efficient use of space, not a waste.

Re: Re: [9fans] acme: some thoughts about design

[Matthias Teege]

On Sat May 29 15:09:51 GMT 2004, russcox@gmail.com wrote:
> the taglines are necessary -- how else would you know
> which file was which?  putting extra stuff in them that can

Don't use files ;-) It is a computer task to save my input but
I dont understand why I must tell the computer where to store.

If I have a usefull search interface I didnt need any filename or
directory structure. A user isn't interessted in filesystems.

Matthias

Re: Re: [9fans] acme: some thoughts about design

[9nut]

> Don't use files ;-) It is a computer task to save my input but
> I dont understand why I must tell the computer where to store.

Obviously a failure of vision on Rob's part!  ☺

It is an interesting thought that has come up before in various
contexts (look at the discussion about annotated filesystem in the
archives) but I don't see how this applies to Acme tags.

Put (was: [9fans] acme: some thoughts about design)

[FODEMESI Gergely]

On Sat, 29 May 2004 9nut@9netics.com wrote:

> > Don't use files ;-) It is a computer task to save my input but
> > I dont understand why I must tell the computer where to store.

Even in 1997 I met people who thought, that a user should not be obliged
to know when, where and what to save or that the concept of saving should
exist at all. (A real visionary might have thought about this probably
decades ago.)

> Obviously a failure of vision on Rob's part!

Put might have come from an idea like above (ie. "save" is not the best
way to express the real need), or it was just shorter than "Save".

 gergo

[9fans] acme: some thoughts about design

[cej]

>> Am I wrong?
>
>yes
>

why?

++pac.

Re: [9fans] acme: some thoughts about design

[boyd, rounin]

> Am I wrong?

yes

[9fans] acme: some thoughts about design

[cej]

> sounds like you want sam, but with acme style execute semantics.
No, I would love commandline-Sam using acme as interface. Am I wrong?

++pac.

Re: [9fans] acme: some thoughts about design

[boyd, rounin]

> What I'm thinking about is to simple type somthing like that:
> 
> "Dear customer, please pay < hoc -e '47.11 * 8.15' Euros, as
> fast as you can"

yeah, i had thought of that.  a1-2 chord would be nice.

Re: [9fans] acme: some thoughts about design

[Matthias Teege]

> i can't actually believe i'm about to say this, but:
> 
>     button-1 to select and hold down and button-2 chord to execute it.

;-)

What I'm thinking about is to simple type somthing like that:

"Dear customer, please pay < hoc -e '47.11 * 8.15' Euros, as
fast as you can"

and then mark '< hoc -e '47.11 * 8.15' and execute it in that
way, that the result replaces the selection. This is somthing
I can explain to a clerk.

send a command to the command window without
snarf/paste is a nice idea.

Matthias

Re: [9fans] acme: some thoughts about design

[boyd, rounin]

> Yes!, mark and execute in any sam window maybe with an
> execute key on keyboard.

i can't actually believe i'm about to say this, but:

    button-1 to select and hold down and button-2 chord to execute it.

i just thought of a problem,  but:

    button 2: does a !text send in the command window
    button 3: text send in command window

you want to be able to execute external as well as internal sam commands.

i was thinking of Put and w and am not sure what stdin/stdout should be for external commands.

this may require some thought.

Re: [9fans] acme: some thoughts about design

[Matthias Teege]

On Thu Jun  3 09:40:03 GMT 2004, boyd@insultant.net wrote:
> sounds like you want sam, but with acme style execute semantics.

Yes!, mark and execute in any sam window maybe with an
execute key on keyboard.
Matthias

Re: [9fans] acme: some thoughts about design

[boyd, rounin]

sounds like you want sam, but with acme style execute semantics.

[9fans] acme: some thoughts about design

[cej]

Thanks for reaction! Here is some explanations to what i meant...

/As I mentioned earlier, wouldn't a frame with [sorted] listing of
//window tags be a cleaner solution for navigation?

> i don't think so, no. how would it work? say i have some window
> containing this list. how's it sorted? lists are one-dimensional; my
> acme window arangement is not. while there's a trivial way to do
> the transformation (go down col 1, then col 2...), that becomes
> quite awkward, mentally.

why? the list will always take you to the correct place, won't it? otherwise, OK, one  could have such window for each column separately...

> but the biggest problem is that i want to look at a window and
> know which file i'm editing. 

cursor position | highlighting in "listing/tag window" not sufficient?
 
> i have a lot of acme windows most of

so do i ;-)

> the time, and counting down a list - even given some kind of
> markers denoting col boundaries - seems like it would take
> forever.

> and how would commands work? how do you tell Put which
> window to Put if they're all in a list?

use last "ordinary window" ... i think

> actually, this all sounds so bad to me i've concluded i don't
> really understand what you're suggesting.       care to sort me out?


best regards,
++pac.

    

Re: [9fans] acme: some thoughts about design

[a]

bugger. backspace didn't work out so well. huh.

Re: [9fans] acme: some thoughts about design

[a]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 919 bytes --]

//As I mentioned earlier, wouldn't a frame with [sorted] listing of
//window tags be a cleaner solution for navigation?

i don't think so, no. how would it work? say i have some window
containing this list. how's it sorted? lists are one-dimensional; my
acme window arangement is not. while there's a trivial way to do
the transformation (go down col 1, then col 2...), that becomes
quite awkward, mentally.

but the biggest problem is that i want to look at a window and
know which file i'm editing. i have a lot of acme windows most of
the time, and counting down a list - even given some kind of
markers denoting col boundaries - seems like it would take
forever.

and how would commands work? how do you tell Put which
window to Put if they're all in a list?

actually, this all sounds so bad to me i've concluded i don't
really understand what you're suggesting. â˜â˜care to sort me out?
 ï

[9fans] acme: some thoughts about design

[cej]

> > The thing I don't like [very much] is taglines [as a place for commands]:

> if you don't want to use the taglines for commands, don't.

> the taglines are necessary -- how else would you know
> which file was which?  putting extra stuff in them that can
> be ignored seems like an efficient use of space, not a waste.

As I mentioned earlier, wouldn't a frame with [sorted] listing of window
tags be a cleaner solution for navigation?

++pac.

Re: [9fans] acme: some thoughts about design

[Bruce Ellis]

directed, of course - that's what walk does.
but not necessarily acyclic, unless you have
a really uninteresting namespace.  that's why
cp -r is fraught with peril.

brucee

a@9srv.net wrote:
> i don't think anybody's seriously questioning the general
> utility of search capabilities. but the directed graph we
> currently have is very useful for all sorts of things. it
> is, for example, a very "natural" (but see later) layout
> for source trees and related documentation.

Re: [9fans] acme: some thoughts about design

[Bruce Ellis]

if you can't organize your data store then you probably
can't find a clean towel either.  the "drop it all on
the floor and expect the floor to be your friend" is
delusional.  and i still can't find the remote control.
just use the right tool for the job.  i didn't use
"diff" to compare the '96 and the '98.

http://www.pikeswines.com.au (nice fish)

and there is no need to clean a vacuum.

brucee

boyd, rounin wrote:

>>The problem is, if I want to associate a file with, say, "computers" and
>>"vaccuum cleaners", how do I layout my filesystem?
>
> organisation?  smarts?
>
> reverting to a serach engine is excessive.
>
> oh, i can't find my remote control ... hmm, better find it with a search engine.