2008/5/28 Ben Schmidt <[EMAIL PROTECTED]>: > > The way it stands right now a user cannot > > prevent a plugin writer from overwriting their maps. > > Yes they can, as detailed by a previous poster, using > autocommands or after scripts the user can have the last > say.
Okay, :s/cannot/& practicably/ You'd have to put in a plugin, in your after directory, lines such as au ... * map <buffer> \x foo where ... covers all autocommands (unless you know a neater fix). Is it right to place that burden on the user? > There is also the solution most of us use for Emacs. The > user can choose not to install the plugin. Pretty much no > matter how much effort is put in, people will still be > able to write bad code, bad interfaces, etc., etc., and > it's the user's choice whether they make use of it. What if the user wants the plugin, but doesn't want that plugin to overwrite a couple of the mappings that already exist in the user's vimrc (e.g. plugins distributed with Vim). Tough for the user? > I think a <final> modifier to a map would just become > a bit awkward figuring out what its scope should be, > etc.: should it apply to all mappings, buffer-local and > global? Yes, I think that would be simplest. > It could also just start making more problems, too...e.g. > what if a plugin author (ab)used it? You'd end up with an > almost indestructible plugin rather than allowing the > user to have another say later as they can now, etc.. What's the incentive for the plugin writer to do that? In the current situation plugin authors need to make an effort to make all the necessary checks to avoid overwriting a user's mapping. This just doesn't happen in practice, and the user is the one that loses out. For a plugin author not to use <final> would require no effort. Additionally if a plugin author used <final> in a map that you've already used in your vimrc it wouldn't have any effect. May I also inquire again, are constants not useful when programming? --Antony P.S. I've had plugins overwrite my commands too! --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
