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