warnings and window-point

warnings and window-point

[Juanma Barranquero]

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

Not sure if that's a bug or a feature, because it's been so since the
beginning (it already happens in 22.1, where warnings.el was introduced).
But it is definitely weird.

Warnings are added at the end of the *Warnings* buffer, and the buffer is
displayed, but the window-point does not move. So if you write a lot of
warnings, like

(dotimes (i 40) (lwarn 'emacs :warning "i = %d" i))

only the beginning of the buffer is shown, and the window-point is stuck at
the beginning of the *second* warning in the buffer. Basically, if you have
the *Warnings* buffer open in some window, but you don't scroll it, once
the window is full, you're unaware that new warnings are appearing.

Perhaps the idea is to keep past warnings visible until the user scrolls
the buffer themself, but if warning-series is set, display-warning calls
set-window-start and sets the origin of the window at the first warning of
the series (and weirdly, the window-point is not reset to the first visible
position in the window).

(dotimes (i 100)
  (when (= i 50) (setq warning-series t))
  (lwarn 'emacs :warning "i = %d" i))

What I would've expected is something like this:

diff --git i/lisp/emacs-lisp/warnings.el w/lisp/emacs-lisp/warnings.el
index e5c1d9cec4..c9d7aff529 100644
--- i/lisp/emacs-lisp/warnings.el
+++ w/lisp/emacs-lisp/warnings.el
@@ -316,7 +316,8 @@ display-warning
                     (warning-suppress-p type warning-suppress-types)
                     (let ((window (display-buffer buffer)))
-                      (when (and (markerp warning-series)
-                                 (eq (marker-buffer warning-series)
buffer))
-                        (set-window-start window warning-series))
+                      (if (and (markerp warning-series)
+                               (eq (marker-buffer warning-series) buffer))
+                          (set-window-start window warning-series)
+                        (set-window-point window end))
                       (sit-for 0)))))))))

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

Re: warnings and window-point

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 22 Nov 2019 02:01:24 +0100
> 
> Not sure if that's a bug or a feature, because it's been so since the beginning (it already happens in 22.1,
> where warnings.el was introduced). But it is definitely weird.

I wouldn't change such old code just because it appears "weird",
especially if we have a clue for why it is so:

> Perhaps the idea is to keep past warnings visible until the user scrolls the buffer themself

Re: warnings and window-point

[Juanma Barranquero]

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

No, I don't propose to change it, at least not now. The problem I had that
led me to study this I fixed locally with some advice.

It's just curiosity, because I really don't understand the intent;
particularly, the fact that the point is in the second warning is really
weird.

> > Perhaps the idea is to keep past warnings visible until the user
scrolls the buffer themself

Yeah, it's just that... As a justification isn't very good, because the
buffer is autoscrolled if warning-series is set to non-nil. So it's like
yeah, let's not move it, except in some cases we do. And warning-series is
surely intended to be set by the application code generating the warnings,
not the user, so when it does scroll, it doesn't do so under the user's
direction or control.

I honestly think that's really an oversight no one has either detected or,
more likely, cared about until now because warnings.el doesn't get (I
think) much use.

So I'd like to try the patch above in the trunk after we branch for 27,
just to see if someone complains.

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

Re: warnings and window-point

[Stefan Monnier]

> So I'd like to try the patch above in the trunk after we branch for 27,
> just to see if someone complains.

FWIW I agree with your analysis.  I think the current behavior is a bug
resulting from a lack of effort rather than a deliberate feature.


        Stefan