Therefore I propose letting users choose their preferred keyboard
layouts instead of forcing any specific one to them.

In your case it seems you are talking about QWERTY and QWERTZ (from
wiki), so the following would be keyboard layouts in the new directory
called "Keyboard"

(General keyboard layouts)
QWERTY.vim
QWERTZ.vim
AZERTY.vim
QZERTY.vim
Dvorak.vim
Colemak.vim
JCUKEN.vim
Neo.vim
Turkish.vim
.
.
OR (Keyboard layout by Country Name)





and there would be 4 files:

QWERTYsequence.vim
QWERTZsequence.vim

QWERTYstructured.vim
QWERTZstructured.vim




OR (specific for your country)

CzechQWERTYsequence.vim
CzechQWERTZsequence.vim

CzechQWERTYstructured.vim
CzechQWERTZstructured.vim




OR simply (having advantage of adding new keyboard layouts in future
but disadvantage of difficult to find which is which when changing
them in command)

CzechLayoutA1.vim
CzechLayoutA2.vim

CzechLayoutB1.vim
CzechLayoutB2.vim




In .vimrc, there would be:

set keyboardlayout=....




Maybe a step forward to change the layout on-the-fly by the following
command (when changing keyboard setting in X window system):

:set keyboardlayout=...



I am not a programmer, but the concept is to make vim a converter and
convert keys on-the-fly:

Input ---> vim(search and map in the layout file) ---> output




The concept is inspired by the following plugins:

VimIM : Vim Input Method
ywvim : Another input method(IM) for VIM, supports all modes

and the Keyboard layout system in Windows because when inputting
Chinese we rely heavily on mapping different keys so as to generate
one Chinese character.




All we need would be desiging 2 sets of clear layout files for every
different kind of keyboard layout

Hope this help.


On Feb 21, 5:53 pm, Milan Vancura <mi...@ucw.cz> wrote:
> > Yes. But what happens when you then edit that macro by putting the
> > register into a buffer, changing it, and yanking it again? This is not
> > uncommonly done. How should the registers be stored in .viminfo? How do
> > you write the input to the feedkeys function as a string in vimscript?
> > Etc.. These are the kinds of issues I was trying to raise.
>
> Hi.
>
> Wouldn't be it same as now, only used more often? There is already a
> possibility to write "<F4>" or "<S-Space>". The only problem is that, at least
> the second, we can't press strongly enough to push it to vim :-)
>
> But, on the other hand, you are right there still will be (and must be)
> ambiguities. We can't do anything about that, in general - it's a user who 
> must
> decide how does he want to understand his keyboard.
>
> For example: I, as Czech, have some Czech accented letters accessible via
> modifier+key on my keyboard.  To make the example more specific, think about
> Mod5+s as "s with hook" (U0161) and redefined my keymap so Capslock key acts 
> as
> Mod5.  It's up to me, and only me, if I define some vim mapping as
>
> :map <Mod5+S> ...rhs...
> - or -
> :map <U0161> ...rhs...
>
> Both do the same on my current keyboard but start to behave differently if I
> change my keyboard setting in X window system, of course. If I switched to
> another kind of Czech keyboard (called "typewriter one"), <U0161> appears at a
> key of "number 3" and Mod5 would be on right Alt or not defined at all.
>
> As I wrote above, we can't do anything about that, as far as I know.
>
> Milan
>
> --
> Milan Vancura, Prague, Czech Republic, Europe

-- 
You received this message from the "vim_dev" 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

Raspunde prin e-mail lui