On Wed, Dec 30, 2015 at 9:10 PM, Bram Moolenaar
<[email protected]> wrote:
>
>
> Roland Puntaier wrote:
>
> > I've debugged into vim and found the location, in which normal keymap
> > application diverges when playing a register macro (@a).
> >
> > It is in getchar.c: 2189
> >
> > if (mp->m_keys[0] == c1
> > && (mp->m_mode & local_State)
> > && ((mp->m_mode & LANGMAP) == 0
> > || typebuf.tb_maplen == 0))
> >
> > Both (no@a) and (@a) have
> >
> > mp->m_mode == 32 == LANGMAP
> > local_State == 48 == 32+16
> >
> > but only (@a) has: typebuf.tb_maplen > 0
> >
> > Cited from getchar.c regarding the tb_maplen:
> >
> > * The head of the buffer may contain the result of mappings, abbreviations
> > * and @a commands. The length of this part is typebuf.tb_maplen.
> >
> > THE LAST TWO LINES COMMENTED AWAY MADE KEYMAP WORK WITH @a COMMANDS.
> >
> > So before: no LANGMAP for @a. That's what ((mp->m_mode & LANGMAP) == 0 ||
> > typebuf.tb_maplen == 0) says, anyway.
> > With patch: LANGMAP for @a, i.e. without the condition.
>
> The 'keymap' option is meant for when typing text in Insert mode. It
> does not apply to when typing commands, in Normal mode. The 'langmap'
> option is the other way around.
>
> A register contains commands, which may start Insert mode and then
> insert some text. Thus it's a mix. Translating all characters with
> 'keymap' (or 'langmap') will cause problems.
>
> I wonder how you managed to get characters into a register that you want
> to apply 'keymap' or 'langmap' to. This translation should have already
> happened when typing the characters.
>
> > tb_maplen is only set in ins_typebuf(), if the nottyped parameter is TRUE.
> > There are 12 such calls in check_abbr, do_execreg, exec_normal_cmd,
> > server_to_input_buf, put_reedit_in_typebuf, put_in_typebuf.
> > As for abbreviation I found no difference in behavior before and after
> > the patch.
> >
> > Personally I would like to use KEYMAP with @a.
> > I also regard it as a general deficiency, when e.g. a russian guy
> > cannot use @a to insert russian text.
To insert text, I would use "a (or, in Insert mode, ^Ra), not @a. But
then, I very seldom use recording (about the only case is when I wan
something to go on repeating until it errors out). I have set apart
register q for those rare cases; but most of my other registers
contain text strings that I want to be ready to paste anytime. Some
are rather long text which I don't use very often but wouldn't
remember by heart, others are short but frequent. And of course if I
want to be able to repeatedly insert some Russian text I'll put it in
the register in Cyrillic; for English (or French or German or …) I
would put it there in Latin. The help for i_CTRL-R says "The text is
inserted as if you typed it, but mappings and abbreviations are not
used."; language-mappings (keymaps) are not used either, so that e.g.
in an HTML file in Russian, when I hit ^Ri what gets inserted is <i>
(the contents of the register) and not <и> which wouldn't be a proper
HTML tag, even if at that point my "cyrillic-phonetic" keymap is
enabled ('iminsert' = 1).
I'm not very familiar with the 'langmap' option but I would expect
registers containing Cyrillic text to be pasted in Cyrillic and
registers containing Latin text to be pasted in Latin in that case
too. Does 'iminsert' apply to this option too? I couldn't find the
answer in the help for any of 'langmap', 'iminsert' and i_CTRL-^
(maybe translate even text typed in Insert mode when 'iminsert' is 0
[to insert Latin text] but not when it is 1 [to insert Cyrillic
text])?
> > But maybe there are unwanted side effects, I'm not aware of.
> >
> > Bram, maybe you can think of side effects or know why this condition
> > was put there in the first place.
>
> Yes, there are undesired side effects.
>
> --
> ARTHUR: Shut up! Will you shut up!
> DENNIS: Ah, now we see the violence inherent in the system.
> ARTHUR: Shut up!
> DENNIS: Oh! Come and see the violence inherent in the system!
> HELP! HELP! I'm being repressed!
> The Quest for the Holy Grail (Monty Python)
>
> /// Bram Moolenaar -- [email protected] -- 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 ///
--
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
