GNU bug report logs -
#77313
30.1.50; Regression: flymake indicators are erroneously using margins
Previous Next
Reported by: Spencer Baugh <sbaugh <at> janestreet.com>
Date: Thu, 27 Mar 2025 15:14:03 UTC
Severity: normal
Found in version 30.1.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 77313 in the body.
You can then email your comments to 77313 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77313
; Package
emacs
.
(Thu, 27 Mar 2025 15:14:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Spencer Baugh <sbaugh <at> janestreet.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 27 Mar 2025 15:14:04 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
The addition of margin-based flymake indicators in Emacs 30 (for use in
terminal frames) also led to a regression: the margin-based indicators
are uglier and should not be used when not necessary, but the code for
determining the default for flymake-indicator-type was wrong and caused
margin indicators to be used sometimes on graphical frames.
The simplest fix, suitable for backporting, is to always default to
fringes.
Please apply the attached patch and backport to Emacs 30.
[0001-flymake-default-to-displaying-indicators-on-fringes.patch (text/x-patch, inline)]
From 252dd491890323710782d22483bd9cedb9d5b90c Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh <at> janestreet.com>
Date: Thu, 27 Mar 2025 11:07:41 -0400
Subject: [PATCH] flymake: default to displaying indicators on fringes
Checking (display-graphic-p) at load time is not a correct way to
determine what kind of indicators to use. This led to a regression in
Emacs 30, where we used the uglier margin indicators even while on
graphical frames if flymake was loaded before any graphical frame was
created. For example, users of the emacs daemon who load flymake in
their init.el.
We can re-add this as a per-frame check later.
* lisp/progmodes/flymake.el (flymake-indicator-type): Default to fringes.
---
lisp/progmodes/flymake.el | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/lisp/progmodes/flymake.el b/lisp/progmodes/flymake.el
index f8a294908ba..29bc3dacdba 100644
--- a/lisp/progmodes/flymake.el
+++ b/lisp/progmodes/flymake.el
@@ -185,9 +185,7 @@ flymake-fringe-indicator-position
(const right-fringe)
(const :tag "No fringe indicators" nil)))
-(defcustom flymake-indicator-type (if (display-graphic-p)
- 'fringes
- 'margins)
+(defcustom flymake-indicator-type 'fringes
"Indicate which indicator type to use for display errors.
The value can be nil (don't indicate errors but just highlight them),
--
2.39.3
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77313
; Package
emacs
.
(Thu, 27 Mar 2025 16:15:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 77313 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 27 Mar 2025 11:13:44 -0400
> From: Spencer Baugh via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> The addition of margin-based flymake indicators in Emacs 30 (for use in
> terminal frames) also led to a regression: the margin-based indicators
> are uglier and should not be used when not necessary, but the code for
> determining the default for flymake-indicator-type was wrong and caused
> margin indicators to be used sometimes on graphical frames.
Please tell how that could or did happen.
> The simplest fix, suitable for backporting, is to always default to
> fringes.
Which means there will be no indicators on TTY frames, right?
If you don't like the default for a user option, you can easily
customize it locally. But why make that change for everyone? Options
are options so that they could be easily adapted to local needs.
At this point, I see no evidence that any change is needed. But maybe
if you tell more about the problems you encountered, I will change my
mind.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77313
; Package
emacs
.
(Thu, 27 Mar 2025 16:29:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 77313 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Thu, 27 Mar 2025 11:13:44 -0400
>> From: Spencer Baugh via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> The addition of margin-based flymake indicators in Emacs 30 (for use in
>> terminal frames) also led to a regression: the margin-based indicators
>> are uglier and should not be used when not necessary, but the code for
>> determining the default for flymake-indicator-type was wrong and caused
>> margin indicators to be used sometimes on graphical frames.
>
> Please tell how that could or did happen.
e.g.:
1. emacs --daemon -l flymake
2. emacsclient -c somefile.el -f flymake-mode
(opening a graphical frame)
In Emacs 29, this uses fringes for the indicators.
In Emacs 30, this uses margins, which is a substantial regression.
>> The simplest fix, suitable for backporting, is to always default to
>> fringes.
>
> Which means there will be no indicators on TTY frames, right?
There were never indicators in TTY frames in Emacs 29.
In Emacs 30, there will also be no indicators on TTY frames if, for
example, the user does:
1. emacs (opening a graphical Emacs)
2. (require 'flymake)
The default of flymake-indicator-type is now 'fringes, since display-graphic-p is true.
3. emacsclient -t
No indicators.
> If you don't like the default for a user option, you can easily
> customize it locally. But why make that change for everyone? Options
> are options so that they could be easily adapted to local needs.
Because it's a regression from Emacs 29.
Keep in mind I was the one who, while reviewing the flymake patch adding
margins, suggested that TTY frames automatically default to using
margins. This code exists because I requested it. I sadly did not
realize that the behavior was implemented with a buggy default value for
flymake-indicator-type, nor was it caught before release; I only just
now have received direct user complaints about the regression.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77313
; Package
emacs
.
(Thu, 27 Mar 2025 16:53:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 77313 <at> debbugs.gnu.org (full text, mbox):
> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: 77313 <at> debbugs.gnu.org
> Date: Thu, 27 Mar 2025 12:28:39 -0400
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> Date: Thu, 27 Mar 2025 11:13:44 -0400
> >> From: Spencer Baugh via "Bug reports for GNU Emacs,
> >> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> >>
> >> The addition of margin-based flymake indicators in Emacs 30 (for use in
> >> terminal frames) also led to a regression: the margin-based indicators
> >> are uglier and should not be used when not necessary, but the code for
> >> determining the default for flymake-indicator-type was wrong and caused
> >> margin indicators to be used sometimes on graphical frames.
> >
> > Please tell how that could or did happen.
>
> e.g.:
>
> 1. emacs --daemon -l flymake
> 2. emacsclient -c somefile.el -f flymake-mode
> (opening a graphical frame)
You can reset the option in after-make-frame-functions.
The daemon is known to be tricky in turning on GUI features; many of
them need to be (re)initialized in after-make-frame-functions. That
doesn't mean we will be turning off all the features that cater to
text-only frames due to those complications.
> >> The simplest fix, suitable for backporting, is to always default to
> >> fringes.
> >
> > Which means there will be no indicators on TTY frames, right?
>
> There were never indicators in TTY frames in Emacs 29.
Yes, and Emacs 30 attempted to improve the situation. Going back is a
step in the wrong direction.
> In Emacs 30, there will also be no indicators on TTY frames if, for
> example, the user does:
>
> 1. emacs (opening a graphical Emacs)
> 2. (require 'flymake)
> The default of flymake-indicator-type is now 'fringes, since display-graphic-p is true.
> 3. emacsclient -t
> No indicators.
I'm okay with making this smarter, but I object to making it dumber.
> > If you don't like the default for a user option, you can easily
> > customize it locally. But why make that change for everyone? Options
> > are options so that they could be easily adapted to local needs.
>
> Because it's a regression from Emacs 29.
Only in certain situations. The most popular situation where the
users get a TTY frame is when they invoke "emacs -nw", and there we
have an improvement, as intended.
> Keep in mind I was the one who, while reviewing the flymake patch adding
> margins, suggested that TTY frames automatically default to using
> margins. This code exists because I requested it. I sadly did not
> realize that the behavior was implemented with a buggy default value for
> flymake-indicator-type, nor was it caught before release; I only just
> now have received direct user complaints about the regression.
That's fine. We all make mistakes. But the way to correct those
mistakes is not to go back, it's to go forward.
So I urge you to work on a fix which doesn't disable the indicators in
"emacs -nw", but instead attempts to detect the situations you
describe above and adapt the indicator style to them.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77313
; Package
emacs
.
(Thu, 27 Mar 2025 16:58:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 77313 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Keep in mind I was the one who, while reviewing the flymake patch adding
>> margins, suggested that TTY frames automatically default to using
>> margins. This code exists because I requested it. I sadly did not
>> realize that the behavior was implemented with a buggy default value for
>> flymake-indicator-type, nor was it caught before release; I only just
>> now have received direct user complaints about the regression.
>
> That's fine. We all make mistakes. But the way to correct those
> mistakes is not to go back, it's to go forward.
>
> So I urge you to work on a fix which doesn't disable the indicators in
> "emacs -nw", but instead attempts to detect the situations you
> describe above and adapt the indicator style to them.
If you insist, I will develop such a fix. It will be more complex. But
can we please nevertheless backport it to Emacs 30? I really want this
regression to be fixed in Emacs 30.2; I've gotten multiple user
complaints about it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77313
; Package
emacs
.
(Thu, 27 Mar 2025 17:43:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 77313 <at> debbugs.gnu.org (full text, mbox):
> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: 77313 <at> debbugs.gnu.org
> Date: Thu, 27 Mar 2025 12:57:32 -0400
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> From: Spencer Baugh <sbaugh <at> janestreet.com>
> >> Keep in mind I was the one who, while reviewing the flymake patch adding
> >> margins, suggested that TTY frames automatically default to using
> >> margins. This code exists because I requested it. I sadly did not
> >> realize that the behavior was implemented with a buggy default value for
> >> flymake-indicator-type, nor was it caught before release; I only just
> >> now have received direct user complaints about the regression.
> >
> > That's fine. We all make mistakes. But the way to correct those
> > mistakes is not to go back, it's to go forward.
> >
> > So I urge you to work on a fix which doesn't disable the indicators in
> > "emacs -nw", but instead attempts to detect the situations you
> > describe above and adapt the indicator style to them.
>
> If you insist, I will develop such a fix. It will be more complex. But
> can we please nevertheless backport it to Emacs 30? I really want this
> regression to be fixed in Emacs 30.2; I've gotten multiple user
> complaints about it.
I'm reluctant to "fix" this by reverting a useful improvement. So
let's first see the proper solution, which solves the problem for
daemon sessions without reintroducing the problem for -nw sessions,
and let's take it from there.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77313
; Package
emacs
.
(Thu, 27 Mar 2025 18:24:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 77313 <at> debbugs.gnu.org (full text, mbox):
>>> Keep in mind I was the one who, while reviewing the flymake patch adding
>>> margins, suggested that TTY frames automatically default to using
>>> margins. This code exists because I requested it. I sadly did not
>>> realize that the behavior was implemented with a buggy default value for
>>> flymake-indicator-type, nor was it caught before release; I only just
>>> now have received direct user complaints about the regression.
>>
>> That's fine. We all make mistakes. But the way to correct those
>> mistakes is not to go back, it's to go forward.
>>
>> So I urge you to work on a fix which doesn't disable the indicators in
>> "emacs -nw", but instead attempts to detect the situations you
>> describe above and adapt the indicator style to them.
>
> If you insist, I will develop such a fix. It will be more complex. But
> can we please nevertheless backport it to Emacs 30? I really want this
> regression to be fixed in Emacs 30.2; I've gotten multiple user
> complaints about it.
There are many improvements developed in Emacs 31 for flymake margins
in bug#75841 and bug#76254. But maybe better indeed to change
the default in Emacs 30.2 (with no merge to master).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77313
; Package
emacs
.
(Thu, 27 Mar 2025 20:35:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 77313 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Juri Linkov <juri <at> linkov.net> writes:
>>>> Keep in mind I was the one who, while reviewing the flymake patch adding
>>>> margins, suggested that TTY frames automatically default to using
>>>> margins. This code exists because I requested it. I sadly did not
>>>> realize that the behavior was implemented with a buggy default value for
>>>> flymake-indicator-type, nor was it caught before release; I only just
>>>> now have received direct user complaints about the regression.
>>>
>>> That's fine. We all make mistakes. But the way to correct those
>>> mistakes is not to go back, it's to go forward.
>>>
>>> So I urge you to work on a fix which doesn't disable the indicators in
>>> "emacs -nw", but instead attempts to detect the situations you
>>> describe above and adapt the indicator style to them.
>>
>> If you insist, I will develop such a fix. It will be more complex. But
>> can we please nevertheless backport it to Emacs 30? I really want this
>> regression to be fixed in Emacs 30.2; I've gotten multiple user
>> complaints about it.
>
> There are many improvements developed in Emacs 31 for flymake margins
> in bug#75841 and bug#76254. But maybe better indeed to change
> the default in Emacs 30.2 (with no merge to master).
Yes, that's what I was suggesting, not merging to master.
Anyway, how about this patch, which changes the default so that the
fringe vs margin decision is made in a per-frame way?
(Opinions welcome on what to name the new default for
flymake-indicator-type)
[0001-flymake-default-to-deciding-indicator-type-per-buffe.patch (text/x-patch, inline)]
From b64253c0f56e3f15f2807654baad462379d1a052 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh <at> janestreet.com>
Date: Thu, 27 Mar 2025 16:32:59 -0400
Subject: [PATCH] flymake: default to deciding indicator type per-buffer
Previously, flymake-indicator-type defaults to either fringes or
margins. But fringes should be used on graphical frames, and
margins on TTY frames, so a single global default is incorrect.
Instead, it should be decided on a per-frame basis.
Now flymake-indicator-type defaults to 'fringes-per-frame, which
uses fringes on (buffers in) graphical frames, margins on
(buffers in) terminal frames.
* lisp/progmodes/flymake.el (flymake-indicator-type): Set to
fringes-per-frame. (bug#77313)
(flymake--use-fringes-p, flymake--use-margins-p): Add.
(flymake--resize-margins): Check flymake--use-margins-p.
(flymake--highlight-line): Check flymake--use-fringes-p and
flymake--use-margins.
---
lisp/progmodes/flymake.el | 26 ++++++++++++++++++--------
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/lisp/progmodes/flymake.el b/lisp/progmodes/flymake.el
index 75ba3efeb65..06001abe156 100644
--- a/lisp/progmodes/flymake.el
+++ b/lisp/progmodes/flymake.el
@@ -185,9 +185,7 @@ flymake-fringe-indicator-position
(const right-fringe)
(const :tag "No fringe indicators" nil)))
-(defcustom flymake-indicator-type (if (display-graphic-p)
- 'fringes
- 'margins)
+(defcustom flymake-indicator-type 'fringes-per-frame
"Indicate which indicator type to use for display errors.
The value can be nil (don't indicate errors but just highlight them),
@@ -199,8 +197,10 @@ flymake-indicator-type
See Info node `Fringes' and Info node `(elisp)Display Margins'."
:version "30.1"
- :type '(choice (const :tag "Use Fringes" fringes)
- (const :tag "Use Margins "margins)
+ :type '(choice (const :tag "Use fringes on graphical, margins on TTY frames"
+ fringes-per-frame)
+ (const :tag "Use Fringes" fringes)
+ (const :tag "Use Margins" margins)
(const :tag "No indicators" nil)))
(defcustom flymake-margin-indicators-string
@@ -777,10 +777,20 @@ flymake--indicator-overlay-spec
`(:inherit (,indicator-cdr
default)))))))))
+(defun flymake--use-fringes-p ()
+ (cl-case flymake-indicator-type
+ (fringes t)
+ ((nil margins) nil)
+ (fringes-per-frame (display-graphic-p))
+ (t t)))
+
+(defun flymake--use-margins-p ()
+ (not (flymake--use-fringes-p)))
+
(defun flymake--resize-margins (&optional orig-width)
"Resize current window margins according to `flymake-margin-indicator-position'.
Return to original margin width if ORIG-WIDTH is non-nil."
- (when (and (eq flymake-indicator-type 'margins)
+ (when (and (flymake--use-margins-p)
flymake-autoresize-margins)
(cond
((and orig-width flymake--original-margin-width)
@@ -945,9 +955,9 @@ flymake--highlight-line
(flymake--indicator-overlay-spec
(flymake--lookup-type-property
type
- (cond ((eq flymake-indicator-type 'fringes)
+ (cond ((flymake--use-fringes-p)
'flymake-bitmap)
- ((eq flymake-indicator-type 'margins)
+ ((flymake--use-margins-p)
'flymake-margin-string))
(alist-get 'bitmap (alist-get type ; backward compat
flymake-diagnostic-types-alist)))))
--
2.39.3
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77313
; Package
emacs
.
(Fri, 28 Mar 2025 07:13:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 77313 <at> debbugs.gnu.org (full text, mbox):
> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 77313 <at> debbugs.gnu.org
> Date: Thu, 27 Mar 2025 16:34:16 -0400
>
> Juri Linkov <juri <at> linkov.net> writes:
>
> > There are many improvements developed in Emacs 31 for flymake margins
> > in bug#75841 and bug#76254. But maybe better indeed to change
> > the default in Emacs 30.2 (with no merge to master).
>
> Yes, that's what I was suggesting, not merging to master.
You are saying that this problem doesn't exist on master? If so,
perhaps we should consider backporting some of the changes on master
to emacs-30 (if that's feasible)?
> Anyway, how about this patch, which changes the default so that the
> fringe vs margin decision is made in a per-frame way?
I think it's the correct direction, but wouldn't it be easier to make
this a frame parameter instead? Then the defcustom could be nil by
default, and if it's non-nil, it would override the frame parameter.
The bonus will be that users will be able to define different styles
even for frames of the same type. Another bonus is that the
frame-parameter machinery is well-tested, so the change will be a
low-risk one.
WDYT?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77313
; Package
emacs
.
(Fri, 28 Mar 2025 16:54:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 77313 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 77313 <at> debbugs.gnu.org
>> Date: Thu, 27 Mar 2025 16:34:16 -0400
>>
>> Juri Linkov <juri <at> linkov.net> writes:
>>
>> > There are many improvements developed in Emacs 31 for flymake margins
>> > in bug#75841 and bug#76254. But maybe better indeed to change
>> > the default in Emacs 30.2 (with no merge to master).
>>
>> Yes, that's what I was suggesting, not merging to master.
>
> You are saying that this problem doesn't exist on master? If so,
> perhaps we should consider backporting some of the changes on master
> to emacs-30 (if that's feasible)?
No, it does exist on master. I was thinking of having a more
sophisticated fix for master which makes the margin vs fringe
autodetection work reliably. But for emacs-30 we'd do the simpler thing
of defaulting to 'fringe, to preserve the behavior that was in Emasc 29.
>> Anyway, how about this patch, which changes the default so that the
>> fringe vs margin decision is made in a per-frame way?
>
> I think it's the correct direction, but wouldn't it be easier to make
> this a frame parameter instead? Then the defcustom could be nil by
> default, and if it's non-nil, it would override the frame parameter.
> The bonus will be that users will be able to define different styles
> even for frames of the same type. Another bonus is that the
> frame-parameter machinery is well-tested, so the change will be a
> low-risk one.
>
> WDYT?
Note that a nil value for the defcustom is already interpreted as
meaning "show no indicators".
As for adding a frame parameter: that's a good idea, but I think we'd
still want to behave correctly if the frame parameter isn't set. In the
case where the frame parameter isn't set, I think we'd have the same
logic that exists in my patch right now, where we decide margin vs
fringe based on (display-graphic-p).
So, adding a frame parameter would be useful, but it could be done
later, purely additively. Which is nice because it keeps this patch
small and more plausible to backport to emacs-30, if we need to do that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77313
; Package
emacs
.
(Sat, 29 Mar 2025 07:06:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 77313 <at> debbugs.gnu.org (full text, mbox):
> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: 77313 <at> debbugs.gnu.org, juri <at> linkov.net
> Date: Fri, 28 Mar 2025 12:53:11 -0400
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > I think it's the correct direction, but wouldn't it be easier to make
> > this a frame parameter instead? Then the defcustom could be nil by
> > default, and if it's non-nil, it would override the frame parameter.
> > The bonus will be that users will be able to define different styles
> > even for frames of the same type. Another bonus is that the
> > frame-parameter machinery is well-tested, so the change will be a
> > low-risk one.
> >
> > WDYT?
>
> Note that a nil value for the defcustom is already interpreted as
> meaning "show no indicators".
>
> As for adding a frame parameter: that's a good idea, but I think we'd
> still want to behave correctly if the frame parameter isn't set. In the
> case where the frame parameter isn't set, I think we'd have the same
> logic that exists in my patch right now, where we decide margin vs
> fringe based on (display-graphic-p).
Maybe. Or maybe we should leave the defcustom in its current simple
form. Because if the default is to have the frame parameter, then
what the defcustom does is much less important.
> So, adding a frame parameter would be useful, but it could be done
> later, purely additively.
I think it should be the main solution for emacs-30, not the backup or
future extension. Why not?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77313
; Package
emacs
.
(Tue, 01 Apr 2025 22:22:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 77313 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Cc: 77313 <at> debbugs.gnu.org, juri <at> linkov.net
>> Date: Fri, 28 Mar 2025 12:53:11 -0400
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > I think it's the correct direction, but wouldn't it be easier to make
>> > this a frame parameter instead? Then the defcustom could be nil by
>> > default, and if it's non-nil, it would override the frame parameter.
>> > The bonus will be that users will be able to define different styles
>> > even for frames of the same type. Another bonus is that the
>> > frame-parameter machinery is well-tested, so the change will be a
>> > low-risk one.
>> >
>> > WDYT?
>>
>> Note that a nil value for the defcustom is already interpreted as
>> meaning "show no indicators".
>>
>> As for adding a frame parameter: that's a good idea, but I think we'd
>> still want to behave correctly if the frame parameter isn't set. In the
>> case where the frame parameter isn't set, I think we'd have the same
>> logic that exists in my patch right now, where we decide margin vs
>> fringe based on (display-graphic-p).
>
> Maybe. Or maybe we should leave the defcustom in its current simple
> form. Because if the default is to have the frame parameter, then
> what the defcustom does is much less important.
How would we achieve "the default is to have the frame parameter"? How
would we make sure that the frame parameter exists on frames which were
created before flymake.el is loaded, for example?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77313
; Package
emacs
.
(Wed, 02 Apr 2025 11:54:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 77313 <at> debbugs.gnu.org (full text, mbox):
> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: 77313 <at> debbugs.gnu.org, juri <at> linkov.net
> Date: Tue, 01 Apr 2025 18:21:38 -0400
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Spencer Baugh <sbaugh <at> janestreet.com>
> >> Cc: 77313 <at> debbugs.gnu.org, juri <at> linkov.net
> >> Date: Fri, 28 Mar 2025 12:53:11 -0400
> >>
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >>
> >> > I think it's the correct direction, but wouldn't it be easier to make
> >> > this a frame parameter instead? Then the defcustom could be nil by
> >> > default, and if it's non-nil, it would override the frame parameter.
> >> > The bonus will be that users will be able to define different styles
> >> > even for frames of the same type. Another bonus is that the
> >> > frame-parameter machinery is well-tested, so the change will be a
> >> > low-risk one.
> >> >
> >> > WDYT?
> >>
> >> Note that a nil value for the defcustom is already interpreted as
> >> meaning "show no indicators".
> >>
> >> As for adding a frame parameter: that's a good idea, but I think we'd
> >> still want to behave correctly if the frame parameter isn't set. In the
> >> case where the frame parameter isn't set, I think we'd have the same
> >> logic that exists in my patch right now, where we decide margin vs
> >> fringe based on (display-graphic-p).
> >
> > Maybe. Or maybe we should leave the defcustom in its current simple
> > form. Because if the default is to have the frame parameter, then
> > what the defcustom does is much less important.
>
> How would we achieve "the default is to have the frame parameter"? How
> would we make sure that the frame parameter exists on frames which were
> created before flymake.el is loaded, for example?
There are several possible way that come to mind. For example, the
first time Flymake is activated in a frame that doesn't have this
parameter, it (Flymake) will set the parameter with the default value
for the frame type. Another possibility is to inject the parameter by
default in the respective frame-creation functions. And there are
probably more ways. If you evaluate (frame-parameters) in "emacs -Q",
you will see quite a few parameters there already, so evidently we
have a means of pulling that trick.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77313
; Package
emacs
.
(Wed, 02 Apr 2025 13:06:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 77313 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Cc: 77313 <at> debbugs.gnu.org, juri <at> linkov.net
>> Date: Tue, 01 Apr 2025 18:21:38 -0400
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> >> Cc: 77313 <at> debbugs.gnu.org, juri <at> linkov.net
>> >> Date: Fri, 28 Mar 2025 12:53:11 -0400
>> >>
>> >> Eli Zaretskii <eliz <at> gnu.org> writes:
>> >>
>> >> > I think it's the correct direction, but wouldn't it be easier to make
>> >> > this a frame parameter instead? Then the defcustom could be nil by
>> >> > default, and if it's non-nil, it would override the frame parameter.
>> >> > The bonus will be that users will be able to define different styles
>> >> > even for frames of the same type. Another bonus is that the
>> >> > frame-parameter machinery is well-tested, so the change will be a
>> >> > low-risk one.
>> >> >
>> >> > WDYT?
>> >>
>> >> Note that a nil value for the defcustom is already interpreted as
>> >> meaning "show no indicators".
>> >>
>> >> As for adding a frame parameter: that's a good idea, but I think we'd
>> >> still want to behave correctly if the frame parameter isn't set. In the
>> >> case where the frame parameter isn't set, I think we'd have the same
>> >> logic that exists in my patch right now, where we decide margin vs
>> >> fringe based on (display-graphic-p).
>> >
>> > Maybe. Or maybe we should leave the defcustom in its current simple
>> > form. Because if the default is to have the frame parameter, then
>> > what the defcustom does is much less important.
>>
>> How would we achieve "the default is to have the frame parameter"? How
>> would we make sure that the frame parameter exists on frames which were
>> created before flymake.el is loaded, for example?
>
> There are several possible way that come to mind. For example, the
> first time Flymake is activated in a frame that doesn't have this
> parameter, it (Flymake) will set the parameter with the default value
> for the frame type.
Yes, and presumably the default value for the frame type would be
user-configurable via a defcustom, which would have the same logic that
exists in my patch right now, where we can either:
- always use margins
- always use fringes
- decide margins vs fringes based on (display-graphic-p)
So again, we can't leave the defcustom in its current simple state.
> Another possibility is to inject the parameter by default in the
> respective frame-creation functions.
So frame.el and x-win.el (and others) will mention "flymake-indicators"?
That seems like a bad idea.
> And there are probably more ways. If you evaluate n(frame-parameters)
> in "emacs -Q", you will see quite a few parameters there already, so
> evidently we have a means of pulling that trick.
I don't see any members of (frame-parameters) which wouldn't be OK with
a default of nil.
This seems substantially more complicated than just using the current
simple defcustom. For another thing, we don't have any customize
support for frame-parameters. I don't think we should do this, at least
not until some user actually requests it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77313
; Package
emacs
.
(Tue, 08 Apr 2025 12:47:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 77313 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Here's an updated version of my previous patch which avoids the need for
a new variant in the defcustom. When flymake-indicator-type is set to
fringes and we're on a text frame, we simply fall back to using margins.
That allows it to be set to fringes by default without losing
functionality for text terminals; this is how this should have been
implemented originally.
Can we make progress on at least installing this on master, so we can
test it before backporting it to Emacs 30.2?
[0001-flymake-fall-back-to-margins-on-text-terminals.patch (text/x-patch, inline)]
From d6122447985b9f1f20b86c3ea714cc447eedcf39 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh <at> janestreet.com>
Date: Tue, 8 Apr 2025 08:43:37 -0400
Subject: [PATCH] flymake: fall back to margins on text terminals
Previously, flymake-indicator-type defaulted to either fringes
or margins. But fringes should be used on graphical frames, and
margins on TTY frames. So default to fringes instead, and
simply fall back to margins automatically on text frames.
* lisp/progmodes/flymake.el (flymake-indicator-type): Set to
fringes. (bug#77313)
(flymake--use-fringes-p, flymake--use-margins-p): Add.
(flymake--resize-margins): Check flymake--use-margins-p.
(flymake--highlight-line): Check flymake--use-fringes-p and
flymake--use-margins.
---
lisp/progmodes/flymake.el | 28 ++++++++++++++++++++--------
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/lisp/progmodes/flymake.el b/lisp/progmodes/flymake.el
index 6cc7e1f7a79..4b40f9b9c31 100644
--- a/lisp/progmodes/flymake.el
+++ b/lisp/progmodes/flymake.el
@@ -185,22 +185,22 @@ flymake-fringe-indicator-position
(const right-fringe)
(const :tag "No fringe indicators" nil)))
-(defcustom flymake-indicator-type (if (display-graphic-p)
- 'fringes
- 'margins)
+(defcustom flymake-indicator-type 'fringes
"Indicate which indicator type to use for display errors.
The value can be nil (don't indicate errors but just highlight them),
-fringes (use fringes) or margins (use margins)
+`fringes' (use fringes) or `margins' (use margins)
Difference between fringes and margin is that fringes support displaying
bitmaps on graphical displays and margins display text in a blank area
from current buffer that works in both graphical and text displays.
+Thus, even when `fringes' is selected, margins will still be used on
+text displays.
See Info node `Fringes' and Info node `(elisp)Display Margins'."
:version "30.1"
:type '(choice (const :tag "Use Fringes" fringes)
- (const :tag "Use Margins "margins)
+ (const :tag "Use Margins" margins)
(const :tag "No indicators" nil)))
(defcustom flymake-margin-indicators-string
@@ -752,9 +752,9 @@ flymake--indicator-overlay-spec
"Return INDICATOR as propertized string to use in error indicators."
(let* ((indicator (flymake--lookup-type-property
type
- (cond ((eq flymake-indicator-type 'fringes)
+ (cond ((flymake--use-fringes-p)
'flymake-bitmap)
- ((eq flymake-indicator-type 'margins)
+ ((flymake--use-margins-p)
'flymake-margin-string))
(alist-get 'bitmap (alist-get type ; backward compat
flymake-diagnostic-types-alist))))
@@ -784,10 +784,22 @@ flymake--indicator-overlay-spec
(format "<%s> <mouse-1>" flymake-margin-indicator-position)
#'flymake-show-buffer-diagnostics-at-event-line))))))))
+(defun flymake--use-fringes-p ()
+ (cl-case flymake-indicator-type
+ (fringes (display-graphic-p))
+ ((nil margins) nil)
+ (t t)))
+
+(defun flymake--use-margins-p ()
+ (cl-case flymake-indicator-type
+ (fringes (not (display-graphic-p)))
+ (margins t)
+ (t nil)))
+
(defun flymake--resize-margins (&optional orig-width)
"Resize current window margins according to `flymake-margin-indicator-position'.
Return to original margin width if ORIG-WIDTH is non-nil."
- (when (and (eq flymake-indicator-type 'margins)
+ (when (and (flymake--use-margins-p)
flymake-autoresize-margins)
(cond
((and orig-width flymake--original-margin-width)
--
2.39.3
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77313
; Package
emacs
.
(Tue, 08 Apr 2025 14:17:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 77313 <at> debbugs.gnu.org (full text, mbox):
> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: 77313 <at> debbugs.gnu.org, juri <at> linkov.net
> Date: Tue, 08 Apr 2025 08:46:17 -0400
>
> Here's an updated version of my previous patch which avoids the need for
> a new variant in the defcustom. When flymake-indicator-type is set to
> fringes and we're on a text frame, we simply fall back to using margins.
> That allows it to be set to fringes by default without losing
> functionality for text terminals; this is how this should have been
> implemented originally.
I think we should also fall back on using margins if the fringes are
disabled on GUI frames.
> -(defcustom flymake-indicator-type (if (display-graphic-p)
> - 'fringes
> - 'margins)
> +(defcustom flymake-indicator-type 'fringes
> "Indicate which indicator type to use for display errors.
>
> The value can be nil (don't indicate errors but just highlight them),
> -fringes (use fringes) or margins (use margins)
> +`fringes' (use fringes) or `margins' (use margins)
>
> Difference between fringes and margin is that fringes support displaying
> bitmaps on graphical displays and margins display text in a blank area
> from current buffer that works in both graphical and text displays.
> +Thus, even when `fringes' is selected, margins will still be used on
> +text displays.
^^^^^^^^^^^^^
"...and also when fringes are disabled."
>
> See Info node `Fringes' and Info node `(elisp)Display Margins'."
> :version "30.1"
The :version should change, since the default value changes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77313
; Package
emacs
.
(Tue, 08 Apr 2025 14:31:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 77313 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Cc: 77313 <at> debbugs.gnu.org, juri <at> linkov.net
>> Date: Tue, 08 Apr 2025 08:46:17 -0400
>>
>> Here's an updated version of my previous patch which avoids the need for
>> a new variant in the defcustom. When flymake-indicator-type is set to
>> fringes and we're on a text frame, we simply fall back to using margins.
>> That allows it to be set to fringes by default without losing
>> functionality for text terminals; this is how this should have been
>> implemented originally.
>
> I think we should also fall back on using margins if the fringes are
> disabled on GUI frames.
Disabled how? I don't see a way to disable the fringe. Do you mean
when the fringe width is set to 0? So are you suggesting we should call
window-fringes and check the width of the fringe we're going to use? I
can do that, just want to confirm.
>> -(defcustom flymake-indicator-type (if (display-graphic-p)
>> - 'fringes
>> - 'margins)
>> +(defcustom flymake-indicator-type 'fringes
>> "Indicate which indicator type to use for display errors.
>>
>> The value can be nil (don't indicate errors but just highlight them),
>> -fringes (use fringes) or margins (use margins)
>> +`fringes' (use fringes) or `margins' (use margins)
>>
>> Difference between fringes and margin is that fringes support displaying
>> bitmaps on graphical displays and margins display text in a blank area
>> from current buffer that works in both graphical and text displays.
>> +Thus, even when `fringes' is selected, margins will still be used on
>> +text displays.
> ^^^^^^^^^^^^^
> "...and also when fringes are disabled."
>
>>
>> See Info node `Fringes' and Info node `(elisp)Display Margins'."
>> :version "30.1"
>
> The :version should change, since the default value changes.
Will update these in the next version.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77313
; Package
emacs
.
(Tue, 08 Apr 2025 14:57:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 77313 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Spencer Baugh <sbaugh <at> janestreet.com> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>>> Cc: 77313 <at> debbugs.gnu.org, juri <at> linkov.net
>>> Date: Tue, 08 Apr 2025 08:46:17 -0400
>>>
>>> Here's an updated version of my previous patch which avoids the need for
>>> a new variant in the defcustom. When flymake-indicator-type is set to
>>> fringes and we're on a text frame, we simply fall back to using margins.
>>> That allows it to be set to fringes by default without losing
>>> functionality for text terminals; this is how this should have been
>>> implemented originally.
>>
>> I think we should also fall back on using margins if the fringes are
>> disabled on GUI frames.
>
> Disabled how? I don't see a way to disable the fringe. Do you mean
> when the fringe width is set to 0? So are you suggesting we should call
> window-fringes and check the width of the fringe we're going to use? I
> can do that, just want to confirm.
Assuming that's what you mean, here's the updated patch.
[0001-flymake-fall-back-to-margins-on-text-terminals.patch (text/x-patch, inline)]
From 555ebfec9641d535778dfc6295f4accb70557721 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh <at> janestreet.com>
Date: Tue, 8 Apr 2025 08:43:37 -0400
Subject: [PATCH] flymake: fall back to margins on text terminals
Previously, flymake-indicator-type defaulted to either fringes
or margins. But fringes should be used on graphical frames, and
margins on TTY frames. So default to fringes instead, and
simply fall back to margins automatically on text frames.
* lisp/progmodes/flymake.el (flymake-indicator-type): Set to
fringes. (bug#77313)
(flymake-mode): Fallback to margins if there's no fringes.
---
lisp/progmodes/flymake.el | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/lisp/progmodes/flymake.el b/lisp/progmodes/flymake.el
index 6cc7e1f7a79..7340fed9be4 100644
--- a/lisp/progmodes/flymake.el
+++ b/lisp/progmodes/flymake.el
@@ -185,22 +185,23 @@ flymake-fringe-indicator-position
(const right-fringe)
(const :tag "No fringe indicators" nil)))
-(defcustom flymake-indicator-type (if (display-graphic-p)
- 'fringes
- 'margins)
+(defcustom flymake-indicator-type 'fringes
"Indicate which indicator type to use for display errors.
The value can be nil (don't indicate errors but just highlight them),
-fringes (use fringes) or margins (use margins)
+the symbol `fringes' (use fringes) or the symbol `margins' (use
+margins).
Difference between fringes and margin is that fringes support displaying
bitmaps on graphical displays and margins display text in a blank area
from current buffer that works in both graphical and text displays.
+Thus, even when `fringes' is selected, margins will still be used on
+text displays and also when fringes are disabled.
See Info node `Fringes' and Info node `(elisp)Display Margins'."
- :version "30.1"
+ :version "31.1"
:type '(choice (const :tag "Use Fringes" fringes)
- (const :tag "Use Margins "margins)
+ (const :tag "Use Margins" margins)
(const :tag "No indicators" nil)))
(defcustom flymake-margin-indicators-string
@@ -1439,6 +1440,13 @@ flymake-mode
(add-hook 'kill-buffer-hook 'flymake-kill-buffer-hook nil t)
(add-hook 'eldoc-documentation-functions 'flymake-eldoc-function t t)
+ (when (and (eq flymake-indicator-type 'fringes)
+ (not (cl-case flymake-fringe-indicator-position
+ (left-fringe (< 0 (nth 0 (window-fringes))))
+ (right-fringe (< 0 (nth 1 (window-fringes)))))))
+ ;; There are no fringes in the buffer, fallback to margins.
+ (setq-local flymake-indicator-type 'margins))
+
;; AutoResize margins.
(flymake--resize-margins)
--
2.39.3
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77313
; Package
emacs
.
(Tue, 08 Apr 2025 15:55:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 77313 <at> debbugs.gnu.org (full text, mbox):
> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: 77313 <at> debbugs.gnu.org, juri <at> linkov.net
> Date: Tue, 08 Apr 2025 10:56:20 -0400
>
> Spencer Baugh <sbaugh <at> janestreet.com> writes:
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> >> I think we should also fall back on using margins if the fringes are
> >> disabled on GUI frames.
> >
> > Disabled how? I don't see a way to disable the fringe. Do you mean
> > when the fringe width is set to 0? So are you suggesting we should call
> > window-fringes and check the width of the fringe we're going to use? I
> > can do that, just want to confirm.
>
> Assuming that's what you mean, here's the updated patch.
Yes, that's what I meant.
> >From 555ebfec9641d535778dfc6295f4accb70557721 Mon Sep 17 00:00:00 2001
> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Date: Tue, 8 Apr 2025 08:43:37 -0400
> Subject: [PATCH] flymake: fall back to margins on text terminals
>
> Previously, flymake-indicator-type defaulted to either fringes
> or margins. But fringes should be used on graphical frames, and
> margins on TTY frames. So default to fringes instead, and
> simply fall back to margins automatically on text frames.
The above needs to be updated to mention the disabled fringes.
> * lisp/progmodes/flymake.el (flymake-indicator-type): Set to
> fringes. (bug#77313)
> (flymake-mode): Fallback to margins if there's no fringes.
This needs a NEWS entry, but other than that it LGTM. Let's wait for
a couple of days to let others a chance to comment.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77313
; Package
emacs
.
(Tue, 08 Apr 2025 21:51:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 77313 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Date: Tue, 8 Apr 2025 08:43:37 -0400
>> Subject: [PATCH] flymake: fall back to margins on text terminals
>>
>> Previously, flymake-indicator-type defaulted to either fringes
>> or margins. But fringes should be used on graphical frames, and
>> margins on TTY frames. So default to fringes instead, and
>> simply fall back to margins automatically on text frames.
>
> The above needs to be updated to mention the disabled fringes.
Updated.
>> * lisp/progmodes/flymake.el (flymake-indicator-type): Set to
>> fringes. (bug#77313)
>> (flymake-mode): Fallback to margins if there's no fringes.
>
> This needs a NEWS entry, but other than that it LGTM. Let's wait for
> a couple of days to let others a chance to comment.
Added a NEWS entry.
[0001-flymake-fall-back-to-margins-on-text-terminals.patch (text/x-patch, inline)]
From 792d90c4f01a6b054a4a05ae7dc2598716def7ea Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh <at> janestreet.com>
Date: Tue, 8 Apr 2025 08:43:37 -0400
Subject: [PATCH] flymake: fall back to margins on text terminals
Previously, flymake-indicator-type defaulted to either fringes
or margins. But fringes should be used on graphical frames, and
margins on TTY frames. So default to fringes instead, and
simply fall back to margins automatically on text frames.
* lisp/progmodes/flymake.el (flymake-indicator-type): Set to
fringes. (bug#77313)
(flymake-mode): Fallback to margins if there's no fringes.
* doc/misc/flymake.texi (Customizable variables): Mention
fallback behavior.
* etc/NEWS: Announce fallback behavior.
---
doc/misc/flymake.texi | 3 +++
etc/NEWS | 8 ++++++++
lisp/progmodes/flymake.el | 20 ++++++++++++++------
3 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/doc/misc/flymake.texi b/doc/misc/flymake.texi
index 54835767928..668a72b4cd1 100644
--- a/doc/misc/flymake.texi
+++ b/doc/misc/flymake.texi
@@ -313,6 +313,9 @@ Customizable variables
errors or warnings.
Depending on your preference, this can either use @code{fringes} or
@code{margins} for indicating errors.
+If set to @code{fringes} (the default), it will automatically fall back
+to using margins in windows or frames without fringes, such as text
+terminals.
@item flymake-error-bitmap
A bitmap used in the fringe to mark lines for which an error has
diff --git a/etc/NEWS b/etc/NEWS
index b2286236d57..123a04527c4 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -1720,6 +1720,14 @@ change their face if the current line exceeds the 'fill-column'. The
new face 'display-fill-column-indicator-warning-face' is used to
highlight the fill-column indicators. By default this is disabled.
+---
+** Flymake
+
+*** Windows without fringes now automatically use margin indicators
+When flymake-indicator-type is set to 'fringes', as is now the default,
+flymake will automatically fall back to using margin indicators in
+windows without fringes, including any window in a text terminal.
+
* New Modes and Packages in Emacs 31.1
diff --git a/lisp/progmodes/flymake.el b/lisp/progmodes/flymake.el
index 6cc7e1f7a79..7340fed9be4 100644
--- a/lisp/progmodes/flymake.el
+++ b/lisp/progmodes/flymake.el
@@ -185,22 +185,23 @@ flymake-fringe-indicator-position
(const right-fringe)
(const :tag "No fringe indicators" nil)))
-(defcustom flymake-indicator-type (if (display-graphic-p)
- 'fringes
- 'margins)
+(defcustom flymake-indicator-type 'fringes
"Indicate which indicator type to use for display errors.
The value can be nil (don't indicate errors but just highlight them),
-fringes (use fringes) or margins (use margins)
+the symbol `fringes' (use fringes) or the symbol `margins' (use
+margins).
Difference between fringes and margin is that fringes support displaying
bitmaps on graphical displays and margins display text in a blank area
from current buffer that works in both graphical and text displays.
+Thus, even when `fringes' is selected, margins will still be used on
+text displays and also when fringes are disabled.
See Info node `Fringes' and Info node `(elisp)Display Margins'."
- :version "30.1"
+ :version "31.1"
:type '(choice (const :tag "Use Fringes" fringes)
- (const :tag "Use Margins "margins)
+ (const :tag "Use Margins" margins)
(const :tag "No indicators" nil)))
(defcustom flymake-margin-indicators-string
@@ -1439,6 +1440,13 @@ flymake-mode
(add-hook 'kill-buffer-hook 'flymake-kill-buffer-hook nil t)
(add-hook 'eldoc-documentation-functions 'flymake-eldoc-function t t)
+ (when (and (eq flymake-indicator-type 'fringes)
+ (not (cl-case flymake-fringe-indicator-position
+ (left-fringe (< 0 (nth 0 (window-fringes))))
+ (right-fringe (< 0 (nth 1 (window-fringes)))))))
+ ;; There are no fringes in the buffer, fallback to margins.
+ (setq-local flymake-indicator-type 'margins))
+
;; AutoResize margins.
(flymake--resize-margins)
--
2.39.3
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77313
; Package
emacs
.
(Sat, 12 Apr 2025 11:14:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 77313 <at> debbugs.gnu.org (full text, mbox):
> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: 77313 <at> debbugs.gnu.org, juri <at> linkov.net
> Date: Tue, 08 Apr 2025 17:50:38 -0400
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> From: Spencer Baugh <sbaugh <at> janestreet.com>
> >> Date: Tue, 8 Apr 2025 08:43:37 -0400
> >> Subject: [PATCH] flymake: fall back to margins on text terminals
> >>
> >> Previously, flymake-indicator-type defaulted to either fringes
> >> or margins. But fringes should be used on graphical frames, and
> >> margins on TTY frames. So default to fringes instead, and
> >> simply fall back to margins automatically on text frames.
> >
> > The above needs to be updated to mention the disabled fringes.
>
> Updated.
>
> >> * lisp/progmodes/flymake.el (flymake-indicator-type): Set to
> >> fringes. (bug#77313)
> >> (flymake-mode): Fallback to margins if there's no fringes.
> >
> > This needs a NEWS entry, but other than that it LGTM. Let's wait for
> > a couple of days to let others a chance to comment.
>
> Added a NEWS entry.
Thanks, installed on master.
Should we now close this bug?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77313
; Package
emacs
.
(Sat, 12 Apr 2025 11:44:05 GMT)
Full text and
rfc822 format available.
Message #68 received at 77313 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Apr 12, 2025, 7:13 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> Thanks, installed on master.
>
> Should we now close this bug?
>
No, we need to backport it to Emacs 30.2 to fix the regression.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77313
; Package
emacs
.
(Sat, 12 Apr 2025 12:51:03 GMT)
Full text and
rfc822 format available.
Message #71 received at 77313 <at> debbugs.gnu.org (full text, mbox):
> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Date: Sat, 12 Apr 2025 07:43:11 -0400
> Cc: 77313 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
>
> On Sat, Apr 12, 2025, 7:13 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> Thanks, installed on master.
>
> Should we now close this bug?
>
> No, we need to backport it to Emacs 30.2 to fix the regression.
OK, but it cannot be cherry-picked as is, because it includes a NEWS
entry. So the fix for emacs-30, when we decide to install it, will
need to be a separate commit.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77313
; Package
emacs
.
(Wed, 16 Apr 2025 17:58:04 GMT)
Full text and
rfc822 format available.
Message #74 received at 77313 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Date: Sat, 12 Apr 2025 07:43:11 -0400
>> Cc: 77313 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
>>
>> On Sat, Apr 12, 2025, 7:13 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>>
>> Thanks, installed on master.
>>
>> Should we now close this bug?
>>
>> No, we need to backport it to Emacs 30.2 to fix the regression.
>
> OK, but it cannot be cherry-picked as is, because it includes a NEWS
> entry. So the fix for emacs-30, when we decide to install it, will
> need to be a separate commit.
OK, here is a version ready for backporting to emacs-30, with a NEWS
entry appropriate for 30.2.
[0001-flymake-fall-back-to-margins-on-text-terminals.patch (text/x-patch, inline)]
From 1031bf89a5444ad225b1ef1af64bbb32a2a7512a Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh <at> janestreet.com>
Date: Tue, 8 Apr 2025 08:43:37 -0400
Subject: [PATCH] flymake: fall back to margins on text terminals
Previously, flymake-indicator-type defaulted to either fringes
or margins. But fringes should be used on graphical frames, and
margins on TTY frames. So default to fringes instead, and
simply fall back to margins automatically on text frames.
* lisp/progmodes/flymake.el (flymake-indicator-type): Set to
fringes. (bug#77313)
(flymake-mode): Fallback to margins if there's no fringes.
* doc/misc/flymake.texi (Customizable variables): Mention
fallback behavior.
* etc/NEWS: Announce fallback behavior.
---
doc/misc/flymake.texi | 3 +++
etc/NEWS | 7 +++++++
lisp/progmodes/flymake.el | 20 ++++++++++++++------
3 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/doc/misc/flymake.texi b/doc/misc/flymake.texi
index 54835767928..668a72b4cd1 100644
--- a/doc/misc/flymake.texi
+++ b/doc/misc/flymake.texi
@@ -313,6 +313,9 @@ Customizable variables
errors or warnings.
Depending on your preference, this can either use @code{fringes} or
@code{margins} for indicating errors.
+If set to @code{fringes} (the default), it will automatically fall back
+to using margins in windows or frames without fringes, such as text
+terminals.
@item flymake-error-bitmap
A bitmap used in the fringe to mark lines for which an error has
diff --git a/etc/NEWS b/etc/NEWS
index dfe4c65f1dd..1915c3170a7 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -30,6 +30,13 @@ with a prefix argument or by typing 'C-u C-h C-n'.
* Changes in Specialized Modes and Packages in Emacs 30.2
+** Flymake
+
+*** Windows without fringes now automatically use margin indicators
+When flymake-indicator-type is set to 'fringes', as is now the default,
+flymake will automatically fall back to using margin indicators in
+windows without fringes, including any window in a text terminal.
+
* New Modes and Packages in Emacs 30.2
diff --git a/lisp/progmodes/flymake.el b/lisp/progmodes/flymake.el
index f8a294908ba..08e96565229 100644
--- a/lisp/progmodes/flymake.el
+++ b/lisp/progmodes/flymake.el
@@ -185,22 +185,23 @@ flymake-fringe-indicator-position
(const right-fringe)
(const :tag "No fringe indicators" nil)))
-(defcustom flymake-indicator-type (if (display-graphic-p)
- 'fringes
- 'margins)
+(defcustom flymake-indicator-type 'fringes
"Indicate which indicator type to use for display errors.
The value can be nil (don't indicate errors but just highlight them),
-fringes (use fringes) or margins (use margins)
+the symbol `fringes' (use fringes) or the symbol `margins' (use
+margins).
Difference between fringes and margin is that fringes support displaying
bitmaps on graphical displays and margins display text in a blank area
from current buffer that works in both graphical and text displays.
+Thus, even when `fringes' is selected, margins will still be used on
+text displays and also when fringes are disabled.
See Info node `Fringes' and Info node `(elisp)Display Margins'."
- :version "30.1"
+ :version "31.1"
:type '(choice (const :tag "Use Fringes" fringes)
- (const :tag "Use Margins "margins)
+ (const :tag "Use Margins" margins)
(const :tag "No indicators" nil)))
(defcustom flymake-margin-indicators-string
@@ -1393,6 +1394,13 @@ flymake-mode
(add-hook 'kill-buffer-hook 'flymake-kill-buffer-hook nil t)
(add-hook 'eldoc-documentation-functions 'flymake-eldoc-function t t)
+ (when (and (eq flymake-indicator-type 'fringes)
+ (not (cl-case flymake-fringe-indicator-position
+ (left-fringe (< 0 (nth 0 (window-fringes))))
+ (right-fringe (< 0 (nth 1 (window-fringes)))))))
+ ;; There are no fringes in the buffer, fallback to margins.
+ (setq-local flymake-indicator-type 'margins))
+
;; AutoResize margins.
(flymake--resize-margins)
--
2.39.3
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77313
; Package
emacs
.
(Thu, 17 Apr 2025 05:42:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 77313 <at> debbugs.gnu.org (full text, mbox):
> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: 77313 <at> debbugs.gnu.org, juri <at> linkov.net
> Date: Wed, 16 Apr 2025 13:57:03 -0400
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> From: Spencer Baugh <sbaugh <at> janestreet.com>
> >> Date: Sat, 12 Apr 2025 07:43:11 -0400
> >> Cc: 77313 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
> >>
> >> On Sat, Apr 12, 2025, 7:13 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >>
> >> Thanks, installed on master.
> >>
> >> Should we now close this bug?
> >>
> >> No, we need to backport it to Emacs 30.2 to fix the regression.
> >
> > OK, but it cannot be cherry-picked as is, because it includes a NEWS
> > entry. So the fix for emacs-30, when we decide to install it, will
> > need to be a separate commit.
>
> OK, here is a version ready for backporting to emacs-30, with a NEWS
> entry appropriate for 30.2.
I don't understand: this seems to be identical to the commit on
master. Did you show a wrong patch?
What I had in mind was a change only to flymake.el, with "Do not
merge" in the commit log message, since you say this is basically a
bugfix. I see no reason to announce this in NEWS, let alone with an
entry that is identical to what we have on master.
What am I missing?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#77313
; Package
emacs
.
(Thu, 17 Apr 2025 20:24:05 GMT)
Full text and
rfc822 format available.
Message #80 received at 77313 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Cc: 77313 <at> debbugs.gnu.org, juri <at> linkov.net
>> Date: Wed, 16 Apr 2025 13:57:03 -0400
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> >> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> >> Date: Sat, 12 Apr 2025 07:43:11 -0400
>> >> Cc: 77313 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
>> >>
>> >> On Sat, Apr 12, 2025, 7:13 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>> >>
>> >> Thanks, installed on master.
>> >>
>> >> Should we now close this bug?
>> >>
>> >> No, we need to backport it to Emacs 30.2 to fix the regression.
>> >
>> > OK, but it cannot be cherry-picked as is, because it includes a NEWS
>> > entry. So the fix for emacs-30, when we decide to install it, will
>> > need to be a separate commit.
>>
>> OK, here is a version ready for backporting to emacs-30, with a NEWS
>> entry appropriate for 30.2.
>
> I don't understand: this seems to be identical to the commit on
> master. Did you show a wrong patch?
>
> What I had in mind was a change only to flymake.el, with "Do not
> merge" in the commit log message, since you say this is basically a
> bugfix. I see no reason to announce this in NEWS, let alone with an
> entry that is identical to what we have on master.
I see, that makes sense. OK, here's a patch like that.
[0001-Backport-fix-flymake-margin-indicator-fallback-logic.patch (text/x-patch, inline)]
From b111266fdc8411f0852088d9eaec22042e841a04 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh <at> janestreet.com>
Date: Thu, 17 Apr 2025 16:22:08 -0400
Subject: [PATCH] Backport: fix flymake margin indicator fallback logic
Backport 861e7f8b60e4bf076bf5991d25a22b3a012746bd to fix bug#77313, so
that fringe indicators are once again reliably the default on frames
that support them.
Do not merge to master.
* lisp/progmodes/flymake.el (flymake-indicator-type)
(flymake-mode): Fix margin fallback behavior.
---
lisp/progmodes/flymake.el | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/lisp/progmodes/flymake.el b/lisp/progmodes/flymake.el
index f8a294908ba..a9e15fbbb12 100644
--- a/lisp/progmodes/flymake.el
+++ b/lisp/progmodes/flymake.el
@@ -185,22 +185,23 @@ flymake-fringe-indicator-position
(const right-fringe)
(const :tag "No fringe indicators" nil)))
-(defcustom flymake-indicator-type (if (display-graphic-p)
- 'fringes
- 'margins)
+(defcustom flymake-indicator-type 'fringes
"Indicate which indicator type to use for display errors.
The value can be nil (don't indicate errors but just highlight them),
-fringes (use fringes) or margins (use margins)
+the symbol `fringes' (use fringes) or the symbol `margins' (use
+margins).
Difference between fringes and margin is that fringes support displaying
bitmaps on graphical displays and margins display text in a blank area
from current buffer that works in both graphical and text displays.
+Thus, even when `fringes' is selected, margins will still be used on
+text displays and also when fringes are disabled.
See Info node `Fringes' and Info node `(elisp)Display Margins'."
- :version "30.1"
+ :version "30.2"
:type '(choice (const :tag "Use Fringes" fringes)
- (const :tag "Use Margins "margins)
+ (const :tag "Use Margins" margins)
(const :tag "No indicators" nil)))
(defcustom flymake-margin-indicators-string
@@ -1393,6 +1394,13 @@ flymake-mode
(add-hook 'kill-buffer-hook 'flymake-kill-buffer-hook nil t)
(add-hook 'eldoc-documentation-functions 'flymake-eldoc-function t t)
+ (when (and (eq flymake-indicator-type 'fringes)
+ (not (cl-case flymake-fringe-indicator-position
+ (left-fringe (< 0 (nth 0 (window-fringes))))
+ (right-fringe (< 0 (nth 1 (window-fringes)))))))
+ ;; There are no fringes in the buffer, fallback to margins.
+ (setq-local flymake-indicator-type 'margins))
+
;; AutoResize margins.
(flymake--resize-margins)
--
2.39.3
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Sat, 19 Apr 2025 14:40:06 GMT)
Full text and
rfc822 format available.
Notification sent
to
Spencer Baugh <sbaugh <at> janestreet.com>
:
bug acknowledged by developer.
(Sat, 19 Apr 2025 14:40:07 GMT)
Full text and
rfc822 format available.
Message #85 received at 77313-done <at> debbugs.gnu.org (full text, mbox):
> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: 77313 <at> debbugs.gnu.org, juri <at> linkov.net
> Date: Thu, 17 Apr 2025 16:23:40 -0400
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Spencer Baugh <sbaugh <at> janestreet.com>
> >> Cc: 77313 <at> debbugs.gnu.org, juri <at> linkov.net
> >> Date: Wed, 16 Apr 2025 13:57:03 -0400
> >>
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> >> From: Spencer Baugh <sbaugh <at> janestreet.com>
> >> >> Date: Sat, 12 Apr 2025 07:43:11 -0400
> >> >> Cc: 77313 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
> >> >>
> >> >> On Sat, Apr 12, 2025, 7:13 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >> >>
> >> >> Thanks, installed on master.
> >> >>
> >> >> Should we now close this bug?
> >> >>
> >> >> No, we need to backport it to Emacs 30.2 to fix the regression.
> >> >
> >> > OK, but it cannot be cherry-picked as is, because it includes a NEWS
> >> > entry. So the fix for emacs-30, when we decide to install it, will
> >> > need to be a separate commit.
> >>
> >> OK, here is a version ready for backporting to emacs-30, with a NEWS
> >> entry appropriate for 30.2.
> >
> > I don't understand: this seems to be identical to the commit on
> > master. Did you show a wrong patch?
> >
> > What I had in mind was a change only to flymake.el, with "Do not
> > merge" in the commit log message, since you say this is basically a
> > bugfix. I see no reason to announce this in NEWS, let alone with an
> > entry that is identical to what we have on master.
>
> I see, that makes sense. OK, here's a patch like that.
Thanks, installed on emacs-30, and closing the bug.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 18 May 2025 11:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 28 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.