Loading ...
Sorry, an error occurred while loading the content.

Re: RFE: Prevent maps from being overwritten with :map

Expand Messages
  • Antony Scriven
    ... Okay, :s/cannot/& practicably/ You d have to put in a plugin, in your after directory, lines such as au ... * map x foo where ... covers all
    Message 1 of 14 , May 28 8:23 AM
    • 0 Attachment
      2008/5/28 Ben Schmidt <mail_ben_schmidt@...>:

      > > 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
      -~----------~----~----~----~------~----~------~--~---
    • Antony Scriven
      ... Thanks. I think I ll have to resort to this, but with a longer list of autocommands: I don t appear to be garnering much support! I still think it s a
      Message 2 of 14 , May 28 8:46 AM
      • 0 Attachment
        2008/5/28 Tony Mechelynck <antoine.mechelynck@...>:

        > [...]
        >
        > You could even use
        >
        > : au VimEnter * au FileType * map <buffer> {lhs} {rhs}

        Thanks. I think I'll have to resort to this, but with a longer
        list of autocommands: I don't appear to be garnering much
        support! I still think it's a nasty hack though. --Antony

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_dev" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Meikel Brandmeyer
        Hello, ... Maybe the community of active plugin developers should consider a kind of Plugin Writer s Codex -- how should a plugin behave. Such a codex should
        Message 3 of 14 , May 28 10:03 AM
        • 0 Attachment
          Hello,

          > No worries, but I'd argue that they are not solutions since
          > they aren't currently working for me. I don't think the user
          > should be penalised if a plugin writer doesn't check for
          > existing mappings. The way it stands right now a user cannot
          > prevent a plugin writer from overwriting their maps. I'd
          > like to be able to define a map in my vimrc and not have it
          > be unexpectedly redefined in certain buffers, similar to the
          > may you might use use the `final' keyword in Java. Do you
          > foresee any problems in allowing users to do this?

          Maybe the community of active plugin developers should
          consider a kind of "Plugin Writer's Codex" -- how should a
          plugin behave.

          Such a codex should be small and simple in order to not
          shy away the casual plugin writer. But it should focus on
          a few important points and it should be actively advertised
          by the more "professional" authors.

          One possible point could be:
          - a common way to make mappings optional

          Maybe a second-level could be provided for those who
          want to dive deeper into plugin writing:
          - use <Plug>
          - use <Leader>

          Putting the burden on the user who has to take radical
          actions to get a plugin to behave well is really not an
          option for me. I think, with a high quality standard of the
          "professional" plugins, which are not only single shots to
          solve an immediate problem, the community would
          benefit in general.

          Just my 2¢.

          Sincerely
          Meikel


          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_dev" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • Erik Falor
          ... Much, if not all of your points are addressed in :help write-plugin. Maybe we just need to get the word out to plugin developers? Could a link to this doc
          Message 4 of 14 , May 28 10:51 AM
          • 0 Attachment
            On 5/28/08, Meikel Brandmeyer <mb@...> wrote:

            Hello,


            > No worries, but I'd argue that they are not solutions since
            > they aren't currently working for me. I don't think the user
            > should be penalised if a plugin writer doesn't check for
            > existing mappings. The way it stands right now a user cannot
            > prevent a plugin writer from overwriting their maps. I'd
            > like to be able to define a map in my vimrc and not have it
            > be unexpectedly redefined in certain buffers, similar to the
            > may you might use use the `final' keyword in Java. Do you
            > foresee any problems in allowing users to do this?


            Maybe the community of active plugin developers should
            consider a kind of "Plugin Writer's Codex" -- how should a
            plugin behave.

            Such a codex should be small and simple in order to not
            shy away the casual plugin writer. But it should focus on
            a few important points and it should be actively advertised
            by the more "professional" authors.

            One possible point could be:
              - a common way to make mappings optional

            Maybe a second-level could be provided for those who
            want to dive deeper into plugin writing:
              - use <Plug>
              - use <Leader>

            Putting the burden on the user who has to take radical
            actions to get a plugin to behave well is really not an
            option for me. I think, with a high quality standard of the
            "professional" plugins, which are not only single shots to
            solve an immediate problem, the community would
            benefit in general.

            Just my 2¢.

            Much, if not all of your points are addressed in :help write-plugin.  Maybe we just need to get the word out to plugin developers?
            Could a link to this doc be added to the scripts page on vim.sf.net?  Then no one would have any excuse for not reading it.

            Sincerely

            Meikel




            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_dev" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---

          • Erik Falor
            ... s/Much/Many/ Dang public school education. Sincerely ... -- Erik Falor Registered Linux User #445632 http://counter.li.org
            Message 5 of 14 , May 28 10:52 AM
            • 0 Attachment
              On 5/28/08, Erik Falor <ewfalor@...> wrote:


              On 5/28/08, Meikel Brandmeyer <mb@...> wrote:

              Hello,


              > No worries, but I'd argue that they are not solutions since
              > they aren't currently working for me. I don't think the user
              > should be penalised if a plugin writer doesn't check for
              > existing mappings. The way it stands right now a user cannot
              > prevent a plugin writer from overwriting their maps. I'd
              > like to be able to define a map in my vimrc and not have it
              > be unexpectedly redefined in certain buffers, similar to the
              > may you might use use the `final' keyword in Java. Do you
              > foresee any problems in allowing users to do this?


              Maybe the community of active plugin developers should
              consider a kind of "Plugin Writer's Codex" -- how should a
              plugin behave.

              Such a codex should be small and simple in order to not
              shy away the casual plugin writer. But it should focus on
              a few important points and it should be actively advertised
              by the more "professional" authors.

              One possible point could be:
                - a common way to make mappings optional

              Maybe a second-level could be provided for those who
              want to dive deeper into plugin writing:
                - use <Plug>
                - use <Leader>

              Putting the burden on the user who has to take radical
              actions to get a plugin to behave well is really not an
              option for me. I think, with a high quality standard of the
              "professional" plugins, which are not only single shots to
              solve an immediate problem, the community would
              benefit in general.

              Just my 2¢.

              Much, if not all of your points are addressed in :help write-plugin.  Maybe we just need to get the word out to plugin developers?
              Could a link to this doc be added to the scripts page on vim.sf.net?  Then no one would have any excuse for not reading it.

              s/Much/Many/
              Dang public school education.

              Sincerely

              Meikel






              --
              Erik Falor
              Registered Linux User #445632 http://counter.li.org
              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_dev" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---

            • Tony Mechelynck
              ... If there are several you can define them in a function; if there are many you can put them in a separate script; then you can call that function or source
              Message 6 of 14 , May 28 5:34 PM
              • 0 Attachment
                On 28/05/08 17:46, Antony Scriven wrote:
                > 2008/5/28 Tony Mechelynck<antoine.mechelynck@...>:
                >
                > > [...]
                > >
                > > You could even use
                > >
                > > : au VimEnter * au FileType * map<buffer> {lhs} {rhs}
                >
                > Thanks. I think I'll have to resort to this, but with a longer
                > list of autocommands: I don't appear to be garnering much
                > support! I still think it's a nasty hack though. --Antony

                If there are several you can define them in a function; if there are
                many you can put them in a separate script; then you can call that
                function or source that script from the VimEnter autocommand.

                Or, to make it "less of a nasty hack", put your mappings in a script and
                place that script in ~/.vim/after/plugin/ (on Unix) or in
                ~/vimfiles/after/plugin/ (on Windows) (creating the directories if they
                don't yet exist): as an after-plugin you can be sure that it will be
                sourced _after_ all "standard" plugins from $VIMRUNTIME/plugin/. In
                addition (at least on Unix) you can give that script a name starting in
                zz (such as zzzzmaps.vim) so that it will even be sourced after the
                other after-plugins.


                Best regards,
                Tony.
                --
                Command, n.:
                Statement presented by a human and accepted by a computer in
                such a manner as to make the human feel as if he is in control.

                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_dev" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              Your message has been successfully submitted and would be delivered to recipients shortly.