removing past start position

[Tavis Ormandy]

Hello, I don't like the way that CTRL-W stops at the position you
entered insert mode.

For example, you can reproduce the behavior I'm talking about like this:

* In normal mode, position the cursor at the end of a word, then enter
insert mode.
* Type some letters to make the word longer, then CTRL-W.
* You should see that the word is only removed up until the position
you entered insert mode.

I would like the word removed until the previous word boundary.

Is there any way to configure that?

Thanks!

--
-------------------------------------
tav...@sdf.lonestar.org | finger me for my pgp key.
-------------------------------------------------------

[Christian Brabandt]

On Di, 14 Apr 2020, Tavis Ormandy wrote:

> Hello, I don't like the way that CTRL-W stops at the position you
> entered insert mode.
>
> For example, you can reproduce the behavior I'm talking about like this:
>
> * In normal mode, position the cursor at the end of a word, then enter
> insert mode.
> * Type some letters to make the word longer, then CTRL-W.
> * You should see that the word is only removed up until the position
> you entered insert mode.
>
> I would like the word removed until the previous word boundary.
>
> Is there any way to configure that?

Sounds like you have started vim in compatible mode. :set nocp should
fix it, but that enables a bunch of other options as well, so more
specifically, use :set bs=2

Best,
Christian
--
Wenn es Silvester stürmt und schneit, ist das neue Jahr nicht weit.

[Tavis Ormandy]

On Tuesday, April 14, 2020 at 9:40:00 AM UTC-7, Christian Brabandt wrote:

Sounds like you have started vim in compatible mode. :set nocp should
fix it, but that enables a bunch of other options as well, so more
specifically, use :set bs=2

Thanks, but I'm not in compatible mode. In compatible mode, AFAICT, CTRL-W

does not remove at all and just moves the cursor position.

I already use bs=2, but I tried 0 and 1 as well, and it doesn't change it :-(

Thanks!

[Christian Brabandt]

On Di, 14 Apr 2020, Tavis Ormandy wrote:

>
>

> On Tuesday, April 14, 2020 at 9:40:00 AM UTC-7, Christian Brabandt wrote:
>
>
> Sounds like you have started vim in compatible mode. :set nocp should
> fix it, but that enables a bunch of other options as well, so more
> specifically, use :set bs=2
>
>
>
>
> Thanks, but I'm not in compatible mode. In compatible mode, AFAICT, CTRL-W
> does not remove at all and just moves the cursor position.

I believe, CTRL-W has always deleted (only until the position where you
entered insert mode) as far as I remember. The behaviour you describe I
only know from compatible mode.

> I already use bs=2, but I tried 0 and 1 as well, and it doesn't change it :-(

Are you sure? I cannot reproduce this. What does `:verbose :set bs? cp?` say?
What Vim version? Can you reproduce starting from vim --clean?

Best,
Christian
--
Achtet nicht die Achtenswerten, und es wird nicht Streit sein im
Volk.
-- Lao-tse (Dao-de-dsching)

[Tavis Ormandy]

On Tue, Apr 14, 2020 at 06:56:32PM +0200, Christian Brabandt wrote:
> > Thanks, but I'm not in compatible mode. In compatible mode, AFAICT, CTRL-W
> > does not remove at all and just moves the cursor position.
>
> I believe, CTRL-W has always deleted (only until the position where you
> entered insert mode) as far as I remember. The behaviour you describe I
> only know from compatible mode.
>
> > I already use bs=2, but I tried 0 and 1 as well, and it doesn't change it :-(
>
> Are you sure? I cannot reproduce this. What does `:verbose :set bs? cp?` say?
> What Vim version? Can you reproduce starting from vim --clean?
>

Yes, I'm sure - but you must have a setting that does what I want!

This is with 8.0.1453, but it's worked like this by default for a long
time, I've just decided I'd try to fix this long-time annoyance today.

To be clear, very detailed reproduction steps:

1. In a new file, write this:

one two three

2. Enter normal mode, position the cursor after "two" and enter insert
mode, then type "four". It should look like this:

one twofour three

3. *before* leaving insert mode, hit CTRL-W. I think it will now look
like this:

one two three

But I want this:

one three

[Christian Brabandt]

On Di, 14 Apr 2020, Tavis Ormandy wrote:

> To be clear, very detailed reproduction steps:
>
> 1. In a new file, write this:
>
> one two three
>
> 2. Enter normal mode, position the cursor after "two" and enter insert
> mode, then type "four". It should look like this:
>
> one twofour three
>
> 3. *before* leaving insert mode, hit CTRL-W. I think it will now look
> like this:
>
> one two three
>
> But I want this:
>
> one three

