GNU bug report logs -
#44689
28.0.50; Use appropriate face for Flymake unknown backend
Previous Next
Reported by: Protesilaos Stavrou <info <at> protesilaos.com>
Date: Mon, 16 Nov 2020 17:18:01 UTC
Severity: wishlist
Tags: fixed, patch
Found in version 28.0.50
Fixed in version 28.1
Done: Lars Ingebrigtsen <larsi <at> gnus.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 44689 in the body.
You can then email your comments to 44689 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#44689
; Package
emacs
.
(Mon, 16 Nov 2020 17:18:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Protesilaos Stavrou <info <at> protesilaos.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Mon, 16 Nov 2020 17:18:02 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)]
When Flymake has not yet checked the backend of a visited file it
displays a question mark on the mode line next to its lighter text.
This "?" indicator is fontified with the 'mode-line' face, which means
that it inherits properties such as ':box', ':background', and
potentially others.
The attached patch changes fontification to 'mode-line-emphasis', which
is a face that is specifically designed for drawing attention to such
indicators.
This allows users/themes to maintain a consistent presentation for their
mode lines, regardless of whether they are active or not.
The attached screenshots show the before and after states with all
themes disabled. Focus on the inactive mode line at the middle of the
screen.
If maintainers think that this change does not provide sufficient
emphasis, I would suggest we look into updating the specifications of
'mode-line-emphasis' instead of using an inappropriate face for
individual indicators.
What do you think?
Best regards,
Protesilaos
--
Protesilaos Stavrou
protesilaos.com
[0001-Use-appropriate-face-for-Flymake-unknown-backend.patch (text/x-patch, attachment)]
[flymake-unknown-backend-after.png (image/png, attachment)]
[flymake-unknown-backend-before.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44689
; Package
emacs
.
(Mon, 16 Nov 2020 22:21:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 44689 <at> debbugs.gnu.org (full text, mbox):
Protesilaos Stavrou <info <at> protesilaos.com> writes:
> The attached patch changes fontification to 'mode-line-emphasis', which
> is a face that is specifically designed for drawing attention to such
> indicators.
I'm not sure why it's useful to draw attention to this bit in the mode
line, though. Is that something users would find useful to have their
attentions drawn to?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44689
; Package
emacs
.
(Tue, 17 Nov 2020 05:39:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 44689 <at> debbugs.gnu.org (full text, mbox):
On 2020-11-16, 23:20 +0100, Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> Protesilaos Stavrou <info <at> protesilaos.com> writes:
>
>> The attached patch changes fontification to 'mode-line-emphasis', which
>> is a face that is specifically designed for drawing attention to such
>> indicators.
>
> I'm not sure why it's useful to draw attention to this bit in the mode
> line, though. Is that something users would find useful to have their
> attentions drawn to?
Perhaps João can answer your question (in cc).
The current design draws a lot of attention to itself when the modeline
is inactive, because it inherits the style of the active modeline---so
it gets a box property and a different background.
'mode-line-emphasis' just feels like a more suitable choice for a face,
if emphasis in the mode line is the ultimate goal. Otherwise I would
personally prefer no face whatsoever.
--
Protesilaos Stavrou
protesilaos.com
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44689
; Package
emacs
.
(Tue, 17 Nov 2020 09:21:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 44689 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Nov 17, 2020 at 5:38 AM Protesilaos Stavrou <info <at> protesilaos.com>
wrote:
> > I'm not sure why it's useful to draw attention to this bit in the mode
> > line, though. Is that something users would find useful to have their
> > attentions drawn to?
>
> Perhaps João can answer your question (in cc).
Thanks. I dunno, really. That '?' is placed whenever Flymake has
been activated but no suitable backend has been found, or no
backend has been found to answer suitably. This is an abnormal
situation. It points to some misconfiguration, in principle. Does
that merit "immediate attention"? I'd say "some attention", but
I'm ignorant of the policy and the associated face here, so I'll leave
this hair-splitting to you, and you have my blessing for choosing
a different face or even no face at all.
> 'mode-line-emphasis' just feels like a more suitable choice for a face,
> if emphasis in the mode line is the ultimate goal.
The ultimate goal is to have Flymake working. The `?` is something
you or some package you're using has misconfigured.
Lars, this reminds me of a bug report (completely forgot the number),
where the mode-line's indicators would become configurable via some
"format string" mini-language, or something like that. Maybe we should
take that up again, and maybe abandon the "format string" and make it
use the same kind of language used in mode-line-format itself. Regardless
of the simpler decision in this bug, it should allow, in principle, that
demanding users modify Flymake's mode-line indications to their
liking.
João
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44689
; Package
emacs
.
(Tue, 17 Nov 2020 09:48:03 GMT)
Full text and
rfc822 format available.
Message #17 received at 44689 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2020-11-17, 09:20 +0000, João Távora <joaotavora <at> gmail.com> wrote:
>> > I'm not sure why it's useful to draw attention to this bit in the mode
>> > line, though. Is that something users would find useful to have their
>> > attentions drawn to?
>>
>> Perhaps João can answer your question (in cc).
>
> Thanks. I dunno, really. That '?' is placed whenever Flymake has
> been activated but no suitable backend has been found, or no
> backend has been found to answer suitably. This is an abnormal
> situation. It points to some misconfiguration, in principle. Does
> that merit "immediate attention"? I'd say "some attention", but
> I'm ignorant of the policy and the associated face here, so I'll leave
> this hair-splitting to you, and you have my blessing for choosing
> a different face or even no face at all.
While you discuss the rest of the issue with Lars, just to point out
that the "?" is easy to get.
On 'emacs -Q':
(require 'flymake)
(setq flymake-start-on-flymake-mode nil)
Now visit an '*.el' file. Activate 'flymake-mode' and check the
modeline.
Screenshot attached.
Thanks again for your contributions!
--
Protesilaos Stavrou
protesilaos.com
[flymake-unknown-backend-emacs-q.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44689
; Package
emacs
.
(Tue, 17 Nov 2020 16:32:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 44689 <at> debbugs.gnu.org (full text, mbox):
Protesilaos Stavrou <info <at> protesilaos.com> writes:
> On 2020-11-17, 09:20 +0000, João Távora <joaotavora <at> gmail.com> wrote:
>
>>> > I'm not sure why it's useful to draw attention to this bit in the mode
>>> > line, though. Is that something users would find useful to have their
>>> > attentions drawn to?
>>>
>>> Perhaps João can answer your question (in cc).
>>
>> Thanks. I dunno, really. That '?' is placed whenever Flymake has
>> been activated but no suitable backend has been found, or no
>> backend has been found to answer suitably. This is an abnormal
>> situation. It points to some misconfiguration, in principle. Does
>> that merit "immediate attention"? I'd say "some attention", but
>> I'm ignorant of the policy and the associated face here, so I'll leave
>> this hair-splitting to you, and you have my blessing for choosing
>> a different face or even no face at all.
>
> While you discuss the rest of the issue with Lars, just to point out
> that the "?" is easy to get.
>
> On 'emacs -Q':
>
> (require 'flymake)
> (setq flymake-start-on-flymake-mode nil)
>
> Now visit an '*.el' file. Activate 'flymake-mode' and check the
> modeline.
Indeed, that's not a misconfiguration. But I'd say it's an edge case:
normally one does want to start checking when enabling flymake, I just
kept that option there for backward compatibility. I personally see no
use for it, do you?
João
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44689
; Package
emacs
.
(Wed, 18 Nov 2020 06:00:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 44689 <at> debbugs.gnu.org (full text, mbox):
On 2020-11-17, 16:30 +0000, João Távora <joaotavora <at> gmail.com> wrote:
>> [...]
>>
>> just to point out that the "?" is easy to get.
>>
>> On 'emacs -Q':
>>
>> (require 'flymake)
>> (setq flymake-start-on-flymake-mode nil)
>>
>> Now visit an '*.el' file. Activate 'flymake-mode' and check the
>> modeline.
>
> Indeed, that's not a misconfiguration. But I'd say it's an edge case:
> normally one does want to start checking when enabling flymake, I just
> kept that option there for backward compatibility. I personally see no
> use for it, do you?
The fact that the option exists means that some people might be using
it. Is there any immediate downside to keeping it around? Personally,
I am fine with any decision you may take and agree that it is not what
one would normally expect when activating 'flycheck-mode'.
What I wanted to suggest when I opened this issue is merely this: if
this "edge case" option remains present, please consider reviewing the
face it uses (with 'mode-line-emphasis' being more appropriate than
'mode-line').
--
Protesilaos Stavrou
protesilaos.com
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44689
; Package
emacs
.
(Wed, 18 Nov 2020 08:30:03 GMT)
Full text and
rfc822 format available.
Message #26 received at 44689 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Nov 18, 2020, 05:58 Protesilaos Stavrou <info <at> protesilaos.com>
wrote:
> On 2020-11-17, 16:30 +0000, João Távora <joaotavora <at> gmail.com> wrote:
>
> >> [...]
> >>
> >> just to point out that the "?" is easy to get.
> >>
> >> On 'emacs -Q':
> >>
> >> (require 'flymake)
> >> (setq flymake-start-on-flymake-mode nil)
> >>
> >> Now visit an '*.el' file. Activate 'flymake-mode' and check the
> >> modeline.
> >
> > Indeed, that's not a misconfiguration. But I'd say it's an edge case:
> > normally one does want to start checking when enabling flymake, I just
> > kept that option there for backward compatibility. I personally see no
> > use for it, do you?
>
> The fact that the option exists means that some people might be using
> it. Is there any immediate downside to keeping it around? Personally,
> I am fine with any decision you may take and agree that it is not what
> one would normally expect when activating 'flycheck-mode'.
>
> What I wanted to suggest when I opened this issue is merely this: if
> this "edge case" option remains present, please consider reviewing the
> face it uses (with 'mode-line-emphasis' being more appropriate than
> 'mode-line').
>
Yes, I am totally fine with changing the face, or using some other
character to indicate this situation. I just don't see it as super priority
because it's an odd setting to have, in my opinion, but patches welcome.
João
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44689
; Package
emacs
.
(Tue, 24 Nov 2020 05:19:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 44689 <at> debbugs.gnu.org (full text, mbox):
João Távora <joaotavora <at> gmail.com> writes:
> Lars, this reminds me of a bug report (completely forgot the number),
> where the mode-line's indicators would become configurable via some
> "format string" mini-language, or something like that. Maybe we should
> take that up again, and maybe abandon the "format string" and make it
> use the same kind of language used in mode-line-format itself.
Yes, it should be possible to basically allow the same customisations,
but have a different "backend" for `format-string' that generates mode
line constructs instead of a propertized string.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44689
; Package
emacs
.
(Tue, 24 Nov 2020 05:24:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 44689 <at> debbugs.gnu.org (full text, mbox):
João Távora <joaotavora <at> gmail.com> writes:
> Yes, I am totally fine with changing the face, or using some other
> character to indicate this situation. I just don't see it as super
> priority because it's an odd setting to have, in my opinion, but
> patches welcome.
I'm now just removed the face from the "?", which makes it look OK in
both active and inactive windows.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) fixed.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Tue, 24 Nov 2020 05:24:01 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 28.1, send any further explanations to
44689 <at> debbugs.gnu.org and Protesilaos Stavrou <info <at> protesilaos.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Tue, 24 Nov 2020 05:24:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 22 Dec 2020 12:24:10 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 258 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.