Re: [Nano-devel] Outstanding 1.2.4 items?

[David Lawrence Ramsey]

--- Jordi Mallach <address@hidden> wrote:

<snip>

>Since I switched to ca_ES.UTF-8, the nano menus get mangled a bit quite 
>easily. I guess the UTF-8 issues are not only in the input, but in the 
>display of menus too.

I guess then that all the translated strings should be converted to wide 
character strings before being displayed (in which case wcslen() should 
be used to check their length instead of strlen()) to avoid these 
problems.  Does that mean that all the translations should be converted 
to UTF-8 as well?

>I'm so looking forward to David completing #4 in his list... :) Even 
>Planet Debian had a remark about nano not groking UTF-8 the other day.  
>It is certainly a demanded feature now, as Debian is pushing UTF-8 in 
>more and more places like control files for Debian packages, etc.
>
>We'll have it soon, I hope ;)

I've thought about it some more, and considering that the eventual 
rewrite of the high-level input routines is more about hooking up the 
non-edit-window input routines properly to the shortcut lists whenever 
possible than fixing input per se (since the low-level input routines 
mostly handle it), I can probably move it up a bit on the priority list.  
Besides, once display_string() is converted to use it as in DB's UTF-8 
patch, everything that uses it should be too, which should save some 
time.

I have a few more questions about UTF-8 support, though:

1. What should be done in nano builds without NLS support?  Proper UTF-8 
support requires setlocale() calls, and such calls are disabled when NLS 
is disabled.  (I've noted that newer versions of Pico have 
"-setlocale_ctype" and "-no_setlocale_collate" options, but after 
reading the setlocale(3) manpage, I'm not so sure that not calling 
setlocale(LC_CTYPE) and calling setlocale(LC_COLLATE) is good default 
behavior.  The latter is supposed to affect regular expressions, after 
all, and Pico still doesn't use those.)

2. Should support for non-wide versions of ncurses be dropped, since 
they can't handle UTF-8 properly, or should it be kept for compatibility 
reasons?  After all, ncurses didn't have wide character support until 
version 5.3.

3. Should -N/--noconvert be expanded to not convert from UTF-8 to wide 
characters, since doing that conversion all the time may lead to an 
inability to properly handle binary files?  (I know nano isn't designed 
to be a binary editor, but the ability to do things like open a file 
with a MacBinary header and delete all of that header in nano without 
having to resort to a hex editor to do it is convenient enough that I'm 
reluctant to get rid of it.)

4. How should the double-escape-ASCII and verbatim input modes be 
handled?  If the answer to #3 is yes, I'm thinking that if UTF-8 
conversion mode is on, the characters generated by both should be wide, 
and if UTF-8 conversion mode is off, the characters generated by both 
should be normal.  (After all, in addition to the reasons mentioned at 
the end of #3, the latter case could be used to fix invalid UTF-8 
sequences.  The tricky part would be having to reparse and reload all 
the lines upon saving.)

>David, by the way, impressive work!

Thank you.