bug#36832: Supply option to suppress scrolling in compilation mode buffers.

bug#36832: Supply option to suppress scrolling in compilation mode buffers.

[Alan Mackenzie]

Hello, Emacs.

In a compilation mode buffer, hit CR on one of the error lines so as to
go to the pertinent line in the erroneous source code.

WHAM!  The compilation mode buffer is unavoidably scrolled so that the
line CR'd upon is at the top of the window.  Well, it's unavoidable
unless you're running under a GUI and have fringes enabled.

This forced scrolling is irritating for at least one Emacs developer.

I propose enhancing the customisation variable compilation-context-lines
with the extra value t meaning "never scroll the compilation mode buffer".

Here is a patch to achieve this:



diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
index 4b2fc516c3..5a8680fd0c 100644
--- a/lisp/progmodes/compile.el
+++ b/lisp/progmodes/compile.el
@@ -2546,26 +2546,30 @@ compilation-context-lines
   "Display this many lines of leading context before the current message.
 If nil and the left fringe is displayed, don't scroll the
 compilation output window; an arrow in the left fringe points to
-the current message.  If nil and there is no left fringe, the message
-displays at the top of the window; there is no arrow."
-  :type '(choice integer (const :tag "No window scrolling" nil))
+the current message.  If nil and there is no left fringe, the
+message displays at the top of the window; there is no arrow.  If
+t, don't scroll the compilation output window at all."
+  :type '(choice integer
+                 (const :tag "Scroll window when no fringe" nil)
+                 (const :tag  "No window scrolling" t))
   :version "22.1")
 
 (defsubst compilation-set-window (w mk)
-  "Align the compilation output window W with marker MK near top."
-  (if (integerp compilation-context-lines)
-      (set-window-start w (save-excursion
-			    (goto-char mk)
-			    (compilation-beginning-of-line
-			     (- 1 compilation-context-lines))
-			    (point)))
+  "Maybe align the compilation output window W with marker MK near top."
+  (cond ((integerp compilation-context-lines)
+         (set-window-start w (save-excursion
+			       (goto-char mk)
+			       (compilation-beginning-of-line
+			        (- 1 compilation-context-lines))
+			       (point))))
+        ((eq compilation-context-lines t))
     ;; If there is no left fringe.
-    (when (equal (car (window-fringes w)) 0)
-      (set-window-start w (save-excursion
-                            (goto-char mk)
-			    (beginning-of-line 1)
-			    (point)))))
-    (set-window-point w mk))
+        ((equal (car (window-fringes w)) 0)
+         (set-window-start w (save-excursion
+                               (goto-char mk)
+			       (beginning-of-line 1)
+			       (point)))
+         (set-window-point w mk))))
 
 (defvar next-error-highlight-timer)
 

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#36832: Supply option to suppress scrolling in compilation mode buffers.

[Eli Zaretskii]

> Date: Sun, 28 Jul 2019 20:32:21 +0000
> From: Alan Mackenzie <acm@muc.de>
> 
> I propose enhancing the customisation variable compilation-context-lines
> with the extra value t meaning "never scroll the compilation mode buffer".

With this setting, how would the user know which error line is the
"current" one, whose source is displayed above?

bug#36832: Supply option to suppress scrolling in compilation mode buffers.

[Alan Mackenzie]

Hello, Eli.

On Tue, Jul 30, 2019 at 18:14:28 +0300, Eli Zaretskii wrote:
> > Date: Sun, 28 Jul 2019 20:32:21 +0000
> > From: Alan Mackenzie <acm@muc.de>

> > I propose enhancing the customisation variable compilation-context-lines
> > with the extra value t meaning "never scroll the compilation mode buffer".

> With this setting, how would the user know which error line is the
> "current" one, whose source is displayed above?

