> This seems useful, but do you _have_ to do all that in a single > function? Perhaps 2. and 3. could be split into separate functions?
It does not make sense as long as 4. exists. > Also, I'd say 4. should just use the actual settings rather than > parse them from a Christmas tree of options. Vim tradition seems to be > to leave it to the user to save and restore the context before doing the > job. There are no options for treating fullwidth characters as single width or for messing with diacritics exactly that way. Also see use-case 5. If I proposed new options *the very first thing* I would implement is a wrapper function for setting and restoring those options that takes a dictionary. Because it is simpler to explain contributors how to configure specific compiler support if it is such dictionary. I know the tradition, but if you check out things like &ignorecase you will see that in one place &ignorecase is ignored, but there is a setting for ignoring case, in other place it is not ignored, but there still is a setting and in the third place there are no options but to use explicit \C/\c. Given that there are exactly no options for some features of this function I propose it would be inconsistent to pass some options in a dictionary and take some other only from environment. -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
