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 existing plugin is if the plugin relies
on text-object commands which are not yet defined failing. This is
theoretically possible but very hacky - I have a hard time imagining it being
used. Even _if_ such a thing existed, it could simply disable the setting for
the plugin's duration.
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.
--
--
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.
