Re: [Nano-devel] Outstanding 1.2.4 items?

[Jordi Mallach]

Hey,

On Wed, Jun 23, 2004 at 04:56:01PM +0200, David Lawrence Ramsey wrote:
        ^^^^^^
        Ok, ridiculous, but had this on my inbox marked as "dude you
        gotta reply at some point" :)

> >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 don't think so, but I'm not sure. GNOME apps do need to have all po
files in UTF-8 encoding, but many other applications I use that handle
UTF-8 well internally have no problems with po files encoded in other
charsets. It'll be easy to test for me, whenever this is ready, so just
ask. :)

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

I don't see how using LC_COLLATE helps at all. If NLS support is not
enabled, can we assume setlocale() exists in the system? I'm not sure at
all we should do anything different with setlocale() at all. I'd assume
the mo files wouldn't even be installed in such a setup, so it wouldn't
matter at all. As you know, having the setlocale() out of the NLS ifdef
in nano-tiny helped the Debian package. Withotu that one-line patch,
8bit characters would not show up at all in the buffer.

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

Not sure. Many apps do UTF-8 just right and don't need ncurses.
Depends: libc6 (>= 2.3.2.ds1-4), libgpmg1 (>= 1.19.6-1), libncurses5 (>= 
5.4-1), vim-common (>> 1:6.3)
These are the dependencies for vim in Debian Sarge.

Jordi
-- 
Jordi Mallach Pérez  --  Debian developer     http://www.debian.org/
address@hidden     address@hidden     http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/~jordi/

signature.asc
Description: Digital signature