[9fans] Acme tag scrolling/expansion

[9fans] Acme tag scrolling/expansion

[Paul Lalonde]

I have a working hack to acme that now lets me use the scroll wheel  
to expand the tag to multiple lines and collapse it again.  It seems  
to have no nasty interactions with the feature set I use.  Moving a  
window into a slot shorter than the tag shortens the tag to fit.  One  
line of the body tries to always show, except when windows are  
collapsed.  Dragging the tag text continues to work.

Does anyone else want it?  How do I submit the patch?  It's  
substantially smaller than I expected.

Should I also allow carriage returns in the tag text now?

One thing that it has caused me to observe in more detail is the  
layout bug where occasionally a window moved into a tight space  
wastes nearly a line of space and doesn't show the separator bar  
between it and the (unshown) body.  I'll pick at it this evening.

Paul

Re: [9fans] Acme tag scrolling/expansion

[Paul Lalonde]

And one more associated question: with longer tags, does it make  
sense to augment the dump format to save/restore tags with carriage  
returns?

Paul

On 7-Oct-05, at 8:34 PM, Paul Lalonde wrote:

> I have a working hack to acme that now lets me use the scroll wheel  
> to expand the tag to multiple lines and collapse it again.  It  
> seems to have no nasty interactions with the feature set I use.   
> Moving a window into a slot shorter than the tag shortens the tag  
> to fit.  One line of the body tries to always show, except when  
> windows are collapsed.  Dragging the tag text continues to work.
>
> Does anyone else want it?  How do I submit the patch?  It's  
> substantially smaller than I expected.
>
> Should I also allow carriage returns in the tag text now?
>
> One thing that it has caused me to observe in more detail is the  
> layout bug where occasionally a window moved into a tight space  
> wastes nearly a line of space and doesn't show the separator bar  
> between it and the (unshown) body.  I'll pick at it this evening.
>
> Paul
>
>

Re: [9fans] Acme tag scrolling/expansion

[Uriel]

On Fri, Oct 07, 2005 at 08:34:14PM -0700, Paul Lalonde wrote:
> I have a working hack to acme that now lets me use the scroll wheel  
> to expand the tag to multiple lines and collapse it again.  It seems  
> to have no nasty interactions with the feature set I use.  Moving a  
> window into a slot shorter than the tag shortens the tag to fit.  One  
> line of the body tries to always show, except when windows are  
> collapsed.  Dragging the tag text continues to work.
> 
> Does anyone else want it?  How do I submit the patch?  It's  
> substantially smaller than I expected.
Very cool; please, could you put it in sources/contrib? 

See: http://plan9.bell-labs.com/wiki/plan9/How_to_contribute/

(I think patch/saved overlaps too much with sources/contrib but either
should be OK)
 
> Should I also allow carriage returns in the tag text now?
This might be confusing because IMHO the main purpose for a multi line
tag is to accommodate longer paths and I don't see much use for explicit
new lines, also opens it to abuse as scratch space for big chunks of
stuff where a guide file should be used instead.

BTW, anyone knows if there is a way to snarf the path from a tag without
making the window 'dirty'? The usual mouse chording idiom that works for
the body seems to fail in the tag, and not even Undo helps after that.

uriel

Re: [9fans] Acme tag scrolling/expansion

[erik quanstrom]

this sounds great. often i can't Put files in the rh column
because Put gets cropped. even with acme covering the whole
width of the screen.

can this work with a 3-button mouse, too?

i disagree with Uriel. to paraphrase feynman, why should
you care how other people "abuse" acme.

it's hard to type "| awkscript <script>" in acme for this 
reason. it gets difficult to read even for a 3-line BEGIN/
for-each-line/END script.

alternatively, what if any line after the first scrolls and is executed 
on \n, like sam.

Uriel <uriell@binarydream.org> writes

| 
| On Fri, Oct 07, 2005 at 08:34:14PM -0700, Paul Lalonde wrote:
| > I have a working hack to acme that now lets me use the scroll wheel  
| > to expand the tag to multiple lines and collapse it again.  It seems  
| > to have no nasty interactions with the feature set I use.  Moving a  
| > window into a slot shorter than the tag shortens the tag to fit.  One  
| > line of the body tries to always show, except when windows are  
| > collapsed.  Dragging the tag text continues to work.
| > 
| > Does anyone else want it?  How do I submit the patch?  It's  
| > substantially smaller than I expected.
| Very cool; please, could you put it in sources/contrib? 
| 
| See: http://plan9.bell-labs.com/wiki/plan9/How_to_contribute/
| 
| (I think patch/saved overlaps too much with sources/contrib but either
| should be OK)
|  
| > Should I also allow carriage returns in the tag text now?
| This might be confusing because IMHO the main purpose for a multi line
| tag is to accommodate longer paths and I don't see much use for explicit
| new lines, also opens it to abuse as scratch space for big chunks of
| stuff where a guide file should be used instead.
| 
| BTW, anyone knows if there is a way to snarf the path from a tag without
| making the window 'dirty'? The usual mouse chording idiom that works for
| the body seems to fail in the tag, and not even Undo helps after that.
| 
| uriel

