Re: [9fans] acme multi-line tags (or maybe, efficient message stores)
i'd rather have a window like win that would operate on the same principle as the sam edit window. So do I. ++pac
Re: [9fans] acme multi-line tags (or maybe, efficient message stores)
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)
2011/10/11 hiro 23h...@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)
By the way, I patched acme so that | (the pipe symbol) can take an Is the patch on sources? ++pac
Re: [9fans] acme multi-line tags (or maybe, efficient message stores)
2011/10/11 Peter A. Cejchan tyap...@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)
Thanks! The acme version in contrib/yiyus includes this and some other
Re: [9fans] acme multi-line tags (or maybe, efficient message stores)
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.
Re: [9fans] acme multi-line tags (or maybe, efficient message stores)
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 { Le, 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)
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)
On Mon Oct 10 00:08:51 EDT 2011, paul.a.lalo...@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?
[9fans] acme multi-line tags (or maybe, efficient message stores)
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)
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) lyn...@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)
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)
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 quans...@quanstro.netwrote: 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. plalo...@telus.net will soon be disconnected. Please use paul.a.lalo...@gmail.com from now on.