Re: [Bug-apl] Back to underline

[Elias Mårtenson]

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 <address@hidden> 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