Re: [Bug-apl] Back to underline

[Juergen Sauermann]

Hi Fred , fine. Maybe the way forward is if you publish a patch in our Bits_and_Pieces directory. I would not like it to be a ./configure option because that would give us many #ifdefs all over the place and I (instead of Fred) would have the burden of maintaining it. It is actually far more more than only changing Avec.def. For example the built-in line editor (i.e. every line entered interactively) currently assumes that every character moves the cursor by one position. So the cursor will be positioned one character off for every underlined one. Also, there is a difference between APLs that have underlined chars in their character set and those that do not. Consider ⍴'A̲' (not sure if this displays properly everywhere - read: RHO QUOTE A COMBINING_UNDERLINE QUOTE) On a system with underlined characters this will return 1 while on Unicode with combining underline machine it gives 2. For all the reasons described here and in earlier emails on this topic, I consider this to really be a Pandora box, and I just do not want to open it. Gnome Terminal, BTW, works with UTF-8 but not so well with the combining underbar. If you cut-and-paste an underlined A and enter B then it underlines the B instead of the A (for me cut-and-paste is currently the only way to generate the combining underbar). /// Jürgen On 08/14/2015 10:22 PM, fred wrote: Jürgen Yes, I understand how to implement underline -- the changed Avec.def was attached. As an observation, a perfect hash over the utf characters would eliminate the need for a binary search. As to ATF format - )on out a symbol x{combiningunderline} can be replaced by x_. But, we wouldn't want the inverse on )in -- it then seems that a flag on )out would be the straight forward answer. I mapped alt+shift+u on the keyboard for combining underline. Probably as bad as backspace+_ though. In my editor I have a macro (/cu/) defined for combining underline (or I just use alt+shift+u). I do use vi occasionally, but generally my own editor. I don't think I have ever used nano. xterm and gnome terminal are ok with utf-8 -- don't know about other terminal emulators. But that is a "chicken and egg" problem -- if there are no applications that DARE to use advanced features there is no impetus to fix the terminal emulators. But, since this "feature" is purely cosmetic, I am quite ok with letting it go (or, just updating my local Avec.def as releases progress). Fred