vile
[Top][All Lists]
Advanced

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

Re: [vile] Non-us keyboard layout mishandling.


From: Thomas Dickey
Subject: Re: [vile] Non-us keyboard layout mishandling.
Date: Sun, 12 Dec 2010 11:19:22 -0500
User-agent: Mutt/1.5.20 (2009-06-14)

On Thu, Nov 18, 2010 at 03:33:14AM +0300, Ramil Farkhshatov wrote:
> Thomas Dickey <address@hidden> wrote:
> 
> > On Thu, 18 Nov 2010, Ramil Farkhshatov wrote:
> >
> > > Thomas Dickey <address@hidden> wrote:
> > >
> > >> On Thu, 18 Nov 2010, Ramil Farkhshatov wrote:
> > >>
> > >>> Hello.
> > >>> Vile in normal mode interprets keypresses made in non-us layout (e.g.
> > >>> utf-8 cyrillic) as a sequence of us (latin) keypresses and does random
> > >>> actions or sets 'arg: ' to some huge values. This behaviour makes
> > >>> confusion when editing. I think that vile should ignore such keypresses.
> > >>
> > >> vile should...
> > >>
> > >> This sounds like a special case which I thought I'd fixed: if your 
> > >> machine
> > >> doesn't have the corresponding ru_RU locale data installed, then vile may
> > >> have incomplete information on the locale.
> > >>
> > >> Is that the case?
> > >
> > > Machine have ru_RU.UTF-8 locale. At least it is generated by glibc's
> > > (v2.12.1) 'localedef' and it is shown in 'locale -a' output list. And I
> > > didn't have any locale issues before except for vile behaviour.

From the reference to glibc, I assume we're talking about Linux.

> > I meant something like this (from my machine's "locale -a"):
> >
> > ru_RU
> > ru_RU.iso88595
> > ru_RU.koi8r
> > ru_RU.utf8
> >
> > Some distributions such as Ubuntu don't deliver 8-bit locales, which I've
> > used to construct a lookup table relating those with UTF-8 encoding, which
> > is used in various ways.
> 
> Output of locale -a:
> C
> en_GB.utf8
> en_US
> en_US.iso88591
> en_US.utf8
> POSIX
> ru_RU.utf8

From this, I'm assuming that the problem is as I stated above.  In 9.8c,
I added a built-in table which supplies the "ru_RU" part as a "builtin"
locale using ISO-8859-5 encoding.  vile  uses that for cases when
the file-encoding is "8bit", as well as to simplify editing UTF-8 files
in 8-bit locales.

The help-file summarizes this (noting that "locale" is the default,
which means that vile should assume that your files are in UTF-8
encoding, based on the "ru_RU.utf8", and the nl_langinfo function):

   file-encoding (fk)
           This is the character encoding of the buffer contents, which is
           not necessarily the same as the display's character encoding. It
           must be one of the following values:

         "8bit"
         "ascii"
         "auto"
         "locale" (default)
         "utf-16"
         "utf-32"
         "utf-8"

           The "auto" setting tells vile to determine the encoding by
           inspecting the buffer contents. The "locale" setting tells vile to
           assume that the buffer contents are in the current locale's
           encoding. The "8bit" setting corresponds to the 8-bit locale
           support used since 9.3i (20021223). (B)

The behavior for the console and xterm should work (works for the cases I
am trying here).  Xvile is a different case (and from the last report, it
was working properly also).

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