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" ;
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
