[9fans] Sam's protocol description?

[9fans] Sam's protocol description?

[David Tolpin]

Hi,

apologies if it is the wrong list to ask. Is protocol which sam and samterm
use to communicate described anywhere? If so, is it possible to get the
description?

David Tolpin

Re: [9fans] Sam's protocol description?

[rob pike, esq.]

i don't know of a formal description. the comments in mesg.h (i think)
explain the trickiest part.  the rest is just a thicket of application-specific
ad hoc details.  nothing thrilling, nothing very clean. it's the worst part
of the program.

but since you mention sam....

i'm sitting in new york this week, working on a server in california using
sam -r and it's just great.  sam was written in a 1200 baud age, sam -r
created for the cray (!), and yet it's the most responsive editor around if
there are a few thousand clicks between your terminal and your computer
(pardon me, your desktop and your server).

i never would have expected it to matter for so long.

-rob

Re: [9fans] Sam's protocol description?

[David Tolpin]

> but since you mention sam....

Rob,

sam is a very good thing, many thanks.

I am trying to do a simple thing, namely put a proxy between sam and samterm;
that would enable adding, for example, incremental XML validation without
touching the source code of either.

I am not sure if it is feasible, but if it is, then it is a very good extension
model, much better than scripting inside an editor.

David

Re: [9fans] Sam's protocol description?

[Scott Schwartz]

| i'm sitting in new york this week, working on a server in california using
| sam -r and it's just great.

Yep, that's what I've seen too.  My only wish is for better latency when
scrolling, perhaps by keeping more of the file in the terminal part.
Also it seems like scrolling backwards draws more network traffic;
read ahead caching?

The other cool thing is that sam can edit bigger files than anything
else I've tried.  But then the other day, under unix, open failed on a
>4GB file.  Before I blindly define _FILE_OFFSET_BITS=64, is the rest
of the program up to it?  I remember back on the sam-fans list it was
said that it worked on the Cray but not anywhere else.

Re: [9fans] Sam's protocol description?

[Scott Schwartz]

| anyone done sam -s host to run it across ssh?

Just bind ssh on top of rx.

Re: [9fans] Sam's protocol description?

[Lucio De Re]

On Sat, Jan 10, 2004 at 04:54:26PM +0100, boyd, rounin wrote:
>
> anyone done sam -s host to run it across ssh?

'S far as I know, the -r default is ssh these days.  But I tried
only a couple of times, then gave up because the remote portion
(on NetBSD) was acting stupid.  My fault of course, but I couldn't
be bothered to fix it.

++L

Re: [9fans] Sam's protocol description?

[Rob Pike]

the unix version i've been running - i've long since lost track
of which version is which - just uses ssh for remote sam.  so i say
  sam -r rob@server.com
that should be the default, but i think it's not in some versions.
but you've got the source.

-rob

Re: [9fans] Sam's protocol description?

[Rob Pike]

