Subject: bug#77313: 30.1.50; Regression: flymake indicators are erroneously using margins

From: Spencer Baugh <[email-masked]>
Date: Fri, 28 Mar 2025 12:53:11 -0400

Eli Zaretskii <[email-masked]> writes:

>> From: Spencer Baugh <[email-masked]>
>> Cc: Eli Zaretskii <[email-masked]>,  [email-masked]
>> Date: Thu, 27 Mar 2025 16:34:16 -0400
>> 
>> Juri Linkov <[email-masked]> 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.