Patch to utilize undefined text-objects
Daniel Thau
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
Ben Fritz
Tony Mechelynck
of your Vim source directory tree (with the parent of src/ runtime/ etc.
being the current directory) but I didn't try to see if it works. I have
the impression that it was made by "git diff" or somesuch after
converting the Mercurial repository to git form. You might try "hg
qimport" (with the mq extension enabled), and if it doesn't work at
first try, you may want to remove the "index" lines in the patch. See
"hg help qimport" and possibly "hg help qqueue" et al. for details.
Best regards,
Tony.
--
The biggest difference between time and space is that you can't reuse time.
-- Merrick Furst
James McCoy
> 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.
autotextobject.diff” both worked fine for me in a clone of the Vim
sources, specifically:
changeset: 5496:34a3b852ec05
bookmark: master
tag: tip
user: Bram Moolenaar <br...@vim.org>
date: Tue Nov 12 18:09:29 2013 +0100
summary: Added tag v7-4-091 for changeset 9502d1caf90b
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jame...@jamessan.com>
Gary Johnson
> 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.
itself is OK.
I saved the attachment to my home directory, then cd'd to my vim
source directory, the one containing the .hg directory, and executed
patch like this.
$ patch -p1 --dry-run < ~/autotextobject.diff
patching file runtime/doc/motion.txt
patching file runtime/doc/options.txt
patching file runtime/doc/tags
Hunk #3 succeeded at 7793 (offset -2 lines).
patching file src/normal.c
Hunk #1 succeeded at 9308 (offset -7 lines).
patching file src/option.c
Hunk #1 succeeded at 554 (offset -1 lines).
patching file src/option.h
That directory has the source for Vim 7.4.41. I didn't notice which
version the patch applied to, but a different version would explain
the offsets.
Here is the patch version info.
$ patch -v
patch 2.6
Copyright (C) 1988 Larry Wall
Copyright (C) 2003 Free Software Foundation, Inc.
This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
written by Larry Wall and Paul Eggert
This system is running Ubuntu 10.04.
HTH,
Gary
Daniel "paradigm" Thau
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.
Ben Fritz
> On 14/11/13 03:06, 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.
>
> >
>
>
>
> It looks like something that ought to apply with -p1 starting at the top
>
> of your Vim source directory tree (with the parent of src/ runtime/ etc.
>
> being the current directory)
Yeah, that's what I tried first. Didn't work.
> but I didn't try to see if it works. I have
>
> the impression that it was made by "git diff" or somesuch after
>
> converting the Mercurial repository to git form.
That was my thought as well.
> You might try "hg
>
> qimport" (with the mq extension enabled),
Don't have it and can't install it on the Solaris machine. Does that work if the directory is a zip downloaded from Github instead of a real repository? My workplace blocks all outgoing Hg, Git, and SVN connections.
> and if it doesn't work at
>
> first try, you may want to remove the "index" lines in the patch.
I tried that too, for the patch utility.
Ben Fritz
> On Wednesday, November 13, 2013 9:06:25 PM UTC-5, Ben Fritz wrote:
> >
> > 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.
>
again tomorrow at work.
> 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.
everything else just apply the patch by hand. It's pretty small.
> Although that does not explain why GNU patch on Windows
> didn't like it.
>
for the lines that are not part of the actual hunk changes. I tried tweaking
the patch to add a few Windows line endings but only managed to get GNU patch to
crash instead.
> I'll try and make a context format with diff -c later for you in the next few
> days if need be.
Ben Fritz
> On Wednesday, November 13, 2013 8:45:43 PM UTC-6, Daniel "paradigm" Thau wrote:
> > On Wednesday, November 13, 2013 9:06:25 PM UTC-5, Ben Fritz wrote:
> > 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.
>
> Ugh, good to know. I'll look for that utility at work tomorrow, or failing
> everything else just apply the patch by hand. It's pretty small.
>
> > days if need be.
>
> No need, I'll generate it myself if I must. Sorry for the trouble.
Actually I just made it now. Attached for anybody else who needs it.
Here's how, from my home computer which DOES have Vim as an Hg repository:
patch -p1 < autotextobject.diff
hg extdiff -o -Nprc > autotextobject_context.patch
Kent Sibilev
> 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
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.
Bram Moolenaar
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 -- Br...@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 ///
Daniel "paradigm" Thau
Daniel "paradigm" Thau
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.
Daniel "paradigm" Thau
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)?
Ben Fritz
> 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.
>
> 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 disagree that this is a problem. By default, the option introduced by this patch is off, meaning that unreserved text-object characters still do nothing unless the user opts into the behavior by explicitly setting an option.
The documentation for the option explicitly says that it only affects potential objects that are NOT already defined. So basically it is an option that says "do something useful instead of failing if I type something undefined". It also explicitly says that future additions to defined text objects will override this option.
If someone is using this option then they should expect minor changes when new text objects get introduced.
>
> 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?
Ben Fritz
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.
Ben Fritz
> 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.
> >
> > 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.
Ben Fritz
of the prompt for a file to patch. I finally found /usr/bin/gpatch on the
Solaris system, thanks to
http://stackoverflow.com/questions/3477580/cant-apply-unified-diff-patch-on-solaris.
This can apply either the context diff or the original unified diff.
I think maybe that's what you meant instead of "qpatch" above.
Windows GNU patch may have worked after I tweaked it for line endings, I thought
it failed due to a failed hunk and aborted it. We both included some help tags
stuff that had nothing to do with your change.
Kent Sibilev
> 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
>
Also I don't understand how the aforementioned fallback would work in practice. For example, if I edit an html content <h1>aat....tbb</h1> 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?
Kent Sibilev
Daniel "paradigm" Thau
> 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 <h1>aat....tbb</h1> 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`" = a backtick quoted string */
flag = current_quote(cap->oap, cap->count1, include,
cap->nchar);
break;
#if 0 /* TODO */
case 'S': /* "aS" = a section */
case 'f': /* "af" = a filename */
case 'u': /* "au" = a URL */
#endif
default:
flag = FAIL;
break;
}
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.
With regards to:
> 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 agree with what Ben said. By default this is off so that any unreserved text-object characters don't do anything unless the user opts-in to this. The disclaimer NOTE in the description should ensure that no one depends on this being guarenteed to act the same with future versions of Vim - it's not actually reserving the entire namespace there.
My argument for this patch really boils down to the following:
As Vim acts now, most of the "<operator>[ai]<character>" namespace is completely unused. Reserving it for future use doesn't benefit anyone nearly as much as having it do something sane/useful. A trivially small patch can be used to have do something useful in the unused part of that namespace (without touching the used part at all). A disclaimer - plus the fact it is a default-off setting - can be made (and is, in the patch) so that people do not rely on those keystrokes always acting the same.
Daniel "paradigm" Thau
FWIW, here's some code that will operate differently if the patch is used and the setting is set:
:execute "normal! i$foo$\<esc>ci$Abar\<esc>"
Off the top of my head I can't see why that would be explicitly desired, but even if it does exist, the plugin can simply disable the new setting my patch adds for it's duration.
If a plugin tries to map something like "di$" it can still do so - the map will outprioritize Vim's default actions.
Jürgen Krämer
Hi,
contain the old and new range of the hunk and end with @@. But in this
patch @@ does not end the line; the line still contains some text that
might be the line from before the hunk.
Regards,
J�rgen
--
Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us. (Calvin)
tooth pik
really like the idea and may [finally!] start using text objects if it
is implemented
count me +1 for on-the-fly text objects
--
_|_ _ __|_|_ ._ o|
|_(_)(_)|_| ||_)||<
|
Kent Sibilev
> 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.
>
>
> My argument for this patch really boils down to the following:
>
> As Vim acts now, most of the "<operator>[ai]<character>" namespace is completely unused. Reserving it for future use doesn't benefit anyone nearly as much as having it do something sane/useful. A trivially small patch can be used to have do something useful in the unused part of that namespace (without touching the used part at all). A disclaimer - plus the fact it is a default-off setting - can be made (and is, in the patch) so that people do not rely on those keystrokes always acting the same.
Daniel "paradigm" Thau
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.
Tony Mechelynck
> On Wednesday, November 13, 2013 8:27:22 PM UTC-6, Tony Mechelynck wrote:
>>
>> of your Vim source directory tree (with the parent of src/ runtime/ etc.
>>
>> being the current directory)
>
> Yeah, that's what I tried first. Didn't work.
>
>> but I didn't try to see if it works. I have
>>
>> the impression that it was made by "git diff" or somesuch after
>>
>> converting the Mercurial repository to git form.
>
> That was my thought as well.
>
>> You might try "hg
>>
>> qimport" (with the mq extension enabled),
>
> Don't have it and can't install it on the Solaris machine. Does that work if the directory is a zip downloaded from Github instead of a real repository? My workplace blocks all outgoing Hg, Git, and SVN connections.
Mercurial repository. Git is still "a foreign language" to me and even
reading the "git help" manuals doesn't give me any understanding of that
software's philosophy, so I cannot help you there. That's also why all
the advice I give is based on Mercurial. If someone else here is a git
guru, (s)he is more than welcome to speak up.
If you can install Mercurial on your home machine and then clone Bram's
repository there, you could try applying the patch there. "hg diff"
understands git-style patches and can even produce them, unlike some
current versions of GNU patch and GNU diff; IMHO in the light of your
comments in this latest post of yours, that difference is your only hope
of getting that patch to apply on a Mercurial clone. — Or if the OP's
patch wasn't built from the latest Vim patchlevel (7.3.91 at the time
this thread was created IIRC) he ought to tell us which patchlevel he
used as a reference - the patch might have bitrotten since then. -- BTW
the mq extension which I mentioned is a Mercurial component which is
included out of the box in all current versions, but disabled by
default. How to enable it is explained in "hg help extensions" and "hg
help config" but the latter has a lot of info about other kinds of
config settings.
If your work sysadmin won't uninstall a Mercurial software package which
you would have installed somewhere under your home directory, you can
make a "bundle" from a Mercurial clone at home (see "hg help bundle")
and "unbundle" it on the work machine, thus creating a clone there
without the need for any hg connection over the Internet. Of course you
still won't be able to "hg pull" from Bram's repo at work, but you can
make incremental bundles at home and sneak them in on a USB key.
If your work sysadmin _does_ forbid (and prevent) installing both Git
and Mercurial on your work machine, you will of course still find the
full source tree as part of a git or Mercurial repository — metadata is
kept in a directory named .git or .hg (respectively) inside it, plus
maybe a very small number of files with longer names starting with .git
or .hg in the top-level repository, so none of that additional stuff
should be a problem. But — "of course" again — you won't be able to run
hg (q)import or hg (q)diff without Mercurial installed, and similarly
mutatis mutandis for the corresponding git commands.
>
>> and if it doesn't work at
>>
>> first try, you may want to remove the "index" lines in the patch.
>
> I tried that too, for the patch utility.
>
>> See
>>
>> "hg help qimport" and possibly "hg help qqueue" et al. for details.
>>
>
Tony.
--
Why I Can't Go Out With You:
I'd LOVE to, but ...
-- I have to floss my cat.
-- I've dedicated my life to linguini.
-- I need to spend more time with my blender.
-- it wouldn't be fair to the other Beautiful People.
-- it's my night to pet the dog/ferret/goldfish.
-- I'm going downtown to try on some gloves.
-- I have to check the freshness dates on my dairy products.
-- I'm going down to the bakery to watch the buns rise.
-- I have an appointment with a cuticle specialist.
-- I have some really hard words to look up.
-- I've got a Friends of the Lowly Rutabaga meeting.
-- I promised to help a friend fold road maps.
Nikolay Pavlov
On Nov 15, 2013 7:49 AM, "Tony Mechelynck" <antoine.m...@gmail.com> wrote:
>
> On 14/11/13 04:00, Ben Fritz wrote:
>>
>> On Wednesday, November 13, 2013 8:27:22 PM UTC-6, Tony Mechelynck wrote:
>
> […]
>
>>> It looks like something that ought to apply with -p1 starting at the top
>>>
>>> of your Vim source directory tree (with the parent of src/ runtime/ etc.
>>>
>>> being the current directory)
>>
>>
>> Yeah, that's what I tried first. Didn't work.
>>
>>> but I didn't try to see if it works. I have
>>>
>>> the impression that it was made by "git diff" or somesuch after
>>>
>>> converting the Mercurial repository to git form.
>>
>>
>> That was my thought as well.
>>
>>> You might try "hg
>>>
>>> qimport" (with the mq extension enabled),
>>
>>
>> Don't have it and can't install it on the Solaris machine. Does that work if the directory is a zip downloaded from Github instead of a real repository? My workplace blocks all outgoing Hg, Git, and SVN connections.
>
>
> A zip downloaded from github will, IIUC, be a git repository and not a Mercurial repository. Git is still "a foreign language" to me and even reading the "git help" manuals doesn't give me any understanding of that software's philosophy, so I cannot help you there. That's also why all the advice I give is based on Mercurial. If someone else here is a git guru, (s)he is more than welcome to speak up.
It will not be a repository at all. Neither git nor mercurial. Github provides repository snapshots. I have never heard of a code hosting that allows downloading archive with repository.
> --
> --
> 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+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
Tony Mechelynck
[…]
> the @@ lines look suspicious to me. I thought they should start with @@,
> contain the old and new range of the hunk and end with @@. But in this
> patch @@ does not end the line; the line still contains some text that
> might be the line from before the hunk.
>
> Regards,
>
IIUC, in a "git-style" diff, that's the name of the "function"
containing the hunk — the function name as guessed by the git diff or hg
diff command, and that doesn't always make sense for a programmer of
whichever language the file is in.
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
44. Your friends no longer send you e-mail...they just log on to your IRC
channel.
Bram Moolenaar
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).
Daniel "paradigm" Thau
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|".
glts
> 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
> 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.
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.
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.
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
Best,
--
David
Daniel "paradigm" Thau
> On Thu, Nov 14, 2013 at 2:14 AM, Daniel Thau <dan...@bedrocklinux.org> 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.
Bram Moolenaar
Daniel Thau wrote:
> Attached is a patch (in both the unified and context formats) to make
> the discussed "am/im" text-object.
> --- 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
Ernie Rael
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
Daniel "paradigm" Thau
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.
Daniel "paradigm" Thau
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.
Ben Fritz
> 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.
> >
> >
> >
I wasn't sure about this idea, but I think it should be fine, and it adds the benefit that you can either do:
vi"
to get the current behavior, or:
vim"
if you want to match multi-line strings!
Daniel "paradigm" Thau
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.
Ben Fritz
FWIW, I've been compiling and running on Solaris and Windows with this patch applied for a couple months now, and haven't seen any problems. I admit I only use the added feature occasionally, but it's nice to know it's there, and I'm sure it's partially due to habit of not having it available for so long.
Peter Aronoff
> > 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.
around. They both build nicely on Mac OSX, and after initial testing, I'm
liking them both.
Just fyi (and for anyone else on the list), I have a Homebrew formula that
makes it easy to install both patches on a Mac. It might be useful for
other people as well:
https://github.com/telemachus/brew/blob/master/Formula/vim.rb
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
Marcin Szamotulski
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
Daniel "paradigm" Thau
Good catch. I can replicate that on my end. Will fix.
Marcin Szamotulski
Regards,
Marcin
Ben Fritz
>
> 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 :-)
Ben Fritz
• one
• two
• three
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.
Daniel "paradigm" Thau
> 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
>
> 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.
Peter Aronoff
> Should be fixed in the attachment. As a bonus, it now supports things
> such as digraphs.
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
Daniel "paradigm" Thau
That is in fact another bug. No idea how that slipped by me. I'll be sure to fix that as well.
Ben Fritz
> 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.
> > >
> > > >
> > >
> > > 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.
Daniel "paradigm" Thau
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.
Christian Wellenbrock
I have written a plugin[1] that adds similar functionality. You might want to take a look at the tests[2] that work similar to Vim's test suite.
[1] https://github.com/wellle/targets.vim
[2] https://github.com/wellle/targets.vim/tree/master/test
Ben Fritz
>
> 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.
That patch still applies in 7-4-256, minus a small tweak to the src/testdir/Makefile. I think I characterized the visual mode issue a little better. It appears to only expand the visual selection to the right, it does not move the left side.
Example, with text "I like to eat apples" I can place the cursor on the first "p" of apples and type "vime". This selects from that p up to just before the "e" in apples. If the cursor is on the "t" in "eat" instead, vime will select from the t to the "e" in apples. With the cursor on the "a" in "eat" the full text is selected. Using "vame" is similar, the full text is only selected if I place the cursor on the "e" in "eat". The selection always starts from the cursor location.