bug#43830: keyboard layout handling incompatible with rest of the OS

[Paul Pogonyshev <pogonyshev@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2068 bytes --]

> All these problems are because of mismatch between your X layout and
> your Emacs input method.  Emacs doesn't know the X layout, so you need
> to define it in Emacs by adapting an existing input method,
> or defining different keys manually.

Sorry, I don't understand. I also don't see anything about this in the
documentation (README).

I want physical key that is '/' in English to type '.' in Russian (because
that is what it does in russian-computer), but invoke shortcuts bound to
C-/, M-/ etc. Is that possible with `reverse-im'?

Paul


On Wed, 7 Oct 2020 at 10:43, Juri Linkov <juri@linkov.net> wrote:

> >> When your X xkb layout has some differences from an Emacs input method,
> >> you need to adjust these mismatched keys, but this is not a big problem.
> >
> > It doesn't. With switching Emacs input methods between English and
> Russian
> > I also get English '/' == Russian '.'. And so C-. in Russian input method
> > works
> > as C-/ in English, because it's the same physical key.
> >
> > Also, the same goes for many S-M-[digit] combinations, because characters
> > on the digit row are often different in Russian layout. For example,
> S-M-6
> > in
> > English layout translates to M-^, `delete-indentation', but in Russian
> > S-M-6
> > becomes M-:, `eval-expression'. And so on.
>
> All these problems are because of mismatch between your X layout and
> your Emacs input method.  Emacs doesn't know the X layout, so you need
> to define it in Emacs by adapting an existing input method,
> or defining different keys manually.
>
> > So, it is a good workaround that *mostly* works. But it doesn't solve the
> > underlying issue. Which was successfully solved by other applications
> tens
> > of years ago.
>
> We already discussed this 10 years ago, and the conclusion was that
> it would require too fundamental changes in how Emacs processes keystrokes.
>
> If now you have new ideas about how this would be possible to implement
> by keeping backward-compatibility of the existing design,
> patches that demonstrate the ideas are welcome.
>

[-- Attachment #2: Type: text/html, Size: 2701 bytes --]