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

Re: Add :function defaults: resets some options that are likely to cause problems when function is run

Expand Messages
  • ZyX
    ... Agreeing here: things I was thinking of when adding to list are easily avoided using &buftype or :{command}!. ... Wondering what purposes may make user set
    Message 1 of 11 , Jan 15, 2013
    • 0 Attachment
      > Why is 'confirm' on the list? What problems does it cause in a script, when Vim would fail, but instead asks the user what to do?

      Agreeing here: things I was thinking of when adding to list are easily avoided using &buftype or :{command}!.

      > 'eventignore' also confuses me. Although it makes sense that it could cause problems, ignoring it would be a very bad idea, it's only ever set by the user for a specific purpose.

      Wondering what purposes may make user set this option? From my experience it is set by plugins for temporary disabling some things and can easily be skipped to restore by interrupting: GLVS, netrw (:noautocmd in some cases would be better) (but it launches commands which result in much less calculations — and much less possibility to interrupt; except for one place), tar.vim (same about :noautocmd in some cases), vimball.vim, zip.vim. Exactly none of them bothered with using :try…:finally, there will be more if I examine ~/.vam (folder with plugins installed by VAM) in place of /usr/share/vim.

      --
      You received this message from the "vim_dev" 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
    • Ben Fritz
      ... Yes, you re right, I see it used by user scripts or plugins which need to make changes to buffers quickly without triggering potentially slow autocmds
      Message 2 of 11 , Jan 15, 2013
      • 0 Attachment
        On Tuesday, January 15, 2013 1:51:05 PM UTC-6, ZyX wrote:
        > > 'eventignore' also confuses me. Although it makes sense that it could cause problems, ignoring it would be a very bad idea, it's only ever set by the user for a specific purpose.
        >
        >
        >
        > Wondering what purposes may make user set this option? From my experience it is set by plugins for temporary disabling some things and can easily be skipped to restore by interrupting: GLVS, netrw (:noautocmd in some cases would be better) (but it launches commands which result in much less calculations — and much less possibility to interrupt; except for one place), tar.vim (same about :noautocmd in some cases), vimball.vim, zip.vim. Exactly none of them bothered with using :try…:finally, there will be more if I examine ~/.vam (folder with plugins installed by VAM) in place of /usr/share/vim.

        Yes, you're right, I see it used by user scripts or plugins which need to make changes to buffers quickly without triggering potentially slow autocmds which are not needed for the new buffer.

        While you're correct that doing so leaves the possibility of the script or plugin accidentally leaving 'eventignore' at a bad value, it's worse in my opinion to ignore the 'eventignore' setting and just run a plugin's events anyway, if a plugin function triggers an autocmd event.

        How frustrating would it be, to set 'eventignore' to BufRead, to prevent Vim from doing any processing on a buffer you intend to throw away anyway, only to have another plugin ignore your settings and do a bunch of stuff on the read anyway?

        --
        You received this message from the "vim_dev" 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
      • ZyX
        ... How would it happen? You need explicit :e or like in :fun-defaults function because otherwise &ei setting will be restored back before autocommand in
        Message 3 of 11 , Jan 15, 2013
        • 0 Attachment
          > How frustrating would it be, to set 'eventignore' to BufRead, to prevent Vim from doing any processing on a buffer you intend to throw away anyway, only to have another plugin ignore your settings and do a bunch of stuff on the read anyway?

          How would it happen? You need explicit :e or like in :fun-defaults function because otherwise &ei setting will be restored back before autocommand in question has a chance to be run, no matter whether :fun-defaults function is run from non-ignored autocmd (it cannot cover more then :autocmd body, if it consists solely of “:call FunDefaults(…)”, much likely it will be restored before any other :autocmd is run, otherwise it covers only nested autocommands), plain function call/mapping/command which you for some reason put into event-ignoring block (it is restored before you create that buffer in this case) or such. The only case where it will happen is making :fun-defaults function open the buffer for you. I know no examples of the code where you make third-party (your own one can be edited and thus is your problem) function open the buffer for you, only some of third-party processing after the buffer was opened; and of that kind which is done without triggering autocommands, except for a few Shell*.

          --
          You received this message from the "vim_dev" 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
        Your message has been successfully submitted and would be delivered to recipients shortly.