i would be surprised if sam could handle a file over 1G
(due to runes/bytes, that's 2Gbytes in the temp file) and
startled at 2G.  but i also think it would be easy to fix
all that.  my experience is underlying stuff tends to be
more of an obstacle.

-rob

Re: [9fans] Sam's protocol description?

[David Tolpin]

The only thing I missed in sam was autoindent; and it turned to be
30 min patch to samterm, if anyone is interested, the patch is at
http:///davidashen.net/misc/samterm-indent.diff, 1771 bytes long. Against
the unix version.

David Tolpin

Re: [9fans] Sam's protocol description?

[David Tolpin]

[ Charset ISO-8859-1 unsupported, converting... ]
> > The only thing I missed in sam was autoindent; and it turned to be
> > 30 min patch to samterm,
>
> hitting tab needs no code and it's a big key.
>

I am used to have two spaces indent, and wily has it (autoindent) anyway.

David

Re: [9fans] Sam's protocol description?

[David Tolpin]

> 2 spaces is just silly. just how long are _ your_ lines and indent level?
> must work great with a variable width font ...

2 spaces good. 8 spaces better.

Re: [9fans] Sam's protocol description?

[David Tolpin]

>  > 2 spaces good. 8 spaces better.
>
> s/8 spaces/tab/

You did not understand my intent.

autoindent is not a space smashing stuff. Autoindent is a feature which
places the cursor under the first non-space character of the previous line.
It works with any way of indents' styling; whether they are 8 or 2 or tabs
or spaces.

The 'space smashing stuff' you see in the patch is meant to decrease the traffic
between sam and samterm, while your proposal does the opposite. Hope this helps.

I find it convenient to have editor do it for me; samterm does a handful
of similar things, such as Ctrl-U, Ctrl-W and parentheses matching. I think
it is natural to have autoindent too.

Hope this helps.

David Tolpin
http://davidashen.net/

[9fans] acme

[vdharani]

hi,

like sam, i think rob mentioned once that the file access part of it will
be split so that acme can be used for working remotely with low bandwidth
usage. i am curious to know what is the current status of that feature.

thanks
dharani

Re: [9fans] Sam's protocol description?

[boyd, rounin]

anyone done sam -s host to run it across ssh?

Re: [9fans] acme

[rob pike, esq.]

> like sam, i think rob mentioned once that the file access part of it will
> be split so that acme can be used for working remotely with low bandwidth
> usage. i am curious to know what is the current status of that feature.

the current status is that nothing has been done.  i think the 'will be'
was more like 'wouldn't it be nice if'.

-rob

Re: [9fans] Sam's protocol description?

[rob pike, esq.]

> did you ever do the SHA1/MD5 style protocol for sam (like venti)?

i got some rudimentary stuff working in a test bed, not sam, but
then events intervened.  i doubt i'll get back to it.

-rob

Re: [9fans] Sam's protocol description?

[boyd, rounin]

> Just bind ssh on top of rx.

on p9, but it does give me an idea for lunix.

i was thinking lunix 'cos i have to do some driver
hacking and i only edit with sam ('cept when things
are VSF and then i'll use ed or cat).

Re: [9fans] Sam's protocol description?

[boyd, rounin]

>   sam -r rob@server.com
> that should be the default, but i think it's not in some versions.
> but you've got the source.

i do :)

did you ever do the SHA1/MD5 style protocol for sam (like venti)?

Re: [9fans] Sam's protocol description?

[boyd, rounin]

> The only thing I missed in sam was autoindent; and it turned to be
> 30 min patch to samterm,

hitting tab needs no code and it's a big key.

Re: [9fans] Sam's protocol description?

[boyd, rounin]

> I am used to have two spaces indent, and wily has it (autoindent) anyway.

so?  stick your tab smashing stuff (use x) in a file that B's itself into
sam.

that's what i used to do when forced to use 4 spaces and for dealing
with iso latin 1 (i ifdef'd off utf). this being on lunix.

2 spaces is just silly. just how long are _ your_ lines and indent level?
must work great with a variable width font ...

Re: [9fans] Sam's protocol description?

[boyd, rounin]

 > 2 spaces good. 8 spaces better.

s/8 spaces/tab/

Re: [9fans] Sam's protocol description?

[boyd, rounin]

> autoindent is not a space smashing stuff. Autoindent is a feature which
> places the cursor under the first non-space character of the previous
line.
> It works with any way of indents' styling; whether they are 8 or 2 or tabs
> or spaces.

yes i have 'set ai' in vi and hacked its god awful source.  so you could
say i know what it does.

Re: [9fans] acme

[Kenji Arisawa]

Thanks Ron,

Reboot dissolved the problem.
The acme problem was happened both on my file server and the terminal.
They had been running since the middle of this August.

Kenji Arisawa

On 2010/11/28, at 3:12, ron minnich wrote:

> On Sat, Nov 27, 2010 at 4:39 AM, Kenji Arisawa <arisawa@ar.aichi-u.ac.jp> wrote:
>> Hello 9fans,
>> 
>> After recent update, acme does not run normally.
>> When I execute acme command in a rio window then the window falls into blank with an error message something like
>> "qunlock ..."
>> Anyone experience similar phenomena?
> 
> I just did a pull and reboot in vmware and don't see this.
> 
> You could get two windows up, ratrace the rc in the other window, run
> acme in the other window, and see what ratrace tells you.
> 
> ron
> 

Re: [9fans] acme

[ron minnich]

On Sat, Nov 27, 2010 at 4:39 AM, Kenji Arisawa <arisawa@ar.aichi-u.ac.jp> wrote:
> Hello 9fans,
>
> After recent update, acme does not run normally.
> When I execute acme command in a rio window then the window falls into blank with an error message something like
> "qunlock ..."
> Anyone experience similar phenomena?

I just did a pull and reboot in vmware and don't see this.

You could get two windows up, ratrace the rc in the other window, run
acme in the other window, and see what ratrace tells you.

ron

[9fans] acme

[Kenji Arisawa]

Hello 9fans,

After recent update, acme does not run normally.
When I execute acme command in a rio window then the window falls into blank with an error message something like
"qunlock ..."
Anyone experience similar phenomena?

Kenji Arisawa

RE: [9fans] acme

[Russ Cox]

>> 1. acme -c1 /rc/bin/termrc /rc/bin/cpurc
>> 2. Highlight the second line of termrc (# terminal startup)
>> 3. Highlight the second line of cpurc (# cpu server start up)
>> 4. 2-click Snarf in the termrc tag line
>> 5. mouse-1-3 to paste into the termrc tag line
>>
>> You will see that Snarf in the termrc window grabbed the
>> highlighted text from the cpurc window.
>>
>> acme(1) is ambiguous -- it simply says:
>>           Snarf
>>                Place selected text in snarf buffer.
>>
>> But which selected text?  We seem to be assuming it means the selected
>> text in the window where you clicked Snarf.  Otherwise why have a
>> Snarf in every window's tag?  But in fact it seems to be the text
>> which was most recently selected, regardless of which window or tag
>> line it is in.
>
> Aha.  This bug was introduced in December 2005
> trying to fix a different bug.  I never copied the bug
> fix into the p9p acme so that's why I couldn't
> reproduce it in casual testing.
>
> Will have to think harder about this; thanks for
> the test case.

Fixed now on sources.  Should be a new binary later.

Russ

RE: [9fans] acme

[Richard Miller]

>> 'Snarf' in a frame's window DOES NOT snarf that frame's dot, the
>> last one dot persists.  Maybe the one that was gathered using
>> mouse-2-3??  I'll try later.
>
> if you can post a very detailed step-by-step account
> with every click and keystroke from starting acme
> that reproduces the problem, that would be helpful.

1. acme -c1 /rc/bin/termrc /rc/bin/cpurc
2. Highlight the second line of termrc (# terminal startup)
3. Highlight the second line of cpurc (# cpu server start up)
4. 2-click Snarf in the termrc tag line
5. mouse-1-3 to paste into the termrc tag line

You will see that Snarf in the termrc window grabbed the
highlighted text from the cpurc window.

acme(1) is ambiguous -- it simply says:
          Snarf
               Place selected text in snarf buffer.

But which selected text?  We seem to be assuming it means the selected
text in the window where you clicked Snarf.  Otherwise why have a
Snarf in every window's tag?  But in fact it seems to be the text
which was most recently selected, regardless of which window or tag
line it is in.

RE: [9fans] acme

[Russ Cox]

> 1. acme -c1 /rc/bin/termrc /rc/bin/cpurc
> 2. Highlight the second line of termrc (# terminal startup)
> 3. Highlight the second line of cpurc (# cpu server start up)
> 4. 2-click Snarf in the termrc tag line
> 5. mouse-1-3 to paste into the termrc tag line
>
> You will see that Snarf in the termrc window grabbed the
> highlighted text from the cpurc window.
>
> acme(1) is ambiguous -- it simply says:
>           Snarf
>                Place selected text in snarf buffer.
>
> But which selected text?  We seem to be assuming it means the selected
> text in the window where you clicked Snarf.  Otherwise why have a
> Snarf in every window's tag?  But in fact it seems to be the text
> which was most recently selected, regardless of which window or tag
> line it is in.

Aha.  This bug was introduced in December 2005
trying to fix a different bug.  I never copied the bug
fix into the p9p acme so that's why I couldn't
reproduce it in casual testing.

Will have to think harder about this; thanks for
the test case.

Russ

RE: [9fans] acme

[cej]

i have pulled -s acme binary last Friday, but the problem persists: 'Snarf' in a frame's window DOES NOT snarf that frame's dot, the last one dot persists. Maybe the one that was gathered using mouse-2-3?? I'll try later.

++pac.

-----Original Message-----
From: 9fans-bounces+cej=gli.cas.cz@cse.psu.edu [mailto:9fans-bounces+cej=gli.cas.cz@cse.psu.edu] On Behalf Of lucio@proxima.alt.za
Sent: Tuesday, June 05, 2007 8:00 PM
To: 9fans@cse.psu.edu
Subject: Re: [9fans] acme

> can't reproduce this.  if you click on Snarf in a window's tag
> then acme snarfs from that window.  if you click on Snarf in
> a column's tag then acme snarfs from that column's active 
> window (the last one with a mouse or keyboard action).

Maybe in more recent ACME than I'm using.  But I have also noted
inconsistencies.  Often after a selection in the tagline itself, even
though it is no longer active.  Mostly, I need to refresh the
selection before Snarf does the expected thing.  But I am being
intentionally vague because it's easy enough to get around it so I
never dug any deeper.

++L

RE: [9fans] acme

[Russ Cox]

> i have pulled -s acme binary last Friday, but the problem persists:
> 'Snarf' in a frame's window DOES NOT snarf that frame's dot, the
> last one dot persists.  Maybe the one that was gathered using
> mouse-2-3??  I'll try later.

if you can post a very detailed step-by-step account
with every click and keystroke from starting acme
that reproduces the problem, that would be helpful.

for example, if i run

	acme -c1 /rc/bin/termrc /rc/bin/cpurc

and then highlight the first line of termrc (#!/bin/rc)
with the mouse, and then 2-click Snarf in the termrc
tag and then mouse-1-3 to paste into the cpurc window,
the snarfed "#!/bin/rc" appears just fine.

russ

RE: [9fans] acme

[cej]

Ill try! ;-))

++pac.


-----Original Message-----
From: 9fans-bounces+cej=gli.cas.cz@cse.psu.edu [mailto:9fans-bounces+cej=gli.cas.cz@cse.psu.edu] On Behalf Of ron minnich
Sent: Tuesday, June 05, 2007 5:10 PM
To: Fans of the OS Plan 9 from Bell Labs
Subject: Re: [9fans] acme

On 6/5/07, Russ Cox <rsc@swtch.com> wrote:

> > Would welcome more keyboard actions, like line up/line down,
> > jumping to starts of words, to line-beginning/end.  I appreciate
> > very much moving left/right over characters, in case of hi-res
> > screen (laptop), where exact mouse positioning is tedious.
>
> shhh.  don't tell uriel.  ^A ^E for line-beginning/end.

and there's always smacme.

ron

Re: [9fans] acme

[ron minnich]

On 6/5/07, lucio@proxima.alt.za <lucio@proxima.alt.za> wrote:

> I thought it would make more sense to split the tagline (multi-line
> tagframe) at the vertical bar, structure the entries on the left to
> one or more per line while the left portion would be free flowing.  Am
> I being too ambitious or simply stupid?
>

just hack on it and see!

it's not that hard -- it's a very useful thing to read anyway, from a
pedagogical standpoint.

ron

Re: [9fans] acme

[lucio]

> can't reproduce this.  if you click on Snarf in a window's tag
> then acme snarfs from that window.  if you click on Snarf in
> a column's tag then acme snarfs from that column's active
> window (the last one with a mouse or keyboard action).

Maybe in more recent ACME than I'm using.  But I have also noted
inconsistencies.  Often after a selection in the tagline itself, even
though it is no longer active.  Mostly, I need to refresh the
selection before Snarf does the expected thing.  But I am being
intentionally vague because it's easy enough to get around it so I
never dug any deeper.

++L

Re: [9fans] acme

[lucio]

> the p9p acme just shows the entire tagline as multiple lines if
> you type down-arrow, but there are window layout problems.
> i should really track them down.  that might fix the "around a corner"
> thing.

I thought it would make more sense to split the tagline (multi-line
tagframe) at the vertical bar, structure the entries on the left to
one or more per line while the left portion would be free flowing.  Am
I being too ambitious or simply stupid?

++L

Re: [9fans] acme

[ron minnich]

On 6/5/07, Russ Cox <rsc@swtch.com> wrote:

> > Would welcome more keyboard actions, like line up/line down,
> > jumping to starts of words, to line-beginning/end.  I appreciate
> > very much moving left/right over characters, in case of hi-res
> > screen (laptop), where exact mouse positioning is tedious.
>
> shhh.  don't tell uriel.  ^A ^E for line-beginning/end.

and there's always smacme.

ron

Re: [9fans] acme

[Russ Cox]

> I won't like to start a flame-war (possibly), however, I decided
> to make some comments on my favourite, and *BELOVED* UI, The
> Acme:

perhaps you could line-wrap your emails.

> Cut+Paste (or, mouse-2-3) on a tagline leaves the frame in a
> 'dirty' state: this bug has not been present in earlier (abou 2
> years ago, or so) versions of Acme.

can't reproduce this.  i remember fixing it long ago.

> Mouse-3 on highlighted path in a tagline doesn't move cursor to
> that frame in case it is visible, unlike when done in regular
> frame; strangely, it works when that frame is NOT visible, for
> both tagline, and regular frame.  And, it also works from tagline
> when the path is mouse-3-dragged, so definitely a bug.

can't reproduce this.

> Mouse-3 on filename opens the frame 'around a corner' if the
> current layout is so that frames are tightly stacked at the
> bottom (frame is quasi-maximized).  Popping up the frame may
> need clicking several times.

yes, this is annoying.  i'd like to fix this but only so much time.

> Scrolling the tagline using downarrow/uparrow does not work;
> scroling with dragging mouse-1 is too fast even on my 'primeval'
> S3 card.

the p9p acme just shows the entire tagline as multiple lines if
you type down-arrow, but there are window layout problems.
i should really track them down.  that might fix the "around a corner"
thing.

> 'Del' has no special position on the tagline, thus closing
> multiple frames sucks.  Could we have 'Del' on far left, preceding
> filepath???  Or , perhaps, e.g., mouse1+3, or Alt+mouse-1, or
> ...., over the frame 'handle' would do?  Are you strictly against
> combinations of keyboard with mouse??  I personally perceive it
> O.K., however, i'm not disabled.  Oberon UI, which, I think,
> initially inspired Acme, is much more exhaustive considering
> possible keyboard-mouse interactions (well, I mean classic Native
> Oberon UI, not the Gadgets/Bluebottle, which, IMHO, downgraded
> the UI to 'standard windozish' one)

if you want to do some repetitive task, write a program.
here's a little shell script i use called Clean.  you can execute
    Clean /sys/src/cmd/acme
and it will delete all the windows with that in their tags.

	#!/bin/rc

	rfork e

	if(~ $#* 0)
		pattern=.
	if not
		pattern=$1

	cd /mnt/acme
	for (i in [0-9]*){
		if(test -d $i){
			tag=`{cat $i/tag}
			tagline = $"tag
			file=$tag(1)

			# must match our pattern if given, must be a clean window,
			# and must not be an Errors window, mail, or win.

			if(! ~ $file */ *+Errors* */-* */mail/* && ! ~ $tagline *Put*
			&& echo $file | grep $pattern >/dev/null >[2]/dev/null)
				echo del >$i/ctl
		}
	}
	status=''

now that there is an edit command you can also do
Edit X./sys/src/cmd/acme.D or Edit Y/'/D

> A command that will switch fullpath/basename from the tagline
> might be useful for orientation (well, I can do 'Sort' often).

Sort is probably better than this.

> When many frames are open in a column, moving cursor to the
> frames 'behind the horizon' requires multiple mouse-3 clicks,
> until it eventually comes up.

same problem as above.

> There is some 'dead space' at the bottom of the Acme's window,
> where nothing is drawn, and nothing happens.  Bug??

no.  that space is not big enough to hold an entire line
of text, so it holds nothing.

> No way to kill a busy (non-responding) frame??

kill the underlying program that is not responding.  slay Mail | rc
for example.  or kill the hung file server that acme is talking to
for that window.

> No way to hide columns except the current one (==maximize frame
> | column horizontally).  We could easily use columns 'handle
> square' (violet one at the upper left corner) exactly in the way
> the frame's handle is used: mouse-3 == maximize, mouse-2 == show
> condensed columns, mouse-1 == increment column width.

i suppose we could.  i think most acme users just don't move
their columns very much.

> Maybe, double-click mouse-2 on 'Del' could close a dirty frame
> immediatelly, without asking (and w/o saving).

interesting.

> GRRRRRRR.....  : the dot is not persistent: if I have selected
> areas of text in different frames, returning to the frame and
> Snarf'ing does *NOT* pick up the relevant 'dot' (just the one
> last selected).....  this is *VERY* annoying, indeed.

can't reproduce this.  if you click on Snarf in a window's tag
then acme snarfs from that window.  if you click on Snarf in
a column's tag then acme snarfs from that column's active
window (the last one with a mouse or keyboard action).

> And, the frames should behave the same way, shouldn't they??  I
> spot different behavior of frames showing dirs from those showing
> files.  yes, and I don't even mention that the tagline is a very
> special frame of its own...

sure they behave differently.  one presents directory contents
so they're never going to be identical.  if you were more specific
about what you didn't like you might get a more useful response.

> Would welcome more keyboard actions, like line up/line down,
> jumping to starts of words, to line-beginning/end.  I appreciate
> very much moving left/right over characters, in case of hi-res
> screen (laptop), where exact mouse positioning is tedious.

shhh.  don't tell uriel.  ^A ^E for line-beginning/end.

> Personal remark: I miss very much something like a command window
> in 'Sam'...  tagline is both very restrictive, and redundant,
> IMHO.  Frame-specific commands could just remember the last-touched
> frame (or two, if a parameter is to be sent) to solve the problem
> of frame-owned taglines (Am I right??  Dunno...).

the bigger tags in the p9p acme solve this a different
way that seems to fit better.  if you had a separate ~~sam~~
window you couldn't make each command in it frame-specific
because the commands are just text -- there's no underlying
data structure sitting underneath.  you can always open a
new nameless window and fill it with Edit commands that
specifically name a window:

	Edit X/name.c/ ,s/foo/bar/g

or even just X-less commands

	,s/foo/bar/g

that you highlight and then 3-2 click Edit in the window
where you want to apply them.

russ

Re: [9fans] acme

[erik quanstrom]

> i suppose the trick is find it on your keyboard, in the spanish
> keyboard is ctrl+ç, and under drawterm X11 i need to type ctrl+altgr+1
> 
> try to find \ whithout configure your local map, then use that key to exit con.

this doesn't seem to be a universal thing.  on my machine drawterm/X11 maps
ctrl+\ maps to ctrl+\.  i haven't set up any X11 keyboard mappings.

- erik

Re: [9fans] acme

[Gabriel Diaz]

> from the man page : )
>
> The control–\ character is a local escape. It prompts with >>>.
> Legitimate responses to the prompt are
> ...
> q     Exit.

i suppose the trick is find it on your keyboard, in the spanish
keyboard is ctrl+ç, and under drawterm X11 i need to type ctrl+altgr+1

try to find \ whithout configure your local map, then use that key to exit con.

slds.

gabi

Re: [9fans] acme

[erik quanstrom]

which version of acme are you using?  i can't replicate all of the behaviors
you report with plan 9 acme.  in particular paths in the tagline work for me
and the dot is persistant.

- erik

Re: [9fans] acme

[Federico Benavento]

hola 9amigo,

>  ===
>  is this a legal declaration?:
>  struct color      convert_position_to_color(struct
> position pos);
>   Or should I do typedef first?
>
>  pcc complains about multiple declaration when function is defined.
>

I guess you're not including the right header or declaring some struct before
declaring the function, which looks fine, although I preffer typdefs

>  =====
>  how do I quit 'con'  ??
>
>

from the man page : )

The control–\ character is a local escape. It prompts with >>>.
Legitimate responses to the prompt are
...
q     Exit.
...

-- 
Federico G. Benavento

[9fans] acme

[cej]

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

Hi all 9friends,

I won't like to start a flame-war (possibly), however,  I decided to make some comments on my favourite, and *BELOVED* UI, The Acme:

Cut+Paste (or, mouse-2-3) on a tagline leaves the frame in a 'dirty' state: this bug has not been present in earlier (abou 2 years ago, or so) versions of Acme.


Mouse-3 on highlighted path in a tagline doesn't move cursor to that frame in case it is visible, unlike when done in regular frame; strangely, it works when that frame is NOT visible, for both tagline, and regular frame. And, it also works from tagline when the path is mouse-3-dragged, so definitely a bug.

Mouse-3 on filename opens the frame 'around a corner' if the current layout is so that frames are tightly stacked at the bottom (frame is quasi-maximized). Popping up the frame may need clicking several times.

Scrolling the tagline using downarrow/uparrow does not work; scroling with dragging mouse-1 is too fast even on my 'primeval' S3 card.

'Del' has no special position on the tagline, thus closing multiple frames sucks. Could we have 'Del'  on far left, preceding filepath??? Or , perhaps, e.g., mouse1+3, or Alt+mouse-1, or ...., over the frame 'handle' would do? Are you strictly against combinations of keyboard with mouse?? I personally perceive it O.K., however, i'm not disabled. Oberon UI, which, I think, initially inspired Acme, is much more exhaustive considering possible keyboard-mouse interactions (well, I mean classic Native Oberon UI, not the Gadgets/Bluebottle, which, IMHO, downgraded the UI to 'standard windozish' one)

A command that will switch fullpath/basename from the tagline might be useful for orientation (well, I can do 'Sort' often).

When many frames are open in a column, moving cursor to the frames 'behind the horizon' requires multiple mouse-3 clicks, until it eventually comes up.

There is some 'dead space' at the bottom of the Acme's window, where nothing is drawn, and nothing happens. Bug??

No way to kill a busy (non-responding) frame??

No way to hide columns except the current one (==maximize frame | column horizontally). We could easily use columns 'handle square' (violet one at the upper left corner) exactly in the way the frame's handle is used: mouse-3 == maximize, mouse-2 == show condensed columns, mouse-1 == increment column width.

Maybe, double-click mouse-2 on 'Del' could close a dirty frame immediatelly, without asking (and w/o saving).

GRRRRRRR..... : the dot is not persistent: if I have selected areas of text in different frames, returning to the frame and Snarf'ing does *NOT* pick up the relevant 'dot' (just the one last selected)..... this is *VERY* annoying, indeed.

And, the frames should behave the same way, shouldn't they?? I spot different behavior of frames showing dirs from those showing files. yes, and I don't even mention that the tagline is a very special frame of its own...

Would welcome more keyboard actions, like line up/line down, jumping to starts of words, to line-beginning/end. I appreciate very much moving left/right over characters, in case of hi-res screen (laptop), where exact mouse positioning is tedious.

Personal remark:
I miss very much something like a command window in 'Sam'... tagline is both very restrictive, and redundant, IMHO. Frame-specific commands could just remember  the last-touched frame (or two, if a parameter is to be sent) to solve the problem of frame-owned taglines (Am I right?? Dunno...).

End remark: I'm (probably) capable of some ideas, but not so of coding them. Please, excuse me. I'm an ethernal pupil.


===
is this a legal declaration?:
struct color      convert_position_to_color(struct position pos);
 Or should I do typedef first?

pcc complains about multiple declaration when function is defined.

======
to Andrey Mirtchowski:

If you had an [awk | rc] script to make thumbnails album in [PostScript | troff], I would be much interested. I don't care about html ;-))

=====
how do I quit 'con'  ??


=====
 

 


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

[9fans] acme

[rob pike, esq.]

Nasty bug causes
	Edit ,|nonexistentcommand
(or ,> or ,<) to lock up acme.  Easy fix.  Add these two lines
to the failure case of runwaittask():


/sys/src/cmd/acme/exec.c:1287 a exec.c:1288,1289
	else{
> 		if(c->iseditcmd)
> 			sendul(cedit, 0);
		free(c->name);
		free(c->text);
		free(c);
	}

Re: [9fans] Acme

[forsyth]

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

as rob says, you can control that effect, but it's perhaps worth noting that
with acme, because each frame carries its own directory with it, it's quite
common to have one big acme window set up once and edit everything from everywhere in it.
remake in any given directory by typing mk (once for all) in the tag of that frame
and clicking it with button 2.  when using rio windows as well, perhaps
to develop or debug a graphics application, files are sent for editing using the B
command (it's documented with sam(1) but because it uses the plumber, it
will send files to acme too if that's what you're using).

using it that way, i find that acme thoughtfully keeps track of all the things i am doing,
at various stages of interruption; on the other hand, it conveniently offers email in
the same environment, which can lead to further interruption (but it's still highly
convenient).


[-- Attachment #2: Type: message/rfc822, Size: 2352 bytes --]

To: <9fans@cse.psu.edu>
Subject: [9fans] Acme
Date: Tue, 19 Mar 2002 22:26:16 -0500
Message-ID: <000701c1cfbe$ff2c1720$aa952f18@jjmj301>

Hi,

I have noticed a problem in Acme.

I open two windows in rio. Then I start Acme in both the windows. Now, if I
open a file in one Acme instance, it opens the file in both the instances.

Is this a problem? Or am I missing something?

Thanks
dharani

Re: [9fans] Acme

[rob pike]

> I open two windows in rio. Then I start Acme in both the windows. Now, if I
> open a file in one Acme instance, it opens the file in both the instances.
> 
> Is this a problem? Or am I missing something?

Both Acmes are using the same plumber, so both receive the plumbing messages
Acme uses to search for things, and so both open the file.  If you don't want this,
there are many ways to deal with it.  The simplest might be to run the plumber
again, before acme, in the window you want to isolate:

	plumber
	acme

-rob

[9fans] Acme

[Tharaneedharan Vilwanathan]

Hi,

I have noticed a problem in Acme.

I open two windows in rio. Then I start Acme in both the windows. Now, if I
open a file in one Acme instance, it opens the file in both the instances.

Is this a problem? Or am I missing something?

Thanks
dharani