how does set lmap apply to mappings?

[Christian Brabandt]

Bram,
what is the reason, setting 'lmap' applies to when a mapping is
remapped?

Consider this:
~$ cat lmap.vim
imap <tab> <Plug>MyPluginEcho
imap <Plug>MyPluginEcho <c-r>="hello"<cr>
cmap <tab> <Plug>MyPluginEcho
cmap <Plug>MyPluginEcho <c-r>="hello"<cr>
" set lmap=i;k

run vim -u lmap.vim -N
and type <tab> in insert mode, note, how "hello" is printed in either
insert mode or command line mode.
Now do
:set lmap=i;k
and do it again. Note that <Plug>MyPluginEcho will be output.

The problem is, setting lmap breaks plugins (see e.g. here:
http://stackoverflow.com/questions/12450803)

I would consider this is a bug and actually think, that setting 'lmap' should
never be applied to when recursively resolving a mapping.

Also, I do not understand what this part of the help is trying to say:

,----[ :h 'lmap' ]-
| This will allow you to activate vim actions without having to switch
| back and forth between the languages. Your language characters will
| be understood as normal vim English characters (according to the
| langmap mappings) in the following cases:
| o Normal/Visual mode (commands, buffer/register names, user mappings)
| o Insert/Replace Mode: Register names after CTRL-R
| o Insert/Replace Mode: Mappings
| Characters entered in Command-line mode will NOT be affected by
| this option. Note that this option can be changed at any time
| allowing to switch between mappings for different languages/encodings.
| Use a mapping to avoid having to type it each time!
`----

What are the language characters? What is the relationship to lmap
mappings?

This patch could fix it, but I am not sure, this fixes it correctly.

diff --git a/src/getchar.c b/src/getchar.c
--- a/src/getchar.c
+++ b/src/getchar.c
@@ -2196,12 +2196,16 @@ vgetorpeek(advance)
{
#ifdef FEAT_LANGMAP
c2 = typebuf.tb_buf[typebuf.tb_off + mlen];
- if (nomap > 0)
- --nomap;
- else if (c2 == K_SPECIAL)
- nomap = 2;
- else
- LANGMAP_ADJUST(c2, TRUE);
+ /* do not apply lmap setting when resolving a mapping */
+ if (typebuf_maplen() != typebuf.tb_len)
+ {
+ if (nomap > 0)
+ --nomap;
+ else if (c2 == K_SPECIAL)
+ nomap = 2;
+ else
+ LANGMAP_ADJUST(c2, TRUE);
+ }
if (mp->m_keys[mlen] != c2)
#else
if (mp->m_keys[mlen] !=



Mit freundlichen Grüßen
Christian
--
Letzte Worte eines Dachdeckers:
"Mensch ist das heute ein Wind"

[Павлов Николай Александрович]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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

This problem was already reported at least once. Do not remember any patches though.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQI1BAEBCgAfBQJUPpinGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj
HhHSvu3cD/9xrJmNrYXD3E2N13YZNJRG8Xns92yJrV7WDN5i5lu9sRBsGGgClLwK
UojjCCJNPPvUwZnLzzt1GzLBBjzOfQ2+E9KoJ0s0LJzyD8nsHJJyGq8sDuvPznwQ
vhOkLfcPp5G2/BejwxSF1ibkYKT78bHPbCOGvstO/QT5JvJhorjde8iVMLkkKOSs
30oUv4FjFePH0PPWRtBoGk9gqYe1JGm0McJwrRx+yigVzMWvPeRv2T2VWUZcCvoP
ecvXRxyKEIKY/57TNFOsdHDjSWYm4+vOHSmLYu/koNlHWmf2gRRB5TElxdx5WZ0d
S0dnrC3NQwNYygK8oS6ch9k2le4SVsatcyasa1N4Cc/0LuAOi7+gtdHVm3E5V2tq
IJZauhiJfTr4GA4482WeYCmYXcDggIfZIuO/Tl7vYGqRNAKr89OmghWEL85+xr/V
p2JmVssvIxQ7gzEyaeSbWIDLnP8Iv9tlXtOYJKo5rBhbzhKZAJTo6yIjhV3ssrQH
/ifLX8rwrZTR2m0OOenwTtz9A1mIOponrLwMWUMy+zdCpCQm7XuGZu3Tkn44UqLX
dx3ggJEyx9QFvMNHwNJwkGFSBHSmGjrIouPNll8uU2nkk0Ad7ADBlvTsw8malG+d
h+AKcGOuXoZJtDq43hJbN75NnFnB71aPl6Q8mSyyMVScnmuqmufn4Q==
=FERe
-----END PGP SIGNATURE-----

[ZyX]

> This problem was already reported at least once. Do not remember any patches though.

https://groups.google.com/forum/#!searchin/vim_dev/langmap$20imap/vim_dev/HJaS5AxwYSE/UxJkOPZRT2EJ

There is an extended discussion there, including reply from Bram (only one):

> We could add an option 'nolangremap' or use a special character in
> 'langmap' to disable remapping.
>
> I'm not sure changing the current behavior of 'langmap' won't break
> someone's scripts or mappings. And the feature has existed for a very
> long time.

[Bram Moolenaar]

Christian Brabandt wrote:

> Bram,
> what is the reason, setting 'lmap' applies to when a mapping is
> remapped?

I can't remember. I believe it has always been this way. Perhaps not
intentionally.

> Consider this:
> ~$ cat lmap.vim
> imap <tab> <Plug>MyPluginEcho
> imap <Plug>MyPluginEcho <c-r>="hello"<cr>
> cmap <tab> <Plug>MyPluginEcho
> cmap <Plug>MyPluginEcho <c-r>="hello"<cr>
> " set lmap=i;k
>
> run vim -u lmap.vim -N
> and type <tab> in insert mode, note, how "hello" is printed in either
> insert mode or command line mode.
> Now do
> :set lmap=i;k
> and do it again. Note that <Plug>MyPluginEcho will be output.
>
> The problem is, setting lmap breaks plugins (see e.g. here:
> http://stackoverflow.com/questions/12450803)
>
> I would consider this is a bug and actually think, that setting 'lmap'
> should never be applied to when recursively resolving a mapping.

Since langmap is supposed to map typed characters, it makes sense that
the RHS of a mapping is not langmapped.

> Also, I do not understand what this part of the help is trying to say:
>
> ,----[ :h 'lmap' ]-
> | This will allow you to activate vim actions without having to switch
> | back and forth between the languages. Your language characters will
> | be understood as normal vim English characters (according to the
> | langmap mappings) in the following cases:
> | o Normal/Visual mode (commands, buffer/register names, user mappings)
> | o Insert/Replace Mode: Register names after CTRL-R
> | o Insert/Replace Mode: Mappings
> | Characters entered in Command-line mode will NOT be affected by
> | this option. Note that this option can be changed at any time
> | allowing to switch between mappings for different languages/encodings.
> | Use a mapping to avoid having to type it each time!
> `----
>
> What are the language characters? What is the relationship to lmap
> mappings?

Language characters is what comes out of the keyboard when switched to a
specific language, e.g. Greek. Then the "a" key produces the "α"
character.

It's possible that this was only tested for when the keyboard produces
non-ascii characters.

> This patch could fix it, but I am not sure, this fixes it correctly.

I think you need to compare mlen to typebuf.tb_maplen.



--
"Time flies like an arrow". So I put an arrow on my desk, now
awaiting one of these time flies showing up.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Christian Brabandt]

