I'm not sure I understand why special treatment of the combining underline would be needed. From GNU APL's point of view it's just like any other character. Sure, you'd probably want to prevent it from being used as the first character (to prevent it from being merged with a prior operator) but other than that I don't see how this is any different than supporting any other characters.
On 15 August 2015 at 04:22, fred <[email protected]> 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 > > On Thu, 2015-08-13 at 21:38 +0200, Juergen Sauermann wrote: > > Hi Fred, > > see my comments inline below. > > /// Jürgen > > > > On 08/11/2015 05:51 PM, fred wrote: > > Jürgen/List > > I have been thinking about your comments on UTF8 combine underline. The > UTF8 standard is clear -- U0332 combines with the previous character. > Any other behaviour is an error. > > Yes, but we have seen examples where this error occurred. If we send > emails with APL code > and the wrong characters are being underlined, then confusion will break > out. > > I like having the ability to underline. This adds 62 (a..z, A..Z, 0..9 > underlined, and neg etc. underlined, which I am ignoring) characters to > the namespace. So, I replaced {quad}af DF (UPPER_HALF_BLOCK) with the > combining underline. This will be utterly benign to most (all) > applications, except for (maybe) some character terminal plotting. The > remaining problem is that combining underline can *start* a symbol, > which is a bit wrong. I didn't bother fixing the tokenizer -- just > Avec.def. Find attached. Note that the combining underline can be > replaced with underline for export compatibility with other APL > implementations -- if needed (perhaps an option on ATF export?). I > wouldn't need that, but, just an idea. > > My fingers are still crying from the time where you would have to enter > Character-Backspace-Underline > in order to get an underlined character. > > If you change a *char_def() *macro, then please make sure that you move > the line to its proper place. > The macro lines must be ordered with increasing unicode values. > Also, you should pick one that is reserved for removal (those with a 0 in > front of the ⎕AV position. > See comment at the beginning of the table). > > If you want the *tokenizer* to recognize your new underline then it > should suffice to change the > flag in the *char_def() *macro from e.g. *END* to *SYMBOL*. > > Forget *ATF* in this context - underlined characters will break it. *ATF* > has a strong 1:1 relationship > between characters and bytes, which is already difficult for Unicode > machines. Mapping 2 Unicode > characters to 1 byte makes things even worse (and the problems that I > mention earlier will apply here). > > The *vi* editor seems to deal with such underlined characters properly, > but other editors, e.g. > *nano*, do not (e.g. cursor movement). > > Same story for terminals - xterm works, the standard terminal in, for > example linux mint, does not. > > The built-in line editor of GNU APL will also stop working properly. > > Putting this all together, this approach means *big Trouble* for a (in my > opinion) relative minor > improvement that also violates the ISO standard. Unless there is a strong > support in the GNU APL > community for this and no objections, I would like to keep things as they > are. Luckily GNU APL is > free software, so you can modify it to suit your needs. I can help you > with technical questions in > this area, but I would prefer to not include it in GNU APL. > > I do not call APL from within emacs (or vi). I use my own editor > instead. I have also attached xed.apl (for consideration in > bits&pieces). That calls out to an external editor to edit functions. > The function xeda edits matrices, calling out to libreoffice to provide > gui editing. Both of these need some, um..., tender loving care, but > they do work for me. I write functions in the workspace interactively, > generate data, and test -- then call from another application using > libapl. xed and xeda are appropriate for my workflow, and may help (but > probably too trivial to be of much interest, I imagine). > > Fred Weigel > > >
