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: Wed, 02 Apr 2025 09:05:00 -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: 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.

Previous Next

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