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

Re: RFC: Two option-handling techniques for scripts

Expand Messages
  • Charles Campbell
    ... FYI -- that s (probably) PluginKiller (http://vim.sourceforge.net/scripts/script.php?script_id=1489) ... Sounds good to me; sounds like my attempts to
    Message 1 of 2 , Mar 25, 2009
    • 0 Attachment
      Ben Fritz wrote:
      > >From many discussions I've had in the past, and from my own limited
      > first-hand experience, I have learned that one of the biggest hurdles
      > to writing a robust vim script to distribute to other people is
      > dealing with the hundreds of options that Vim has, many of which
      > potentially cause your script to do unexpected things. Dr. Chip has
      > even made a plugin that attempts to check these options in an effort
      > to make things easier, but I have not heard it mentioned very often.

      FYI -- that's (probably) PluginKiller

      > I propose two alternate methods to solving this problem, each of which
      > add new functionality and should therefore break no backwards
      > compatibility (though it will cause scripts utilizing the method to
      > not work on older Vims without the functionality; I would think this
      > is to be expected).
      > Method 1: Script-local options
      > [snip]
      > This method would add a command, :setscript, that behaves just
      > like :setlocal, except that the option will only be read during script
      > execution, or during execution of commands defined in the script.
      > [snip]

      Sounds good to me; sounds like my attempts to save&restore options,
      except to push that capability into vim. I'd hope that setscript would
      avoid the option-last-set-from (the scriptname here). As is, the
      save&restore means that the script which does that effectively prevents
      knowing what, if anything, really changed the option last.

      There may be complications with multiple
      setscript &all
      calls -- as in when should it, if ever, be ignored, and when should the
      options be restored. I'm thinking about a script that calls upon a
      different script's mappings/commands/functions/whatnot. Some scripts
      have multiple entry points, and so may themselves have multiple
      setscript &all calls within them (or perhaps multiple ways to call the
      same function with a setscript &all call).
      > Method 2: create an "option stack"
      > This method was already discussed here, briefly, in the middle of this
      > thread:
      > http://groups.google.com/group/vim_dev/browse_thread/thread/92bce4a37ae9858f/07cda2bd46fc62b4?lnk=gst&q=option+stack#07cda2bd46fc62b4
      > Typical use would be as follows:
      > optionpush
      > setlocal all&
      > ...
      > command foo optionpush | call s:Func() | optionpop
      > ...
      > optionpop
      > [snip]

      I'll mention one option that this process doesn't help with:
      equalalways. Setting it causes the window sizes to be adjusted, so one
      cannot do a save&restore and avoid the option's effect. There may well
      be other such options which affect things immediately upon being set.
      This problem with immediate effects may affect the setscript idea, too.
      The "option-last-set-from-..." information is also polluted.

      Chip Campbell

      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.