[9fans] acme: some thoughts about design

[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]

> Am I wrong?

yes

[9fans] acme: some thoughts about design

[cej]

>> Am I wrong?
>
>yes
>

why?

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

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

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