Re: Triggering abbrevs
Ben Schmidt schrieb:
The builtin Escape key already expands abbrevs. Isn't this like a
part of its definition? If I put esc on the right side of a
noremap, I do this in order to get this builtin behaviour.
I disagree. If *I* put Esc on the right hand side of a mapping I do
it to get the builtin behaviour of 'exit insert mode', not 'change the
text in user-customised ways and then exit insert mode'.
But more importantly, if I put something like iword on the right
hand side of a mapping, I expect 'word' to be inserted, not expanded
as an abbreviation.
Much more important is if I put ':command something' on the right hand
side of a mapping, I expect ':command' to get executed, not something
else that the user has defined as an abbreviation.
I would think a good number of scripts would break if the
interpretation were yours and thus the behaviour changed (any mapping
that inserts text has the potential to break!).
The scripts wouldn't break. Of course an abbreviation given in the
{rhs} of a :noremap is not to be expanded, just like any other user
mapping.
My example
:ino esc esc
targets an abbreviation that is not part of the mapping, but already to
be found in the text.
At least a dedicated key like i_Ctrl-] should work always.
Mmm. Looks like we all agree on that one.
Ok :-)
--
Andy
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Triggering abbrevs
Of course an abbreviation given in the
{rhs} of a :noremap is not to be expanded, just like any other user
mapping.
My example
:ino esc esc
targets an abbreviation that is not part of the mapping, but already to
be found in the text.
That makes sense. I didn't realise you were drawing that distinction, but just
thought you had a 'minimal test case'. I guess that would be fair enough,
though
I'd probably still personally prefer the consistency of a noremap never
expanding
abbreviations without an explicit C-].
Ben.
Send instant messages to your online friends http://au.messenger.yahoo.com
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Triggering abbrevs
1. abbrevs are not triggered by a mapping when remapping is off: abbrevs not triggered: :ino esc esc :ino esc c-]esc abbrevs triggered as expected: :imap esc esc :imap esc c-]esc| careful, endless loop I'd like to have abbrevs expanded in all situations. I think that could be quite 'unsafe' to trigger without an explicit command. The whole point of noremap is to ignore all user customisations so that Vim behaves completely predictably. Expanding abbreviations would undermine this. It wouldn't be so bad in insert mode as in command mode, but it still would be bad. But if C-] is a command to expand an abbreviation, then indeed, it should surely do so even for a noremap, as that is its function! I would say it's a bug that that doesn't work. 2. The key i_Ctrl-] is supposed to trigger an abbrev without inserting a character. Now it does insert itself if there is no abbrev to expand. How is this useful in any way? IMHO it should never insert itself. I would agree with that. If it's a command, it should be a command; if it's not a command, it should insert itself; it shouldn't decide on the spur of the moment which it wants to be. I'd probably call that a bug too. My Vim exhibits the same behaviours. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Triggering abbrevs
Ben Schmidt schrieb: 1. abbrevs are not triggered by a mapping when remapping is off: abbrevs not triggered: :ino esc esc :ino esc c-]esc abbrevs triggered as expected: :imap esc esc :imap esc c-]esc| careful, endless loop I'd like to have abbrevs expanded in all situations. I think that could be quite 'unsafe' to trigger without an explicit command. The whole point of noremap is to ignore all user customisations so that Vim behaves completely predictably. Expanding abbreviations would undermine this. It wouldn't be so bad in insert mode as in command mode, but it still would be bad. The builtin Escape key already expands abbrevs. Isn't this like a part of its definition? If I put esc on the right side of a noremap, I do this in order to get this builtin behaviour. I cannot see why :noremap has to do with abbrev expansion, IMHO it's not a related thing. At least a dedicated key like i_Ctrl-] should work always. The current behaviour looks like a side effect by accident, also because it seems to be ignored in the help. -- Andy --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Triggering abbrevs
The builtin Escape key already expands abbrevs. Isn't this like a part of its definition? If I put esc on the right side of a noremap, I do this in order to get this builtin behaviour. I disagree. If *I* put Esc on the right hand side of a mapping I do it to get the builtin behaviour of 'exit insert mode', not 'change the text in user-customised ways and then exit insert mode'. But more importantly, if I put something like iword on the right hand side of a mapping, I expect 'word' to be inserted, not expanded as an abbreviation. Much more important is if I put ':command something' on the right hand side of a mapping, I expect ':command' to get executed, not something else that the user has defined as an abbreviation. I would think a good number of scripts would break if the interpretation were yours and thus the behaviour changed (any mapping that inserts text has the potential to break!). At least a dedicated key like i_Ctrl-] should work always. Mmm. Looks like we all agree on that one. The current behaviour looks like a side effect by accident, also because it seems to be ignored in the help. Fair point. And as they say, if a program is useful, it will have to be changed; if a program is useless, it will have to be documented. Even if the behaviour isn't ideal, at least if it's documented, people know what to expect--and if a workaround is documented, too, unwanted side effects can be avoided. Of course, we don't have a workaround for all of it yet... Grins, Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
