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. :(
Tavis.
--
-------------------------------------
taviso@sdf.lonestar.org | finger me for my pgp key.
-------------------------------------------------------
--
--
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/20200415141824.GA28%40thinkstation.
No comments:
Post a Comment