Re: [9fans] acme: Edit/Font/Whatever in the tag line of every window
On Wed, Oct 8, 2008 at 9:45 AM, [EMAIL PROTECTED] wrote: Edit source, specifically /sys/src/cmd/acme/wind.c^winsettag1. snip Easy. Right up until you want to pull in upstream bugfixes. -sqweek
Re: [9fans] acme: Edit/Font/Whatever in the tag line of every window
Edit source, specifically /sys/src/cmd/acme/wind.c^winsettag1. snip Easy. Right up until you want to pull in upstream bugfixes. there have only been 5 changes to this file since 2002. diff isn't that hard to use, is it? - erik
Re: [9fans] acme and openning of , , '''chk' scripts (by rsc)
It's the plumber that decides. If you want those characters to be understood as file name characters in general - and you really don't, whatever you think now; consider what happens when you click on includefile.h - then change the plumbing rules. -rob On Wed, Oct 8, 2008 at 9:35 AM, Rudolf Sykora [EMAIL PROTECTED] wrote: Hello, is that an intention that acme does not recognize (or , not so sure about '''chk' ) to be a name of a valid file? At least and seems to me to be a valid file name, but clicking on it with button 3 in acme doesn't work --- file is not opened. Only explicit use of Get opens it. Thanks Ruda
Re: [9fans] acme and openning of , , '''chk' scripts (by rsc)
2008/10/8 Rob Pike [EMAIL PROTECTED] It's the plumber that decides. If you want those characters to be understood as file name characters in general - and you really don't, whatever you think now; consider what happens when you click on includefile.h - then change the plumbing rules. -rob Ok, I see. I read the manual page where the plumber is not mentioned (with the exception of 'Incl' command explanation. I thought that openning of files like could work at least when the whole of the name is swept (not just clicked) with button 3 (or first with button 1 and then clicked with 3). Ruda
Re: [9fans] acme and openning of , , '''chk' scripts (by rsc)
Insert a plumbing rule before the usual one that considers those characters part of filenames. Now you can plumb those scripts. When it fails to find the file named includefile.h (with the quotes as part of the filename), the plumber will move on to the next rule to check for includefile.h (no quotes). If there are problems with this approach then I haven't thought of them yet. grai
Re: [9fans] acme and openning of , , '''chk' scripts (by rsc)
2008/10/8 grai [EMAIL PROTECTED] Insert a plumbing rule before the usual one that considers those characters part of filenames. Now you can plumb those scripts. When it fails to find the file named includefile.h (with the quotes as part of the filename), the plumber will move on to the next rule to check for includefile.h (no quotes). If there are problems with this approach then I haven't thought of them yet. grai Thanks. Seems to work for me just OK. But maybe R. Pike has some counterexample... Ruda
Re: [9fans] acme: Edit/Font/Whatever in the tag line of every window
* Rudolf Sykora [EMAIL PROTECTED] [081007 14:02]: Hello, I am sorry for repeating my question, but noone has told me a solution and I have not found one for myself yet. Is there a way 'Edit' appeared in an acme tag line automatically (and for any new window)? Just add it in the source code. Kind regards, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen) pgpLDQJg3iae3.pgp Description: PGP signature
Re: [9fans] Acme questions
2008/9/10 Pietro Gagliardi [EMAIL PROTECTED]: On Sep 10, 2008, at 10:04 AM, hugo rivera wrote: I think double-clicking on the box to the left of the column information line thingy should do it. You mean the small purple box left of the column tag? probably I am doing something wrong, but when I double click it with any mouse button nothing happens. The best I can do is to click it then drag, and then leave a very small column, that is still using some space that I could use
Re: [9fans] Acme questions
On Thu, Sep 11, 2008 at 12:24 PM, sqweek [EMAIL PROTECTED] wrote: I think Pietro was making a suggestion, rather than explaining the current state of affairs. -sqweek i think your doubts benefit more than mine do.
Re: [9fans] Acme questions
2008/9/11 sqweek [EMAIL PROTECTED]: I think Pietro was making a suggestion, rather than explaining the current state of affairs. Oops. Well, I think is a good suggestion. :-)
Re: [9fans] Acme questions
2008/9/10 erik quanstrom [EMAIL PROTECTED]: no. and you're right, it would be a great feature but it would take quite a bit of rethinking. Sorry to hear that. not in the same way. you want to b3 :-/text/ (no quotes) in the tag. i'm sure there are other ways to do this. Great, thanks.
Re: [9fans] Acme questions
On Wed, Sep 10, 2008 at 7:48 PM, Pietro Gagliardi [EMAIL PROTECTED] wrote: I think double-clicking on the box to the left of the column information line thingy should do it. erm. you really could have tried this first. it doesn't take much, you know. for the record, i once had a go at implementing a hide command within acme, but i never got it stable enough to make available. it would be nice if more of the invariants in the acme code were documented. what i was really aiming towards was a way to allow acme to take up multiple rio windows - the idea would be to allow dragging of acme windows (or columns) between the acme rio windows. that way i could edit a load of related files in a single rio window but avoid cluttering things up when i want to digress into another project for a while (but also avoid the risk of simul-editing a file that you get when starting two acmes at the same time). it could also make the X command more useful than it currently is. in sam, the X command is great because you can edit many related files at the same time without necessarily cluttering the screen with them, but in acme it's a bit of a pain to do a global edit across (say) 100 source files. it's for this sort of thing i end up firing up sam -d, but it's so easy to waste time with files that i'm already editing, etc. at the acme data structure level, i reckoned it shouldn't be too hard - there are multiple Windows per Column, multiple Columns per Row, but there's only one Row. if there were multiple rio windows, each would be represented by a Row, but so far i've always got bogged down in the implementation details, time restrictions and my own brain limitations...
Re: [9fans] Acme without Flamage
[EMAIL PROTECTED] (sqweek) writes: On Thu, Aug 21, 2008 at 5:06 PM, Paul Donnelly [EMAIL PROTECTED] wrote: The bear is indentation, since to make it work out it's necessary to use a fixed-width font (something I'd rather not do) and adjust it by hand, which needs to happen more often and by greater degrees than in a language like C. The chief issues being: (list (list 'a 'b 'c) (list 1 2 3)) ; ^ ; These need to line up. ; These need to line up. ; V (let ((a 3) (b 4)) (+ a b)) ; ^ ; Should be two spaces or so. Huh. I always thought lisp had a couple of simple indentation rules, but after spending a little time on fmtsexp.c it has become apparent that the two spaces or so is a special case for let! Not sure I care to try and deal with such cases, but maybe it is still somewhat useful: http://sqweek.dnsdojo.org/plan9/fmtsexp.c -sqweek A fairly complete description of the rules is that forms line up with other forms at the same level of nesting (the binding forms in the LET or the arguments to LIST), but anything using BODY FOO in its lambda list (BODY collects trailing arguments into FOO) gets two-space indentation for the body. Indeed, this is the reason BODY exists. DEFMETHOD, though, needs to be specially recognized. LOOP has special needs. It's easier to indent with a program running in or communing with your Lisp, since there's no other way to know, short of reading every file in a project, whether a given macro uses BODY or not.
Re: [9fans] Acme without Flamage
On Thu, Aug 21, 2008 at 2:06 AM, Paul Donnelly [EMAIL PROTECTED]wrote: [EMAIL PROTECTED] (Gorka Guardiola) writes: On Wed, Aug 20, 2008 at 7:42 PM, David Leimbach [EMAIL PROTECTED] wrote: The only thing I'd miss in Acme vs emacs then, most likely, for lisp-like languages is paren-matching. And I'd miss it dearly. Double click on the paren selects the area enclosed by the matching paren. -- - curiosity sKilled the cat I don't know if posts to usenet (where I lurk this list) go through to the mailing list, but I've found Acme's paren matching to be sufficient. The bear is indentation, since to make it work out it's necessary to use a fixed-width font (something I'd rather not do) and adjust it by hand, which needs to happen more often and by greater degrees than in a language like C. The chief issues being: (list (list 'a 'b 'c) (list 1 2 3)) ; ^ ; These need to line up. ; These need to line up. ; V (let ((a 3) (b 4)) (+ a b)) ; ^ ; Should be two spaces or so. Yeah I guess I'm spoiled by the hotkey visual cues I get from Emacs when typing in code, that automatically show me the matching parens as I type. Perhaps I really don't *need* that. I'll try Plan 9 Port acme again for some Scheme Shell or something and see how it goes. (Emacs screws up Scheme Shell pretty badly, due to it's not accepting | characters in it's syntax definition, and as I said before, customizing emacs is not the same as me getting my work done) Dave
Re: [9fans] Acme without Flamage
One of the central tenets of Plan 9 is that everything is a file. So all file based activities are really, really easy. Most OO programming appears to follow a more DB oriented style (at least those with horrendous packaging/module mechanisms). That files are used to store your programs appears to be incidental. Therefore using a file oriented system when programming something like Java is painful, to say the least. Thus, acme is very probably not the right editor, unless you are in complete control of the code. But I would say the same holds for vi or emacs. Its just that those two have had a lot of additions poured into them that were inspired by the IDE world. Acme is supremely fabulous when you are in complete control or if you're programming using a language/environment where there are no strange rules on where your files have to go (the underlying OO DB, essentially). Initially, all that replacing vi/emacs with acme does is change your habits from keyboarding to mousing. All the pain you get from the bad code remains the same. Some of the IDE inspired features in vi/emacs may help lessen that pain slightly. But to get a more radical change, I'm afraid using a proper IDE is where it happens. Welcome to objects, good-bye files. Robby
Re: [9fans] Acme without Flamage
On Wed, Aug 20, 2008 at 11:12 PM, Wendell xe [EMAIL PROTECTED] wrote: My nutshell evaluation of Acme is that it is for systems-level coding in C on modest-sized projects. It seems very well designed for that purpose but quickly becomes awkward as you move away. It is definitely not suited to working with Java or Lisp, I used to feel much the same. Then I went back to coding java at work, fired up eclipse and was like ... where's my chording? :( :(. I had to whip up a plumbing rule so I could button 3 stack traces, but after that it was pretty comfortable. I keep switching between them now, generally using eclipse for browsing existing code or when using a lot of interfaces that I'm not familiar with (function completion = lazy way out), and acme when I want to view files side by side (eclipse's window management can bite me) or when eclipse annoys me too much with its highlights and tooltips and ctrl-w closing the window and automatic paren balancing and popups and underlines and FUCK OFF I KNOW THE FUNCTION NEEDS TO RETURN A BOOLEAN I'M HALFWAY THROUGH DEFINING IT GIVE ME A CHANCE JEEZE. ...which is somewhat often. or navigating large directories. Hm, why is acme particularly bad at this? I know I sigh every time I open my home directory in p9p acme because it's full to the brim with .foo .bar .qux .etc, the trick is just to know what you're looking for and type it in instead of trying to find it. Finally, I'm kind of surprised at the lack of interest in controlling fonts. My usual coding font is 12 pt. Dina or Terminus. But if my eyes are really tired, I might switch to 16 pt. Monaco. On the other hand, I sometimes use 8 pt. ProFont to better get an overview. I would think even Plan 9 hackers would appreciate being able to quickly shift around like that. That surprises me, to be honest. Most people I know find a font they like and stick with it. -sqweek
Re: [9fans] Acme without Flamage
On Wed, Aug 20, 2008 at 10:14 AM, sqweek [EMAIL PROTECTED] wrote: On Wed, Aug 20, 2008 at 11:12 PM, Wendell xe [EMAIL PROTECTED] wrote: My nutshell evaluation of Acme is that it is for systems-level coding in C on modest-sized projects. It seems very well designed for that purpose but quickly becomes awkward as you move away. It is definitely not suited to working with Java or Lisp, I used to feel much the same. Then I went back to coding java at work, fired up eclipse and was like ... where's my chording? :( :(. I had to whip up a plumbing rule so I could button 3 stack traces, but after that it was pretty comfortable. I keep switching between them now, generally using eclipse for browsing existing code or when using a lot of interfaces that I'm not familiar with (function completion = lazy way out), and acme when I want to view files side by side (eclipse's window management can bite me) or when eclipse annoys me too much with its highlights and tooltips and ctrl-w closing the window and automatic paren balancing and popups and underlines and FUCK OFF I KNOW THE FUNCTION NEEDS TO RETURN A BOOLEAN I'M HALFWAY THROUGH DEFINING IT GIVE ME A CHANCE JEEZE. ...which is somewhat often. Hmmm acme plumbing rule for lisp s-expressions... that'd be neat :-) As I've never written a plumbing rule in my life, I'm not sure how practical that is. (just haven't needed to do it...) The only thing I'd miss in Acme vs emacs then, most likely, for lisp-like languages is paren-matching. And I'd miss it dearly.
Re: [9fans] Acme without Flamage
On Wed, Aug 20, 2008 at 7:42 PM, David Leimbach [EMAIL PROTECTED] wrote: The only thing I'd miss in Acme vs emacs then, most likely, for lisp-like languages is paren-matching. And I'd miss it dearly. Double click on the paren selects the area enclosed by the matching paren. -- - curiosity sKilled the cat
Re: [9fans] Acme 2-1 chord behaves differently in external programs
Date: Sun Apr 27 19:42:09 EDT 2008 Is it intentional that the 2-1 chord behaves differently in external programs? For example, I have a guide file with 0,.d in it. If I 2-1 on Edit in a normal text window in Acme, it does what I'd expect: delete from start of file to current selection. In win, for example, it does nothing. I don't know that I'd call it intentional, but I doubt there is an easy fix. Acme client programs read from the event file to learn about mouse clicks. The ones they don't want to handle they write back, causing acme to handle them instead. Unfortunately, the write back interface is a little narrower than the read interface, and giving the argument from another window is one of the things that the write back can't accomodate. I'm not entirely sure I have the problem right here, since even replacing 'Edit' with 'echo' in the above scenario gives different behavior in regular windows vs. ones managed by external programs. They do still seem to function, though, and Edit works as expected if given the same argument normally. You don't say which external programs you are talking about, but in general each gets to assign meaning as it decides. I tried win and Mail. In win, echo with an external argument is like sending the text echo argument to the shell session, which is what I expected. In Mail, echo with an external argument runs the command echo, but without the argument. The difference is that win is handling the event itself, while Mail is bouncing it back to acme, losing the argument on the return trip. Russ
Re: [9fans] acme g/$/ funny
Edit ,x/.*/g/$/a/foo/ shouldn't this append foo after every line? Edit ,x/.*\n/g/\n/a/foo or Edit ,x/.*\n/g/$/a/foo where the latter gives a little hint about what the code might be doing
Re: [9fans] acme g/$/ funny
On Jul 17, 2008, at 6:03 AM, roger peppe wrote: Edit ,x/.*/g/$/a/foo/ shouldn't this append foo after every line? sam gives slightly different behaviour here (but still questionable) - it appends foo after every empty line. is this actually a bug, or have i misunderstood the way that '$' is meant to work? it does seem strange that in the following edit command, the guard never matches anything. Edit ,x/foo$/g/foo$/d pietro: You misunderstood how Pike regexps work ... That appends foo at the beginning of the next line. Try i/foo/. It always brings a smile to my face when you say things like that to people who have forgotten more about Plan 9 than you know. Thank you. rog: Edit ,x/.*/g/$/a/foo/ shouldn't this append foo after every line? I would have expected it to. pietro: The pattern /./ matches everything EXCEPT a newline, which would be matched with $. This is only half right. $ matches the empty string before a newline, not the newline itself. Don't believe me? Search for $$. The real issue here is that inside an x/.*/ loop, the text being considered has no newline, so the position at the end is no longer an empty string before a newline. (The newline is outside the search window.) One possible fix would be to redefine $ to match the end of the text as well as before newlines. I've sometimes wanted that in x loops that don't iterate over whole lines. That would have the unfortunate effect that if you had a four-line file like: abc\n def\n ghi\n jkl\n and you ran ,s/$/!/g you would then have the four-and-a-half line file: abc!\n def!\n ghi!\n jkl!\n ! so you'd have to then define that $ matches the end of the text unless the last character is a newline. This is the point where I usually give up and decide the current semantics are not worth fiddling with. Russ
Re: [9fans] acme scrollbar
[EMAIL PROTECTED] wrote: I dislike this idea. I think for most people, most of the time, the lines acme's working with will fit well within the width of a window. Yeah, I bet most of us have run into longer lines at times, but the interface is optimized for the common case. I wouldn't like to see that go. I'm frequently editing text that line wraps, I think your sample size is too small.
Re: [9fans] acme scrollbar
Hi, The scrollbar handle will always change it's length when moving through the files. Why isn't the length based on the total lines of the file? because that would require reading the whole file. - erik
Re: [9fans] acme scrollbar
That makes perfect sense, thanks. I love the way how the text at the clicked point will just move to the top. Perhaps I am being stupid, but why doesn't left-clicking cause that point to move down to the bottom? I never know where in the text I will end up when I'm scrolling upwards... -- hiro
Re: [9fans] acme scrollbar
The left click is basically doing the opposite of the right click - it moves the top line to the position of the click. That way a left click after a right click restores the previous view of the file. (There may be some small distortion due to lines longer than the width of the window but that doesn't really matter much.) * hiro ([EMAIL PROTECTED]) wrote: That makes perfect sense, thanks. I love the way how the text at the clicked point will just move to the top. Perhaps I am being stupid, but why doesn't left-clicking cause that point to move down to the bottom? I never know where in the text I will end up when I'm scrolling upwards... -- hiro
Re: [9fans] acme scrollbar
On 7/3/08, Martin Neubauer [EMAIL PROTECTED] wrote: The left click is basically doing the opposite of the right click - it moves the top line to the position of the click. That way a left click after a right click restores the previous view of the file. (There may be some small distortion due to lines longer than the width of the window but that doesn't really matter much.) Oh, i ruled this possibility out, because I didn't see any opposite behaviour. The long lines *do* matter much. This feature is useless when it's unreliable. What do you think about my idea of moving the line to the bottom instead?
Re: [9fans] acme scrollbar
What do you think about my idea of moving the line to the bottom instead? bad idea. to be honest i don't think the precise semantics of the scroll distance are very important, but it is important that left and right buttons are near inverses of each other, which means that when scrolling down, you can easily get back to the last view you saw without moving the mouse at all. the only change i think i'd make is that perhaps a right click should move the text just *below* the mouse position to the top. that way there wouldn't be a line's worth of zero-movement vertical space at the top of the window - which is particularly noticeable when the window is only a couple of lines long - in which case half the scrollbar doesn't react at all to left or right buttons currently. i'd implement this, but UI changes are controversial.
Re: [9fans] acme scrollbar
I dislike this idea. I think for most people, most of the time, the lines acme's working with will fit well within the width of a window. Yeah, I bet most of us have run into longer lines at times, but the interface is optimized for the common case. I wouldn't like to see that go. Having the undo (paralleling the undo of a 1-2, 1-3 chord) is very nice. The feature is certainly *not* useless for not being 100% reliable; what's it' off by, a line? Even that's a good enough job for your eye to find the line quick enough. Anthony ---BeginMessage--- On 7/3/08, Martin Neubauer [EMAIL PROTECTED] wrote: The left click is basically doing the opposite of the right click - it moves the top line to the position of the click. That way a left click after a right click restores the previous view of the file. (There may be some small distortion due to lines longer than the width of the window but that doesn't really matter much.) Oh, i ruled this possibility out, because I didn't see any opposite behaviour. The long lines *do* matter much. This feature is useless when it's unreliable. What do you think about my idea of moving the line to the bottom instead?---End Message---
Re: [9fans] acme scrollbar
On 7/3/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I dislike this idea. I think for most people, most of the time, the lines acme's working with will fit well within the width of a window. Yeah, I bet most of us have run into longer lines at times, but the interface is optimized for the common case. I wouldn't like to see that go. Having the undo (paralleling the undo of a 1-2, 1-3 chord) is very nice. The feature is certainly *not* useless for not being 100% reliable; what's it' off by, a line? Even that's a good enough job for your eye to find the line quick enough. Anthony Then probably my eyes are just too slow:( It really doesn't work with me. But probably I'm getting old?!
Re: [9fans] acme scrollbar
bad idea. to be honest i don't think the precise semantics of the scroll distance are very important, but it is important that left and right buttons are near inverses of each other, which means that when scrolling down, you can easily get back to the last view you saw without moving the mouse at all. Ok, a matter of taste. I always had the feeling that knowing exactly how far the window will move even before clicking is a really awesome feature.
Re: [9fans] Acme and unicode
Thanks a lot for your help, I am not sure what I was doing, but now everything is ok. Saludos Hugo
Re: [9fans] Acme and unicode
/lib/keyboard (or $PLAN9/lib/keyboard in your case). Hi guys: I hope this is not a very silly question, but I do not remember how to write unicode characters in Acme. I am using plan 9 from user space on FreeBSD. As far as I remember, it was something like Alt+X SOME_NUMBER, but this does not work. Saludos Hugo
Re: [9fans] Acme and unicode
http://swtch.com/plan9port/man/man7/keyboard.html On Wed, May 14, 2008 at 8:44 AM, hugo rivera [EMAIL PROTECTED] wrote: Hi guys: I hope this is not a very silly question, but I do not remember how to write unicode characters in Acme. I am using plan 9 from user space on FreeBSD. As far as I remember, it was something like Alt+X SOME_NUMBER, but this does not work. Saludos Hugo
Re: [9fans] Acme and unicode
keyboard(7) (keyboard(6) on plan 9). lots of shortcuts for specific things, but alt+x+1234 should produce glyphs. see also $PLAN9/lib/keyboard. ---BeginMessage--- Hi guys: I hope this is not a very silly question, but I do not remember how to write unicode characters in Acme. I am using plan 9 from user space on FreeBSD. As far as I remember, it was something like Alt+X SOME_NUMBER, but this does not work. Saludos Hugo---End Message---
Re: [9fans] Acme and unicode
It is perhaps worth pointing out that in Plan 9 (and in Plan 9 from User Space), Alt is just a=20 key like any other, not a modifier like Shift: you don't have to hold it down through the entire sequence. Thanks. I never noticed that. Since I need Alt-* a lot that is very helpful to know. -- John Stalker School of Mathematics Trinity College Dublin tel +353 1 896 1983 fax +353 1 896 2282
Re: [9fans] acme/sam linewrapping off
I understand that a speadsheet would solve the situation, but... Vim has always been sufficient for the task I described, having that one particular feature. If acme were able of the same, it would suffice me as well... Ruda On 24/03/2008, Robert Raschke [EMAIL PROTECTED] wrote: On 3/23/08, Rudolf Sykora [EMAIL PROTECTED] wrote: Another, even more compelling example is, when you want to look at some scientific data from some experiment. Maybe there's someone out there who has done a spreadsheet for Plan 9? I've never looked, are there any open source spreadsheets around that would lend themselves as a starting point? Robby
Re: [9fans] acme/sam linewrapping off
On Tue, Mar 25, 2008 at 3:33 PM, Rudolf Sykora [EMAIL PROTECTED] wrote: I understand that a speadsheet would solve the situation, but... Vim has always been sufficient for the task I described, having that one particular feature. If acme were able of the same, it would suffice me as well... Ruda Then [EMAIL PROTECTED] may be a good choice for your problem :-) stefanha to 9fans I am porting Vim and have made the first tarballs available. See http://vmsplice.net/9vim.html. If you are interested, please try it and let me know how it goes. It is usable, but do not rely on it yet. Things that currently do not work: * Shell execution (including :sh, !, :make, vimdiff, man page viewing, and suspend) * Mouse * Some unicode characters appear not to be fixed width * Startup is slow Stefan PS: Please avoid flamewar :). -- HZ
Re: [9fans] acme/sam linewrapping off
Well, [EMAIL PROTECTED] could definitely be a choice. But, doesn't it go against the basic philosophy ... ??! the response here usually follows these steps: (1) at most a mild suggestion to try using the system somewhat as intended (2) ignoring it this is in contrast to affirmative-action companies such as Apple, where a port of Vim to the iPhone and Touch would quickly be sensed by the caveman intrusion detection system, and Jobs would soon turn up to shame the ingrate in public, and rip the device from those cheating hands.
Re: [9fans] acme/sam linewrapping off
I haven't said that to use Vim is bad. Vim is my most favourite editor. I am myself happy to have Vim around in Plan9 (and am not alone for sure). Nonetheless, it's bad to not have an alternative which would follow the system's principles. Please read all I mentioned before. Vim does not follow those and is more and more distant from them (adding more and more features, becoming bloated). But now, there is not a Plan9-like editor suited for editing e.g. aforementioned files with several (real-number) fields (it simply gets wrapped and is unreadable then; using small fonts is not a proper solution since a too small font renders the file unreadable again). To be forced to use Vim right away is in my opinion sad. (Opposite to what you propose: you have to use Vim, you have no other way == you can't ignore it.) R On 25/03/2008, Charles Forsyth [EMAIL PROTECTED] wrote: Well, [EMAIL PROTECTED] could definitely be a choice. But, doesn't it go against the basic philosophy ... ??! the response here usually follows these steps: (1) at most a mild suggestion to try using the system somewhat as intended (2) ignoring it this is in contrast to affirmative-action companies such as Apple, where a port of Vim to the iPhone and Touch would quickly be sensed by the caveman intrusion detection system, and Jobs would soon turn up to shame the ingrate in public, and rip the device from those cheating hands.
Re: [9fans] acme/sam linewrapping off
Thanks, I'll read it and see if it can be of help R On 25/03/2008, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hola, i think you can take other approaches to solve your problems instead of using vim, or making acme behave like vim. see what others have done with acme: http://plan9.bell-labs.com/iwp9/papers/20.acme-trans.pdf may be that could give you more ideas, other perspectives, etc. about the tasks you do with those files how do you do them. may be if you want just compare some columns, or some rows, or look for a value, or change values, or whatever, you could write functions, regexp, etc which will make your tasks easier and more confortable to do. acme chording is really great when you get used to it. or even writting an acme client :), having a programmable environment gives you many options, original programmes could not imagine all the situations, but they were (and are) smart and included tools making you able to set the program to your needs. good luck :) gabi
Re: [9fans] acme/sam linewrapping off
have you considered using sam to break each line into multiple lines
and then rejoining. e.g. if you have a | separated record structure, you
could do something like:
,x/^.*\n/ {
s/\|/\n/g
s/\n/\n\n/
}
edit the fields, then rejoin before writing it back:
,y/\n\n/ x/\n/ c/|/
,x/\n\n/ c/\n/
fyi, i'm a casual sam user and there are probably better ways.
Re: [9fans] acme/sam linewrapping off
Is there any way how to sensibly edit a file with long lines (eg. a table with many fields, like /sys/lib/lp/devices) using acme/sam? What I miss is a way to not wrap long lines when I need to concentrate on the different fields and a whole single line is a true representative of an item (a printer). make the frame long enough to hold the whole line. for example in acme, use a single column display and a tiny font. you can get one by middle clicking on this Font /lib/font/bit/misc/ascii.5x7.font - erik
Re: [9fans] acme/sam linewrapping off
Thanks for the answer, although it did not please me... :( (In Vim, you only have to do :set nowrap and you are done... From time to time I find this rather useful.) Ruda it's unreasonable for the lp configuration file to need lines 200 characters long. i would think it would make more sense to talk about addressing lp's unreasonable requirments rather than complaining about acme's lack of features. - erik
