[Note: a third patch below]
Hmm, hard to see how those changes relate to either of those issues. The
description of their solutions don't directly relate either. Maybe other
changes were what fixed these things?
The change to set_fraction() for 7.4.280 looks a bit nonsensical too.
w_fraction is an integer, scaled up by a large number FRACTION_MULT to
allow it to act like a fixed point float. At the time I wrote that, there
were no floats used anywhere in vim, and it seemed risky somehow to start
using them just for this, cross-platform-wise. Are floats used elsewhere
now? If so we could make this a float instead which would simplify the
math.
Anyway, the scaling looks wrong now (it is mixing the scaled-up ints with
ints that haven't been scaled up, and treating them the same). Could
probably revert the change in set_fraction() and it would be better.
In fact I do still see a bug with the w_fraction stuff. Resize down to two
lines, move cursor from top line to bottom line, resize larger, then resize
back down to 2 lines. Now cursor is on top line instead of bottom where it
started. I suspect reverting set_fraction() will fix that...
Yep, tried it and it fixed it. Patch below (please combine with previous
patch).
The other changes in the fix seem separate, and are probably what's fixing
the 7.4.280 issue.
The changes for 7.4.365 don't appear related. They change the indenting on
the two calls to set_topline() in win_new_height(), but didn't move them
inside the two if-branches. That must have happened earlier.
Ah, it was 7.4.309. I think it's the added "if (sline > 0)" check that
fixes that, not moving the call to set_topline() which I think is an error.
So I suspect my three patches (including the one below) should be safe.
Are there tests for 7.4.280 and 7.4.309 to confirm?
New patch:
Subject: [PATCH 3/3] Fixed: resize window to 2 lines, move cursor from top to
bottom line, resize larger, and resize back down to 2 lines again. Cursor
line was now at top instead of bottom.
---
src/window.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/window.c b/src/window.c
index 48e343263..0c77d7914 100644
--- a/src/window.c
+++ b/src/window.c
@@ -5725,7 +5725,7 @@ set_fraction(win_T *wp)
{
if (wp->w_height > 1)
wp->w_fraction = ((long)wp->w_wrow * FRACTION_MULT
- + wp->w_height / 2) / (long)wp->w_height;
+ + FRACTION_MULT / 2) / (long)wp->w_height;
}
/*
--
2.19.1.windows.1
On Mon, 25 Feb 2019 at 03:44, Christian Brabandt <[email protected]> wrote:
>
> On So, 24 Feb 2019, Robert Webb wrote:
>
> > > * Bug: resize windows by dragging the divider between them down to
> a
> > single
> > > line. The window directly above the divider is fine (as it has
> focus),
> > but
> > > windows higher up that are reduced to a single line, or windows
> below
> > that
> > > are reduced to a single line, don't end up showing the line with
> the
> > > cursor. They are one away from it. As soon as you move the mouse
> over
> > > them they update to correctly show the cursor line. This is kind
> of
> > > annoying. Aside from seeing something change out of the corner of
> your
> > eye
> > > as the mouse moves and wondering what happened, I also often want
> to see
> > > that one line. I often reduce a window down to one important line
> I want
> > > to see while working in another window.
> > >
> > > I'm using gvim on Windows, 8.1, patches 1-897.
> >
> > It's very likely the code to keep the cursor in the same relative
> > position. Hmm, I wonder who wrote that? :-)
> >
> >
> > Well it worked when I wrote it :)
> >
> > I had a quick look and found the problem quickly by comparing the old
> and new
> > code.
> >
> > Problem was that the call to set_topline() had been moved into the two
> > if-branches, so it didn't get called any more when sline == 0.
> >
> > Do you think that was done to fix some other issue though, or just
> because it
> > was presumed more efficient?
>
> That was done because of 7.4.365 and the other change was because of
> 7.4.280. The patch description mention some problems/crash that those
> changes tried to fix.
>
> > Patch below fixes the bug. Is this the right way to supply patches?
>
> Yes, as long as it is some kind of patch, Bram typically figures it out
> ;)
>
> Best,
> Christian
> --
> Wer sich sonst keinen Schmuck leistet, soll wenigstens jedes Wort auf die
> Goldwaage legen dürfen.
>
> --
> --
> You received this message from the "vim_dev" 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_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
--
--
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
