[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: change proposal: nvi behavior for multi-width character
On 2017/11/07 3:41, Zhihao Yuan wrote:
(1) cursor position (nvi-cursor.patch)
This patch fixes cursor position when a multi-width character
does not fit in a line, and is located on the next line.
Can you describe the problem? Such as, is the cursor
currently misplaced (to the first line)?
When a double-width character does not fit in a line, and cursor
moves to that char by 'l' command, cursor is put on the 1st column
of that char, instead of the 2nd column. Then, if cursor moves
further from a double-width char in that line to a single-width one,
it is located on the 2nd column of the double-width char, instead of
the single-width char it moving toward.
Well, this is very complicated to explain in words. Can you please
test cursor motion with long lines which contain both single- and
double-width chars? Then, you will find something wrong. This problem
occurs not only with our nvi but also with your nvi2.
Also, when cursor indicates a multi-width character, put it on
the first column of the character, instead of the last column in
the current implementation. Otherwise, some terminal emulators
do not focus on the entire the character, the right-most column
As long as it doesn't break xterm.
Xterm focuses entire of a double-width char in both cases when cursor
is located on the left or right parts of that char.
(2) join command (nvi-join.patch)
This patch changes amount of white spaces inserted when lines
ending or beginning with multi-width characters are joined:
last char first char behavior
--- --- ---
multi-width multi-width nothing ins'ed
multi-width single-width 1 spc ins'ed
single-width multi-width 1 spc ins'ed
single-width single-width original
This is (basically) the same behavior to nvi-m17n. As a Japanese,
I feel this is a quite reasonable choice, and I guess it may be
for other non-European languages that leave no space between
It's true to CJK, but generally unsafe to make such
an assumption. Unless nvi2 (https://github.com/lichray/nvi2/)
can recognize Unicode codepoints, unlikely I can
take this change.
Do you know specific languages for which this makes things
inconvenient? I've also found that vi shipped with Solaris 10
(Version SVR4.0, Solaris 2.5.0) works similarly.
Main Index |
Thread Index |