Sunday, October 11, 2015

Re: Alternative keymaps [Was: vim and touch typing]

On Sun, 11 Oct 2015 17:01:39 +0300 Nikolay Pavlov <zyx.vim@gmail.com> wrote:

> 2015-10-11 11:08 GMT+03:00 Gevisz <gevisz@gmail.com>:
> > On Fri, 9 Oct 2015 18:14:47 +1100 Erik Christiansen <dvalin@internode.on.net> wrote:
> >
> >> On 08.10.15 20:33, Gevisz wrote:
> >> > In this connection I have only one inconvenience connected with the facts that
> >> > 1) I usually have to use 3 keyboard layouts at the same time switching
> >> > between them with a hot key,
> >> > 2) it is impossible to have a "direct hot key switch" to a certain
> >> > keyboard layout in Linux world.
> >>
> >> It is very risky to say that anything is impossible in linux;
> >
> > Ok, next to impossible. ;)
> >
> >> it usually turns out that there are at least three ways to do what
> >> one at first thinks impossible. My first reaction to your problem was
> >> to suggest several files to switch to ~/.Xmodmap, and then find out
> >> if a SIGHUP to X would make it re-read its config.
> >
> > And what if not?
> >
> > I may try this solution but I still have to google how to send
> > a SIGNUP signal to X and, moreover, to find out how to send it
> > in a quick and convenient way. Otherwise this way will not be
> > a solution at all.
> >
> > Moreover, even before trying it, I suspect that this way of
> > achieving a "direct hot key keyboard switch" will cause X to
> > re-read its configuration from a file on a disk that can take
> > a noticeable time, which is not desired.
>
> Nobody ever directly reads files from disk, except for the kernel.
> These configuration files will shortly appear in the filesystem cache
> and thus will be always read from memory.

Ok, thank you for explanation.

> Next problem is how fast
> they are being parsed, and I have a reason to think that Vim will be
> slightly faster, mainly because its keymaps are a few commands (VimL
> is rather slow, "less commands are better" is the main optimization
> principle) and one or two files, while X server configuration consits
> of many files. (Though AFAIK X will walk over less directories, but
> with FS caches, the fact that Vim walks over &runtimepath constantly
> seeking for regular, filetype plugins, autoload functions, etc and
> most directories in &runtimepath contain no keymap subdirectory this
> does not matter.)
>
> >
> > The true solution to this should be to keep all the needed
> > keyboard layouts in memory and only change the pointer to
> > the corresponding memory locations by a corresponding hot key.
> >
> > I believe that such a solution should be provided in the X configuration
> > and realized in the corresponding window manager plugin but, as far as I know,
> > it is not. That is why I wrote that it is impossible in Linux (unless you
> > can re-write X, of course :).
> >
> >
> >> Much easier, by appearances, is Tony's suggestion. A quick look at
> >> ";h keymap", leading to ";h mbyte-keymap", looks very promising, not
> >> least since there are many ready-to-use mappings:
> >>
> >> $ locate -r 'keymap.*vim' | wc -l
> >> 130
> >>
> >> That, though, only maps in Vim, and only during text insertion.
> >> (which may be just what you want)
> >
> > Yes, you are right, this workaround can be what I actually need.
> > Moreover, I have used a similar workaround when I used emacs about 15 years ago.
> >
> > However, in ":h mbyte-keymap" is written that this workaround would interfere
> > with using "commands that take a single character argument, like f and r" what
> > is definitely a drawback.
> >
> > Moreover, as far as I understand, in this workaround the keymap tables are
> > read anew from disk every time you hit <C-^>, so it, again, can take a noticeable
> > time, what is not good.
>
> Before speaking about "noticeable" time check this.

I will do it. At least for the Vim solution.
But, unfortunately, not earlier than next Wednesday.

> On my system to make this time noticeable it needs to be both absent
> from FS caches and system under high IO pressure. Also note that you
> *don't* need to wait while keymap is being switched in Vim due to its highly
> synchronous nature. All keys you will type while it is loading will be
> processed after loading is finished. Not sure how it is handled in X
> server.
>
> Also with default bindings i_CTRL-^ *only* toggles &iminsert option
> and does nothing else. Though if you need three different keymaps you
> will probably have to use some mapping that at least reads keymap file
> anew each time you switch to non-english keymap which is not equal to
> &keymap option value.

Dealing with only two different keyboard layouts will already be a progress for me.

> > Otherwise, this suggestion looks interesting and I will try it a bit later.
> >
> >> If cross-application mapping is desired, though, then an alternative to
> >> ~/.Xmodmap is to just execute (several of) something like:
> >>
> >> $ xmodmap -e 'keycode 91 = 0x2c' # Change numeric pad '.' to ','
> >>
> >> in a shell script, after using xev to elucidate the keycode and keysim of
> >> all the keys you want to remap.
> >>
> >> For me, this reverts the above mapping:
> >>
> >> $ xmodmap -e 'keycode 91 = 0x2e' # Change numeric pad ',' to '.'
> >
> > Thank you for pointing me to the xmodmap and xev utilities. I will consider
> > this solution as well but it would lead to execution of a long remapping script
> > that again should take a noticeable time comparing with just changing a pointer
> > to the corresponding keymap table in memory.
> >
> >> OK, that's three ways. Time to stop.
> >>
> >> Erik
> >>
> >
> > --
> > --
> > You received this message from the "vim_use" maillist.
> > Do not top-post! Type your reply below the text you are replying to.
> > For more information, visit http://www.vim.org/maillist.php
> >
> > ---
> > You received this message because you are subscribed to the Google Groups "vim_use" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

No comments:

Post a Comment