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

From: Spencer Baugh <[email-masked]>
Date: Wed, 02 Apr 2025 09:05:00 -0400

Eli Zaretskii <[email-masked]> writes:

>> From: Spencer Baugh <[email-masked]>
>> Cc: [email-masked],  [email-masked]
>> Date: Tue, 01 Apr 2025 18:21:38 -0400
>> 
>> Eli Zaretskii <[email-masked]> writes:
>> 
>> >> From: Spencer Baugh <[email-masked]>
>> >> Cc: [email-masked],  [email-masked]
>> >> Date: Fri, 28 Mar 2025 12:53:11 -0400
>> >> 
>> >> Eli Zaretskii <[email-masked]> 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.