[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
signature.asc
Description: Digital signature
Re: [vile] problem with 'wide characters' (utf-8) under macosx, j. van den hoff, 2014/12/06