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
> 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
> 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
> 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
> 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
> >
> >
> >
>
>
>
>
>
>
