Re: [I18n]Re: [li18nux:1094] BACKSPACE behavior
Hi, At Wed, 2 Oct 2002 23:21:12 +0700, Theppitak Karoonboonyanan wrote: This may look awkward for the definition of 0x08 to move back inconsistently. But the situation can still be defined more gracefully if we allow the cursor to stop at each combining character, and moving left through a combined cell means moving through the combining characters one by one to the base character before advancing to previous cell. This implementation has been adopted by some locally-patched terminal emulator, such as xiterm+thai (available in debian sid). This idea is inconsistent with already existing softwares, where cursor moves one column (half character) even when it moves across doublewidth characters. There are also existing softwares which treats combining characters in this way (against your idea). I think your idea can be implemented to be enabled only when some option is specified. However, in future, I think one internationalized software should work well for all people in the world. To achieve this, terminal's behavior must be defined consistently. At least, definition of 0x08 must not be modified. In this case, new control codes would be added for character-element-based movement of your idea. --- Tomohiro KUBOTA [EMAIL PROTECTED] http://www.debian.or.jp/~kubota/ Introduction to I18N http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Re: [li18nux:1094] BACKSPACE behavior
On Thu, Oct 03, 2002 at 06:11:47PM +0900, Tomohiro KUBOTA wrote: At Wed, 2 Oct 2002 23:21:12 +0700, Theppitak Karoonboonyanan wrote: This may look awkward for the definition of 0x08 to move back inconsistently. But the situation can still be defined more gracefully if we allow the cursor to stop at each combining character, and moving left through a combined cell means moving through the combining characters one by one to the base character before advancing to previous cell. This implementation has been adopted by some locally-patched terminal emulator, such as xiterm+thai (available in debian sid). This idea is inconsistent with already existing softwares, where cursor moves one column (half character) even when it moves across doublewidth characters. There are also existing softwares which treats combining characters in this way (against your idea). I think your idea can be implemented to be enabled only when some option is specified. However, in future, I think one internationalized software should work well for all people in the world. To achieve this, terminal's behavior must be defined consistently. At least, definition of 0x08 must not be modified. In this case, new control codes would be added for character-element-based movement of your idea. Yes, you're right. These new control codes will not compromise any requirement as in what I proposed. Another possibility is that bash or any other shells be modified so that they don't emit 0x08 in case of backspace upon combined cells. Hmm.. This may be more sound. -Thep. -- Theppitak Karoonboonyanan Thai Linux Working Group (TLWG) http://linux.thai.net/thep/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Re: [li18nux:1094] BACKSPACE behavior
Hi, At Thu, 3 Oct 2002 16:53:02 +0700, Theppitak Karoonboonyanan wrote: Another possibility is that bash or any other shells be modified so that they don't emit 0x08 in case of backspace upon combined cells. Hmm.. This may be more sound. In *any* cases, bash (or any shells) don't emit 0x08 alone in case of BACKSPACE key push. For example, after normal (singlewidth) character, 0x08 0x20 0x08 is emitted. Thus, you don't need to regard deviation from BACKSPACE key equal 0x08 as something bad. To erase last combining character element, i.e., to implement your favorite behavior, the shell must emit 0x08 base character code. If the previous combined character consists of one base character and multiple combining characters, combining character codes (without the last combining character) must be emitted additionally. The shell must erase last one character from its internal buffer. Of course it may one byte (for example, TIS-620) or more (for example, UTF-8). On the contrary, for BACKSPACE key to erase whole combined character, the shell must emit 0x08 0x20 0x08 and erase whole combined character from the internal buffer. I think both behaviors can be possible technically. I don't have any opinion on which behavior should be implemented (or should be default if both will be implemented). I think it is a good idea to consult people who wrote bash-2.05b i18n patch about Thai people's expectation of BACKSPACE key behavior. --- Tomohiro KUBOTA [EMAIL PROTECTED] http://www.debian.or.jp/~kubota/ Introduction to I18N http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n]Keymap writing
Hello, I just undertook the crazy task of trying to write an X keymap for a french variant of the Dvorak keyboard ( where the letters are laid out according to their usage in the french language ) : http://www.algo.be/ergo/dvorak-fr.html My first attempt consisted in modifying the output of Xmodmap. However, this is probably not the Right Thing To Do if I want my driver distributed. I guess I would have to write an XKB keymap for that purpose. Moreover, the keymap requires the use of a modified dead key, eg: dead_grave and d are supposed to produce a dollar sign ($), which is not a common behaviour. With all my good will, I could not find anywhere where to redefine dead keys. I also figured out that the keymap code in XFree is far, far from trivial. I would like to understand it, but I could not find the corresponding documentation anywhere. Could someone please point me to the right documentation ? Thanks a lot, -- Thomas Tempe, Protect your privacy! Encrypt your mail! Use GPG! Systematic preventive privacy-invading personal data recording is strictly useless at stopping evil anti-american terrorists without systematic preventive goulag. http://www.stop1984.org -- Thomas Tempe, Protect your privacy! Encrypt your mail! Use GPG! Systematic preventive privacy-invading personal data recording is strictly useless at stopping evil anti-american terrorists without systematic preventive goulag. http://www.stop1984.org msg01071/pgp0.pgp Description: PGP signature
Re: [I18n]Re: [li18nux:1094] BACKSPACE behavior
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
