[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is ins
From: |
Michael Heerdegen |
Subject: |
bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay. |
Date: |
Mon, 28 Feb 2022 00:19:36 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
Eli Zaretskii <eliz@gnu.org> writes:
> In the context of redisplay, any change of the window-start point is
> referred to as "scrolling the window". So when you tell the display
> engine to make sure the window-start is visible, and the last used
> window-start isn't, you cannot at the same time ask it not to scroll,
> because that's a contradiction.
But when I said that using the new variable makes Emacs really scroll,
visually, not only in an abstract sense, didn't you say mean that was
unavoidable?
> > And tell me that a solution without scrolling involved
> > is not possible, and why, or why you think that scrolling is
> > unavoidable. You said it can't be avoided when we do something in the
> > display engine.
>
> That's not what I said. Quote:
>
> It isn't unavoidable, but doing something more sophisticated would
> call for a significantly more complex code. The current solution for
> when this variable is set and the window-start point is invisible is
> very simple: we recenter the window around point. The recentering
> method is safe, because it always succeeds, which is why it also
> serves as the fallback method of finding the suitable window-start for
> redisplaying a window. The code that implements the recentering was
> already there, so the introduction of this new variable boiled down to
> recognizing the conditions under which we should go directly to
> recentering, bypassing all the other methods.
Recenter means actual, not only per definition scroll - right?
> I need a more concrete proposal to answer these questions. IOW, I
> don't think I understand what kind of solution do you have in mind
> here.
I didn't make one since my knowledge here in inferior. Personally I
would adjust window-start from a hook and call `redisplay', which is
probably not the best solution.
> That was an (obviously failed) attempt to joke about the practice not
> to close bug reports where there's nothing left to do, that's all.
> Why you saw that as unfriendly, and against you on top of that, I
> don't think I understand; I certainly didn't mean that.
Ok..ok. Then I misinterpreted your intention. Didn't sound at all like
a joke to me. Then let's try to get back to the issue.
Michael.
- bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay., (continued)
- bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay., Michael Heerdegen, 2022/02/09
- bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay., Eli Zaretskii, 2022/02/10
- bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay., Michael Heerdegen, 2022/02/10
- bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay., Eli Zaretskii, 2022/02/11
- bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay., Michael Heerdegen, 2022/02/11
- bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay., Eli Zaretskii, 2022/02/12
- bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay., Michael Heerdegen, 2022/02/12
- bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay., Eli Zaretskii, 2022/02/13
- bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay., Michael Heerdegen, 2022/02/26
- bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay., Eli Zaretskii, 2022/02/27
- bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.,
Michael Heerdegen <=
- bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay., Eli Zaretskii, 2022/02/28