Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: GVIM Editor

From: joel:neely:fedex at: 13-Mar-2002 6:16

Hi, Louis, Dr. Louis A. Turk wrote:
> Except for the paste problem, there is only one thing about vim > I have found so far that I don't like: when long lines are > wrapped vim skips the wrapped part of the line completely when > pressing j or k, and goes to the next line. >
I completely understand the (minor, I hope) frustration. When I have spent lots of time in a word processor (OBTW: When does a word processor do to words what a "food processor" does with food? When it's made by microSoft! ;-) and then get back to a real text editor, I have to take a moment to retrain my eyes. But let me see if I can offer a conceptual model that makes all of this make sense.
> Is it possible to change this? >
Not AFAIK. But there's a reason, having to do with the difference between word processing and text processing (as in editing source code for programming). Programmers most often use indentation to show nesting of structure in source code, which can easily cause a line to be arbitrarily long (especially if tabs are used for the indentation, but see below). Indenting a line more deeply doesn't change the fact that it is still one line, even if it ends up wider than the current display window and has to wrap. The command j moves you forward/down one line (as you already know) and k moves you backward/up one line. vi/vim defines "line" in terms of newline characters, not the display. If you resize your window and make it wider, then any "wrapped" lines should reflow (possibly not needing multiple rows on the display any more). The reason for sticking with the newline-based definition of line is that locations don't change depending on the current size of your editing window. (I don't recall whether Cygwin lets you resize the console window, but in general vi/vim makes no assumptions about fixed window sizes. If you run the windows binary of gvim, you can resize the window at will.) For example, if you type 123G you'll Go to the 123rd line of the file, which location won't change depending on your window width. Also, back in the day, it was common for people to use terminals (e.g. VT 100) with 80-character width, but print to hardcopy devices (e.g., line printers, DECwriters, etc.) with 132-character width. Therefore "line" was viewed as a logical artifact, not a physical one. When you turn on line number display in vi/vim, using :set number (or the abbreviation :set nu in carpel-tunnel-defense mode ;-) the lines are numbered using the same newline-based strategy, regardless of window width and any wrapping that may have occurred. Then if you print your file to a wider output device with a line-numbering utility (or stretch your window horizontally), the line numbering won't change. Finally, you can write macros to do useful things: for example, if you were turning a plain text file into an HTML table, with each line containing a single cell's data ... (and please, nobody point out that this could be done with a very small script... I'm just using a simple example that requires no further explanation! ;-) ... you could write a single-keystroke macro that does the following, starting on a line of text from the original data: - insert above the current line a new line containing only <td> - move down one line (back to the line you started from) - insert below the current line a new line containing only </td> - and move to the line following that insertion. This would leave you positioned on the next (logical) line from the original data following the one you started from. Thus you could hit the macro key several times in succession to enclose several items in <td>...</td> pairs. Of course, you would want this to work the same regardless of how wide or narrow your terminal was (i.e., whether or not display-wrapping had occurred), so basing lines on the places where newlines were found, rather than on temporary display wrapping, would give you more stable, predictable behavior. I hope this was of some help... I always find it easier to deal with something when I know *why* it was designed the way it was. Even if I disagree with the logic, at least I can understand it, expect what it will do, and use it successfully. -jn- -- ; sub REBOL {}; sub head ($) {@_[0]} REBOL [] # despam: func [e] [replace replace/all e ":" "." "#" "@"] ; sub despam {my ($e) = @_; $e =~ tr/:#/.@/; return "\n$e"} print head reverse despam "moc:xedef#yleen:leoj" ;