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 09:15:26 -0500
User-agent: Mutt/1.5.20 (2009-06-14)

On Sat, Dec 06, 2014 at 02:42:11PM +0100, j. van den hoff wrote:
> On Sat, 06 Dec 2014 13:37:40 +0100, Thomas Dickey <address@hidden> wrote:
...
> >With "auto", vile inspects the file as it reads it, and decides what its
> >encoding is.  One problem with that approach is if you start with a plain
> >ASCII file and want to change it to UTF-8.  You can do that by doing
> >
> >     :setl file-encoding=utf-8
> >
> >before introducing the non-ASCII text.  (The "setl" is needed because
> >vile maintains that value as a local-setting for each buffer, and a plain
> >"set" will not tell it to revise its idea of a particular buffer).
> 
> I see.  thanks.  the question still remains, why `file-encoding=auto' works
> (as it is intended, I understand) when opening the respective input file
> (already containing utf-8 characters) in urxvt while it does not when using
> the Terminal.app.  it is not important any more for me (I'll now stick with
> the default setting of file-encoding') but still...

I'd suspect that my shell environment (such as locale) in Terminal.app
was different from the one in X11.

On my Mac's, I setup one user to own the gui, and a different user who
ssh's to various places (and most of the editing that I do is via the
latter), so I may be overlooking some case where X11 and Terminal.app
environments disagree.
 
> I see also some other quirk:  when actually entering further utf-8 sign (say
> german diaeresis) to the file within Terminal.app (where now the already
> existing chars are displayed correctly), those are displayed as `??' (two

vile will display a non-UTF-8 byte with a single "?" mark followed by
its hexadecimal value.  But I don't recall (or see in the code) something
that would do a double "??".  You could (I think...) get that from some
obscure translating problem between UTF-8 and one of the ISO-8859-x's
that are used in the "8bit" encoding, but I'm not sure where to look :-(

If I had something like that which I could easily reproduce, the only
way I know to track it down (as a bug report) would be to build vile with
the debugging trace, and see who did it.

> question marks), until I leave display of that buffer (by going to an
> alternate file) and coming back at which time the symbol appears correctly
> displayed (or by leaving input mode and performing undo/redo of the edit,
> which also produces correct display of the character).  any idea how _this_
> behaviour comes about (again:  this does not happen when using `vim' instead,
> so it seems not to be just a problem of the terminal.app)?

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