Ah got it. That must have been there very long (and I actually like this
behaviour).

I suppose you want something like this:

diff --git a/src/edit.c b/src/edit.c
index edd2374e8..5be76db07 100644
--- a/src/edit.c
+++ b/src/edit.c
@@ -4883,9 +4883,7 @@ ins_bs(
#ifdef FEAT_RIGHTLEFT
revins_on ||
#endif
- (curwin->w_cursor.col > mincol
- && (curwin->w_cursor.lnum != Insstart_orig.lnum
- || curwin->w_cursor.col != Insstart_orig.col)));
+ curwin->w_cursor.col > mincol);
}
did_backspace = TRUE;
}


If you want to have this included into propper vim, we probably need
another CPOPTION value (or backspace value?), to make this configurable
and a test.

Best,
Christian
--
Letzte Worte eines Fallschirmspringers:
"Welcher Notfallschirm?"

[Bram Moolenaar]

Yeah, would need another value in 'backspace'. CTRL-W stopping at the
insert point has always been the behavior.
:set backspace=indent,eol,start,nostop
Can't think of a good name for "nostop", could be improved. Or just:
:set bs=3

--
Friends? I have lots of friends! In fact, I have all episodes ever made.

/// 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 ///

[Tavis Ormandy]

On Tue, Apr 14, 2020 at 08:23:09PM +0200, Bram Moolenaar wrote:
> Christian wrote:
> >
> > I suppose you want something like this:
> >
> > diff --git a/src/edit.c b/src/edit.c
> > index edd2374e8..5be76db07 100644
> > --- a/src/edit.c
> > +++ b/src/edit.c
> > @@ -4883,9 +4883,7 @@ ins_bs(
> > #ifdef FEAT_RIGHTLEFT
> > revins_on ||
> > #endif
> > - (curwin->w_cursor.col > mincol
> > - && (curwin->w_cursor.lnum != Insstart_orig.lnum
> > - || curwin->w_cursor.col != Insstart_orig.col)));
> > + curwin->w_cursor.col > mincol);
> > }
> > did_backspace = TRUE;
> > }

Thanks, I tried it, that is exactly what I want!

> >
> >
> > If you want to have this included into propper vim, we probably need
> > another CPOPTION value (or backspace value?), to make this configurable
> > and a test.
>
> Yeah, would need another value in 'backspace'. CTRL-W stopping at the
> insert point has always been the behavior.
> :set backspace=indent,eol,start,nostop
> Can't think of a good name for "nostop", could be improved. Or just:
> :set bs=3
>

That would be really appreciated. I can't tell you how many times I've
confused myself by forgetting CTRL-W stops at the insertion point.

Thanks so much for the help.

[Brian L. Matthews]

While certainly it's your guys' decision, but, as CTRL-W stops but then
continues before the start of the insertion, is another option really
necessary? In fact, I think it could be the current behavior is better,
as it stops indicating you've now deleted everything you just entered,
but if you really want to delete more, just keep hitting CTRL-W.

Brian

[Tavis Ormandy]

On Tue, Apr 14, 2020 at 11:34:28AM -0700, Brian L. Matthews wrote:
> > Yeah, would need another value in 'backspace'. CTRL-W stopping at the
> > insert point has always been the behavior.
> > :set backspace=indent,eol,start,nostop
> > Can't think of a good name for "nostop", could be improved. Or just:
> > :set bs=3
> >
>
> While certainly it's your guys' decision, but, as CTRL-W stops but then
> continues before the start of the insertion, is another option really
> necessary? In fact, I think it could be the current behavior is better, as
> it stops indicating you've now deleted everything you just entered, but if
> you really want to delete more, just keep hitting CTRL-W.
>

You don't need CTRL-W at all if you don't mind hitting more keys, but
since we do have it and configurable behaviour, why not cover all the
variations people could want?

I understand you like bs=2, you probably wouldn't be too thrilled if it
was changed to require more keystrokes, even if you could just keep
hitting more keys :)

Tavis.

[Brian L. Matthews]

On 4/14/20 11:45 AM, Tavis Ormandy wrote:
> On Tue, Apr 14, 2020 at 11:34:28AM -0700, Brian L. Matthews wrote:
>>> Yeah, would need another value in 'backspace'. CTRL-W stopping at the
>>> insert point has always been the behavior.
>>> :set backspace=indent,eol,start,nostop
>>> Can't think of a good name for "nostop", could be improved. Or just:
>>> :set bs=3
>>>
>> While certainly it's your guys' decision, but, as CTRL-W stops but then
>> continues before the start of the insertion, is another option really
>> necessary? In fact, I think it could be the current behavior is better, as
>> it stops indicating you've now deleted everything you just entered, but if
>> you really want to delete more, just keep hitting CTRL-W.
>>
> You don't need CTRL-W at all if you don't mind hitting more keys, but
> since we do have it and configurable behaviour, why not cover all the
> variations people could want?

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 understand you like bs=2, you probably wouldn't be too thrilled if it
> was changed to require more keystrokes, even if you could just keep
> hitting more keys :)

