On Tuesday, June 17, 2014 1:17:02 PM UTC-4, Tom McDonald wrote:
> On Friday, January 31, 2014 2:52:38 PM UTC-5, Daniel "paradigm" Thau wrote:
> > On Wednesday, January 29, 2014 7:40:10 PM UTC-5, Daniel "paradigm" Thau 
> > wrote:
> > > Apologies for the delay.
> > > 
> > > Review for those who have forgotten and/or don't care to backread:
> > > 
> > > With this patch, if the user attempts to use a block textobject 
> > > (parenthesis, square brackets, curley brackets, angle brackets) and the 
> > > cursor is not already within the object, vim will search for the object 
> > > in a given direction.  For example, if the cursor is on one of the "l"'s 
> > > below and the user enters "ci)OK<esc>"
> > > 
> > >     lll(mmm)rrr
> > > 
> > > the following will result:
> > > 
> > >     lll(OK)rrr
> > > 
> > > Note that this should not touch any already valid Vim input; only in the 
> > > contexts where block text object commands do *not* already work does this 
> > > do anything.
> > > 
> > > I've been using it quite happily for the last two months or so, but more 
> > > eyes and testing would not be a bad idea.
> > > 
> > > Attached is the patch, in both unified and context format, including a 
> > > test.
> > 
> > Forgot to include the alternations for the Makefile to include the new 
> > test; should be fixed in this attachment.
> 
> I'm getting the feeling that this would cause pain in some scenarios. 
> Consider JavaScript code like this:
> 
>     var Foo = augment(Object, function () {
> 
>         this.method = function () {
>             // some method
>         };
> 
>         this.otherMethod = function (a, b, c) {
>             // some other method
>         };
> 
>     });
> 
> This example is short, but imagine a much longer one. If my cursor were 
> somewhere near "otherMethod", I might expect that ci) would bring me to the 
> function parameters that follow on the same line. However, I'm already inside 
> a ()-block, and if I'm just focusing on the immediate context, it's quite 
> easy to miss that.
> 
> I would be pretty disoriented if I ended up in Insert mode with nearly my 
> entire buffer emptied when all I tried to do was change some function 
> parameters to the right of my cursor. In the end, I'd have a hard time 
> getting myself to trust these text objects.
> 
> The instances where Vim presently scans the line for the next text object are 
> well-justified, and won't lead to huge surprises, because those text objects 
> are only valid over a single line (e.g. quoted strings).

I can see why you'd expect that, but in my experience that's never come up.  It 
may be I have a better sense of context than other users, although I suspect 
most users would become accustomed to it very quickly.  Even if they wouldn't - 
this situation is fairly situationally specific.  In *some* instances some 
subsets of the additional functionality provided by this would be of limited, 
use.  In a {}-heavy program, the functionality here for {} wouldn't be as 
useful.  If you were lisp'ing, the () stuff would be significantly less useful, 
and the other stuff wouldn't come up as much either.  However, in your example, 
() would still be both useful and do exactly what one would expect.  And in 
plenty of other languages/situations the functionality mentioned here does 
exactly what is expected.  I wouldn't discount everything that this allows 
because in some situations some of it isn't useful.

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

Raspunde prin e-mail lui