Re: patch for block textobj search
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"
> > >
> > > 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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Patch to utilize undefined text-objects
On Thursday, March 27, 2014 1:05:08 PM UTC-4, Ben Fritz wrote: > On Friday, January 31, 2014 1:54:30 PM UTC-6, Daniel "paradigm" Thau wrote: > > On Thursday, January 30, 2014 9:07:19 PM UTC-5, Daniel "paradigm" Thau > > wrote: > > > On Thursday, January 30, 2014 8:07:04 PM UTC-5, Marcin Szamotulski wrote: > > > > On 16:45 Wed 29 Jan , Daniel "paradigm" Thau wrote: > > > > > > > > > Apologies for the delay. > > > > > > > > > > > > > > > > > > Review for those who have forgotten and/or don't care to backread: > > > > > > > > > > > > > > > > > > This patch adds a new text object, "m", which will take one more > > > > > character as input. That character will be used as bounds to the > > > > > left and right for the object. For example, "cim$" will change > > > > > between dollar signs. This supports multi-line objects, so one could > > > > > do "cim'" which, unlike "ci'", will search across lines; this way > > > > > users have both. > > > > > > > > > > > > > Thanks I'm really happy to see this patch. I compiled it now and there > > > > > > > > is one thing that does not work: the "." command. For example di< or > > > > ci< > > > > > > > > can be repeated with . but dim, or cim, cannot. > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Marcin Szamotulski > > > > > > Good catch. I can replicate that on my end. Will fix. > > > > Should be fixed in the attachment. As a bonus, it now supports things such > > as digraphs. > > I tried updating this patch for 7-4-220 and mostly succeeded, just by > applying a couple hundred lines of fuzz, but visual mode is not selecting the > full text inside the matched pairs. I don't have time to try to fix it > further. I'm attaching the updated patch in case I just did something wrong. > I know there have been some visual mode changes outside of this patch between > now and the time the patch was created. Thanks for staying on this! My schedule has hit a huge crunch for the next month or two, and I don't want to rush a fix out myself and risk causing new issues. I'd rather delay fixing this and ensure that when I do the patch is as clean and bug-free as is possible against the code base at that time. When my schedule clears I may also add functionality for adding a v:count to the text object calls, which currently does not work for the new functionality for either of my patches. I might change how my tests work as well in order to have them both be cleaner and more thorough. -- -- 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/d/optout.
Re: Patch to utilize undefined text-objects
On Tuesday, February 4, 2014 5:06:08 PM UTC-5, telemachus wrote: > On Tuesday, February 4th, 2014 at 4:50PM, Daniel "paradigm" Thau wrote: > > > Should be fixed in the attachment. As a bonus, it now supports things > > > such as digraphs. > > > > I'm loving this patch, but I do have a question. Is the following a bug or > > intended behavior: > > > > 1. Start with this text (cursor at the 'i') > > > > foo,i,foo > > > > 2. Enter 'cim,' > > 3. This is the result, with the cursor immediately before the ',' > > > > foo,foo > > > > 4. Expected result was this, with the cursor in between the commas: > > > > foo,,foo > > > > > > Thanks, Peter > > -- > > We have not been faced with the need to satisfy someone else's > > requirements, and for this freedom we are grateful. > > Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System That is in fact another bug. No idea how that slipped by me. I'll be sure to fix that as well. -- -- 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.
Re: Patch to utilize undefined text-objects
On Tuesday, February 4, 2014 1:50:19 PM UTC-5, Ben Fritz wrote:
> On Friday, January 31, 2014 10:40:49 PM UTC-6, Ben Fritz wrote:
>
> > On Friday, January 31, 2014 1:54:30 PM UTC-6, Daniel "paradigm" Thau wrote:
>
> > >
>
> > > Should be fixed in the attachment. As a bonus, it now supports things
> > > such as digraphs.
>
> >
>
> > I think you just gave me a way to edit bulleted list items in plaintext,
> > using a c-coded text object. I'll need to try it out tomorrow :-)
>
>
>
> Thanks! I tried out the latest patch, now using cim with my own digraph, I
> can easily edit entire list items when I have a list like this:
>
>
>
> • one
>
> • two
>
> • three
>
Excellent :)
> I noticed a very minor bug, though.
>
>
>
> When 'selection' is set to "exclusive" (as with :behave mswin) then vim{char}
> is missing a character in the selection. Similarly, vam{char} is missing the
> final matched character.
Interesting. I'll look into it.
--
--
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.
Re: Patch to utilize undefined text-objects
On Thursday, January 30, 2014 9:07:19 PM UTC-5, Daniel "paradigm" Thau wrote:
> On Thursday, January 30, 2014 8:07:04 PM UTC-5, Marcin Szamotulski wrote:
> > On 16:45 Wed 29 Jan , Daniel "paradigm" Thau wrote:
> >
> > > Apologies for the delay.
> >
> > >
> >
> > > Review for those who have forgotten and/or don't care to backread:
> >
> > >
> >
> > > This patch adds a new text object, "m", which will take one more
> > > character as input. That character will be used as bounds to the left
> > > and right for the object. For example, "cim$" will change between dollar
> > > signs. This supports multi-line objects, so one could do "cim'" which,
> > > unlike "ci'", will search across lines; this way users have both.
> >
> > >
> >
> > > 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.
> >
> >
> >
> > Hi,
> >
> >
> >
> > Thanks I'm really happy to see this patch. I compiled it now and there
> >
> > is one thing that does not work: the "." command. For example di< or ci<
> >
> > can be repeated with . but dim, or cim, cannot.
> >
> >
> >
> > Best regards,
> >
> > Marcin Szamotulski
>
> Good catch. I can replicate that on my end. Will fix.
Should be fixed in the attachment. As a bonus, it now supports things such as
digraphs.
--
--
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.
diff --git a/runtime/doc/motion.txt b/runtime/doc/motion.txt
index d40d825..1cb2287 100644
--- a/runtime/doc/motion.txt
+++ b/runtime/doc/motion.txt
@@ -662,6 +662,14 @@ i` *v_i`* *i`*
Special case: With a count of 2 the quotes are
included, but no extra white space as with a"/a'/a`.
+am{char} *v_am* *am*
+ "a matched {char}". Selects the text from the
+ previous {char} until the next {char}. A count is
+ currently not used.
+
+im{char} *v_im* *im*
+ Like am{char} but exclude the {char}.
+
When used after an operator:
For non-block objects:
For the "a" commands: The operator applies to the object and the white
diff --git a/runtime/doc/tags b/runtime/doc/tags
index dce548f..eb258d5 100644
--- a/runtime/doc/tags
+++ b/runtime/doc/tags
@@ -4760,6 +4760,7 @@ aleph options.txt /*aleph*
alt intro.txt /*alt*
alt-input debugger.txt /*alt-input*
alternate-file editing.txt /*alternate-file*
+am motion.txt /*am*
amiga-window starting.txt /*amiga-window*
and() eval.txt /*and()*
anonymous-function eval.txt /*anonymous-function*
@@ -6532,6 +6533,7 @@ if_ruby.txt if_ruby.txt /*if_ruby.txt*
if_sniff.txt if_sniff.txt /*if_sniff.txt*
if_tcl.txt if_tcl.txt /*if_tcl.txt*
ignore-errors eval.txt /*ignore-errors*
+im motion.txt /*im*
improved-autocmds-5.4 version5.txt /*improved-autocmds-5.4*
improved-quickfix version5.txt /*improved-quickfix*
improved-sessions version5.txt /*improved-sessions*
@@ -8457,6 +8459,7 @@ v_a[ motion.txt /*v_a[*
v_a] motion.txt /*v_a]*
v_a` motion.txt /*v_a`*
v_ab motion.txt /*v_ab*
+v_am motion.txt /*v_am*
v_ap motion.txt /*v_ap*
v_aquote motion.txt /*v_aquote*
v_as motion.txt /*v_as*
@@ -8504,6 +8507,7 @@ v_i[ motion.txt /*v_i[*
v_i] motion.txt /*v_i]*
v_i` motion.txt /*v_i`*
v_ib motion.txt /*v_ib*
+v_im motion.txt /*v_im*
v_ip motion.txt /*v_ip*
v_iquote motion.txt /*v_iquote*
v_is motion.txt /*v_is*
diff --git a/src/normal.c b/src/normal.c
index 66a5b7a..710c6b4 100644
--- a/src/normal.c
+++ b/src/normal.c
@@ -981,7 +981,7 @@ getcount:
cp = &ca.nchar;
}
lang = (repl || (nv_cmds[idx].cmd_flags & NV_LANG));
-
+getchar:
/*
* Get a second or third character.
*/
@@ -1132,6 +1132,18 @@ getcount:
}
#endif
}
+#ifdef FEAT_TEXTOBJ
+ /*
+ * The im/am text object needs one more character to use as left/right
+ * bounds.
+ */
+ if ((ca.cmdchar == 'a' || ca.cmdchar == 'i') && ca.nchar == 'm'
+ && ca.extra_char == NUL)
+ {
+ cp = &ca.extra_char;
+ goto getchar;
+ }
+#endif
--no_mapping;
-
Re: patch for block textobj search
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"
>
> 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.
--
--
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.
diff --git a/runtime/doc/motion.txt b/runtime/doc/motion.txt
index d40d825..63d7486 100644
--- a/runtime/doc/motion.txt
+++ b/runtime/doc/motion.txt
@@ -574,6 +574,10 @@ a[ "a [] block", select [count] '[' ']' blocks. This
goes backwards to the [count] unclosed '[', and finds
the matching ']'. The enclosed text is selected,
including the '[' and ']'.
+ If it fails to find the block under or around the
+ cursor, and '[' was specified, it will search the
+ buffer backwards for the block or, if ']' was
+ specified, it will search the buffer forwards.
When used in Visual mode it is made characterwise.
i] *v_i]* *v_i[* *i]* *i[*
@@ -581,6 +585,10 @@ i[ "inner [] block", select [count] '[' ']' blocks. This
goes backwards to the [count] unclosed '[', and finds
the matching ']'. The enclosed text is selected,
excluding the '[' and ']'.
+ If it fails to find the block under or around the
+ cursor, and '[' was specified, it will search the
+ buffer backwards for the block or, if ']' was
+ specified, it will search the buffer forwards.
When used in Visual mode it is made characterwise.
a) *v_a)* *a)* *a(*
@@ -589,6 +597,10 @@ ab "a block", select [count] blocks, from "[count] [(" to
the matching ')', including the '(' and ')' (see
|[(|). Does not include white space outside of the
parenthesis.
+ If it fails to find the block under or around the
+ cursor, and '(' was specified, it will search the
+ buffer backwards for the block or, if ')' was
+ specified, it will search the buffer forwards.
When used in Visual mode it is made characterwise.
i) *v_i)* *i)* *i(*
@@ -596,18 +608,30 @@ i( *v_ib* *v_i(* *ib*
ib "inner block", select [count] blocks, from "[count] [("
to the matching ')', excluding the '(' and ')' (see
|[(|).
+ If it fails to find the block under or around the
+ cursor, and '(' was specified, it will search the
+ buffer backwards for the block or, if ')' was
+ specified, it will search the buffer forwards.
When used in Visual mode it is made characterwise.
a> *v_a>* *v_a<* *a>* *a<*
a< "a <> block", select [count] <> blocks, from the
[count]'th unmatched '<' backwards to the matching
'>', including the '<' and '>'.
+ If it fails to find the block under or around the
+ cursor, and '<' was specified, it will search the
+ buffer backwards for the block or, if '>' was
+ specified, it will search the buffer forwards.
When used in Visual mode it is made characterwise.
i> *v_i>* *v_i<* *i>* *i<*
i< "inner <> block", select [count] <> blocks, from
the [count]'th unmatched '<' backwards to the matching
'>', excluding the '<' and '>'.
+ If
Re: Patch to utilize undefined text-objects
On Thursday, January 30, 2014 8:07:04 PM UTC-5, Marcin Szamotulski wrote: > On 16:45 Wed 29 Jan , Daniel "paradigm" Thau wrote: > > > Apologies for the delay. > > > > > > Review for those who have forgotten and/or don't care to backread: > > > > > > This patch adds a new text object, "m", which will take one more character > > as input. That character will be used as bounds to the left and right for > > the object. For example, "cim$" will change between dollar signs. This > > supports multi-line objects, so one could do "cim'" which, unlike "ci'", > > will search across lines; this way users have both. > > > > > > 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. > > > > Hi, > > > > Thanks I'm really happy to see this patch. I compiled it now and there > > is one thing that does not work: the "." command. For example di< or ci< > > can be repeated with . but dim, or cim, cannot. > > > > Best regards, > > Marcin Szamotulski Good catch. I can replicate that on my end. Will fix. -- -- 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.
Re: Patch to utilize undefined text-objects
On Wednesday, January 29, 2014 7:45:23 PM UTC-5, Daniel "paradigm" Thau wrote:
> Apologies for the delay.
>
> Review for those who have forgotten and/or don't care to backread:
>
> This patch adds a new text object, "m", which will take one more character as
> input. That character will be used as bounds to the left and right for the
> object. For example, "cim$" will change between dollar signs. This supports
> multi-line objects, so one could do "cim'" which, unlike "ci'", will search
> across lines; this way users have both.
>
> 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.
Added wrong file/filename for the test results. Fixed in attachment.
--
--
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.
diff --git a/runtime/doc/motion.txt b/runtime/doc/motion.txt
index d40d825..1cb2287 100644
--- a/runtime/doc/motion.txt
+++ b/runtime/doc/motion.txt
@@ -662,6 +662,14 @@ i` *v_i`* *i`*
Special case: With a count of 2 the quotes are
included, but no extra white space as with a"/a'/a`.
+am{char} *v_am* *am*
+ "a matched {char}". Selects the text from the
+ previous {char} until the next {char}. A count is
+ currently not used.
+
+im{char} *v_im* *im*
+ Like am{char} but exclude the {char}.
+
When used after an operator:
For non-block objects:
For the "a" commands: The operator applies to the object and the white
diff --git a/runtime/doc/tags b/runtime/doc/tags
index dce548f..eb258d5 100644
--- a/runtime/doc/tags
+++ b/runtime/doc/tags
@@ -4760,6 +4760,7 @@ aleph options.txt /*aleph*
alt intro.txt /*alt*
alt-input debugger.txt /*alt-input*
alternate-file editing.txt /*alternate-file*
+am motion.txt /*am*
amiga-window starting.txt /*amiga-window*
and() eval.txt /*and()*
anonymous-function eval.txt /*anonymous-function*
@@ -6532,6 +6533,7 @@ if_ruby.txt if_ruby.txt /*if_ruby.txt*
if_sniff.txt if_sniff.txt /*if_sniff.txt*
if_tcl.txt if_tcl.txt /*if_tcl.txt*
ignore-errors eval.txt /*ignore-errors*
+im motion.txt /*im*
improved-autocmds-5.4 version5.txt /*improved-autocmds-5.4*
improved-quickfix version5.txt /*improved-quickfix*
improved-sessions version5.txt /*improved-sessions*
@@ -8457,6 +8459,7 @@ v_a[ motion.txt /*v_a[*
v_a] motion.txt /*v_a]*
v_a` motion.txt /*v_a`*
v_ab motion.txt /*v_ab*
+v_am motion.txt /*v_am*
v_ap motion.txt /*v_ap*
v_aquote motion.txt /*v_aquote*
v_as motion.txt /*v_as*
@@ -8504,6 +8507,7 @@ v_i[ motion.txt /*v_i[*
v_i] motion.txt /*v_i]*
v_i` motion.txt /*v_i`*
v_ib motion.txt /*v_ib*
+v_im motion.txt /*v_im*
v_ip motion.txt /*v_ip*
v_iquote motion.txt /*v_iquote*
v_is motion.txt /*v_is*
diff --git a/src/normal.c b/src/normal.c
index 66a5b7a..09d9d0e 100644
--- a/src/normal.c
+++ b/src/normal.c
@@ -9310,6 +9310,11 @@ nv_object(cap)
flag = current_quote(cap->oap, cap->count1, include,
cap->nchar);
break;
+ case 'm': /* "am{char}" = a matched pair of characters */
+ cap->extra_char = plain_vgetc();
+ flag = current_match(cap->oap, cap->count1, include,
+ cap->extra_char);
+ break;
#if 0 /* TODO */
case 'S': /* "aS" = a section */
case 'f': /* "af" = a filename */
diff --git a/src/proto/search.pro b/src/proto/search.pro
index f94fb69..0cf3be3 100644
--- a/src/proto/search.pro
+++ b/src/proto/search.pro
@@ -32,6 +32,7 @@ int current_block __ARGS((oparg_T *oap, long count, int include, int what, int o
int current_tagblock __ARGS((oparg_T *oap, long count_arg, int include));
int current_par __ARGS((oparg_T *oap, long count, int include, int type));
int current_quote __ARGS((oparg_T *oap, long count, int include, int quotechar));
+int current_match __ARGS((oparg_T *oap, long count, int include, int matchchar));
int current_search __ARGS((long count, int forward));
int linewhite __ARGS((linenr_T lnum));
void find_pattern_in_path __ARGS((char_u *ptr, int dir, int len, int whole, int skip_comments, int type, long count, int action, linenr_T start_lnum, linenr_T end_lnum));
diff --git a/src/search.c b/src/search.c
index 0341a5e..58db91e 100644
--- a/src/search.c
+++ b/src/search.c
@@ -4489,6 +4489,147 @@ current_quote(oap, count, include, quotechar)
return OK;
}
+
Re: Patch to utilize undefined text-objects
Apologies for the delay.
Review for those who have forgotten and/or don't care to backread:
This patch adds a new text object, "m", which will take one more character as
input. That character will be used as bounds to the left and right for the
object. For example, "cim$" will change between dollar signs. This supports
multi-line objects, so one could do "cim'" which, unlike "ci'", will search
across lines; this way users have both.
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.
--
--
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.
diff --git a/runtime/doc/motion.txt b/runtime/doc/motion.txt
index d40d825..1cb2287 100644
--- a/runtime/doc/motion.txt
+++ b/runtime/doc/motion.txt
@@ -662,6 +662,14 @@ i` *v_i`* *i`*
Special case: With a count of 2 the quotes are
included, but no extra white space as with a"/a'/a`.
+am{char} *v_am* *am*
+ "a matched {char}". Selects the text from the
+ previous {char} until the next {char}. A count is
+ currently not used.
+
+im{char} *v_im* *im*
+ Like am{char} but exclude the {char}.
+
When used after an operator:
For non-block objects:
For the "a" commands: The operator applies to the object and the white
diff --git a/runtime/doc/tags b/runtime/doc/tags
index dce548f..eb258d5 100644
--- a/runtime/doc/tags
+++ b/runtime/doc/tags
@@ -4760,6 +4760,7 @@ aleph options.txt /*aleph*
alt intro.txt /*alt*
alt-input debugger.txt /*alt-input*
alternate-file editing.txt /*alternate-file*
+am motion.txt /*am*
amiga-window starting.txt /*amiga-window*
and() eval.txt /*and()*
anonymous-function eval.txt /*anonymous-function*
@@ -6532,6 +6533,7 @@ if_ruby.txt if_ruby.txt /*if_ruby.txt*
if_sniff.txt if_sniff.txt /*if_sniff.txt*
if_tcl.txt if_tcl.txt /*if_tcl.txt*
ignore-errors eval.txt /*ignore-errors*
+im motion.txt /*im*
improved-autocmds-5.4 version5.txt /*improved-autocmds-5.4*
improved-quickfix version5.txt /*improved-quickfix*
improved-sessions version5.txt /*improved-sessions*
@@ -8457,6 +8459,7 @@ v_a[ motion.txt /*v_a[*
v_a] motion.txt /*v_a]*
v_a` motion.txt /*v_a`*
v_ab motion.txt /*v_ab*
+v_am motion.txt /*v_am*
v_ap motion.txt /*v_ap*
v_aquote motion.txt /*v_aquote*
v_as motion.txt /*v_as*
@@ -8504,6 +8507,7 @@ v_i[ motion.txt /*v_i[*
v_i] motion.txt /*v_i]*
v_i` motion.txt /*v_i`*
v_ib motion.txt /*v_ib*
+v_im motion.txt /*v_im*
v_ip motion.txt /*v_ip*
v_iquote motion.txt /*v_iquote*
v_is motion.txt /*v_is*
diff --git a/src/normal.c b/src/normal.c
index 66a5b7a..09d9d0e 100644
--- a/src/normal.c
+++ b/src/normal.c
@@ -9310,6 +9310,11 @@ nv_object(cap)
flag = current_quote(cap->oap, cap->count1, include,
cap->nchar);
break;
+ case 'm': /* "am{char}" = a matched pair of characters */
+ cap->extra_char = plain_vgetc();
+ flag = current_match(cap->oap, cap->count1, include,
+ cap->extra_char);
+ break;
#if 0 /* TODO */
case 'S': /* "aS" = a section */
case 'f': /* "af" = a filename */
diff --git a/src/proto/search.pro b/src/proto/search.pro
index f94fb69..0cf3be3 100644
--- a/src/proto/search.pro
+++ b/src/proto/search.pro
@@ -32,6 +32,7 @@ int current_block __ARGS((oparg_T *oap, long count, int include, int what, int o
int current_tagblock __ARGS((oparg_T *oap, long count_arg, int include));
int current_par __ARGS((oparg_T *oap, long count, int include, int type));
int current_quote __ARGS((oparg_T *oap, long count, int include, int quotechar));
+int current_match __ARGS((oparg_T *oap, long count, int include, int matchchar));
int current_search __ARGS((long count, int forward));
int linewhite __ARGS((linenr_T lnum));
void find_pattern_in_path __ARGS((char_u *ptr, int dir, int len, int whole, int skip_comments, int type, long count, int action, linenr_T start_lnum, linenr_T end_lnum));
diff --git a/src/search.c b/src/search.c
index 0341a5e..58db91e 100644
--- a/src/search.c
+++ b/src/search.c
@@ -4489,6 +4489,147 @@ current_quote(oap, count, include, quotechar)
return OK;
}
+/*
+ * Find matching {char} on each side of cursor/visually selected range.
+ * Returns TRUE if found, else FALSE.
+ */
+int
+current_match(oap, count, include, matchchar)
+oparg_T *oap; /* used to set operator range, mode, etc */
+long count; /* not currently used */
+int include; /* TRUE == include bounding char */
+int matchchar; /* char to match on both sides */
+{
+pos_T old_po
Re: patch for block textobj search
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"
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.
--
--
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.
diff --git a/runtime/doc/motion.txt b/runtime/doc/motion.txt
index d40d825..63d7486 100644
--- a/runtime/doc/motion.txt
+++ b/runtime/doc/motion.txt
@@ -574,6 +574,10 @@ a[ "a [] block", select [count] '[' ']' blocks. This
goes backwards to the [count] unclosed '[', and finds
the matching ']'. The enclosed text is selected,
including the '[' and ']'.
+ If it fails to find the block under or around the
+ cursor, and '[' was specified, it will search the
+ buffer backwards for the block or, if ']' was
+ specified, it will search the buffer forwards.
When used in Visual mode it is made characterwise.
i] *v_i]* *v_i[* *i]* *i[*
@@ -581,6 +585,10 @@ i[ "inner [] block", select [count] '[' ']' blocks. This
goes backwards to the [count] unclosed '[', and finds
the matching ']'. The enclosed text is selected,
excluding the '[' and ']'.
+ If it fails to find the block under or around the
+ cursor, and '[' was specified, it will search the
+ buffer backwards for the block or, if ']' was
+ specified, it will search the buffer forwards.
When used in Visual mode it is made characterwise.
a) *v_a)* *a)* *a(*
@@ -589,6 +597,10 @@ ab "a block", select [count] blocks, from "[count] [(" to
the matching ')', including the '(' and ')' (see
|[(|). Does not include white space outside of the
parenthesis.
+ If it fails to find the block under or around the
+ cursor, and '(' was specified, it will search the
+ buffer backwards for the block or, if ')' was
+ specified, it will search the buffer forwards.
When used in Visual mode it is made characterwise.
i) *v_i)* *i)* *i(*
@@ -596,18 +608,30 @@ i( *v_ib* *v_i(* *ib*
ib "inner block", select [count] blocks, from "[count] [("
to the matching ')', excluding the '(' and ')' (see
|[(|).
+ If it fails to find the block under or around the
+ cursor, and '(' was specified, it will search the
+ buffer backwards for the block or, if ')' was
+ specified, it will search the buffer forwards.
When used in Visual mode it is made characterwise.
a> *v_a>* *v_a<* *a>* *a<*
a< "a <> block", select [count] <> blocks, from the
[count]'th unmatched '<' backwards to the matching
'>', including the '<' and '>'.
+ If it fails to find the block under or around the
+ cursor, and '<' was specified, it will search the
+ buffer backwards for the block or, if '>' was
+ specified, it will search the buffer forwards.
When used in Visual mode it is made characterwise.
i> *v_i>* *v_i<* *i>* *i<*
i< "inner <> block", select [count] <> blocks, from
the [count]'th unmatched '<' backwards to the matching
'>', excluding the '<' and '>'.
+ If it fails to find the block under or around the
+ cursor, and '<' was specified, it will search the
+ buffer backwards for the block or, if '>' was
+ specified, it will search the buffer forwards.
When used in Visual mode it is made characterwise.
*v_at* *at*
@@ -629,6 +653,10 @@ a{ *v_aB* *v_a{* *aB*
aB "a Block", select [count] Blocks, from "[count] [{" to
the matching '}', including the '{' and '}' (see
|[{|).
+ If it fails to find the block under or around the
+ cursor, and '{' was specified, it will search the
+ buffer backwards for the block or, if '}' was
+ specified, it will search the buffer forwards.
When used in Visual mode it is made characterwise.
i} *v_i}* *i}* *i{*
@@ -636,6 +664,10 @@ i{ *v_iB* *v_i{* *iB*
iB "inner Block", select [count] Blocks, from "[count] [{"
to the matching '}', excluding the '{' and '}' (see
|[{|).
Re: patch for block textobj search
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 "/(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 -- 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///
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: patch for block textobj search
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 "/(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.
--
--
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.
*** a/runtime/doc/motion.txt
--- b/runtime/doc/motion.txt
***
*** 574,579 a[ "a [] block", select [count] '[' ']' blocks. This
--- 574,583
goes backwards to the [count] unclosed '[', and finds
the matching ']'. The enclosed text is selected,
including the '[' and ']'.
+ If it fails to find the block under or around the
+ cursor, and '[' was specified, it will search the
+ buffer backwards for the block or, if ']' was
+ specified, it will search the buffer forwards.
When used in Visual mode it is made characterwise.
i] *v_i]* *v_i[* *i]* *i[*
***
*** 581,586 i[ "inner [] block", select [count] '[' ']' blocks. This
--- 585,594
goes backwards to the [count] unclosed '[', and finds
the matching ']'. The enclosed text is selected,
excluding the '[' and ']'.
+ If it fails to find the block under or around the
+ cursor, and '[' was specified, it will search the
+ buffer backwards for the block or, if ']' was
+ specified, it will search the buffer forwards.
When used in Visual mode it is made characterwise.
a) *v_a)* *a)* *a(*
***
*** 589,594 ab "a block", select [count] blocks, from "[count] [(" to
--- 597,606
the matching ')', including the '(' and ')' (see
|[(|). Does not include white space outside of the
parenthesis.
+ If it fails to find the block under or around the
+ cursor, and '(' was specified,
Re: patch for block textobj search
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 "/(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.
--
--
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.
*** a/runtime/doc/motion.txt
--- b/runtime/doc/motion.txt
***
*** 662,667 i` *v_i`* *i`*
--- 662,675
Special case: With a count of 2 the quotes are
included, but no extra white space as with a"/a'/a`.
+ am{char} *v_am* *am*
+ "a matched {char}". Selects the text from the
+ previous {char} until the next {char}. A count is
+ currently not used.
+
+ im{char} *v_im* *im*
+ Like am{char} but exclude the {char}.
+
When used after an operator:
For non-block objects:
For the "a" commands: The operator applies to the object and the white
*** a/src/normal.c
--- b/src/normal.c
***
*** 9309,9314 nv_object(cap)
--- 9309,9319
flag = current_quote(cap->oap, cap->count1, include,
cap->nchar);
break;
+ case 'm': /* "am{char}" = a matched pair of characters */
+ cap->extra_char = plain_vgetc();
+ flag = current_match(cap->oap, cap->count1, include,
+ cap->extra_char);
+ break;
#if 0 /* TODO */
case 'S': /* "aS" = a section */
case 'f': /* "af" = a filename */
*** a/src/proto/search.pro
--- b/src/proto/search.pro
***
*** 32,37 int current_block __ARGS((oparg_T *oap, long count, int include, int what, int o
--- 32,38
int current_tagblock __ARGS((oparg_T *oap, long count_arg, int include));
int current_par __ARGS((oparg_T *oap, long count, int include, int type));
int current_quote __ARGS((oparg_T *oap, long count, int include, int quotechar));
+ int current_match __ARGS((oparg_T *oap, long count, int include, int matchchar));
int current_search __ARGS((long count, int forward));
int linewhite __ARGS((linenr_T lnum));
void find_pattern_in_path __ARGS((char_u *ptr, int dir, int len, int whole, int skip_comments, int type, long count, int action, linenr_T start_lnum, linenr_T end_lnum));
*** a/src/search.c
--- b/src/search.c
***
*** 4489,4494 current_quote(oap, count, include, quotechar)
--- 4489,4635
Re: patch for block textobj search
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 "/(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.
--
--
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.
Re: Patch to utilize undefined text-objects
On Tuesday, November 19, 2013 4:42:32 PM UTC-5, Bram Moolenaar wrote:
> Daniel Thau wrote:
>
>
>
> > Attached is a patch (in both the unified and context formats) to make
>
> > the discussed "am/im" text-object.
>
>
>
> > *** a/runtime/doc/motion.txt
>
> > --- b/runtime/doc/motion.txt
>
> > ***
>
> > *** 662,667 i` *v_i`*
> > *i`*
>
> > --- 662,687
>
> > Special case: With a count of 2 the quotes are
>
> > included, but no extra white space as with a"/a'/a`.
>
> >
>
> > + am{char} *v_am* *am*
>
> > + "a matched {char}". Selects the text from the
>
> > + previous {char} until the next {char}.
>
> > + Only works within one line.
>
> > + When the cursor starts on a {char}, Vim will figure
>
> > + out which {char} pairs are desired by searching from
>
> > + the start of the line.
>
> > + Any trailing white space is included, unless there is
>
> > + none, then leading white space is included.
>
> > + When used in Visual mode it is made characterwise.
>
> > + Repeating this object in Visual mode another
>
> > + {char}..{char} range is included. A count is
>
> > + currently not used.
>
> > +
>
> > + im{char} *v_im* *im*
>
> > + Like am{char} but exclude the {char} and
>
> > + repeating won't extend the Visual selection.
>
> > + Special case: With a count of 2 the quotes are
>
> > + included, but no extra white space as with am{char}.
>
> > +
>
>
>
> I'm sure users will ask about a multi-line implementation. This
>
> requires defining how Vim decides whether a matching {char} is the start
>
> or the end, but otherwise it should work.
>
>
>
> --
>
> BEDEVERE: And that, my lord, is how we know the Earth to be banana-shaped.
>
> "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
>
>
>
> /// 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///
Attached is a patch to have the im/am object support multi-line. I figured
you'd probably not want the pre-existing i"/a" object to do multi-line, so
instead of continuing to piggyback off of it I made a new function for the
im/am object. It does not yet support doing a iv to select a larger range - I
can get to that later if this strategy seems acceptable.
--
--
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.
*** a/runtime/doc/motion.txt
--- b/runtime/doc/motion.txt
***
*** 662,667 i` *v_i`* *i`*
--- 662,675
Special case: With a count of 2 the quotes are
included, but no extra white space as with a"/a'/a`.
+ am{char} *v_am* *am*
+ "a matched {char}". Selects the text from the
+ previous {char} until the next {char}. A count is
+ currently not used.
+
+ im{char} *v_im* *im*
+ Like am{char} but exclude the {char}.
+
When used after an operator:
For non-block objects:
For the "a" commands: The operator applies to the object and the white
*** a/src/normal.c
--- b/src/normal.c
***
*** 9309,9314 nv_object(cap)
--- 9309,9319
flag = current_quote(cap->oap, cap->count1, include,
cap->nchar);
break;
+ case 'm': /* "am{char}" = a matched pair of characters */
+ cap->extra_char = plain_vgetc();
+ flag = current_match(cap->oap, cap->count1, include,
+ cap->extra_char);
+ break;
#if 0 /* TODO */
case 'S': /* "aS" = a section */
case 'f': /* "af" = a filename */
*** a/src/proto/search.pro
--- b/src/proto/search.pro
***
*** 32,37 int current_block __ARGS((oparg_T *oap, long count, int include, int what, int o
--- 32,38
int current_tagblock __ARGS((oparg_T *oap, long count_arg, int include));
int current_par __ARGS((oparg_T *oap, long count, int include, int type));
int current_quote __ARGS((oparg_T *oap, long count, int include, int quotechar));
+ int current_match __ARGS((oparg_T *oap, l
Re: Patch to utilize undefined text-objects
On Tuesday, November 19, 2013 4:42:32 PM UTC-5, Bram Moolenaar wrote:
> Daniel Thau wrote:
>
>
>
> > Attached is a patch (in both the unified and context formats) to make
>
> > the discussed "am/im" text-object.
>
>
>
> > *** a/runtime/doc/motion.txt
>
> > --- b/runtime/doc/motion.txt
>
> > ***
>
> > *** 662,667 i` *v_i`*
> > *i`*
>
> > --- 662,687
>
> > Special case: With a count of 2 the quotes are
>
> > included, but no extra white space as with a"/a'/a`.
>
> >
>
> > + am{char} *v_am* *am*
>
> > + "a matched {char}". Selects the text from the
>
> > + previous {char} until the next {char}.
>
> > + Only works within one line.
>
> > + When the cursor starts on a {char}, Vim will figure
>
> > + out which {char} pairs are desired by searching from
>
> > + the start of the line.
>
> > + Any trailing white space is included, unless there is
>
> > + none, then leading white space is included.
>
> > + When used in Visual mode it is made characterwise.
>
> > + Repeating this object in Visual mode another
>
> > + {char}..{char} range is included. A count is
>
> > + currently not used.
>
> > +
>
> > + im{char} *v_im* *im*
>
> > + Like am{char} but exclude the {char} and
>
> > + repeating won't extend the Visual selection.
>
> > + Special case: With a count of 2 the quotes are
>
> > + included, but no extra white space as with am{char}.
>
> > +
>
>
>
> I'm sure users will ask about a multi-line implementation. This
>
> requires defining how Vim decides whether a matching {char} is the start
>
> or the end, but otherwise it should work.
I can experiment with adding multi-line to the new im/am object. Perhaps make
another function for it instead of piggypacking off the quote funciton. I'll
play with having the matching {char} at the beginning and at the end and see if
either feels more natural. However, that raises additional questions; there's
a number of ways of going about it.
- Should the quote objects also do multiline (after all their currently valid
uses), or should they continue to do what they are doing and only have the new
m-quote objects do multi-line?
- Should the m objects (including m-quote) seek ahead in the same line the way
normal quotes do before checking for multi-line, or should they immediately
check multiline and not do the seek-ahead-on-the-same-line thing that the
normal quote objects do?
I'm inclined to have normal quote objects do what they've always done, and have
the new m objects always go multi-line and not search same-line.
Consider a buffer like so:
foo bar "
baz " qux "
With the cursor on the "z" in baz. The way I am invisioning this, vi" will
select the quz and vim" will select the baz. The other im/am objects will
similarly just do multi-line and not worry about seeking ahead on the same line.
If there's any disagreement with the way I'm leaning on this I'm more than
happy to go about it any other way.
--
--
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.
Re: Patch to utilize undefined text-objects
On Tuesday, November 19, 2013 4:49:07 PM UTC-5, Ernie Rael wrote:
> In the documentation for "im{char}" you use the word "quote". That
>
> doesn't bother me, but I wanted to be sure that is what you meant
>
> (that's the only use of that word in the patch).
>
>
>
> -ernie
>
>
>
> On 11/19/2013 8:01 AM, Daniel "paradigm" Thau wrote:
>
> > Attached is a patch (in both the unified and context formats) to make the
> > discussed "am/im" text-object.
>
> >
That was not intentional. Good catch. Adjusted patches attached.
--
--
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.
*** a/runtime/doc/motion.txt
--- b/runtime/doc/motion.txt
***
*** 662,667 i` *v_i`* *i`*
--- 662,687
Special case: With a count of 2 the quotes are
included, but no extra white space as with a"/a'/a`.
+ am{char} *v_am* *am*
+ "a matched {char}". Selects the text from the
+ previous {char} until the next {char}.
+ Only works within one line.
+ When the cursor starts on a {char}, Vim will figure
+ out which {char} pairs are desired by searching from
+ the start of the line.
+ Any trailing white space is included, unless there is
+ none, then leading white space is included.
+ When used in Visual mode it is made characterwise.
+ Repeating this object in Visual mode another
+ {char}..{char} range is included. A count is
+ currently not used.
+
+ im{char} *v_im* *im*
+ Like am{char} but exclude the {char} and
+ repeating won't extend the Visual selection.
+ Special case: With a count of 2 the {char}s are
+ included, but no extra white space as with am{char}.
+
When used after an operator:
For non-block objects:
For the "a" commands: The operator applies to the object and the white
*** a/runtime/doc/tags
--- b/runtime/doc/tags
***
*** 4751,4756 aleph options.txt /*aleph*
--- 4751,4757
alt intro.txt /*alt*
alt-input debugger.txt /*alt-input*
alternate-file editing.txt /*alternate-file*
+ am motion.txt /*am*
amiga-window starting.txt /*amiga-window*
and() eval.txt /*and()*
anonymous-function eval.txt /*anonymous-function*
***
*** 6520,6525 if_ruby.txt if_ruby.txt /*if_ruby.txt*
--- 6521,6527
if_sniff.txt if_sniff.txt /*if_sniff.txt*
if_tcl.txt if_tcl.txt /*if_tcl.txt*
ignore-errors eval.txt /*ignore-errors*
+ im motion.txt /*im*
improved-autocmds-5.4 version5.txt /*improved-autocmds-5.4*
improved-quickfix version5.txt /*improved-quickfix*
improved-sessions version5.txt /*improved-sessions*
***
*** 8441,8446 v_a[ motion.txt /*v_a[*
--- 8443,8449
v_a] motion.txt /*v_a]*
v_a` motion.txt /*v_a`*
v_ab motion.txt /*v_ab*
+ v_am motion.txt /*v_am*
v_ap motion.txt /*v_ap*
v_aquote motion.txt /*v_aquote*
v_as motion.txt /*v_as*
***
*** 8488,8493 v_i[ motion.txt /*v_i[*
--- 8491,8497
v_i] motion.txt /*v_i]*
v_i` motion.txt /*v_i`*
v_ib motion.txt /*v_ib*
+ v_im motion.txt /*v_im*
v_ip motion.txt /*v_ip*
v_iquote motion.txt /*v_iquote*
v_is motion.txt /*v_is*
*** a/src/normal.c
--- b/src/normal.c
***
*** 9309,9314 nv_object(cap)
--- 9309,9319
flag = current_quote(cap->oap, cap->count1, include,
cap->nchar);
break;
+ case 'm': /* "am" = a matching pair of characters */
+ cap->extra_char = plain_vgetc();
+ flag = current_quote(cap->oap, cap->count1, include,
+ cap->extra_char);
+ break;
#if 0 /* TODO */
case 'S': /* "aS" = a section */
case 'f': /* "af" = a filename */
diff --git a/runtime/doc/motion.txt b/runtime/doc/motion.txt
index d40d825..8af2b6e 100644
--- a/runtime/doc/motion.txt
+++ b/runtime/doc/motion.txt
@@ -662,6 +662,26 @@ i` *v_i`* *i`*
Special case: With a count of 2 the quotes are
included, but no extra white space as with a"/a'/a`.
+am{char} *v_am* *am*
+ "a matched {char}". Selects the text from the
+ previous {char} until the next {char}.
+ Only works within one line.
+ When the cursor starts on a {char}, Vim will figure
+ out which {char} pairs are desired by searching from
+ the start of the line.
+ Any trailing white space is included, unless there is
+ none, then leading white space is includ
Re: patch for block textobj search
On Tuesday, November 19, 2013 4:42:45 PM UTC-5, Christian Brabandt wrote:
> Hi Daniel!
>
>
>
> On Di, 19 Nov 2013, 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 "/(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 <>.
>
> >
>
>
>
> I think it should be ( to move to the previous object and ) to move to
>
> the next block. This would match the behaviour of [s ]s and [z and ]z
>
> and other similar motions.
>
>
>
> Other then that, this sounds like a useful addition (although some
>
> scripts might depend on the current behaviour).
>
>
>
> regards,
>
> Christian
>
> --
>
> "Sie brauchen den Mund nicht so weit aufmachen", sagte der Zahnarzt
>
> "Wollen Sie denn nicht bohren?"
>
> "Doch, schon, ... aber ich bleibe drau�en."
Hi Christian,
Thanks for the input. That makes perfect sense to me. Adjusted patches are
attached.
--
--
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.
*** a/runtime/doc/motion.txt
--- b/runtime/doc/motion.txt
***
*** 574,579 a[ "a [] block", select [count] '[' ']' blocks. This
--- 574,583
goes backwards to the [count] unclosed '[', and finds
the matching ']'. The enclosed text is selected,
including the '[' and ']'.
+ If it fails to find the block under or around the
+ cursor, and '[' was specified, it will search the
+ buffer backwards for the block or, if ']' was
+ specified, it will search the buffer forwards.
When used in Visual mode it is made characterwise.
i] *v_i]* *v_i[* *i]* *i[*
***
*** 581,586 i[ "inner [] block", select [count] '[' ']' blocks. This
--- 585,594
goes backwards to the [count] unclosed '[', and finds
the matching ']'. The enclosed text is selected,
excluding the '[' and ']'.
+ If it fails to find the block under or around the
+ cursor, and '[' was specified, it will search the
+ buffer backwards for the block or, if ']' was
+ specified, it will search the buffer forwards.
When used in Visual mode it is made characterwise.
a) *v_a)* *a)* *a(*
***
*** 589,594 ab "a block", select [count] blocks, from "[count] [(" to
--- 597,606
the matching ')', including the '(' and ')' (see
|[(|). Does not include white space outside of the
parenthesis.
+ If it fails to find the block under or around the
+ cursor, and '(' was specified, it will search the
Re: patch for block textobj search
On Tuesday, November 19, 2013 3:34:21 PM UTC-5, Ben Fritz wrote:
> On Tuesday, November 19, 2013 1:25:48 PM UTC-6, 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 "/(vi(" or "5jf(vi(".
> >
> > However, in that situation the text-object commands don't do anything.
>
> No, in this situation the text object certainly CAN do something, because
> these text objects can be nested!
>
> Consider the [ai][{B] text object you mention. Chances are, you're inside a
> function when your cursor is on the "x=1" line. So pressing va{ should select
> the entire function body. It should not select the next block after the
> cursor.
Perhaps I was unclear. *If* the text object can do something, then it does
that thing. If there is some larger ()-object that isn't seen in my example,
then yes, that would be selected. Only if the text object command fails -
literally, it gets to the part of the code that does a "return FAIL" - does it
search forward/backward for the object. Neither this patch nor my other one
will alter normally valid Vim commands.
--
--
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.
patch for block textobj search
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 "/(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.
--
--
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.
*** a/runtime/doc/motion.txt
--- b/runtime/doc/motion.txt
***
*** 574,579 a[ "a [] block", select [count] '[' ']' blocks. This
--- 574,583
goes backwards to the [count] unclosed '[', and finds
the matching ']'. The enclosed text is selected,
including the '[' and ']'.
+ If it fails to find the block under or around the
+ cursor, and '[' was specified, it will search the
+ buffer forward for the block or, if ']' was specified,
+ it will search the buffer backwards.
When used in Visual mode it is made characterwise.
i] *v_i]* *v_i[* *i]* *i[*
***
*** 581,586 i[ "inner [] block", select [count] '[' ']' blocks. This
--- 585,594
goes backwards to the [count] unclosed '[', and finds
the matching ']'. The enclosed text is selected,
excluding the '[' and ']'.
+ If it fails to find the block under or around the
+ cursor, and '[' was specified, it will search the
+ buffer forward for the block or, if ']' was specified,
+ it will search the buffer backwards.
When used in Visual mode it is made characterwise.
a) *v_a)* *a)* *a(*
***
*** 589,594 ab "a block", select [count] blocks, from "[count] [(" to
--- 597,606
the matching ')', including the '(' and ')' (see
|[(|). Does not include white space outside of the
parenthesis.
+ If it fails to find the block under or around the
+ cursor, and '(' was specified, it will search the
+ buffer forward for the block or, if ')' was specified,
+ it will search the buffer backwards.
When used in Visual mode it is made characterwise.
i) *v_i)* *i)* *i(*
***
*** 596,613 i( *v_ib* *v_i(* *ib*
--- 608,637
ib "inner block", select [count] blocks, from "[count] [("
to the matching ')', excluding the '(' and ')' (see
|[(|).
+ If it fails to find the block under or around the
+ cursor, and '(' was specified, it will search the
+ buffer forward for the block or, if ')' was specified,
+ it will search the buffer backwards.
When used in Visual mode it is made characterwise.
a> *v_a>* *v_a<* *a>* *a<*
a< "a <> block", select [count] <> blocks, from the
[count]'th unmatched '<' backwards to the matching
'>', including the '<' and '>'.
+ If it fails to find the block under or around the
+ cursor, and '<' was specified, it will search the
+ buffer forward for the block or, if '>' was specified,
+ it will search the buffer backwards.
When used in Visual mode it is made characterwise.
i> *v_i>* *v_i<* *i>* *i<*
i< "inner <> block", select [count] <> blocks, from
the [count]'th unmatched '<' backwards to the matching
'>', excluding the '<' and '>'.
+ If it fails to find the block under or around the
+ cursor, and '<' was specified, it will search the
+ buffer forward for the block or, if
Re: Patch to utilize undefined text-objects
Attached is a patch (in both the unified and context formats) to make the
discussed "am/im" text-object.
--
--
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.
*** a/runtime/doc/motion.txt
--- b/runtime/doc/motion.txt
***
*** 662,667 i` *v_i`* *i`*
--- 662,687
Special case: With a count of 2 the quotes are
included, but no extra white space as with a"/a'/a`.
+ am{char} *v_am* *am*
+ "a matched {char}". Selects the text from the
+ previous {char} until the next {char}.
+ Only works within one line.
+ When the cursor starts on a {char}, Vim will figure
+ out which {char} pairs are desired by searching from
+ the start of the line.
+ Any trailing white space is included, unless there is
+ none, then leading white space is included.
+ When used in Visual mode it is made characterwise.
+ Repeating this object in Visual mode another
+ {char}..{char} range is included. A count is
+ currently not used.
+
+ im{char} *v_im* *im*
+ Like am{char} but exclude the {char} and
+ repeating won't extend the Visual selection.
+ Special case: With a count of 2 the quotes are
+ included, but no extra white space as with am{char}.
+
When used after an operator:
For non-block objects:
For the "a" commands: The operator applies to the object and the white
*** a/runtime/doc/tags
--- b/runtime/doc/tags
***
*** 4751,4756 aleph options.txt /*aleph*
--- 4751,4757
alt intro.txt /*alt*
alt-input debugger.txt /*alt-input*
alternate-file editing.txt /*alternate-file*
+ am motion.txt /*am*
amiga-window starting.txt /*amiga-window*
and() eval.txt /*and()*
anonymous-function eval.txt /*anonymous-function*
***
*** 6520,6525 if_ruby.txt if_ruby.txt /*if_ruby.txt*
--- 6521,6527
if_sniff.txt if_sniff.txt /*if_sniff.txt*
if_tcl.txt if_tcl.txt /*if_tcl.txt*
ignore-errors eval.txt /*ignore-errors*
+ im motion.txt /*im*
improved-autocmds-5.4 version5.txt /*improved-autocmds-5.4*
improved-quickfix version5.txt /*improved-quickfix*
improved-sessions version5.txt /*improved-sessions*
***
*** 8441,8446 v_a[ motion.txt /*v_a[*
--- 8443,8449
v_a] motion.txt /*v_a]*
v_a` motion.txt /*v_a`*
v_ab motion.txt /*v_ab*
+ v_am motion.txt /*v_am*
v_ap motion.txt /*v_ap*
v_aquote motion.txt /*v_aquote*
v_as motion.txt /*v_as*
***
*** 8488,8493 v_i[ motion.txt /*v_i[*
--- 8491,8497
v_i] motion.txt /*v_i]*
v_i` motion.txt /*v_i`*
v_ib motion.txt /*v_ib*
+ v_im motion.txt /*v_im*
v_ip motion.txt /*v_ip*
v_iquote motion.txt /*v_iquote*
v_is motion.txt /*v_is*
*** a/src/normal.c
--- b/src/normal.c
***
*** 9309,9314 nv_object(cap)
--- 9309,9319
flag = current_quote(cap->oap, cap->count1, include,
cap->nchar);
break;
+ case 'm': /* "am" = a matching pair of characters */
+ cap->extra_char = plain_vgetc();
+ flag = current_quote(cap->oap, cap->count1, include,
+ cap->extra_char);
+ break;
#if 0 /* TODO */
case 'S': /* "aS" = a section */
case 'f': /* "af" = a filename */
diff --git a/runtime/doc/motion.txt b/runtime/doc/motion.txt
index d40d825..8af2b6e 100644
--- a/runtime/doc/motion.txt
+++ b/runtime/doc/motion.txt
@@ -662,6 +662,26 @@ i` *v_i`* *i`*
Special case: With a count of 2 the quotes are
included, but no extra white space as with a"/a'/a`.
+am{char} *v_am* *am*
+ "a matched {char}". Selects the text from the
+ previous {char} until the next {char}.
+ Only works within one line.
+ When the cursor starts on a {char}, Vim will figure
+ out which {char} pairs are desired by searching from
+ the start of the line.
+ Any trailing white space is included, unless there is
+ none, then leading white space is included.
+ When used in Visual mode it is made characterwise.
+ Repeating this object in Visual mode another
+ {char}..{char} range is included. A count is
+ currently not used.
+
+im{char} *v_im* *im*
+ Like am{char} but exclude the {char} and
+ repeating won't extend the Visual selection.
+ Special case: With a count of 2 the quotes are
+ included, but no extra white space as with am{char}.
+
When used after an operator:
For non-block objects:
For the "a" commands: The operator applies to the object and the white
diff --git a/runtime/doc/tags b/runtime/doc/tags
index 73475a9..405996e 100644
--- a/runtime/doc/tags
+++ b/runtime/doc/tags
@@ -4751,6 +4751,7 @@ aleph options.txt
Re: Patch to utilize undefined text-objects
On Sunday, November 17, 2013 3:55:18 PM UTC-5, glts wrote: > On Thu, Nov 14, 2013 at 2:14 AM, 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. This is very useful for editing lists. Similarly, if > > > one is composing TeX being able to quickly operate on the area between > > > dollar signs is useful. If one is editing snake_case_variables, being > > > able to do a quick "ci_" is also nice. The key here is that it happens > > > on-the-fly with all as-of-yet-undefined objects without requiring the > > > user consider every possible character he/she would be interested in > > > ahead of time. > > > > > > Outside of documentation and adding the setting itself, the it is only a > > > few additional lines of code. > > > > > > I've wanted this feature for a while; if there is anything else I should > > > do to help get it upstreamed do let me know and I'll see what I can do. > > > > Just to add a dissenting opinion. A feature that is easy to implement > > isn't necessarily a good addition to core Vim. For me, the proposed > > functionality is only marginally useful and just cries for a plugin > > solution. It would be really easy to do, too. > If you mean my original proposal, while it could certainly be done in script it would be *much* cleaner to do it in vim's source. If you mean Bram's proposed alteration of my proposal, not only would be easy to do, it's been done; someone else in this thread already pointed this one out: https://github.com/thinca/vim-textobj-between/blob/master/doc/textobj-between.txt What I had hoped for was a bit different from that and I don't think could be done nnearly as cleanly in script as it could be in vim, but Bram didn't seem as keen on it. > > Personally, I love to use a solid text object framework like > > > > http://www.vim.org/scripts/script.php?script_id=2100 > > > > and choose for myself which special-case text object I need on top of > > that. I like that Vim only has a few core text objects and lets me fill > > in the rest. I don't really see how this in any way conflicts with that option. > > By the way, "ii" is often used for "inner indent", which selects lines > > with the same or greater amount of indentation as the current line: > > > > http://www.vim.org/scripts/script.php?script_id=2484 > > http://www.vim.org/scripts/script.php?script_id=3037 > Good to know, "i" is out then. -- -- 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.
Re: Patch to utilize undefined text-objects
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.
Re: Patch to utilize undefined text-objects
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 "[ai]" 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.
Re: Patch to utilize undefined text-objects
On Thursday, November 14, 2013 11:16:24 AM UTC-5, Kent Sibilev wrote: > On Thursday, November 14, 2013 9:59:51 AM UTC-5, Ben Fritz wrote: > > > On Wednesday, November 13, 2013 10:10:39 PM UTC-6, Kent Sibilev wrote: > > > > > > > On Wednesday, November 13, 2013 8:14:20 PM UTC-5, Daniel "paradigm" 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. This is very useful for editing lists. Similarly, if > > > > > > > > > > > > > > Maybe i'm missing something, but you don't need to patch Vim in order to > > > get > > > > > > > this functionality. What you need is kana's textobj pluing: > > > > > > > > > > > > > > https://github.com/kana/vim-textobj-user > > > > > > > > > > > > > > along with textobj-between > > > > > > > > > > > > > > https://github.com/thinca/vim-textobj-between > > > > > > > > > > > > > > Also you can check kana's other projects where he provides many other > > > useful > > > > > > > text objects like: > > > > > > > > > > > > > > https://github.com/kana/vim-textobj-line > > > > > > > https://github.com/kana/vim-textobj-indent > > > > > > > etc. > > > > > > > > > > > > While mappings are more customizable, and there is a plugin for this, C > > > > > > code is faster and works in more situations. Mappings can be removed, > > > > > > ignored for various commands, problems can occur while chaining them > > > > > > together, complex mappings can break the undo sequence, etc. > > > > > > > > > > > > I don't think the existence of a plugin is a good reason to avoid a > > > > > > patch in this case. Text objects are one of the most powerful features > > > > > > of Vim. I support making them more powerful and adding more of them. The > > > > > > same arguments you make here can be used against adding ANY new text > > > > > > object, even defined ones. > > > > > > > > > > > > Relative line numbering could be done (poorly) with a plugin before the > > > > > > 'relativenumber' option was introduced. I'm very glad that made it into > > > > > > the C code. > > > > > > > > > > > > And Daniel's point about listing desired text-objects ahead of time is > > > > > > important as well. With the exception of commas, most of the time when > > > > > > I'd like a patch like this it's for something I didn't even think about > > > > > > ahead of time and will probably not think of again until the next time I > > > > > > need it. Stopping to make another mapping or plugin configuration, and > > > > > > maybe restarting Vim, is NOT an option. I'll just do it by hand. > > > > > > > > > > > > I certainly support this patch. I'll be applying it and running with it > > > > > > a while at least to try it out. I'd love to see a better option, but this > > > > > > is WAY better than nothing. > > > > I agree that having the native Vim support for a certain functionality is > more appealing. My point is that the proposed patch is quite limited in > nature and could potentially break existing plugins. I'd love to have a > native support of the functionality that is provided by textobj-user where I > can define my own text objects and avoid the possibility of problems > associated with complex mappings. Saying that i've been using textobj-user > plugin for many years and still have to encounter a single problem you > mentioned. The only way the patch could break an existi
Re: Patch to utilize undefined text-objects
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:
>
> > On Wednesday, November 13, 2013 11:10:39 PM UTC-5, Kent Sibilev wrote:
>
> > > Maybe i'm missing something, but you don't need to patch Vim in order to
> > > get this functionality. What you need is kana's textobj pluing:
>
> > > https://github.com/kana/vim-textobj-user
>
> > > along with textobj-between
>
> > > https://github.com/thinca/vim-textobj-between
>
> >
>
> > Yes, there are plenty of ways to make custom text-objects without editing
> > Vim. However, everything you've listed require the end-user list the
> > desired objects ahead of time. You could loop over the character range in
> > a plugin or vimrc and make them all, or make an operator-mode mapping to a
> > function that calls getchar() then tries to either make it on-the-fly or
> > fall back to existing things, but all of these options get ugly fast.
> > Adding three lines to normal.c ends up being much quicker and cleaner.
>
>
>
> With textobj-between plugin installed you don't need to loop over and make a
> mapping for every possible character. The plugin adds a single text object
> activated by pressing 'f'. So if you want to delete a content between to
> underscores (_) characters, you press dif_. If you want change text between
> two dollar sign characters you press cif$, etc.
My patch (as it is now) has it so you just press "di_" or "di$" - it's a
character shorter. It's also much simpler, total-code wise. Without the
documentation or setting, it is literally a one line change. Vim has all the
structure for this already in place, it just falls back to "flag = FAIL"
instead of doing something potentially useful. As Ben said, simply because it
can be done in a plugin doesn't mean that the best place for it if it can be
done simply in Vim itself.
>
>
>
> Also I don't understand how the aforementioned fallback would work in
> practice. For example, if I edit an html content aattbb and my
> cursor is on one of the dot characters. Is it true that pressing dit would
> delete only dots characters instead of all tag's content?
No - it would delete the tag's content, just as it does before the patch. The
*only* place the patch does anything is with invalid text-objects. With Vim
without my patch, if you enter "di$" it doesn't do anything because "$" is not
a valid text object specifier. Only in those conditions does my patch do
anything.
This may be best illustrated by showing the actual code. Here is Vim's code
without my patch:
switch (cap->nchar)
{
case 'w': /* "aw" = a word */
flag = current_word(cap->oap, cap->count1, include, FALSE);
break;
case 'W': /* "aW" = a WORD */
flag = current_word(cap->oap, cap->count1, include, TRUE);
break;
case 'b': /* "ab" = a braces block */
case '(':
case ')':
flag = current_block(cap->oap, cap->count1, include, '(', ')');
break;
case 'B': /* "aB" = a Brackets block */
case '{':
case '}':
flag = current_block(cap->oap, cap->count1, include, '{', '}');
break;
case '[': /* "a[" = a [] block */
case ']':
flag = current_block(cap->oap, cap->count1, include, '[', ']');
break;
case '<': /* "a<" = a <> block */
case '>':
flag = current_block(cap->oap, cap->count1, include, '<', '>');
break;
case 't': /* "at" = a tag block (xml and html) */
flag = current_tagblock(cap->oap, cap->count1, include);
break;
case 'p': /* "ap" = a paragraph */
flag = current_par(cap->oap, cap->count1, include, 'p');
break;
case 's': /* "as" = a sentence */
flag = current_sent(cap->oap, cap->count1, include);
break;
case '"': /* "a"" = a double quoted string */
case '\'': /* "a'" = a single quoted string */
case '`': /* "a`
Re: Patch to utilize undefined text-objects
On Thursday, November 14, 2013 6:31:12 AM UTC-5, Daniel "paradigm" Thau wrote: > On Wednesday, November 13, 2013 11:29:18 PM UTC-5, 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. This is very useful for editing lists. Similarly, if > > > > > one is composing TeX being able to quickly operate on the area between > > > > > dollar signs is useful. If one is editing snake_case_variables, being > > > > > able to do a quick "ci_" is also nice. The key here is that it happens > > > > > on-the-fly with all as-of-yet-undefined objects without requiring the > > > > > user consider every possible character he/she would be interested in > > > > > ahead of time. > > > > > > > > > > Outside of documentation and adding the setting itself, the it is only a > > > > > few additional lines of code. > > > > > > > > > > I've wanted this feature for a while; if there is anything else I should > > > > > do to help get it upstreamed do let me know and I'll see what I can do. > > > > > > > > The problem is that this only works for characters that are not taken > > > > yet. Thus if we add another text-object type the behavior changes. > > > > It's like reserving all remaining characters to use for this feature. > > > > > > > > I don't think this can be done properly without adding another > > > > character, thus making the text selection a three-character operation. > > > > > > > > -- > > > > Looking at Perl through Lisp glasses, Perl looks atrocious. > > > > > > > > /// 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/// > > My hope was that we could simply add a disclaimer saying that these are not > reserved and any new text object added in the future would take precident > over these. My patch includes some wording along those lines in the > documentation. If that is not acceptable, but making this a three-character > option is, I'll be happy alter it accordingly. As an alternative to a three-character option, it doesn't look like "I" or "A" do anything in operator-pending (but they do in visual mode). Perhaps would could utilize those for catch-all text-objects (and limit it to only working in operator-pending)? -- -- 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.
Re: Patch to utilize undefined text-objects
On Wednesday, November 13, 2013 11:29:18 PM UTC-5, 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. This is very useful for editing lists. Similarly, if > > > one is composing TeX being able to quickly operate on the area between > > > dollar signs is useful. If one is editing snake_case_variables, being > > > able to do a quick "ci_" is also nice. The key here is that it happens > > > on-the-fly with all as-of-yet-undefined objects without requiring the > > > user consider every possible character he/she would be interested in > > > ahead of time. > > > > > > Outside of documentation and adding the setting itself, the it is only a > > > few additional lines of code. > > > > > > I've wanted this feature for a while; if there is anything else I should > > > do to help get it upstreamed do let me know and I'll see what I can do. > > > > The problem is that this only works for characters that are not taken > > yet. Thus if we add another text-object type the behavior changes. > > It's like reserving all remaining characters to use for this feature. > > > > I don't think this can be done properly without adding another > > character, thus making the text selection a three-character operation. > > > > -- > > Looking at Perl through Lisp glasses, Perl looks atrocious. > > > > /// 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/// My hope was that we could simply add a disclaimer saying that these are not reserved and any new text object added in the future would take precident over these. My patch includes some wording along those lines in the documentation. If that is not acceptable, but making this a three-character option is, I'll be happy alter it accordingly. -- -- 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.
Re: Patch to utilize undefined text-objects
On Wednesday, November 13, 2013 11:10:39 PM UTC-5, Kent Sibilev wrote: > On Wednesday, November 13, 2013 8:14:20 PM UTC-5, Daniel "paradigm" 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. This is very useful for editing lists. Similarly, if > > > > Maybe i'm missing something, but you don't need to patch Vim in order to get > this functionality. What you need is kana's textobj pluing: > > > > https://github.com/kana/vim-textobj-user > > > > along with textobj-between > > > > https://github.com/thinca/vim-textobj-between > > > > Also you can check kana's other projects where he provides many other useful > text objects like: > > > > https://github.com/kana/vim-textobj-line > > https://github.com/kana/vim-textobj-indent > > etc. Yes, there are plenty of ways to make custom text-objects without editing Vim. However, everything you've listed require the end-user list the desired objects ahead of time. You could loop over the character range in a plugin or vimrc and make them all, or make an operator-mode mapping to a function that calls getchar() then tries to either make it on-the-fly or fall back to existing things, but all of these options get ugly fast. Adding three lines to normal.c ends up being much quicker and cleaner. -- -- 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.
Re: Patch to utilize undefined text-objects
On Wednesday, November 13, 2013 9:06:25 PM UTC-5, Ben Fritz wrote: > On Wednesday, November 13, 2013 7:14:20 PM UTC-6, Daniel "paradigm" 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. This is very useful for editing lists. Similarly, if > > > one is composing TeX being able to quickly operate on the area between > > > > > > dollar signs is useful. If one is editing snake_case_variables, being > > > able to do a quick "ci_" is also nice. The key here is that it happens > > > on-the-fly with all as-of-yet-undefined objects without requiring the > > > > > > user consider every possible character he/she would be interested in > > > ahead of time. > > > > > > Outside of documentation and adding the setting itself, the it is only a > > > few additional lines of code. > > > > > > I've wanted this feature for a while; if there is anything else I should > > > > > > do to help get it upstreamed do let me know and I'll see what I can do. > > > > > > - Daniel Thau > > > > I cannot get this patch to apply using either whatever "patch" utility is > installed on Solaris or GNU patch on Windows. Can you please post in a > different patch format? No matter how I tweak the patch file, and no matter > what I put for the -p value, I cannot get it to apply. The best it does is > tell me the patch looks like a unified context diff and then ask me for a > file to patch. As far as I know that's a fairly standard unified format patch against the latest Vim from hg (7.4.91). I tried creating one with "git diff" (as Tony cleverly surmized), "git format-patch", as well as good old fashioned GNU diff on Linux with the "-u" flag to make a unified format patch - all three versions came out more or less the same, baring email boilerplate from git. I managed to apply all of them with GNU patch against the latest Vim from hg. Some googling around makes it seem as though Solaris's /usr/bin/patch may not know unified diff format. See if you have a /usr/bin/qpatch on your system and try with that. Although that does not explain why GNU patch on Windows didn't like it. I'll try and make a context format with diff -c later for you in the next few days if need be. -- -- 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.
