Re: [Bug-apl] Back to underline

[Juergen Sauermann]

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