Re: change proposal: nvi behavior for multi-width character

[Rin Okuyama <rokuyama%rk.phys.keio.ac.jp@localhost>]

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
>     instead.
>
>
> 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
>     words.
>
>
> 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.

rin