vile
[Top][All Lists]
Advanced

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

Re: [vile] vile-9.6j.patch.gz


From: Thomas Dickey
Subject: Re: [vile] vile-9.6j.patch.gz
Date: Sun, 30 Mar 2008 14:34:09 -0400 (EDT)

On Sun, 30 Mar 2008, Paul van Tilburg wrote:

On Wed, Mar 26, 2008 at 06:09:32PM -0400, Thomas Dickey wrote:
On Wed, 26 Mar 2008, Paul van Tilburg wrote:
Hmm, nothing changed for me.. characters with accents still get inserted
as \xC3.
Anything I can test?

I'm puzzled, since it's working for me (I tried nl_NL.utf8 here).
So I'm either building it differently, or running it differently.

Is this in insert-mode?  With some specific characters?

Yes, in insert mode.  I always use UTF-8, mostly for accents on vowels.

Perhaps the
driver is related: If it's configured --with-screen=curses or
--with-screen=ncurses, those are not UTF-8 capable (though
--with-screen=ncursesw should work).  I'm generally using the default
terminfo/termcap driver.

I use the following configure command:

../configure --prefix=/usr --mandir='$${prefix}/share/man' \
   --with-locale --with-perl --with-cflags=-O2 --with-loadable-filters=all

that's comparable to what I'm doing.

I assume you're setting file-encoding=utf-8 as mentioned last week.

Yes, well if I create a new file with file-encouding set to auto,
I get \xC3 for example instead of \?C3.

I see one problem (will fix...): when I cut/paste your example to create a new file with either file-encoding=auto or utf-8, and saved it, I get an iso-8859-1 file.

It appears to behaving as if the file-encoding for the buffer is still set to auto until it's _read_ (it's not strictly the mode value which is the issue, but one of the side-effects of setting the mode).

Doing a ":setl file-encoding=utf-8" before the save does work around that;
the buffer is written as utf-8, and is read back properly.


Without a specific setting, vile's reading characters according to
the locale (with or without iconv), and applying them to the buffers
according to _their_ file-encoding.

% locale
LANG=en_US.UTF-8
LC_CTYPE=nl_NL.UTF8
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=nl_NL.UTF8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=nl_NL.UTF8
LC_NAME=nl_NL.UTF8
LC_ADDRESS=nl_NL.UTF8
LC_TELEPHONE=nl_NL.UTF8
LC_MEASUREMENT=nl_NL.UTF8
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

With xterm, I "just" use a meta-whatever to get upper-128 codes
(which uxterm translates into UTF-8).  A quick check using vile's
^VxNN seems to be working.

My xterm behaves oddly.. compose key usages seems to result in
no chars being inputted at all, but I can copy & paste UTF-8 chars
into the xterm (shell prompt).

Anyway, if I edit the file attached, both in xterm and gnome-terminal
with the above shown locales I see:

Accents: \?E9\?F3\?E1\?ED
Dashes: ??? ???

(So the en- and em-dash (U2013, U2014) are shown correctly, but the vowels
with accents are not).

Paul

--
PhD Student @ Eindhoven                     | email: address@hidden
University of Technology, The Netherlands   | JID: address@hidden
Using the Power of Debian GNU/Linux <<< | GnuPG key ID: 0x50064181


--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

reply via email to

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