[9fans] acme multi-line tags (or maybe, efficient message stores)

[9fans] acme multi-line tags (or maybe, efficient message stores)

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

After the previous round of arguments about (native plan9) acme multi-line
window tags, did anyone ever come up with a patch that at least some
people were happy with?

--lyndon

P.S.  Is there any point to keeping mailing list archives any more?
With every messsage including the history of every discussion before
it, the concept of search is rendered obsolete.

P.P.S.  Of course, nobody gives a fsck about history any more.

P.P.P.S.  [P.S.] introduces an interesting idea.  Instead of storing
message text in a file, place each line of text into venti as a block,
then store the message as a list of venti hashes pointing to the
per-line content.  With all the duplicate included text, this should
be good for a 90% reduction in venti block storage for most mail
servers.  The 'included line' prefixes would have to be stored
seperately for this to work.

--lyndon

Re: [9fans] acme multi-line tags (or maybe, efficient message stores)

[Paul Lalonde]

Not as far as I know.  The grief comes with mixed fonts in the same column.  As the tag grows it breaks the column layout height.  You wind up with the choice of pushing the windows below around (ugly and unusable) or winding up with fractional lines in each window whose font is not the tag font.  The layout logic doesn't handle that gracefully as it only counts text lines, not pixel heights, and I didn't have the time to make that change.
That said, I find acme (and Edit in particular) damned near unusable without multi-line tags now.
Paul

Sent from my iPad

On 2011-10-09, at 12:48, "Lyndon Nerenberg (VE6BBM/VE7TFX)"  <lyndon@orthanc.ca> wrote:

> After the previous round of arguments about (native plan9) acme multi-line
> window tags, did anyone ever come up with a patch that at least some
> people were happy with?
> 
> --lyndon
> 
> P.S.  Is there any point to keeping mailing list archives any more?
> With every messsage including the history of every discussion before
> it, the concept of search is rendered obsolete.
> 
> P.P.S.  Of course, nobody gives a fsck about history any more.
> 
> P.P.P.S.  [P.S.] introduces an interesting idea.  Instead of storing
> message text in a file, place each line of text into venti as a block,
> then store the message as a list of venti hashes pointing to the
> per-line content.  With all the duplicate included text, this should
> be good for a 90% reduction in venti block storage for most mail
> servers.  The 'included line' prefixes would have to be stored
> seperately for this to work.
> 
> --lyndon
> 
> 

Re: [9fans] acme multi-line tags (or maybe, efficient message stores)

[erik quanstrom]

> didn't have the time to make that change.  That said, I find acme (and
> Edit in particular) damned near unusable without multi-line tags now.

do you have a particular usage senerio where this is most apparent?

- erik

Re: [9fans] acme multi-line tags (or maybe, efficient message stores)

[Paul Lalonde]

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

I often keep an Edit I'm refining in a separate tag line for easy selection.
But the real use was in keeping commands that need chorded parameters, so my
debugger sessions, for example, keep a line of "list print break" etc, so I
can chord in the parameter easily.  That way I don't have to construct the
breakpoint instruction in a scratch window, and I can keep enough of them
around to be useful - one tag line isn't big enough.

Paul

On Sun, Oct 9, 2011 at 8:21 PM, erik quanstrom <quanstro@quanstro.net>wrote:

> > didn't have the time to make that change.  That said, I find acme (and
> > Edit in particular) damned near unusable without multi-line tags now.
>
> do you have a particular usage senerio where this is most apparent?
>
> - erik
>
>


--
I'm migrating my email.  plalonde@telus.net will soon be disconnected.
 Please use paul.a.lalonde@gmail.com from now on.

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

Re: [9fans] acme multi-line tags (or maybe, efficient message stores)

[dexen deVries]

On Monday 10 of October 2011 05:21:22 erik quanstrom wrote:
> > didn't have the time to make that change.  That said, I find acme (and
> > Edit in particular) damned near unusable without multi-line tags now.
> 
> do you have a particular usage senerio where this is most apparent?

when editing multi-file project, my tags often holds bookmarks of 2...4 
locations in current file, usually as symbol matchign regex (:/SYMBOL_NAME),
plus scratchpad for 1...2 Edit commands.

using p9p acme.

-- 
dexen deVries

[[[↓][→]]]

http://xkcd.com/732/

Re: [9fans] acme multi-line tags (or maybe, efficient message stores)

[erik quanstrom]

On Mon Oct 10 00:08:51 EDT 2011, paul.a.lalonde@gmail.com wrote:

> I often keep an Edit I'm refining in a separate tag line for easy selection.
> But the real use was in keeping commands that need chorded parameters, so my
> debugger sessions, for example, keep a line of "list print break" etc, so I
> can chord in the parameter easily.  That way I don't have to construct the
> breakpoint instruction in a scratch window, and I can keep enough of them
> around to be useful - one tag line isn't big enough.

