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

[j. van den hoff]

On Sat, 06 Dec 2014 13:37:40 +0100, Thomas Dickey <address@hidden> wrote:

> On Sat, Dec 06, 2014 at 11:32:52AM +0100, j. van den hoff wrote:
> > a further observation: the test file I've used just contains the lines
> >
> > ä
> > ö
> >
> > i.e \u00E4 and \u00F6. in the show-variables list there is then one  
> > entry:
> >
> > $bufname = ä
> >
> > in both terminal emulators (urxvt, Terminal.app). here is the
> > strange thing (for me):
> > in urxvt the file content is displayed properly, but `bufname' is
> > diplayed as
> >
> >  $bufname = ä  (hope this goes through the mail as intended...)
> >
> > while in Terminal.app it's the other way round: the file content is
> > diplayed via the
> > utf-8 hexcodes and `bufname' appears correctly displayed as
> >
> > $bufname = ä.
> >
> > More important, I think I've found the "solution" just now:  I looked  
> > hard at
> > my .vilerc again and found a setting `set file-encoding=auto' (it  
> > seemed to
> > be required at one point in the past but I can't recall the reason why I
> > added this anymore).  just deactivating it leads to proper display in  
> > the
> > Terminal.app.
>
> The default is "locale", which seems to make most people happy...

yes, obviously this is correct... I recall now _why_ I modified it in the  
first place:
need to edit some older files in latin1 encoding within a utf-8 locale.

> > so it seems it was just my fault after all.  apologies for "spamming"  
> > the
> > list ...  but while I am at it:  reading the help regarding  
> > `file-encoding'
> > did not really clarify to me what was wrong with the `auto' setting  
> > (and then
> > only for Terminal.app).  any clarifications would be appreciated.
>
> 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 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 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)?



>


--
Using Opera's revolutionary email client: http://www.opera.com/mail/