Hi Bram!

Okay, here is a patch, that does that when the new option 'langnoremap'
is set (which defaults to off for backwards compatibility)

Best,
Christian
--
Computer sind nicht intelligent. Sie glauben das nur.

[Christian Brabandt]

> Thanks. I'll leave it to others to try it out.

Turns out, the check for langnoremap has to be checked in a couple of
more places.
Here is an updated patch that fixes an issue, that when using <c-r>=
the righthand side would still be langmapped (e.g. when using set
lmap==-)

Therefore, I moved the check for the langnoremap option into the
LANGMAP_ADJUST macro.

> Perhaps we should set the 'langnoremap' option in vimrc_example.vim
> script. Most new users will want it on.

[X] Done

Best,
Christian
--

[Dettorer]

Hi

Le lundi 20 octobre 2014 22:22:26 UTC+2, Christian Brabandt a écrit :
> Turns out, the check for langnoremap has to be checked in a couple of
> more places.
> Here is an updated patch that fixes an issue, that when using <c-r>=
> the righthand side would still be langmapped (e.g. when using set
> lmap==-)
>
> Therefore, I moved the check for the langnoremap option into the
> LANGMAP_ADJUST macro.

Thanks!

It seems to work just fine with me (I'm the one who wanted to remap his
entire keyboard from bépo to qwerty, the langmap I use now is here:
https://bitbucket.org/Dettorer/configuration/src/e338617fa2952b66bd5f2fe2d3742ce126d8d1f9/.vimrc.bepo_langmap?at=master)

However, it raised a few questions related to langmap itself:

1) If I want to, for exemple, remap ';' to ':', with this langmap I have
to do 'noremap ; N' ('N' being then mapped to ':' by the langmap), is it
the expected behaviour?

2) In a sequence, some keys are not mapped by langmap. For exemple the
motion 'f(' (find next '('): the '(' is the bépo's key for '(', it is
not mapped. I don't know if this is expected, but I like that
behaviour. However, in something like 'ci(' (change whithin
parenthesis), the '(' is mapped by langmap (so in bépo I type '9'). This
seems a bit inconsistent.

Anyway, thanks a lot for this patch!

Regards,

--
Dettorer

[Daniel Hahler]

Dettorer wrote:

> However, it raised a few questions related to langmap itself:
>
> 1) If I want to, for exemple, remap ';' to ':', with this langmap I have
> to do 'noremap ; N' ('N' being then mapped to ':' by the langmap), is it
> the expected behaviour?

I don't think so, and the new setting looks like it should prevent just that.

E.g. with:

set showcmd
set langmap=:>,ö:
set langnoremap
map , :

Pressing "," should open the cmdline window, but sends ">".

Is this what you mean?

> 2) In a sequence, some keys are not mapped by langmap. For exemple the
> motion 'f(' (find next '('): the '(' is the bépo's key for '(', it is
> not mapped. I don't know if this is expected, but I like that
> behaviour.

Yes, "f" should always look for what is coming next unmapped.
In my above example, "f:" goes to ":", not ">".

> However, in something like 'ci(' (change whithin
> parenthesis), the '(' is mapped by langmap (so in bépo I type '9'). This
> seems a bit inconsistent.

Confirmed and agreed.


There is another issue when ">" is the target of a langmap (e.g. ":>"):
Pressing ":" shows ":" in the "showcmd" place, until some timeout, where it changes to ">". "set notimeout" makes it stay at ":".
Shouldn't it be ">" from the beginning?

This appears to be specific to the ">" target mapping. It does not happen with langmap=a<.

> Anyway, thanks a lot for this patch!

Yes, thanks a lot, Christian!

It makes the langmap feature much more useful.

Hopefully the issues above can be fixed, too.


Thanks,
Daniel.