GNU bug report logs - #77313
30.1.50; Regression: flymake indicators are erroneously using margins

Previous Next

Full log

View this message in rfc822 format

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77313 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: bug#77313: 30.1.50; Regression: flymake indicators are erroneously using margins
Date: Fri, 28 Mar 2025 12:53:11 -0400

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.