bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[E Sabof]

[-- Attachment #1: Type: text/plain, Size: 621 bytes --]

Evaluate in emacs -Q

(let (pt pt2 ws ov)
  (insert "Lorem ipsum dolor sit amet.")
  (setq pt (point))
  (insert "Consectetuer adipiscing elit." "\n")
  (setq ws (point))
  (insert "Phasellus lacus." "\n")
  (insert "Cum sociis natoque penatibus et magnis dis.")
  (setq pt2 (point))
  (insert "\n")
  (insert "Parturient montes, nascetur ridiculus mus." "\n")
  (insert "Nullam eu ante vel est convallis dignissim." "\n")
  (set-window-start nil ws)
  (setq ov (make-overlay pt pt2))
  (overlay-put ov 'display "..."))

It will appear as though the overlay is at the beginning of the line, even
though it's not.

Evgeni

[-- Attachment #2: Type: text/html, Size: 992 bytes --]

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Eli Zaretskii]

> Date: Sun, 9 Jun 2013 10:13:09 +0100
> From: E Sabof <esabof@gmail.com>
> 
> Evaluate in emacs -Q
> 
> (let (pt pt2 ws ov)
>   (insert "Lorem ipsum dolor sit amet.")
>   (setq pt (point))
>   (insert "Consectetuer adipiscing elit." "\n")
>   (setq ws (point))
>   (insert "Phasellus lacus." "\n")
>   (insert "Cum sociis natoque penatibus et magnis dis.")
>   (setq pt2 (point))
>   (insert "\n")
>   (insert "Parturient montes, nascetur ridiculus mus." "\n")
>   (insert "Nullam eu ante vel est convallis dignissim." "\n")
>   (set-window-start nil ws)
>   (setq ov (make-overlay pt pt2))
>   (overlay-put ov 'display "..."))
> 
> It will appear as though the overlay is at the beginning of the line, even
> though it's not.

"If it hurts, don't do that."  You've put window-start on a position
that is at the beginning of a line, but happens to be covered by an
overlay.  Emacs obeyed.

What did you expect instead, and why?  Is there some real-life use
case where this causes trouble?

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[E Sabof]

[-- Attachment #1: Type: text/plain, Size: 610 bytes --]

On Sun, Jun 9, 2013 at 6:06 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> "If it hurts, don't do that."  You've put window-start on a position
> that is at the beginning of a line, but happens to be covered by an
> overlay.  Emacs obeyed.
>
> What did you expect instead, and why?  Is there some real-life use
> case where this causes trouble?
>

I think the correct behavior would be to adjust the window-position. As far
as the window is concerned, putting a hiding overlay should be no different
than deleting text.

Yes, it happens quite frequently after (fold-dwim-hide-all), and maybe in
similar commands.

[-- Attachment #2: Type: text/html, Size: 1098 bytes --]

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Eli Zaretskii]

> Date: Sun, 9 Jun 2013 18:37:12 +0100
> From: E Sabof <esabof@gmail.com>
> Cc: 14582@debbugs.gnu.org
> 
> I think the correct behavior would be to adjust the window-position.

Adjust to where?

> Yes, it happens quite frequently after (fold-dwim-hide-all), and maybe in
> similar commands.

Who calls set-window-start there, and why do they set window-start in
the middle of text that is hidden?

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[E Sabof]

[-- Attachment #1: Type: text/plain, Size: 757 bytes --]

On Sun, Jun 9, 2013 at 6:52 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sun, 9 Jun 2013 18:37:12 +0100
> > From: E Sabof <esabof@gmail.com>
> > Cc: 14582@debbugs.gnu.org
> >
> > I think the correct behavior would be to adjust the window-position.
>
> Adjust to where?
>

Either to the next or previous character starting a line.

>
> > Yes, it happens quite frequently after (fold-dwim-hide-all), and maybe in
> > similar commands.
>
> Who calls set-window-start there, and why do they set window-start in
> the middle of text that is hidden?
>

There is no need to call it explicitly. Part of a function might be before
the window start, and part after. If one evokes hs-hide-all (to which
fold-dwim-hide-all
delegates), the same thing will happen.

[-- Attachment #2: Type: text/html, Size: 1577 bytes --]

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Eli Zaretskii]

> Date: Sun, 9 Jun 2013 19:16:06 +0100
> From: E Sabof <esabof@gmail.com>
> Cc: 14582@debbugs.gnu.org
> 
> > > I think the correct behavior would be to adjust the window-position.
> >
> > Adjust to where?
> >
> 
> Either to the next or previous character starting a line.

You mean, a character that is outside the overlay, I presume.

> > > Yes, it happens quite frequently after (fold-dwim-hide-all), and maybe in
> > > similar commands.
> >
> > Who calls set-window-start there, and why do they set window-start in
> > the middle of text that is hidden?
> >
> 
> There is no need to call it explicitly. Part of a function might be before
> the window start, and part after. If one evokes hs-hide-all (to which
> fold-dwim-hide-all
> delegates), the same thing will happen.

It would help if you could show a recipe with one of these starting
from "emacs -Q".

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[E Sabof]

[-- Attachment #1: Type: text/plain, Size: 176 bytes --]

> It would help if you could show a recipe with one of these starting
> from "emacs -Q".
>

Sure:

M-x hs-minor-mode
Scroll until only the last line is visible
M-x hs-hide-all

[-- Attachment #2: Type: text/html, Size: 586 bytes --]

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[E Sabof]

[-- Attachment #1: Type: text/plain, Size: 355 bytes --]

On Sun, Jun 9, 2013 at 7:40 PM, E Sabof <esabof@gmail.com> wrote:

>
> It would help if you could show a recipe with one of these starting
>> from "emacs -Q".
>>
>
> Sure:
>
> M-x hs-minor-mode
> Scroll until only the last line is visible
> M-x hs-hide-all
>
>
It already does something similar, if you repeat the above recipe, but two
lines are visible.

[-- Attachment #2: Type: text/html, Size: 1168 bytes --]

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Lars Ingebrigtsen]

E Sabof <esabof@gmail.com> writes:

>  It would help if you could show a recipe with one of these starting
>  from "emacs -Q".
>
> Sure:
>
> M-x hs-minor-mode
> Scroll until only the last line is visible
> M-x hs-hide-all

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

I tried reproducing this in Emacs 29, but I didn't see anything odd in
the window after doing this in src/buffer.c.

Are you still seeing this issue in recent Emacs versions?  If so, do you
have a more complete recipe to reproduce the problem?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Are you still seeing this issue in recent Emacs versions?  If so, do
> you have a more complete recipe to reproduce the problem?

AFAIU, I still see this.

The effect is that the first visual line in the folded buffer looks like

...

i.e. consists of just three eliding dots, but when I scroll up, I see
that the dots belong to e.g.

(progn...)

I see that all the time when working with hideshow, and it's quite
annoying.

Lars, you just need to follow the recipe of the OP in an Elisp buffer
containing some code to reproduce the issue.  You maybe need to repeat a
second time (unfold + refold again).

If still not lucky, I'll try to create a step-by-step recipe, but maybe
it's clear enough.  And I hope I did not misinterpret the original
report.

Michael.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: E Sabof <esabof@gmail.com>,  Eli Zaretskii <eliz@gnu.org>,
>   14582@debbugs.gnu.org
> Date: Mon, 31 Jan 2022 01:36:41 +0100
> 
> The effect is that the first visual line in the folded buffer looks like
> 
> ...
> 
> i.e. consists of just three eliding dots, but when I scroll up, I see
> that the dots belong to e.g.
> 
> (progn...)
> 
> I see that all the time when working with hideshow, and it's quite
> annoying.

After considering this for a while, I don't think it would be a good
idea to try to fix this on the level of the display engine.  The
reason is that there are gobs of Lisp programs out there playing all
kinds of tricks with overlays and invisible text and expecting Emacs
to heed those tricks, and so any change like the one suggested,
i.e. let the display engine disobey the window-start setting in this
situation, is definitely going to break some package, and probably a
lot of them.

Basically, we are being asked to introduce application-level logic
into the general-purpose parts of the display code: the application
sets the window-start at some place which happens to be a bad idea,
and wants the display engine to save the application from itself.  I
don't think it's TRT.  The application alone knows what would be a
good place for setting the window-start, and should avoid setting it
where the result will be sub-optimal.

If this issue causes trouble in hideshow or elsewhere, my suggestion
is to fix it in those packages instead.  It shouldn't be hard to know
whether a given buffer position is or isn't invisible, and move point
from there if so.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Basically, we are being asked to introduce application-level logic
> into the general-purpose parts of the display code: the application
> sets the window-start at some place which happens to be a bad idea,
> and wants the display engine to save the application from itself.  I
> don't think it's TRT.

There is a misunderstanding here: hideshow doesn't change window-start.

What actually happens is: Elisp, be it hideshow or whatever, changes
visibility of some part(s) of the buffer.  Sometimes it can happen that
the old window start position (in any window) is part of a fold
(invisible region) afterwards.  Then the issue I described occurs.

Michael.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: larsi@gnus.org,  esabof@gmail.com,  14582@debbugs.gnu.org
> Date: Mon, 31 Jan 2022 19:42:39 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Basically, we are being asked to introduce application-level logic
> > into the general-purpose parts of the display code: the application
> > sets the window-start at some place which happens to be a bad idea,
> > and wants the display engine to save the application from itself.  I
> > don't think it's TRT.
> 
> There is a misunderstanding here: hideshow doesn't change window-start.
> 
> What actually happens is: Elisp, be it hideshow or whatever, changes
> visibility of some part(s) of the buffer.  Sometimes it can happen that
> the old window start position (in any window) is part of a fold
> (invisible region) afterwards.  Then the issue I described occurs.

Then please provide a full, self-contained recipe starting from "emacs
-Q" that uses hideshow.  The only recipe I saw and analyzed in this
bug was the original one, which did set window-start.  Perhaps you are
talking about a different issue.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Then please provide a full, self-contained recipe starting from "emacs
> -Q" that uses hideshow.  The only recipe I saw and analyzed in this
> bug was the original one, which did set window-start.  Perhaps you are
> talking about a different issue.

I think I mean the same.  I guess the original recipe only explicitly
sets window-start to ensure the recipe reliably works regardless of the
number of display lines and such things.

Anyway, this here works for me:

Open emacs -Q (I'm in X), and evaluate (with M-:) the follow piece of code:

#+begin_src emacs-lisp
(progn
  (dotimes (_ 33) (insert "\
\(defun foo ()
  1
  2)\n"))
  (goto-char (point-max))
  (sit-for 1)
  (scroll-down)
  (sit-for 1)
  (hs-minor-mode)
  (hs-hide-all))
#+end_src

That gives me a display of *scratch* where the first visible window line
displays "...)" instead of expected "(defun xyz nil...)".

Michael.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: larsi@gnus.org,  esabof@gmail.com,  14582@debbugs.gnu.org
> Date: Tue, 01 Feb 2022 04:03:04 +0100
> 
> I think I mean the same.  I guess the original recipe only explicitly
> sets window-start to ensure the recipe reliably works regardless of the
> number of display lines and such things.
> 
> Anyway, this here works for me:
> 
> Open emacs -Q (I'm in X), and evaluate (with M-:) the follow piece of code:
> 
> #+begin_src emacs-lisp
> (progn
>   (dotimes (_ 33) (insert "\
> \(defun foo ()
>   1
>   2)\n"))
>   (goto-char (point-max))
>   (sit-for 1)
>   (scroll-down)
>   (sit-for 1)
>   (hs-minor-mode)
>   (hs-hide-all))
> #+end_src
> 
> That gives me a display of *scratch* where the first visible window line
> displays "...)" instead of expected "(defun xyz nil...)".

Yes, it's basically the same issue.

So please tell me: why do you expect Emacs to move the window-start so
that the window displays starting at "(defun ...)" in the above case?
What would be the trigger for making that change in the window-start
position?

It's a good-faith question.  The display engine doesn't know anything
about the semantics and the intended effect of hiding the bodies of
the functions by putting the invisible property there; in fact, the
display engine doesn't even know what a function's body is, nor where
it begins and ends.  The original window-start position was inside a
function's body, and the call to hs-hide-all causes that position to
be displayed as the ellipsis, that's all.  There's nothing here to
cause the display engine to move window-start.  So it doesn't, because
it, by design, tries not to move the window-start fixed as much as
possible.

Perhaps your mental model of redisplay is that it determines the
window-start position _after_ it applies the various text properties
and overlays, which affect what will be visible on display.  In which
case it would have noticed that after hiding the function bodies the
visual line will start at "(defun ...", and would therefore start the
window's display there.  But that's not how redisplay works: it in
fact first determines where to put window-start, and only after that
redisplays the window using that window-start position.  And if that
causes the window-start position to be covered by some display or
invisible property or some overlay, it's all fine from the POV of the
display engine -- precisely _because_ it isn't any of its business to
understand what those properties and overlays mean and what effect
they want to produce.

hs-minor-mode _does_ know what effect it wants to produce, so it's
hs-minor-mode that needs to adjust window-start if it happens to wind
up in the part of text that is about to be hidden on display.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Perhaps your mental model of redisplay is that it determines the
> window-start position _after_ it applies the various text properties
> and overlays, which affect what will be visible on display.  In which
> case it would have noticed that after hiding the function bodies the
> visual line will start at "(defun ...", and would therefore start the
> window's display there.

Yes, something like that.  At least, I would not expect that only a part
of a (visual) line is displayed, however that comes.

> hs-minor-mode _does_ know what effect it wants to produce, so it's
> hs-minor-mode that needs to adjust window-start if it happens to wind
> up in the part of text that is about to be hidden on display.

Let's extend the discussion to invisible text in general - hideshow is
only one application of invisible text.  Are there cases where the
current behavior makes sense and is expected?  More sense than the
behavior I expect?

I ask because you said that the display engine can't know the intention.
Does it have to?  Why can't the credo just be "always ensure complete
visual lines are displayed"?


Regards,

Michael.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: larsi@gnus.org,  esabof@gmail.com,  14582@debbugs.gnu.org
> Date: Wed, 02 Feb 2022 02:12:03 +0100
> 
> Let's extend the discussion to invisible text in general - hideshow is
> only one application of invisible text.  Are there cases where the
> current behavior makes sense and is expected?  More sense than the
> behavior I expect?

How can we know?  There's any number of Lisp programs out there using
invisible properties.  Starting with Org.

> I ask because you said that the display engine can't know the intention.
> Does it have to?  Why can't the credo just be "always ensure complete
> visual lines are displayed"?

Because a Lisp program may wish otherwise.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> How can we know?  There's any number of Lisp programs out there using
> invisible properties.  Starting with Org.

In Org I actually see the same bug (I tried org-shifttab).  Isearch also
has the issue when re-hiding opened invisible text areas.  Could be that
in most usage scenarios the current behavior is not wanted.

> > Why can't the credo just be "always ensure complete visual lines are
> > displayed"?
>
> Because a Lisp program may wish otherwise.

I do know and only know Lisp programs that wish like this.  It feels
wrong that Elisp programs should have to adjust window-start.  Anyway,
no surprise that I see it like that.

Is there a third alternative, a hook or something that could be used, to
perform this task automatically?  I mean, else, every program that
toggles invisibility of text would have to loop over all windows that
display a certain buffer, examine text properties and check whether
window-start has to be adjusted.  I would not even be sure what to do in
situations when the first line is only partially visible and such stuff.

Michael.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: larsi@gnus.org,  esabof@gmail.com,  14582@debbugs.gnu.org
> Date: Wed, 02 Feb 2022 05:02:41 +0100
> 
> Is there a third alternative, a hook or something that could be used, to
> perform this task automatically?

It cannot be a hook, because from the display engine POV nothing
happened that could trigger a hook.  The visible contents of the
window is different, that's all.

So it shouldn't be a hook, it should be a buffer-local variable that
would change how redisplay behaves in these cases.  I will see what
can be done about it.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Eli Zaretskii]

> Date: Wed, 02 Feb 2022 14:31:35 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: larsi@gnus.org, esabof@gmail.com, 14582@debbugs.gnu.org
> 
> > From: Michael Heerdegen <michael_heerdegen@web.de>
> > Cc: larsi@gnus.org,  esabof@gmail.com,  14582@debbugs.gnu.org
> > Date: Wed, 02 Feb 2022 05:02:41 +0100
> > 
> > Is there a third alternative, a hook or something that could be used, to
> > perform this task automatically?
> 
> It cannot be a hook, because from the display engine POV nothing
> happened that could trigger a hook.  The visible contents of the
> window is different, that's all.
> 
> So it shouldn't be a hook, it should be a buffer-local variable that
> would change how redisplay behaves in these cases.  I will see what
> can be done about it.

I installed a change along these lines.  A buffer that sets the new
variable make-window-start-visible non-nil should force redisplay to
reject a window-start point that is in invisible text or is covered by
a "replacing" 'display' property (which also makes window-start
invisible), and choose a different starting point.

Please test.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> I installed a change along these lines.  A buffer that sets the new
> variable make-window-start-visible non-nil should force redisplay to
> reject a window-start point that is in invisible text or is covered by
> a "replacing" 'display' property (which also makes window-start
> invisible), and choose a different starting point.
>
> Please test.

Cool - thanks.

I played shortly with the new option enabled.  I didn't experience this
issue, but in some situations redisplay seems to infloop.  Seems that
happens when the first line is wrapped - at least I didn't see the same
problem without wrapped lines.  Here is a reproducer for emacs -Q (just
eval with M-:):

#+begin_src emacs-lisp
(progn
  (dotimes (_ 100) (insert "\
\(defun foooooooooo (long-arg another-long-arg an-even-very-long-arg \
and-one-more-arg)
  1
  2)\n"))
  (setq make-window-start-visible t)
  (goto-char (point-max))
  (sit-for 1)
  (scroll-down)
  (sit-for 1)
  (hs-minor-mode)
  (hs-hide-all))
#+end_src

BTW, I wondered - do we also have to care about window-end - or can
the thing this report is about only happen for window-start?

Thanks,

Michael.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: larsi@gnus.org,  esabof@gmail.com,  14582@debbugs.gnu.org
> Date: Fri, 04 Feb 2022 02:37:44 +0100
> 
> I played shortly with the new option enabled.  I didn't experience this
> issue, but in some situations redisplay seems to infloop.  Seems that
> happens when the first line is wrapped - at least I didn't see the same
> problem without wrapped lines.  Here is a reproducer for emacs -Q (just
> eval with M-:):
> 
> #+begin_src emacs-lisp
> (progn
>   (dotimes (_ 100) (insert "\
> \(defun foooooooooo (long-arg another-long-arg an-even-very-long-arg \
> and-one-more-arg)
>   1
>   2)\n"))
>   (setq make-window-start-visible t)
>   (goto-char (point-max))
>   (sit-for 1)
>   (scroll-down)
>   (sit-for 1)
>   (hs-minor-mode)
>   (hs-hide-all))
> #+end_src

Thanks, should be fixed now.

> BTW, I wondered - do we also have to care about window-end - or can
> the thing this report is about only happen for window-start?

window-end point is determined as side effect of successful complete
redisplay of a window, and cannot be determined before redisplay is
complete.  The window-end point isn't necessarily at the end of some
physical line, and it is by definition at the end of a visual line.
So I don't see why would we need to care about something similar
happening at the window's end.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Thanks, should be fixed now.

Thank you.

Hmm - found another infloop, even without invisibility involved, when
narrowing:

#+begin_src emacs-lisp
(progn
  (dotimes (_ 100) (insert "\
\(defun foo (x y)
  1
  2)\n"))
  (setq make-window-start-visible t)
  (goto-char (point-min))
  (sit-for 1)
  (forward-line +12)
  (sit-for 1)
  (narrow-to-region (point) (save-excursion (forward-line 6) (point)))
  (sit-for 1)
  ;; (hs-minor-mode)
  ;; (hs-hide-all)
  )
#+end_src

Michael.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: larsi@gnus.org,  esabof@gmail.com,  14582@debbugs.gnu.org
> Date: Sun, 06 Feb 2022 03:54:10 +0100
> 
> Hmm - found another infloop, even without invisibility involved, when
> narrowing:
> 
> #+begin_src emacs-lisp
> (progn
>   (dotimes (_ 100) (insert "\
> \(defun foo (x y)
>   1
>   2)\n"))
>   (setq make-window-start-visible t)
>   (goto-char (point-min))
>   (sit-for 1)
>   (forward-line +12)
>   (sit-for 1)
>   (narrow-to-region (point) (save-excursion (forward-line 6) (point)))
>   (sit-for 1)
>   ;; (hs-minor-mode)
>   ;; (hs-hide-all)
>   )
> #+end_src

Fixed, thanks.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Fixed, thanks.

Ok, thanks.

The next problem: I'm reading *info*.  I'm hitting [down] multiple
times, and when a line starts with something in Info-quoted face,
hitting [down] one more time scrolls the buffer one line or two lines
upwards, although the cursor is far from the last visible line.  With
other words: when continuously hitting [down], when the cursor crosses
some line with a certain property, the display is scrolled by a tiny
amount, but only when the display starts at `point-min' (i.e. with the
beginning of the narrowed section).  It happens only once.

I think this "has to do with different line heights" or so.
Unfortunately I'm not able to reproduce this problem with emacs -Q.
Should I bisect my config, or do you already have an idea where this
behavior could come from?

Michael.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: larsi@gnus.org,  esabof@gmail.com,  14582@debbugs.gnu.org
> Date: Tue, 08 Feb 2022 01:29:21 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Fixed, thanks.
> 
> Ok, thanks.
> 
> The next problem: I'm reading *info*.  I'm hitting [down] multiple
> times, and when a line starts with something in Info-quoted face,
> hitting [down] one more time scrolls the buffer one line or two lines
> upwards, although the cursor is far from the last visible line.  With
> other words: when continuously hitting [down], when the cursor crosses
> some line with a certain property, the display is scrolled by a tiny
> amount, but only when the display starts at `point-min' (i.e. with the
> beginning of the narrowed section).  It happens only once.
> 
> I think this "has to do with different line heights" or so.
> Unfortunately I'm not able to reproduce this problem with emacs -Q.
> Should I bisect my config, or do you already have an idea where this
> behavior could come from?

I have an idea, but I prefer that you find the customization
responsible for this (something related to scrolling, I guess?), to be
able to reproduce in "emacs -Q".

But what does this have to do with this bug report and the new
make-window-start-visible feature?

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> But what does this have to do with this bug report and the new
> make-window-start-visible feature?

It only happens when the new feature is turned on.  Sorry that I failed
to make that clear.  Never saw this problem before.  Issue disappears
when turning the new feature off.

But I don't see the problem in -Q when I enable
make-window-start-visible.

I asked for your ideas because finding a recipe is a bit harder this
time.  Just evaluating my big "set all important options" block in emacs
-Q is not enough.  I guess I will need 10 or 15 mins, so don't waste
your time when a related setting is not obvious.  It doesn't seem to be
just a simple scroll-* option.  I guess it's not scrolling related at
all but simply caused by the new feature.

Michael.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: larsi@gnus.org,  esabof@gmail.com,  14582@debbugs.gnu.org
> Date: Tue, 08 Feb 2022 05:05:08 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > But what does this have to do with this bug report and the new
> > make-window-start-visible feature?
> 
> It only happens when the new feature is turned on.  Sorry that I failed
> to make that clear.  Never saw this problem before.  Issue disappears
> when turning the new feature off.

Why would you turn on make-window-start-visible in Info buffers?

> But I don't see the problem in -Q when I enable
> make-window-start-visible.

Neither do I, so there's something else at work here.

> I asked for your ideas because finding a recipe is a bit harder this
> time.  Just evaluating my big "set all important options" block in emacs
> -Q is not enough.  I guess I will need 10 or 15 mins, so don't waste
> your time when a related setting is not obvious.  It doesn't seem to be
> just a simple scroll-* option.  I guess it's not scrolling related at
> all but simply caused by the new feature.

The new feature overrides the decision about window-start made by
redisplay, and that is very closely related to scrolling, because
scrolling in Emacs works by basically setting the window-start point
and letting redisplay do the rest.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Why would you turn on make-window-start-visible in Info buffers?

I currently (setq-default make-window-start-visible t) to test the new
feature.  And, honestly, I wanted to keep that setting.

Michael.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Neither do I, so there's something else at work here.

I failed to find a recipe in half an hour and gave up for now - instead
I found one for a very similar case of unexpected auto-scrolling that
only appears when the new feature is turned on.  Also seems to depend on
the buffer contents.  Maybe it is related and a fix fixes the other
thing, too.

emacs -Q
1 C-h i
2 move point to the beginning of one of the last visible lines.
  no scrolling happens (good).
3 M-: (setq make-window-start-visible t) RET  => *info* buffer scrolled

If you scroll back so that (point-min) becomes visible and repeat step
2 any activation of the minibuffer, e.g. just hitting M-: or C-x k,
scrolls the *info* buffer.

Doesn't happen in C-h n.  Dunno what makes the difference - the fact
that *info* is narrowed or that different fonts are used.

Ah - wait, now I can reproduce the other thing, too:

M-:
(progn
  (setq-default display-time-interval 1.)
  (setq display-time-format "%H:%M:%S")
  (setq-default make-window-start-visible t)
  (display-time-mode +1))
RET
C-h i
[down] [down] not too fast ... until it scrolls

I guess it's the same and just differs in when and how redisplay is
triggered.

Michael.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: larsi@gnus.org,  esabof@gmail.com,  14582@debbugs.gnu.org
> Date: Wed, 09 Feb 2022 04:53:05 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Neither do I, so there's something else at work here.
> 
> I failed to find a recipe in half an hour and gave up for now - instead
> I found one for a very similar case of unexpected auto-scrolling that
> only appears when the new feature is turned on.  Also seems to depend on
> the buffer contents.  Maybe it is related and a fix fixes the other
> thing, too.
> 
> emacs -Q
> 1 C-h i
> 2 move point to the beginning of one of the last visible lines.
>   no scrolling happens (good).
> 3 M-: (setq make-window-start-visible t) RET  => *info* buffer scrolled
> 
> If you scroll back so that (point-min) becomes visible and repeat step
> 2 any activation of the minibuffer, e.g. just hitting M-: or C-x k,
> scrolls the *info* buffer.
> 
> Doesn't happen in C-h n.  Dunno what makes the difference - the fact
> that *info* is narrowed or that different fonts are used.
> 
> Ah - wait, now I can reproduce the other thing, too:
> 
> M-:
> (progn
>   (setq-default display-time-interval 1.)
>   (setq display-time-format "%H:%M:%S")
>   (setq-default make-window-start-visible t)
>   (display-time-mode +1))
> RET
> C-h i
> [down] [down] not too fast ... until it scrolls

You asked for it.  Info buffers have a 'display' property whose value
is a string at the beginning of each node, and that 'display' property
makes the window's start point invisible.  So whenever Emacs can make
the window-start visible, it does.

IOW, here you have one example why the default way of handling
"hidden" window-start point is sometimes exactly what we want.

Bottom line: I advise against making this the default.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Info buffers have a 'display' property whose value is a string at the
> beginning of each node, and that 'display' property makes the window's
> start point invisible.  So whenever Emacs can make the window-start
> visible, it does.

But Emacs scrolls the first lines out of view: at the upper edge, less
text is visible after the adjustment.  How does this make anything
visible that had not been visible before?

Michael.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: larsi@gnus.org,  esabof@gmail.com,  14582@debbugs.gnu.org
> Date: Thu, 10 Feb 2022 02:07:19 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Info buffers have a 'display' property whose value is a string at the
> > beginning of each node, and that 'display' property makes the window's
> > start point invisible.  So whenever Emacs can make the window-start
> > visible, it does.
> 
> But Emacs scrolls the first lines out of view: at the upper edge, less
> text is visible after the adjustment.  How does this make anything
> visible that had not been visible before?

That's not what make-window-start-visible means.  It means "if the
current window-start is invisible, try to find an alternative
window-start that would be visible, while still showing point".

Your interpretation of the setting is simply impossible to implement:
the display engine cannot possibly do anything to uncover the hidden
window-start point without scrolling the window in some way.  So
_something_ that was visible before must become invisible after,
because we scroll the window.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> That's not what make-window-start-visible means.  It means "if the
> current window-start is invisible, try to find an alternative
> window-start that would be visible, while still showing point".
>
> Your interpretation of the setting is simply impossible to implement:
> the display engine cannot possibly do anything to uncover the hidden
> window-start point without scrolling the window in some way.  So
> _something_ that was visible before must become invisible after,
> because we scroll the window.

I'm irritated that the newly chosen window-start can be after the
original position.  I don't know any use case where this is useful, and
it was only irritating whenever it happened in my test.  Is this
unavoidable?

BTW, why does the adjustment happen when I just move the cursor inside
the displayed window content without causing any display change?  The
new heuristic seems to depend on the value of `point' (I don't mean
values that would cause scrolling the normal way).

Thanks,

Michael.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: larsi@gnus.org,  esabof@gmail.com,  14582@debbugs.gnu.org
> Date: Fri, 11 Feb 2022 05:42:44 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That's not what make-window-start-visible means.  It means "if the
> > current window-start is invisible, try to find an alternative
> > window-start that would be visible, while still showing point".
> >
> > Your interpretation of the setting is simply impossible to implement:
> > the display engine cannot possibly do anything to uncover the hidden
> > window-start point without scrolling the window in some way.  So
> > _something_ that was visible before must become invisible after,
> > because we scroll the window.
> 
> I'm irritated that the newly chosen window-start can be after the
> original position.  I don't know any use case where this is useful, and
> it was only irritating whenever it happened in my test.  Is this
> unavoidable?

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.

Anything else would mean a much deeper surgery on the (already
non-trivially complex) logic of redisplaying a window, whereby we both
verify that the previous window-start is still usable, and try various
optimizations to make the redrawing itself as cheap as possible.

> BTW, why does the adjustment happen when I just move the cursor inside
> the displayed window content without causing any display change?  The
> new heuristic seems to depend on the value of `point' (I don't mean
> values that would cause scrolling the normal way).

You may be unaware, but moving point always triggers redisplay of the
window.  That eventually nothing happens on the screen except showing
the cursor at a different location is because Emacs is smart enough to
detect that nothing else needs to change.  IOW, it's not like
redisplay is being explicitly told that only point moved, and moved
slightly enough to allow the same window-start to be used, it has to
deduce that by itself.

When this new variable is set, and the window-start is hidden, Emacs
falls back on recentering the window around point.  If point is closer
to BOB than half the window, recentering will normally fail to find a
better window-start that would show point at the center of the window,
but when point is farther than half the window, Emacs will scroll the
window as result of recentering.  That's why you see the dependance on
point position.

Once again, this option was intended to be used in relatively rare
situations.  I do not recommend to set it by default, especially if
the side effects annoy you.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Once again, this option was intended to be used in relatively rare
> situations.  I do not recommend to set it by default, especially if
> the side effects annoy you.

Ok, finally I understand now that the display engine can't do what I had
in mind.

IME folding can confuse the eye, and the vertical position of the cursor
is one of the main visual anchors - I would want to avoid any scrolling
involved to solve this bug.  Which would mean a fix is yet to be found.

Michael.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: larsi@gnus.org,  esabof@gmail.com,  14582@debbugs.gnu.org
> Date: Sat, 12 Feb 2022 01:25:44 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Once again, this option was intended to be used in relatively rare
> > situations.  I do not recommend to set it by default, especially if
> > the side effects annoy you.
> 
> Ok, finally I understand now that the display engine can't do what I had
> in mind.
> 
> IME folding can confuse the eye, and the vertical position of the cursor
> is one of the main visual anchors - I would want to avoid any scrolling
> involved to solve this bug.  Which would mean a fix is yet to be found.

I disagree.  The fix for the problems originally reported here was
found, and it so far solves all the use cases presented here that
involve either folding or selective-display.  The fix handles the
potentially confusing display when folding or selective-display
settings are changed so that the previous window-start point winds up
being hidden.

After the change in folding or selective-display, and as long as these
settings don't change, the window-start point is expected to be
visible at all times (due to how window redisplay is done, something
that wasn't changed by the changes in this bug report), and thus no
unexpected scrolling should happen.

The use of the new variable in all buffers is not recommended, and not
what it is supposed to support.  In particular, its use in Info
buffers may cause unexpected side-effects.  Since display in Info
buffers is fine without this variable, I don't see how what you get
there is any evidence of a missing fix.  A fix for what problem?

Bottom line: I think this bug should be closed, as the original issues
were all resolved.  If you disagree, I guess I'll let Lars close it in
about 10 years from now.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> > IME folding can confuse the eye, and the vertical position of the cursor
> > is one of the main visual anchors - I would want to avoid any scrolling
> > involved to solve this bug.  Which would mean a fix is yet to be found.
>
> I disagree.

> The fix for the problems originally reported here was
> found, and it so far solves all the use cases presented here that
> involve either folding or selective-display.  The fix handles the
> potentially confusing display when folding or selective-display
> settings are changed so that the previous window-start point winds up
> being hidden.

Ok, we have introduced a new variable.  So far it is used nowhere in
Emacs, and it's said to not turn it on by default.  Nothing has actually
changed.  The recipe I had posted behaves the same.  Do I miss
something?

BTW, did you ever use folding?  I think not as often as I do, else you
would have known the issue we are talking about.  My feedback was not
meant to annoy you - I wanted to share my experience as a user.  Didn't
know that that's irrelevant.

> Bottom line: I think this bug should be closed, as the original issues
> were all resolved.  If you disagree, I guess I'll let Lars close it in
> about 10 years from now.

I don't even know what to respond to that.

Michael.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: larsi@gnus.org,  esabof@gmail.com,  14582@debbugs.gnu.org
> Date: Sat, 12 Feb 2022 23:53:25 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The fix for the problems originally reported here was
> > found, and it so far solves all the use cases presented here that
> > involve either folding or selective-display.  The fix handles the
> > potentially confusing display when folding or selective-display
> > settings are changed so that the previous window-start point winds up
> > being hidden.
> 
> Ok, we have introduced a new variable.  So far it is used nowhere in
> Emacs, and it's said to not turn it on by default.  Nothing has actually
> changed.  The recipe I had posted behaves the same.  Do I miss
> something?

Please feel free to submit changes to relevant modes and features to
use this new variable.  I use them only very infrequently, and am not
annoyed by the issues that started this bug report, so I'm not a good
candidate for suggesting such changes or testing them in Real Life.
(I thought as soon as the new variable is demonstrated to be able to
solve those issues, the patches to the relevant applications will
follow immediately, either by Evgeni or by you.)

> BTW, did you ever use folding?  I think not as often as I do, else you
> would have known the issue we are talking about.  My feedback was not
> meant to annoy you - I wanted to share my experience as a user.  Didn't
> know that that's irrelevant.

It was hardly perceived as irrelevant: I spent some non-trivial time
working on this, which I wouldn't do if I haven't thought this is
relevant and worth working on.

> > Bottom line: I think this bug should be closed, as the original issues
> > were all resolved.  If you disagree, I guess I'll let Lars close it in
> > about 10 years from now.
> 
> I don't even know what to respond to that.

Sadly, it looks like I can never disagree with you without annoying
you to the extreme.  Happens all the time.  What am I doing wrong?  Am
I not entitled to my own opinions about how things should be done in
Emacs?

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Please feel free to submit changes to relevant modes and features to
> use this new variable.  I use them only very infrequently, and am not
> annoyed by the issues that started this bug report, so I'm not a good
> candidate for suggesting such changes or testing them in Real Life.
> (I thought as soon as the new variable is demonstrated to be able to
> solve those issues, the patches to the relevant applications will
> follow immediately, either by Evgeni or by you.)

But what when I do not what to scroll?

> > BTW, did you ever use folding?  I think not as often as I do, else you
> > would have known the issue we are talking about.  My feedback was not
> > meant to annoy you - I wanted to share my experience as a user.  Didn't
> > know that that's irrelevant.
>
> It was hardly perceived as irrelevant: I spent some non-trivial time
> working on this, which I wouldn't do if I haven't thought this is
> relevant and worth working on.

I was referring to my latest feedback telling that scrolling is
suboptimal in my experience in this case, not to the conversation before
that.

> > > Bottom line: I think this bug should be closed, as the original issues
> > > were all resolved.  If you disagree, I guess I'll let Lars close it in
> > > about 10 years from now.
> >
> > I don't even know what to respond to that.
>
> Sadly, it looks like I can never disagree with you without annoying
> you to the extreme.  Happens all the time.  What am I doing wrong?

It's not only me - that ever happens only when talking to you.

Please stay friendly and if you don't agree with what I say, at least
tell me.  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.  Then maybe we should do it in a different way?  Would
that be ok for you?  If not, why?

> Am I not entitled to my own opinions about how things should be done
> in Emacs?

There are other ways to express them.  This is not about different
opinions.  To be honest, I don't know a lot about your opinion here.  I
would if you had given me feedback about the problem with scrolling I
had raised.

That message was not a friendly or neutral response, at least the part
about the alternative would be to tell Lars to close the report in 10
years.  Or was it?

You just ignored what I said and told the bug should be closed.  If
you intended to say something different, I don't know, I can only answer
and react to what you wrote.  Saying "Bug should be closed" without
replying to mentioned problems just sounds like "the discussion is
over".


Michael.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: larsi@gnus.org,  esabof@gmail.com,  14582@debbugs.gnu.org
> Date: Sun, 27 Feb 2022 04:54:02 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Please feel free to submit changes to relevant modes and features to
> > use this new variable.  I use them only very infrequently, and am not
> > annoyed by the issues that started this bug report, so I'm not a good
> > candidate for suggesting such changes or testing them in Real Life.
> > (I thought as soon as the new variable is demonstrated to be able to
> > solve those issues, the patches to the relevant applications will
> > follow immediately, either by Evgeni or by you.)
> 
> But what when I do not what to scroll?

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.

> > > BTW, did you ever use folding?  I think not as often as I do, else you
> > > would have known the issue we are talking about.  My feedback was not
> > > meant to annoy you - I wanted to share my experience as a user.  Didn't
> > > know that that's irrelevant.
> >
> > It was hardly perceived as irrelevant: I spent some non-trivial time
> > working on this, which I wouldn't do if I haven't thought this is
> > relevant and worth working on.
> 
> I was referring to my latest feedback telling that scrolling is
> suboptimal in my experience in this case, not to the conversation before
> that.

About that, I posted a detailed explanation why I thought the original
problem is fixed now.  How does that count as perceiving your opinions
to be irrelevant?  We surely disagree on this, but disagreement
doesn't mean I consider your opinion irrelevant, and the detailed
responses are the evidence that I didn't.

> Please stay friendly and if you don't agree with what I say, at least
> tell me.

I've re-read every message I posted, and didn't find anything
unfriendly I wrote there.  What I did find was a lot of effort to
explain how this stuff works and why the effect is what it is.  I
thought it will count for something.

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

  Anything else would mean a much deeper surgery on the (already
  non-trivially complex) logic of redisplaying a window, whereby we both
  verify that the previous window-start is still usable, and try various
  optimizations to make the redrawing itself as cheap as possible.

> Then maybe we should do it in a different way?  Would
> that be ok for you?  If not, why?

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.

> > Am I not entitled to my own opinions about how things should be done
> > in Emacs?
> 
> There are other ways to express them.  This is not about different
> opinions.  To be honest, I don't know a lot about your opinion here.  I
> would if you had given me feedback about the problem with scrolling I
> had raised.

I did explain much more than I thought was strictly necessary, in the
hope that you will see my POV.  If you have more questions about those
explanations, feel free to ask.

> That message was not a friendly or neutral response, at least the part
> about the alternative would be to tell Lars to close the report in 10
> years.  Or was it?

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.

> You just ignored what I said and told the bug should be closed.  If
> you intended to say something different, I don't know, I can only answer
> and react to what you wrote.  Saying "Bug should be closed" without
> replying to mentioned problems just sounds like "the discussion is
> over".

I didn't "just ignore" what you said.  I posted 2 detailed
explanations why my opinion is different:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=14582#112
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=14582#118

The latter explicitly provides, in a very detailed manner, my reasons
why I think this bug should be closed.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Michael Heerdegen]

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.

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: larsi@gnus.org,  esabof@gmail.com,  14582@debbugs.gnu.org
> Date: Mon, 28 Feb 2022 00:19:36 +0100
> 
> 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?

I think we are having a terminological misunderstanding here.  What do
you mean by "really scroll", and how is it different from the other
types of "scrolling", in your mental model of what we are discussing?

I'm asking because it is not trivial to define "real scrolling".  For
example, suppose Emacs changes the window-start point, and then
redraws each and every screen line from top of the window to its
bottom -- do you consider this "real scrolling"?  It may well appear
to the user as scrolling, since every line moves up or down by the
same number of screen lines.

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

No, not necessarily.  Recentering in this context means Emacs
calculates a new window-start position such that the line showing
point will be centered in the window, and then redisplays the window
using that window-start position.  _How_ it redisplays the window is a
separate question -- the display engine has several optimizations it
will try to make redisplay as fast as possible, and some of these
optimizations can be considered "real scrolling" (according to my
interpretation of that term).

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

The question is how would you compute the new window-start?  What
happens after that, i.e. how the call to 'redisplay' redraws the
window given a specific window-start position, you cannot control --
it could very well decide it wants to scroll the window.  It's no
accident that scroll commands in Emacs do precisely that: they compute
a suitable window-start, and then let the display engine do its job
under the restriction that it shall abide by that window-start
position.

bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Lars, you just need to follow the recipe of the OP in an Elisp buffer
> containing some code to reproduce the issue.  You maybe need to repeat a
> second time (unfold + refold again).
>
> If still not lucky, I'll try to create a step-by-step recipe, but maybe
> it's clear enough.  And I hope I did not misinterpret the original
> report.

Like Eli said, if hideshow is placing the window-start at an odd place,
it should probably be fixed in hideshow.  So a recipe to reproduce the
hideshow problem would be appreciated.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no