On Thursday, November 21, 2013 7:25:02 AM UTC-5, Bram Moolenaar wrote:
> Daneil Thau wrote:
>
>
>
> > On Wednesday, November 20, 2013 7:17:57 PM UTC-5, Daniel "paradigm" Thau
> > wrote:
>
> > > On Wednesday, November 20, 2013 7:16:59 PM UTC-5, Daniel "paradigm" Thau
> > > wrote:
>
> > > > On Tuesday, November 19, 2013 2:25:48 PM UTC-5, Daniel "paradigm" Thau
> > > > wrote:
>
> > > > > I noticed a common pattern when using Vim:
>
> > > > > - I want to operate on a text object that is not under/around the
> > > > > cursor
>
> > > > > - The cursor is not over/in a text object of this type.
>
> > > > >
>
> > > > > For example, with the cursor on the "x" and a desire to operate on
> > > > > the conditional part of the if-statement:
>
> > > > >
>
> > > > > x = 1;
>
> > > > > ...
>
> > > > > if (...) {
>
> > > > > ...
>
> > > > > }
>
> > > > >
>
> > > > > In these situations I have been moving the cursor to the object then
> > > > > selecting the object with something like "/(<cr>vi(" or "5jf(vi(".
>
> > > > >
>
> > > > > However, in that situation the text-object commands don't do
> > > > > anything. We could have Vim do something useful in this context -
> > > > > jump to the desired text object. If the given text-object command is
> > > > > valid - if the cursor is already in a ()-block - then what Vim
> > > > > normally does should happen. However, if Vim is about to "return
> > > > > FAIL" could simply search the buffer for the object and, if it finds
> > > > > it, use that object instead.
>
> > > > >
>
> > > > > Moreover, block text-objects (parens, {}, [], <>) have two (or
> > > > > three!) ways to access them. This could be used to indicate
> > > > > direction. "vi(" will select the ()-block under/around the cursor
> > > > > or, if no such block exists in that area, searches forward for a
> > > > > ()-block. "vi)" will do the same except it will search in reverse.
> > > > > "vib" will just act as it always has. Similar actions will be used
> > > > > on {}, [], and <>.
>
> > > > >
>
> > > > > Attached is a patch (both in the context and unified formats) to
> > > > > implement this. It seems relatively simple/clean to me, but people
> > > > > looking over and testing would be benficial in case I failed to
> > > > > consider something.
>
> > > >
>
> > > > Attached is a newer version of the same patch with reworked code to be
> > > > a bit cleaner. It includes Christian's suggestion for the search
> > > > direction.
>
> > >
>
> > > The attachments didn't seem to stick; trying again.
>
> >
>
> > Aaand I did the wrong patches. My apologies, here goes try three.
>
>
>
> I suppose the behavior could be useful in some situations.
>
>
>
> It would be good to include tests. The more complicated the code gets,
>
> the more important it is to have tests that it works properly.
>
>
>
> --
>
> For large projects, Team Leaders use sophisticated project management software
>
> to keep track of who's doing what. The software collects the lies and guesses
>
> of the project team and organizes them in to instantly outdated charts that
>
> are too boring to look at closely. This is called "planning".
>
> (Scott Adams - The Dilbert principle)
>
>
>
> /// Bram Moolenaar -- [email protected] -- 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 ///
Roger. I'll be sure to add tests to both my patches.
--
--
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/groups/opt_out.
