On Sun, Oct 11, 2015 at 10:08 AM, Gevisz <gev...@gmail.com> wrote:
> On Fri, 9 Oct 2015 18:14:47 +1100 Erik Christiansen <dva...@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.

The official way to send a signal to some program in Unix/Linux is by
means of the "kill" utility and friends, for instance (depending on
your X server's process name)
    killall -HUP Xorg
(in the shell, or after :! on the Vim command-line) might do the trick.

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

I use keymaps in Vim, and when keymaps are active (when 'iminsert' is
locally set to 1), every time I hit r in Normal mode the cursor
changes to my lCursor color and the "replacing" character is
interpreted according to the keymap, even if I use a language-mapping
with a multikey {lhs}
>
> 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.
>
> 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
>>

Best regards,
Tony.

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to