coallesce mayset queries

[mralusw]

Well, you were right in #191 that anything other then verb setg all q? moves the cursor. That was not readily apparent from the repo's history, and I still can't find the explanation. I've tried several approaches with no luck.

The approach in this PR is to query all settings of interest at once in the beginning. Finding the appropriate query + answer for each checked setting, then, requires just a little tweaking of your initial "home" regex. A downside is that any future queries will need to be registered in s:mayset_checks before usage.

It may not matter much on modern machines, but the previous version is a little slow on old boxes and on "semi"-embedded — at least as a percentage of a modest vimrc's startup time. Make of it what you will.

I've left some debug checks commented out, as they might come in handy.

[tpope]

A downside is that any future queries will need to be registered in s:mayset_checks before usage.

Let's fix this. Instead of s:MaySet(), let's have a s:DefaultSet() that records the option and value.

let s:defaults = {}
function! s:DefaultSet(option, value) abort
  let s:defaults[a:option] = a:value
endfunction

At the bottom of the plugin, we can set each option after we check for it.

Please limit to Vim 7.4 compatible syntax: No lambdas, no #{}.

[mralusw]

Great idea — I've just force-pushed an implementation. It's still faster than before and it also simplifies the configuration part.

At the bottom of the plugin, we can set each option after we check for it.

… though I'm not sure if :set order matters for some of these options. I've tried to minimize changes. In particular, all MaySet() defaults are executed in one fell swoop just before the syntax / ftplugin / mappings, and in the same relative order, just as they would occur previously (instead of at the very end as you seem to suggest). However, non-MaySet() defaults are all executed before the MaySet() ones.

[mralusw]

I've cleaned up the commits and added code to support un-queried (non-Mayset()) options via the same interface. I don't really see the point of forcing all :set's to go through the same interface, TBH, so the last two commits are probably overkill.