Re: [9fans] Acme tag scrolling/expansion

[Paul Lalonde]

On 8-Oct-05, at 5:46 AM, erik quanstrom wrote:
> can this work with a 3-button mouse, too?

I'd like it to, but I was unable to find an interaction that didn't  
break the current behaviour: the obvious thing is to manipulate the  
window button.  The second most obvious thing is to add TagExpand and  
TagReduce keywords, but that's a nasty cop-out - they are slow and  
awkward to use, which isn't bad for expanding, but is awful (I tried  
it) for making the tag smaller and reclaiming space.  Pretty much  
every gesture of 3 buttons is already used up.

Any suggestions?
>
> it's hard to type "| awkscript <script>" in acme for this
> reason. it gets difficult to read even for a 3-line BEGIN/
> for-each-line/END script.
For this I'm on uriel's side: I drop my scripts into the guide file  
and chord it to Send or to '|' in the appropriate window.

>
> alternatively, what if any line after the first scrolls and is  
> executed
> on \n, like sam.

Now that I won't implement - I think Rob would shoot me!

Paul

Re: [9fans] Acme tag scrolling/expansion

[Paul Lalonde]

On 8-Oct-05, at 2:06 AM, Uriel wrote
> Very cool; please, could you put it in sources/contrib?
> See: http://plan9.bell-labs.com/wiki/plan9/How_to_contribute/

Ah - I forgot to mention; ever since my shuttle turned into an  
unresponsive pile of silicon, I've been working in plan9port under OS  
X; patch doesn't exist there :-(

>> Should I also allow carriage returns in the tag text now?
>>
> This might be confusing because IMHO the main purpose for a multi line
> tag is to accommodate longer paths and I don't see much use for  
> explicit
> new lines, also opens it to abuse as scratch space for big chunks of
> stuff where a guide file should be used instead.
>

I used to think that too; but I found myself using the longer tag to  
hide less-frequent commands, especially with my debugger.  I know I  
can use "Send" to bridge from a guide file, but then I can't also  
chord in a parameter.  So, debugging with GDB in particular, I need  
break, display, print,  and so on, in my tag if I want to chord  
parameters.  Now I keep them tucked on the second line, and find  
myself opening my tag, chording the command, and closing it up, all  
in one "gesture".  Incidentally - you can already cut and paste  
newlines into the tag.

The hard part of multi-line tags is finding a backwards compatible  
format for the dump files.

Paul

Re: [9fans] Acme tag scrolling/expansion

[Uriel]

On Sat, Oct 08, 2005 at 06:19:38AM -0700, Paul Lalonde wrote:
> Ah - I forgot to mention; ever since my shuttle turned into an  
> unresponsive pile of silicon, I've been working in plan9port under OS  
> X; patch doesn't exist there :-(
Oh, well, that still should let you upload stuff to a sources/contrib
dir using 9p(1) or the python 9p client. Or you can drawterm to a 9grid
node.
 
> I used to think that too; but I found myself using the longer tag to  
> hide less-frequent commands, especially with my debugger.  I know I  
> can use "Send" to bridge from a guide file, but then I can't also  
> chord in a parameter.  So, debugging with GDB in particular, I need  
> break, display, print,  and so on, in my tag if I want to chord  
> parameters.  Now I keep them tucked on the second line, and find  
> myself opening my tag, chording the command, and closing it up, all  
> in one "gesture".  Incidentally - you can already cut and paste  
> newlines into the tag.
I agree, but still I'm unsure \n should be accepted in the tag just
making the text flow into the following line when it doesn't fit in the
current one should be enough... but I can't think of any strong reason
to avoid \n except simplicity as things like dump assume a single line.

It would be nice if there was a way to see that there are more lines
than what is visible... not sure how that can be done without an extra
scroll bar, but that I think would be a bad idea.

But I should try the patch before commenting so much :)

uriel

Re: [9fans] Acme tag scrolling/expansion

[Paul Lalonde]

On 8-Oct-05, at 6:33 AM, Uriel wrote:
>>
> I agree, but still I'm unsure \n should be accepted in the tag just
> making the text flow into the following line when it doesn't fit in  
> the
> current one should be enough... but I can't think of any strong reason
> to avoid \n except simplicity as things like dump assume a single  
> line.

I thought Dump did that too, but then I found the code that searches  
for the end of the tag or the first newline to cut it off at; my dump  
files are 100 backwards compatible, because they haven't changed!

> It would be nice if there was a way to see that there are more lines
> than what is visible... not sure how that can be done without an extra
> scroll bar, but that I think would be a bad idea.

Yes; I thought of overloading the window button, but again, that  
changes existing functionality/expectations.  It's pretty easy to  
scroll open the tag and check though.

Paul