i'd rather have a window like win that would operate on the same principle
as the sam edit window.

unless i've misread the man page, i don't think this is possible with the current
command interface*.  you'd have to insert the text into the tag and then execute
it.  it'd be the opposite of screen scraping.  :-)

- erik

*i want to send "Edit X ,s:frobnatz:blatz:g." or "Edit b somefile",  how do i do that?

Re: [9fans] acme multi-line tags (or maybe, efficient message stores)

[Peter A. Cejchan]

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

> > i'd rather have a window like win that would operate on the same
> principle
> > as the sam edit window.
>
>
>
So do I.
++pac

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

Re: [9fans] acme multi-line tags (or maybe, efficient message stores)

[hiro]

I'd rather make sam a bit more powerful. Then I can use multiple
instances with my regular windows manager I can't find all the windows
in windows in windows on my current multi display setup, acme sucks
just like my web browser with it's tabs.
Also virtual machines and 9vx suck on multi display. Workarounds and
workarounds. Perhaps I can switch to notepad again some day...

Re: [9fans] acme multi-line tags (or maybe, efficient message stores)

[yy]

2011/10/11 hiro <23hiro@googlemail.com>:
> I'd rather make sam a bit more powerful. Then I can use multiple
> instances with my regular windows manager I can't find all the windows
> in windows in windows on my current multi display setup, acme sucks
> just like my web browser with it's tabs.
> Also virtual machines and 9vx suck on multi display. Workarounds and
> workarounds. Perhaps I can switch to notepad again some day...
>
>

That's the reason devwsys was written (soon to be renamed to wsys), see:
http://bytebucket.org/yiyus/devwsys-prev/wiki/devwsys.4.html

By the way, I patched acme so that | (the pipe symbol) can take an
argument using 2-1 chording, being equivalent to executing the
argument in that window. That way, I can have a window on top with the
commands I need and execute them in any window I want (the pipe symbol
is always visible in every acme window). It is a workaround, and does
not cover every situation (it does not let you to pass arguments to
those commands), but most of the time is good enough for me.


--
- yiyus || JGL .

Re: [9fans] acme multi-line tags (or maybe, efficient message stores)

[Peter A. Cejchan]

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

> >  By the way, I patched acme so that | (the pipe symbol) can take an
>

Is the patch on sources?
++pac

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

Re: [9fans] acme multi-line tags (or maybe, efficient message stores)

[yy]

2011/10/11 Peter A. Cejchan <tyapca7@gmail.com>:
>
>> >  By the way, I patched acme so that | (the pipe symbol) can take an
>
>
> Is the patch on sources?


Only an older version, where the argument is sent to the Edit command.
This is easier when you just want to Edit, but does not work with
commands. This is the original patch:
http://9fans.net/archive/2009/08/571

The acme version in contrib/yiyus includes this and some other
patches. I can update it later today. The newer version of the patch
involved writing an executeargs function but was not much more
complicated.


-- 
- yiyus || JGL .

Re: [9fans] acme multi-line tags (or maybe, efficient message stores)

[Peter A. Cejchan]

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

Thanks!

> The acme version in contrib/yiyus includes this and some other
>

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

Re: [9fans] acme multi-line tags (or maybe, efficient message stores)

[yy]

I have updated the acme version in contrib/yiyus. It includes some
other changes, but only this is relevant to this thread:

term% diff /sys/src/cmd/acme/exec.c exec.c
70a71
> 	{ L"e",		edit,		FALSE,	XXX,		XXX		},
148a150,156
> 	if(runestrncmp(r, L"|", 1) == 0 && q1-q0 == 1){
> 		Text tt;
> 		tt = *t;
> 		tt.file = argt->file;
> 		execute(&tt, argt->q0, argt->q1, FALSE, nil);
> 		return;
> 	}

The first change (new line 71) is to use a single "e" as an Edit
command, so you can always use the e in "Del" to do 2-1 chording with
Edit commands. The other change allows to execute any command using
2-1 chording on the pipe symbol.

There are many more tricks which you can use. For example, I have also
had scripts named as the letters of "Snarf" which I bind to bin before
running acme to build and test whatever I'm doing. The advantage of
this approach is that you don't even need to patch acme.

Yes, just hacky workarounds, but weren't multiline tags a hack too?


--
- yiyus || JGL .

Re: [9fans] acme multi-line tags (or maybe, efficient message stores)

[hiro]

> That's the reason devwsys was written (soon to be renamed to wsys), see:
> http://bytebucket.org/yiyus/devwsys-prev/wiki/devwsys.4.html

That's cool, I will try that out.