There's a difference between changing long-existing behavior and adding
new behavior. Yes, I wouldn't be happy if bs=2 went away, I use that all
the time (with BS). But that's not what we're discussing here (a fairer
comparison would be if it was changed so BS would have to be hit a
second time upon hitting the start of inserted text to continue into
existing text. While changing it now would affect decades (literally!)
of muscle memory, in time I'd learn, and if it had always worked that
way, I would have seen it as a feature.)

Anyways, as I said, this is completely up to Bram (and Christian). I'm
certainly not going to like and use vim any less if the new option and
behavior is added (or if it's not), just offering my opinion. I'm nobody
:-), so feel free to ignore it.

Brian

[Tavis Ormandy]

On Tue, Apr 14, 2020 at 01:44:50PM -0700, Brian L. Matthews wrote:
> > You don't need CTRL-W at all if you don't mind hitting more keys, but
> > since we do have it and configurable behaviour, why not cover all the
> > variations people could want?
>
> 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.

If you want software minimalism, you have a ton of editors to choose
from.

> There's a difference between changing long-existing behavior and adding new
> behavior. Yes, I wouldn't be happy if bs=2 went away, I use that all the
> time (with BS).

Umm, bs already has three options. Arguing that 3 is the perfect number
seems really odd. Any option that you wouldn't use doesn't make vim
better for you, but it sure does for other people... that's a good thing!

I happily volunteer any of the options you use that I don't to make the
option counts neutral, how's that ;-)

Tavis.

[Christian Brabandt]

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)

[Tavis Ormandy]

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. :(

[Bram Moolenaar]

Tavis Ormandy wrote:

> On Tue, Apr 14, 2020 at 01:44:50PM -0700, Brian L. Matthews wrote:
> > > You don't need CTRL-W at all if you don't mind hitting more keys, but
> > > since we do have it and configurable behaviour, why not cover all the
> > > variations people could want?
> >
> > 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.
>
>
> If you want software minimalism, you have a ton of editors to choose
> from.
>
> > There's a difference between changing long-existing behavior and adding new
> > behavior. Yes, I wouldn't be happy if bs=2 went away, I use that all the
> > time (with BS).
>
> Umm, bs already has three options. Arguing that 3 is the perfect number
> seems really odd. Any option that you wouldn't use doesn't make vim
> better for you, but it sure does for other people... that's a good thing!
>
> I happily volunteer any of the options you use that I don't to make the
> option counts neutral, how's that ;-)

To make CTRL-W delete all text until the start of the file:
:set bs=7

To make CTRL_W delete all text you ever wrote:
:set bs=42

Intermediate values TBD.

--
OLD WOMAN: King of the WHO?
ARTHUR: The Britons.
OLD WOMAN: Who are the Britons?
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

[Tavis Ormandy]

On Wed, Apr 15, 2020 at 08:06:14PM +0200, Bram Moolenaar wrote:
>
> To make CTRL-W delete all text until the start of the file:
> :set bs=7
>
> To make CTRL_W delete all text you ever wrote:
> :set bs=42
>
> Intermediate values TBD.
>

ITYM all the text you ever wrote *up to* the insertion point ;-)

Tavis.

--
----------------------------
tav...@sdf.org | finger me for my pgp key.
----------------------------------------------

[Bram Moolenaar]

> On Wed, Apr 15, 2020 at 08:06:14PM +0200, Bram Moolenaar wrote:
> >
> > To make CTRL-W delete all text until the start of the file:
> > :set bs=7
> >
> > To make CTRL_W delete all text you ever wrote:
> > :set bs=42
> >
> > Intermediate values TBD.
> >
>
> ITYM all the text you ever wrote *up to* the insertion point ;-)

Birth.

--
ARTHUR: You are indeed brave Sir knight, but the fight is mine.
BLACK KNIGHT: Had enough?
ARTHUR: You stupid bastard. You havn't got any arms left.

[Christian Brabandt]

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

[Jaehwang Jerry Jung]

> 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>

Here's the mapping I've been using:

inoremap <C-w> <C-\><C-o><ESC><C-w>

The advantage of this is that it doesn't create a new undo block.