Either by remembering it (she's just hit <CR> on it, after all), or by
doing C-x o to move to that line, then C-x o to move back again.

The new option is intended for users who find being reminded of the
current error line less important than being able to see the error lines
above the current one "in context".

A possible modification would be to highlight the current line in the
compilation mode buffer, but that's beginning to feel like a lot of work
for a feature which might not really be wanted by anybody.

This is an option, a non-default option, one which nobody is forced to
use.  Having hacked it up a couple of days ago, I find it less stressful
to use than the setting where the buffer jumps when I hit <CR> on it.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#36832: Supply option to suppress scrolling in compilation mode buffers.

[Eli Zaretskii]

> Date: Tue, 30 Jul 2019 15:59:37 +0000
> Cc: 36832@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > With this setting, how would the user know which error line is the
> > "current" one, whose source is displayed above?
> 
> Either by remembering it (she's just hit <CR> on it, after all), or by
> doing C-x o to move to that line, then C-x o to move back again.
> 
> The new option is intended for users who find being reminded of the
> current error line less important than being able to see the error lines
> above the current one "in context".
> 
> A possible modification would be to highlight the current line in the
> compilation mode buffer, but that's beginning to feel like a lot of work
> for a feature which might not really be wanted by anybody.

If this feature will not be wanted by anybody, why are we discussing
its addition?

I'm okay with adding the value you suggest if there will be some means
for delineating the current error line, either automatically when the
value t is in use or by an independent optional feature.

> This is an option, a non-default option, one which nobody is forced to
> use.  Having hacked it up a couple of days ago, I find it less stressful
> to use than the setting where the buffer jumps when I hit <CR> on it.

I understand, but I don't want us to introduce options that look like
we didn't think them through.

bug#36832: Supply option to suppress scrolling in compilation mode buffers.

[Juri Linkov]

> I'm okay with adding the value you suggest if there will be some means
> for delineating the current error line, either automatically when the
> value t is in use or by an independent optional feature.

We are waiting for the paperwork from the contributor
who already implemented this feature in bug#32676.

bug#36832: Supply option to suppress scrolling in compilation mode buffers.

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Alan Mackenzie <acm@muc.de>,  36832@debbugs.gnu.org
> Date: Tue, 30 Jul 2019 22:20:58 +0300
> 
> > I'm okay with adding the value you suggest if there will be some means
> > for delineating the current error line, either automatically when the
> > value t is in use or by an independent optional feature.
> 
> We are waiting for the paperwork from the contributor
> who already implemented this feature in bug#32676.

He was last heard from 3 months ago.  Did the paperwork start?  It
usually doesn't take that long.

bug#36832: Supply option to suppress scrolling in compilation mode buffers.

[Alan Mackenzie]

Hello, Eli.

On Tue, Jul 30, 2019 at 19:17:45 +0300, Eli Zaretskii wrote:
> > Date: Tue, 30 Jul 2019 15:59:37 +0000
> > Cc: 36832@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > With this setting, how would the user know which error line is the
> > > "current" one, whose source is displayed above?

> > Either by remembering it (she's just hit <CR> on it, after all), or by
> > doing C-x o to move to that line, then C-x o to move back again.

> > The new option is intended for users who find being reminded of the
> > current error line less important than being able to see the error lines
> > above the current one "in context".

> > A possible modification would be to highlight the current line in the
> > compilation mode buffer, but that's beginning to feel like a lot of work
> > for a feature which might not really be wanted by anybody.

> If this feature will not be wanted by anybody, why are we discussing
> its addition?

To attempt to guess whether anybody will want it.

> I'm okay with adding the value you suggest if there will be some means
> for delineating the current error line, either automatically when the
> value t is in use or by an independent optional feature.

I suppose we could put something like ">" or "=>" in column 0 of the
pertinent line, the way that edebug does, when there's no fringe.

> > This is an option, a non-default option, one which nobody is forced to
> > use.  Having hacked it up a couple of days ago, I find it less stressful
> > to use than the setting where the buffer jumps when I hit <CR> on it.

> I understand, but I don't want us to introduce options that look like
> we didn't think them through.

OK.

The current code does two things, sometimes, on <CR> being hit: (i) it
puts an indicator into the fringe; (ii) it scrolls the compile mode
window upwards, the pertinent line moving either to the top, or to a
specified window line.

Unfortunately, the code which does these things seems to be fragmented,
and there is just one user option to control (i) and (ii) above.

One solution would be always to mark to the line in the compile mode
window, whether by an indicator in the fringe or a ">" or "=>" at column
0.  Then only scroll the compile mode window when the user has explicitly
requested this by the user option compilation-context-lines.

Why do these little things so often turn out to be so complicated?  ;-(

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#36832: Supply option to suppress scrolling in compilation mode buffers.

[Eli Zaretskii]

> Date: Tue, 30 Jul 2019 19:32:35 +0000
> Cc: 36832@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> The current code does two things, sometimes, on <CR> being hit: (i) it
> puts an indicator into the fringe; (ii) it scrolls the compile mode
> window upwards, the pertinent line moving either to the top, or to a
> specified window line.
> 
> Unfortunately, the code which does these things seems to be fragmented,
> and there is just one user option to control (i) and (ii) above.
> 
> One solution would be always to mark to the line in the compile mode
> window, whether by an indicator in the fringe or a ">" or "=>" at column
> 0.  Then only scroll the compile mode window when the user has explicitly
> requested this by the user option compilation-context-lines.

Yes, that would be an okay solution.

> Why do these little things so often turn out to be so complicated?  ;-(

;-)

bug#36832: Supply option to suppress scrolling in compilation mode buffers.

[Alan Mackenzie]

Hello, Eli.

On Wed, Jul 31, 2019 at 17:21:49 +0300, Eli Zaretskii wrote:
> > Date: Tue, 30 Jul 2019 19:32:35 +0000
> > Cc: 36832@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > The current code does two things, sometimes, on <CR> being hit: (i) it
> > puts an indicator into the fringe; (ii) it scrolls the compile mode
> > window upwards, the pertinent line moving either to the top, or to a
> > specified window line.

> > Unfortunately, the code which does these things seems to be fragmented,
> > and there is just one user option to control (i) and (ii) above.

> > One solution would be always to mark to the line in the compile mode
> > window, whether by an indicator in the fringe or a ">" or "=>" at column
> > 0.  Then only scroll the compile mode window when the user has explicitly
> > requested this by the user option compilation-context-lines.

> Yes, that would be an okay solution.

I've just committed a patch to master which does the above.  When
compilation-context-lines has the value t, it no longer scrolls the
compilation-mode buffer line to the top of the window, instead using an
overlay with before-string property "=>" to mark the current line.

This time, the changes are entirely within compile.el.  (Plus a
documentation change and a NEWS entry.)

If there are no objections, I'll close this bug as fixed.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#36832: Supply option to suppress scrolling in compilation mode buffers.

[Mattias Engdegård]

After 29d1c72d7c, next-error and previous-error no longer work as before in compilation-mode.
The fringe arrow is often not moved at all until the compilation window is made active, and the cursor in that buffer isn't moved at all; scrolling never occurs. This is with a plain NS build on macOS 10.14, compilation-context-lines being nil (the default).

When compilation-context-lines is set to an integer, it seems to work normally.

In compilation-set-window, the expression

    (set-window-point w mk)

was previously executed unconditionally if compilation-context-lines was not an integer; now, it is only run if there is no left fringe. The following change restores previous behaviour in that respect:

@@ -2600,7 +2600,8 @@ compilation-set-window
                                (goto-char mk)
                               (beginning-of-line 1)
                               (point)))
-         (set-window-point w mk))))
+         (set-window-point w mk))
+        (t (set-window-point w mk))))

but you probably want to reformulate the code to avoid duplication.

bug#36832: Supply option to suppress scrolling in compilation mode buffers.

[Alan Mackenzie]

Bug fixed by implementing the proposed feature, incorporating
modification suggested in the bug thread.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#36832: Supply option to suppress scrolling in compilation mode buffers

[Mattias Engdegård]

Alan wrote:

>Bug fixed by implementing the proposed feature, incorporating
>modification suggested in the bug thread.

The fix to compilation-set-window has now been pushed as well. (You probably assumed I would do it, so now I have.)

bug#36832: Supply option to suppress scrolling in compilation mode buffers

[Alan Mackenzie]

Hello, Mattias.

On Wed, Sep 04, 2019 at 14:41:29 +0200, Mattias Engdegård wrote:
> Alan wrote:

> >Bug fixed by implementing the proposed feature, incorporating
> >modification suggested in the bug thread.

> The fix to compilation-set-window has now been pushed as well. (You
> probably assumed I would do it, so now I have.)

Thanks for fixing this.  Sorry I haven't replied sooner - Real Life is
taking priority a bit at the moment.

-- 
Alan Mackenzie (Nuremberg, Germany).