On Mi, 15 Apr 2020, Tavis Ormandy wrote:
> On Wed, Apr 15, 2020 at 08:22:27AM +0200, Christian Brabandt wrote:
> > I am sympathetic to these arguments. We shouldn't add new options
> > especially if they only affect a very tiny behaviour of Vim. Changing
> > the core of vim certainly adds to the complexity of the different code
> > paths so this needs to be rectified so that the user can benefit from
> > it. And I believe Bram has a similar feeling.
>
> What option doesn't affect a very tiny behaviour? We're talking about an
> editor, the reason we're not all using pico is because we can work more
> efficiently by building our own perfect collection of very tiny
> behaviours, no? :)
>
> > However in this case, we already have an option setting to influence the
> > behaviour of how to do the backspacing. So just adding a new value there
> > might be okay (of course we need a clear value and description of that
> > the new value does different, so that it doesn't confuse users).
> >
> > Having said all that, I have been thinking, whether a clever mapping
> > could not already achieve what is desired. Something like this perhaps:
> >
> > inoremap <c-w> <left><c-o>v<c-left><del>
> >
>
> Thanks, it's very clever. I tried it out, but it does replace one
> annoyance with another. :(
Okay, will post a proper patch later.
Best,
Christian
--
Jeder Mensch hat ein Brett vor dem Kopf - es kommt nur auf die
Entfernung an.
-- Marie von Ebner-Eschenbach
--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20200416061932.GZ25035%40256bit.org.
No comments:
Post a Comment