On Di, 14 Apr 2020, Brian L. Matthews wrote:
> While this is more software design philosophy than vim-specific, it's
> because every configurable behavior requires code to parse the new option
> (however minimal), code to use the new option, one or more tests,
> documentation changes, it makes the code that little bit harder to maintain
> and learn, and it makes learning to use the software a little bit harder. If
> the new behavior is significantly better, then yes, why not. I'm not sure if
> this qualifies.
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.
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>
It might not work correctly on certain edge cases (e.g. start of line)
but it has the benefit, it would even work in todays Vims, no need to
wait for a patch to be applied. And if we define the correct behaviour
for edge cases, we might easily re-adjust the mapping logic.
Best,
Christian
--
In einer hoch entwickelten Zivilisation ist "Diener des Volkes"
gleichbedeutend mit "Herr des Volkes".
-- Robert Anson Heinlein (Die Leben des Lazarus Long)
--
--
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/20200415062226.GR25035%40256bit.org.
Tuesday, April 14, 2020
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment