Preventing Double maps/abbs

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?

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