Preventing Double maps/abbs

[howard Schwartz]

I recently discovered a pitfall similar to recursive abbreviations or maps (in
math logic we would would tend to call them `transitive' instead of recursive).

As you know, noremap prevents map a b then map b c thus mapping a to c

But a ran into this dilemma: my friend used these abbreviations and maps:

ab q can map q i ^[
ab gr gramma map g :write^M

thus eliminating the gq formatting command. When I tried to restore it, I
first tried to unmap q

I got the error message, ``No such mapping'' even though the maps command
clearly listedd q as mapped to write. I quickly learned I had to
unabbreviate q before I could unmap q. Similar things applied to the letter g
in order to recover he command gq.

What seems to happen is an interaction between abbreviations and maps: When I
gave the ex command :q <ENTER> upon hitting <ENTER> vim expands q to `can' and
then treats `can' as a write command. When I try to unmap q, I press
<ENTER>. Thus,
q expands to `can' and vim correctly replies ``no such mapping'' meaning
there is no direct map of the latters `can' to a write command.

Multiple abbreviations or maps of the same letters is not a problem, within
maps or ab alone -- ordinarily last definition wins.

What seems to be needed is a version of abbreviate that says ``only abbreviate
these letters, do not use them to map a command''. The modes for maps and ab
do not help, because sometimes one really wants letters expanded on the
command line, for example when executing a substitute command.

And, in general it is an advantage to be able to use the same strings of 1 or
two characters, as both maps and appreviations. For `rabid' abbreviators like
my friend, this gives one more letters to do more things.

Is there some way to prevent this behaviour for some, particular maps or
abbreviations?

[Jürgen Krämer]

Hi,

howard Schwartz wrote:
> I recently discovered a pitfall similar to recursive abbreviations or maps (in
> math logic we would would tend to call them `transitive' instead of recursive).
>
> As you know, noremap prevents map a b then map b c thus mapping a to c
>
> But a ran into this dilemma: my friend used these abbreviations and maps:
>
> ab q can map q i ^[
> ab gr gramma map g :write^M
>
> thus eliminating the gq formatting command. When I tried to restore it, I
> first tried to unmap q

it would probably have been better if your friend had used

iabbrev q can
iabbrev gr gramma
nmap q i ^[
nmap g :write^M

to define the abbreviations and maps, thus restricting them to the modes
where they are really needed.

> I got the error message, ``No such mapping'' even though the maps command
> clearly listedd q as mapped to write. I quickly learned I had to
> unabbreviate q before I could unmap q. Similar things applied to the letter g
> in order to recover he command gq.
>
> What seems to happen is an interaction between abbreviations and maps: When I
> gave the ex command :q <ENTER> upon hitting <ENTER> vim expands q to `can' and
> then treats `can' as a write command. When I try to unmap q, I press
> <ENTER>. Thus,
> q expands to `can' and vim correctly replies ``no such mapping'' meaning
> there is no direct map of the latters `can' to a write command.

For me Vim's reply is

E492: Not an editor command: can

No remapping took place, but "can" is not a recognized command.

> Multiple abbreviations or maps of the same letters is not a problem, within
> maps or ab alone -- ordinarily last definition wins.
>
> What seems to be needed is a version of abbreviate that says ``only abbreviate
> these letters, do not use them to map a command''. The modes for maps and ab
> do not help, because sometimes one really wants letters expanded on the
> command line, for example when executing a substitute command.

There are also [ic]noreabbrev variants which would prevent the
right-hand-side of an abbreviation to be re-used as the left-hand-side
of a mapping.

Regards,
J�rgen

--
Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us. (Calvin)

[howardb21]

On Feb 2, 10:26 pm, Jürgen Krämer <jottka...@googlemail.com> wrote:
> Hi,

>
> There are also [ic]noreabbrev variants which would prevent the
> right-hand-side of an abbreviation to be re-used as the left-hand-side
> of a mapping.

Where do I find these variants? I searched Vim's documentation and
only found versions of nore that prevent re-use of the right had side
of a map or abbreviation. Please point me to the variants.

[Benjamin R. Haskell]

Those are the variants.

:nmap a bcd
:nmap b ef

Means that 'a' would turn into 'bcd', which then gets remapped, turning
into 'efcd'.

:nnoremap a bcd
:nnoremap b ef

Means that 'a' would turn into 'bcd', but it stays 'bcd' because of the
no-re-mapping.

--
Best,
Ben

[Jürgen Krämer]

Hi,

howardb21 wrote:

> On Feb 2, 10:26 pm, J�rgen Kr�mer <jottka...@googlemail.com> wrote:
>>
>> There are also [ic]noreabbrev variants which would prevent the
>> right-hand-side of an abbreviation to be re-used as the left-hand-side
>> of a mapping.
>
> Where do I find these variants? I searched Vim's documentation and
> only found versions of nore that prevent re-use of the right had side
> of a map or abbreviation. Please point me to the variants.

:help :cnoreabbrev
:help :inoreabbrev

[howardb21]

On Feb 5, 11:35 pm, Jürgen Krämer <jottka...@googlemail.com> wrote:
> Hi,
>
> howardb21 wrote:
> > On Feb 2, 10:26 pm, J rgen Kr mer <jottka...@googlemail.com> wrote:
>
> >> There are also [ic]noreabbrev variants which would prevent the
> >> right-hand-side of an abbreviation to be re-used as the left-hand-side
> >> of a mapping.
>
> > Where do I find these variants?

>   :help :cnoreabbrev
>   :help :inoreabbrev
>
> Regards,
> J rgen

Pardon my ignorance, but the variants of noremap o noeabbrev, simply
prevent the
the second member of a map/abbreviation from being used as a first
member in another map/abrev. OR they restrict a mapping/abrev to one
mode only.

If I go :inoreabbrev g group

this prevents group from being
used as an abbreviation, and prevents, `g' from being expanded on the
command line. but it does not prevent `g' from being used in Another
map or abbreviation anywhere. It g is used for another insert mode
abbreviation - not too bad - last definition will win. If it it done
in command or normal mode, than g will
act differently in insert, normal, command, even visual modes and
never, perhaps act as as the original `go' command of normal mode.

It still seems, there is no way to map or abrev a character in such a
way that this character is prohibited from being mapped or abrev'ed
again, unless the original
map/abrev is undone.

[Jürgen Krämer]

Hi,

howardb21 wrote:

>
> On Feb 5, 11:35 pm, J�rgen Kr�mer <jottka...@googlemail.com> wrote:
>> Hi,
>>
>> howardb21 wrote:
>>> On Feb 2, 10:26 pm, J rgen Kr mer <jottka...@googlemail.com> wrote:
>>
>>>> There are also [ic]noreabbrev variants which would prevent the
>>>> right-hand-side of an abbreviation to be re-used as the left-hand-side
>>>> of a mapping.
>>
>>> Where do I find these variants?
>
>> :help :cnoreabbrev
>> :help :inoreabbrev
>>
>> Regards,
>> J rgen
>
> Pardon my ignorance, but the variants of noremap o noeabbrev, simply
> prevent the
> the second member of a map/abbreviation from being used as a first
> member in another map/abrev. OR they restrict a mapping/abrev to one
> mode only.
>
> If I go :inoreabbrev g group
>
> this prevents group from being
> used as an abbreviation, and prevents, `g' from being expanded on the
> command line.

yes, the leading "i" and "c" restrict the abbreviation to insert mode
and command-line mode, respectively. The "nore" part prevents the just
expanded right-hand-side ("group" in your case) from being immediately
used as the left-hand-side of a map. E.g., if you had defined

:iabbrev g group
:imap group <c-o>:echo "This is my group."<cr>

and you enter "g" and a space in insert mode, only the space would be
inserted into the buffer and the text "This is my group." would be
echoed on the command line.

> but it does not prevent `g' from being used in Another
> map or abbreviation anywhere. It g is used for another insert mode
> abbreviation - not too bad - last definition will win. If it it done
> in command or normal mode, than g will
> act differently in insert, normal, command, even visual modes and
> never, perhaps act as as the original `go' command of normal mode.
>
> It still seems, there is no way to map or abrev a character in such a
> way that this character is prohibited from being mapped or abrev'ed
> again, unless the original
> map/abrev is undone.

There is the <unique> flag for maps and abbreviations (see

:help :map-<unique>

), which prevents you from redefining/overwriting a map or abbreviation,
though it seems a map can still be overwritten by an abbreviation and
vice versa.