On Thursday, November 14, 2013 1:28:50 PM UTC-5, Kent Sibilev wrote: > On Thursday, November 14, 2013 11:28:45 AM UTC-5, Daniel "paradigm" Thau > wrote: > > > On Thursday, November 14, 2013 11:01:56 AM UTC-5, Kent Sibilev wrote: > > > > On Thursday, November 14, 2013 6:24:42 AM UTC-5, Daniel "paradigm" Thau > > > wrote: > > > > > Vim tries to use the existing text-objects with a function for each type of > > object, then if an invalid specifier is provided it falls back to "flag = > > FAIL". All my patch does is wrap that "flag = FAIL" at the end in an > > if-check against the setting I added and, if the setting is set, do a > > > > > > flag = current_quote(cap->oap, cap->count1, include, cap->nchar); > > > > > > i.e.: fall back to treating it like quotes are treated if an object is > > requested that isn't (yet) defined. > > > > > > > > > [skip] > > > > > > My argument for this patch really boils down to the following: > > > > > > As Vim acts now, most of the "<operator>[ai]<character>" namespace is > > completely unused. Reserving it for future use doesn't benefit anyone > > nearly as much as having it do something sane/useful. A trivially small > > patch can be used to have do something useful in the unused part of that > > namespace (without touching the used part at all). A disclaimer - plus the > > fact it is a default-off setting - can be made (and is, in the patch) so > > that people do not rely on those keystrokes always acting the same. > > > > I agree with what you are saying. My only complain is that your patch > provides a single fallback algorithm, in particular relying on current_quote > function. What I would like is to have a more general solution where I can > specify my own function to execute based on the pressed character.
I'm not sure I completely follow. I'll try to rephase what I think you're saying: >From what I understand, you're requesting a system to make it easy for >end-users to add new text-objects. There are plenty of plugins to do this >(you've listed some), but the problem with them is that they re-implement >things that Vim already has code for, since Vim does not expose this code in >any way a plugin could access. Am I close? If so, while I agree that would be a good thing, I don't see how it is necessarily relevant here. The idea behind my patch is that after the defined text-object code - either vim's hardcoded stuff or your new end-user-definable-stuff - there is free namespace. It'd be a separate patch - I don't think this patch necessarily needs to keep your proposed patch in mind. The only way I could see the two ideas being connected is that maybe another algorithm could be set for the catch-all; however, I can't see how any of the other ones would be used. current_block() requires both bounds be provided, and for the catch-all we're only given one character - what would we use for the other bound? Everything else - current_word(), current_par(), current_sent() - are all hardcoded to only do one thing. The only sane option I see for a generic fall-back is current_quote, which is designed for both bounds being the same. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
