[vim/vim] Documentation of CTRL-D/CTRL-U is no longer accurate (Issue #14338)
luukvbaal
@chrisbra after patch 9.1.0215, the following from :h CTRL-D is no longer accurate:
The cursor is moved the same number of lines down in the file
Also, CTRL-D was the only scroll key that would stop at the end of the buffer (neovim/neovim#28100 (comment)) instead of scrolling to reveal EOB lines.
We can either:
- Update the documentation.
- Try to restore the previous cursor/EOB behavior only for CTRL-D/U.
- Try to apply the previous cursor/EOB behavior from CTRL-D/U to all page scroll keys if that behavior is considered desirable.
Personally I tend toward 1. or 3., I don't see why these keys should behave differently (other than backward compatibility).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
thanks for noticing. Can we restore the old behaviour?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
luukvbaal
I can try, but are we making a decision solely for backward compatibility? Or can we consider which of the two old behaviors makes more sense for scrolling the viewport. Either the cursor position stays the same and only starts moving to be at the top/botline(CTRL-E/Y/F/B), or the cursor moves the same amount of lines as the viewport did(CTRL-D/U).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
luukvbaal
Did it make sense they they behaved differently? Do we not care and try to restore the old behavior regardless?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
luukvbaal
If we try to restore the old behavior for CTRL-D/U , it's also unclear how "The cursor is moved the same number of lines down in the file" should work with 'smoothscroll'. The behavior from CTRL-E/Y/F/B is more predictable.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Gary Johnson
> I can try, but are we making a decision solely for backward compatibility? Or
> can we consider which of the two old behaviors makes more sense for scrolling
> the viewport. Either the cursor position stays the same and only starts moving
> to be at the top/botline(CTRL-E/Y/F/B), or the cursor moves the same amount of
> lines as the viewport did(CTRL-D/U).
the difference was deliberate. They're both useful. Which behavior
makes more sense to you may not be what makes more sense to someone
else. Unless there is a problem with the old behavior, other than
the inconvenience of maintaining it, I think it should be restored.
Regards,
Gary
vim-dev ML
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Chocolate Overflow
After using (n)vim for a long time, the sudden change confused me for a bit even if I had never actually read that bit of documentation. I also prefer the old behavior which stops like G does. I personally have no use for seeing what's beyond EOF, and others can just add zz if they want to maintain focus.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
David
At first I even thought it was a nvim issue but wow, from vim itself? changing decades old behavior?
if braan was here this type of change would never have happened...
You guys should really get together and decide on what you want the vim path forward to be as these types of changes are really bad for everyone. Get together and write some manifesto on some general guidelines or rules to follow when opening a PR something like (prefer backwards compatibility vs breaking decades old behavior), or the opposite. I just think it would make for a more transparent discussion instead of changing old behavior and then saying "documentation is no longer accurate".
I personally use a mapping that does => zz to scroll things halfway and keep the cursor in the middle and now this behavior doesnt work. Is there at least some other alternative that can be used to achieve the same behavior?
I don't want to sound agressive or ungrateful as I understand open source is incredibly hard to do well and very exhausting due to the absurd lack of funding maintainers get, but I also believe I should say something and not just remain quiet so that the vim maintainers know that these type of decisions do impact end users on their day to day work/life.
All the best.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
luukvbaal
I agree (I don't think Bram would have). To be honest I didn't expect the previous PRs to be merged quite so quickly. We could have had this discussion in the original PR as well, the changed behavior was quite obvious from the test changes. I could have been more transparent as well, I suppose was used to Brams inevitable feedback from the last time I contributed to Vim :)
Anyways, if you don't want development to affect your day to day maybe you shouldn't use a development version. Since it is now clear the old behavior is preferred, I'm working on restoring that...
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Shane-XB-Qian
Anyways, if you don't want development to affect your day to day maybe you shouldn't use a development version.
general users did not know it's your feat or bug, please donot expect too much, but always try best to verify or test etc, keep consistently.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Christian Brabandt
Closed #14338 as completed via cb204e6.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Christian Brabandt
@dagadbm When I merged it, I thought it was simply supporting smothscrolling, wasn't aware that this could cause backwards-incompatible issues. Thanks for @luukvbaal for restoring the previous behaviour, while keeping smoothscrolling support. I have just merged it.
In any case, things are a bit in flow currently and we are not close to a release. So some potential fallout can be expected. I try not to break backwards compatibility intentionally, but of course I'd like Vim to be improved and fixed. Yes it might be slightly differently from how Bram used to work, but I need to make some compromises. I don't know all of the code as good as Bram and cannot test each change thoroughly and I have to trust contributors (which I think are also making a good job). Otherwise, the list of issues and PRs just flows over and I will never get a chance to get those numbers down.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Gary Johnson
> In any case, things are a bit in flow currently and we are not close to a
> release. So some potential fallout can be expected. I try not to break
> backwards compatibility intentionally, but of course I'd like Vim to be
> improved and fixed. Yes it might be slightly differently from how Bram used to
> work, but I need to make some compromises. I don't know all of the code as good
> as Bram and cannot test each change thoroughly and I have to trust contributors
> (which I think are also making a good job). Otherwise, the list of issues and
> PRs just flows over and I will never get a chance to get those numbers down.
You have been doing a fantastic job. I appreciate your hard work
and your dedication to keeping that balance between backwards
compatibility and improvement. Thank you.
Thanks also to the others who have jumped in and helped to keep Vim
thriving.
Regards,
Gary
vim-dev ML
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
David
happened with that security incident on the xs package also helps open up
more eyes of open source developers.
I hope what I said was taken as a positive feedback as in a way to make it
easier to review PRs or to address issues.
I do not contribute to vim at most I can politely be annoyed at something
but under no way should the maintainer feel like my frustration is an
indication of failure.
I also apologize for even bringing Bram into this... it was a very dick
move now that I think of it... sorry.
On Tue, Apr 2, 2024, 23:46 vim-dev ML ***@***.***> wrote:
> On 2024-04-02, Christian Brabandt wrote:
>
> > In any case, things are a bit in flow currently and we are not close to a
> > release. So some potential fallout can be expected. I try not to break
> > backwards compatibility intentionally, but of course I'd like Vim to be
> > improved and fixed. Yes it might be slightly differently from how Bram
> used to
> > work, but I need to make some compromises. I don't know all of the code
> as good
> > as Bram and cannot test each change thoroughly and I have to trust
> contributors
> > (which I think are also making a good job). Otherwise, the list of
> issues and
> > PRs just flows over and I will never get a chance to get those numbers
> down.
>
> Christian,
>
> You have been doing a fantastic job. I appreciate your hard work
> and your dedication to keeping that balance between backwards
> compatibility and improvement. Thank you.
>
> Thanks also to the others who have jumped in and helped to keep Vim
> thriving.
>
> Regards,
> Gary
>
> —
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AD7WGR4CYZFT53KVXNAVWUDY3MYMNAVCNFSM6AAAAABFOWHJ22VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZTGIZDQNBUGA>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
Shane-XB-Qian
@dagadbm relex, the passion of giving feedback which to fix broken shortly/timely was ok, specially to those IF that broken was stayed actually longer than reasonable dev window or obvious wrong ones, but just sometime somehow need to give some patient or something. anyway, part of was good job, thanks, keep going whatever, and help bram's legacy by our all.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
luukvbaal
Crossposting neovim/neovim#28251 for visibility. Do we need to restore the old behavior? In my opinion the new behavior better matches the documentation, and applies better to 'smoothscroll'.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Christian Brabandt
thanks for already providing the fix!
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Yee Cheng Chin
Anyways, if you don't want development to affect your day to day maybe you shouldn't use a development version. Since it is now clear that maintaining the old behavior is preferred, I'm working on restoring that...
I don't want to detract from the discussion too much but FWIW we don't really have a clear "development version" versus release version of Vim. While it's true that Vim has a major/minor/patch number scheme, the major and minor version gets incremented infrequently enough that most package managers and other release channels (e.g. MacVim which I maintain) just grab the latest builds. With the myriad of options to get Vim, each commit does have the potential to impact a number of end users, for better for worse (to be fair that is how we manage to get feedback so quickly). It's useful to be mindful of that.
@luukvbaal Just for a piece of constructive criticism, looking at #14316, it mentioned "staying backward compatible as much as possible", which I think was not a useful way to phrase such a change. The point of a review is not just to make sure the code is fine, but to have have certain design decisions vetted and reviewed by the maintainer (I think any backwards incompatible change in even non-Vim software would be considered design changes and need to be raised). Even say if Bram reviewed this, it would have been easy for him to miss such a thing. It's best to help the reviewer help you when listing out all the things that they need to know so save everyone's time.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.