On Sunday, November 17, 2013 3:02:17 PM UTC-5, Bram Moolenaar wrote:
> Ben Fritz wrote:
> 
> 
> 
> > On Thursday, November 14, 2013 8:52:22 AM UTC-6, Ben Fritz wrote:
> 
> > > On Wednesday, November 13, 2013 10:29:18 PM UTC-6, Bram Moolenaar wrote:
> 
> > > > Daniel Thau wrote:
> 
> > > > > Attached is a patch to add an 'autotextobject' setting which will 
> > > > > treat
> 
> > > > > undefined text-objects like quote text objects, using the provided
> 
> > > > > character as bounds.  For example, with this setting if a user enters
> 
> > > > > "di," with the cursor between two commas, the text between the commas
> 
> > > > > will be removed. 
> 
> > > > 
> 
> > > > I don't think this can be done properly without adding another
> 
> > > > character, thus making the text selection a three-character operation.
> 
> > > > 
> 
> > > 
> 
> > > Why not? What is the reasoning behind a third character?
> 
> > 
> 
> > Oh, I think I get it now.
> 
> > 
> 
> > I actually think this could work really well.
> 
> > 
> 
> > What about another DEFINED text object, that would work on pairs of
> 
> > arbitrary characters? Only that one text object would work this way, the
> 
> > rest would be as they are now.
> 
> > 
> 
> > Then a user could type something like "vam," for "a matched , pair" or
> 
> > "dim^" for "delete inside matched ^ pair".
> 
> > 
> 
> > If the new text object "im{char}" and "am{char}" were used instead of an
> 
> > undefined and future incompatible "i{char}" and "a{char}" then you don't
> 
> > need to worry about future changes breaking scripts or anything like
> 
> > that. Additionally you can use this feature for alternate behaviors for
> 
> > currently defined text object characters, for example if you want to
> 
> > change inside B characters for some reason, or inside >> operators in
> 
> > C/C++, etc.
> 
> 
> 
> Yes, that's exactly what I was thinking.
> 
> 
> 
> We can document that "this command may break if a future version of Vim
> 
> adds another text object", but users will be upset if we break their
> 
> commands no matter what.  Once users are used to something we should
> 
> make sure it keeps working.
> 
> 
> 
> I also like that you can match any character, including the ones already
> 
> used for text objects, such as '>' and 't'.
> 
> 
> 
> It's another character to type, that's true.
> 
> 
> 
> -- 
> 
> Hacker: Someone skilled in computer programming (good guy).
> 
> Cracker: A hacker that uses his skills to crack software (bad guy).
> 
> 
> 
>  /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
> 
> ///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> 
> \\\  an exciting new programming language -- http://www.Zimbu.org        ///
> 
>  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

I can live happily with that.  I'll modify the patch and submit a new one 
accordingly.  Two questions, then:

(1) Any objections to dropping the setting for this?  With this new version in 
mind the setting no longer seems beneficial.
(2) Any preferences on what character should be used to utilize it?  I'm 
tempted to go with both "i" and "a" if there are no objections, so that one can 
do (for example) "dii$" or "caa|".

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

Raspunde prin e-mail lui