> I like the idea, as dealing with all the different options is indeed painful 
> for
> script writers. On the other hand, it's not that by setting this flag, you can
> now completely forget about the differences; it depends on what your function 
> is
> actually doing, there may be other options affecting your functions, and
> sometime you do want to observe e.g. the 'ignorecase' setting.

I collected the most problematic global options (from my own article). Using 
local ones will be tricky (to forget you need to save and then restore options 
for all buffers and windows). Though I now realize that I need more and should 
have actually used options.txt directly and not options.txt indirectly through 
article:

    'autochdir'
    'autowrite'
    'autowriteall'
    'backspace'
    ?'backup'
    ?'backupcopy'
    'breakat'
    ?'cdpath'
    ??'clipboard'
    ?'cmdheight'
    'confirm'
    'delcombine'
    'digraph'
    'eadirection'
    'edcompatible'
    'equalalways'
    'eventignore'
    'foldlevelstart'
    'foldopen'
    'guipty'
    ??'hidden'
    'insertmode'
    'isfname'
    'isident'
    'isprint'
    'joinspaces'
    'langmap'
    ?'loadplugins'
    ??'maxcombine'
    'more'
    'paste'
    ?'pastetoggle'
    ?'report'
    'revins'
    ?'scrolloff'
    ??'scrollopt'
    ?'shortmess'
    'showbreak' (changes virtcol() output)
    ?'sidescroll'
    ?'sidescrolloff'
    'smarttab'
    'splitbelow'
    'splitright'
    'switchbuf'
    'tagstack'
    'tildeop'
    ???'undolevels'
    'updatetime'
    ?'warn'
    'whichwrap'
    ?'wildcharm'
    'wildignore'
    'wildignorecase'
    'write'
    'writeany'
Any comments?

> Add to that that for backwards compatibility, scripts have to accommodate the
> various settings for a long time to come, and it's less helpful - at least in
> the near time frame.

Yes, indeed. Though it is mitigated with compatibility library defining 
wrapping function that either has `defaults` or uses try…finally. It is just 
the same for all new useful functions.

> Also note that resetting 'selection' may help with making and modifying a
> selection entirely within your function, but based on my experience, when you
> want to work on an existing selection made by the user or leave a selection
> behind (as in a text object), you have to consider the actual 'selection' 
> value,
> as the end position '> is not automatically adjusted when the option changes.

Will look into the issue.

-- 
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

Raspunde prin e-mail lui