Re: [9fans] Acme tag scrolling/expansion

[Paul Lalonde]

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

Uriel - regarding the patch, can you help me?
I've attached my tarball, it should just build.
Or, I could use a walk-through of using 9p from p9p to drop the file  
into contrib somewhere handy.
Thanks,
     Paul

[-- Attachment #2: paul_acme.tgz --]
[-- Type: application/octet-stream, Size: 84014 bytes --]

[-- Attachment #3: Type: text/plain, Size: 1642 bytes --]


On 8-Oct-05, at 6:33 AM, Uriel wrote:

> On Sat, Oct 08, 2005 at 06:19:38AM -0700, Paul Lalonde wrote:
>
>> Ah - I forgot to mention; ever since my shuttle turned into an
>> unresponsive pile of silicon, I've been working in plan9port under OS
>> X; patch doesn't exist there :-(
>>
> Oh, well, that still should let you upload stuff to a sources/contrib
> dir using 9p(1) or the python 9p client. Or you can drawterm to a  
> 9grid
> node.
>
>
>> I used to think that too; but I found myself using the longer tag to
>> hide less-frequent commands, especially with my debugger.  I know I
>> can use "Send" to bridge from a guide file, but then I can't also
>> chord in a parameter.  So, debugging with GDB in particular, I need
>> break, display, print,  and so on, in my tag if I want to chord
>> parameters.  Now I keep them tucked on the second line, and find
>> myself opening my tag, chording the command, and closing it up, all
>> in one "gesture".  Incidentally - you can already cut and paste
>> newlines into the tag.
>>
> I agree, but still I'm unsure \n should be accepted in the tag just
> making the text flow into the following line when it doesn't fit in  
> the
> current one should be enough... but I can't think of any strong reason
> to avoid \n except simplicity as things like dump assume a single  
> line.
>
> It would be nice if there was a way to see that there are more lines
> than what is visible... not sure how that can be done without an extra
> scroll bar, but that I think would be a bad idea.
>
> But I should try the patch before commenting so much :)
>
> uriel
>

Re: [9fans] Acme tag scrolling/expansion

[Paul Lalonde]

Crap - Sorry about the tarball - I have to learn to read the  
generated To line on reply vs reply-to-all, which in both cases  
defaults to the list, not the sender.

Paul

On 8-Oct-05, at 6:44 AM, Paul Lalonde wrote:

> Uriel - regarding the patch, can you help me?
> I've attached my tarball, it should just build.
> Or, I could use a walk-through of using 9p from p9p to drop the  
> file into contrib somewhere handy.
> Thanks,
>     Paul
>
> <paul_acme.tgz>
>
> On 8-Oct-05, at 6:33 AM, Uriel wrote:
>
>
>> On Sat, Oct 08, 2005 at 06:19:38AM -0700, Paul Lalonde wrote:
>>
>>
>>> Ah - I forgot to mention; ever since my shuttle turned into an
>>> unresponsive pile of silicon, I've been working in plan9port  
>>> under OS
>>> X; patch doesn't exist there :-(
>>>
>>>
>> Oh, well, that still should let you upload stuff to a sources/contrib
>> dir using 9p(1) or the python 9p client. Or you can drawterm to a  
>> 9grid
>> node.
>>
>>
>>
>>> I used to think that too; but I found myself using the longer tag to
>>> hide less-frequent commands, especially with my debugger.  I know I
>>> can use "Send" to bridge from a guide file, but then I can't also
>>> chord in a parameter.  So, debugging with GDB in particular, I need
>>> break, display, print,  and so on, in my tag if I want to chord
>>> parameters.  Now I keep them tucked on the second line, and find
>>> myself opening my tag, chording the command, and closing it up, all
>>> in one "gesture".  Incidentally - you can already cut and paste
>>> newlines into the tag.
>>>
>>>
>> I agree, but still I'm unsure \n should be accepted in the tag just
>> making the text flow into the following line when it doesn't fit  
>> in the
>> current one should be enough... but I can't think of any strong  
>> reason
>> to avoid \n except simplicity as things like dump assume a single  
>> line.
>>
>> It would be nice if there was a way to see that there are more lines
>> than what is visible... not sure how that can be done without an  
>> extra
>> scroll bar, but that I think would be a bad idea.
>>
>> But I should try the patch before commenting so much :)
>>
>> uriel
>>
>>
>
>

Re: [9fans] Acme tag scrolling/expansion

[Russ Cox]

There's no need to use Plan 9's patch(1) if you're working
on Unix.  You can just post or mail me the output of cvs diff -u.
I update the two in sync.

Also, for everyone, please don't knee-jerk drop new versions of
programs in sources/contrib as Uriel suggests.  If you make a
change that doesn't make it into the distribution (like pie menus
for rio) then fine, put it in contrib, but the first choice should be
to try to put it into the main distribution.

Thanks for the changes, Paul.  I've downloaded your tar ball
and will look through them.

Russ