vile
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vile] problem with 'wide characters' (utf-8) under macosx


From: Thomas Dickey
Subject: Re: [vile] problem with 'wide characters' (utf-8) under macosx
Date: Sat, 6 Dec 2014 18:22:44 -0500
User-agent: Mutt/1.5.20 (2009-06-14)

On Sat, Dec 06, 2014 at 11:43:01PM +0100, j. van den hoff wrote:
> On Sat, 06 Dec 2014 22:53:46 +0100, Thomas Dickey <address@hidden> wrote:
> 
> >On Sat, Dec 06, 2014 at 09:45:04PM +0100, j. van den hoff wrote:
> >>>In its preferences ("Advanced" tab), I have
> >>>   Character encoding: Unicode (UTF-8)
> >>>   Set locale environment variables on startup
> >>
> >>I have exactly the same there but end up with the strange
> >>`locale' settings
> >>including LC_CTYPE=UTF-8.  this definitely is no longer a vile related
> >>question but do you have any idea from where Terminal.app derives it's
> >>information _what_ locale environement vars to set (even in your
> >>case they
> >>are not the same -- with the lucky exception of LC_CTYPE -- as
> >>in uxterm).
> >
> >hmm - no, I don't...  When I setup my Mac's (both macmini
> >servers), I didn't
> >delve into its locale settings.  In the system preferences, I see the
> >language/region part, which is English/United States - which is probably
> >where Terminal.app gets its information from.  I do recall that initially
> 
> that sounds probable. and maybe I managed to confuse it in that area using
> a custom setup declaring region as 'Germany' and currency 'Euro' but
> using English as format language and
> using `.' as decimal separator -- might be the reason
> the used algorithm gave up to decide what sort of LC_CTYPE localisation
> is right and fell back to just setting it to `UTF-8'.

That sounds plausible.  The preferences dialog doesn't give much detail.
 
> >OSX wasn't making useful locale settings that I could pass via ssh
> >-- I used
> >to just override it on the remote end.  I'm running last year's release
> >Mavericks on both machines (am still seeing X as buggy in yosemite).
> 
> good to know. I, too, stick with 10.9.5, waiting until yosemite has
> converged
> to something really usable (hopefully).

unless I get an interesting bug-report for xterm, I can wait.

I spent a chunk of today getting the gcc port upgraded to gcc5,
so that I could investigate a bug-report for ncurses.
 
> >>>vile's different from the other editors because it will (if available)
> >>>use the "de_DE" to infer a useful value for the "8bit" encoding.
> >>>(vile has built-in locale tables in case "de_DE" itself is not supplied
> >>>on your machine, so that can do this - about 70kb).
> >>
> >>I see.
> >
> >right.  If it cannot find the useful value, then it falls back to POSIX
> >or Latin-1, depending.  The ":show-printable" I saw today looked
> >like POSIX.
> >
> >(I probably should revisit this and attempt to improve it - but the port
> >is old, too ...)
> 
> maybe you could initiate that they use the current version?

I might be able to get something done there (I discussed the port with its
maintainer a year or so ago...).  For ncurses, probably not (too much
inertia, until I finish work on a new release).
 
> >>>("xterm-color" is problematic as well - a different topic).
> >>
> >>is it? what do you recommend here?
> >
> >The closest for Terminal.app would be from ncurses:
> >     nsterm-256color
> >which I added in 2012.
> >
> >But for Mac's that's hard:
> >     a) the terminal database in /usr/share/terminfo is very old.
> >     b) Terminal.app only has certain settings (actually in Mavericks,
> >        none are "xterm-color").  It does have "nsterm", which was
> 
> $TERM is reported as `xterm-color' in the Terminal.app window
> irrespective of whether it is declared as `xterm-256color' or
> `nsterm'
> in the prefereneces. not sure what actually is going on here. :-(.

It seems to "work" here: if I create a new window, "echo $TERM" shows
a difference.  However, I've tested the result before and found it didn't
change the behavior.  That means half of the selections are wrong :-)
 
> >        added to ncurses in 2001.  A quick check with that entry shows
> >        some problem with line-drawing.
> >     c) Unlike the Linux and *BSD's, the port for ncurses is still 5.9
> >        release (2011).  That includes the terminal database in
> >        /opt/local/share/terminfo
> >
> >As xterm-color, the function keys are half-right.
> 
> OK, thx for clarifying.

no problem

-- 
Thomas E. Dickey <address@hidden>
http://invisible-island.net
ftp://invisible-island.net

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]