I had originally argued strongly in favour of a BACKSPACE display
semantics that removes the character left of the cursor (let's call this
character L), and then moves the cursor wcwidth(L) character cells
to the left. This is by far the most sensible solution, because this
way, if you echo the keyboard output back into the display, pressing
backspace will give you exactly the same effect as you would expect
in an editor. The result would have been that in order for backspace
to work correctly with double-width (and combining) characters,
no changes will have to be made to the "tty cooked mode" editor in
the kernel that you get when you type text into stdin of any
Unix application.
Unfortunately, existing CJK implementation practice has messed up
this and has used backspace with a move-cursor-left-one-cell display
semantics. An argument that we have to stick in UTF-8 modes compatible
with this highly unfortunate and inconvenient CJK implementation
practice has been made, but I am still not convinced that
a) there really is such a backwards compatibility requirement
b) that the 1-cell-left semantics of backspace has any advantage
over the erase-1-character-left semantics whatsoever
I would say at least that the jury of what a backspace sent to a
UTF-8 terminal means is still out, and I'd advise authors of editors
not to send any backspace 0x08 characters to terminals. Please use
absolute or relative cursor positioning command sequences, which have
unambiguous semantics.
Markus
--
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
_______________________________________________
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
