bug#33740: [PATCH] Customizable flymake mode-line indicator

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Andrii Kolomoiets]

Hi,

I would like to hide Flymake label in mode line leaving just counters.

Customizable mode line indicator like in this patch can solve my issue
and can help to those wanting to keep their mode line cleaner.


diff --git a/lisp/progmodes/flymake.el b/lisp/progmodes/flymake.el
index 7b100da..477abdd 100644
--- a/lisp/progmodes/flymake.el
+++ b/lisp/progmodes/flymake.el
@@ -220,6 +220,10 @@ Specifically, start it when the saved buffer is actually displayed."
   :version "26.1"
   :type 'boolean)

+(defcustom flymake-mode-line-indicator "Flymake"
+  "Mode label in mode-line."
+  :type 'string)
+
(when (fboundp 'define-fringe-bitmap)
   (define-fringe-bitmap 'flymake-double-exclamation-mark
     (vector #b00000000
@@ -1152,7 +1156,7 @@ default) no filter is applied."
                                       diags-by-type)))
                      (flymake--backend-state-diags state)))
              flymake--backend-state)
-    `((:propertize " Flymake"
+    `((:propertize ,(format " %s" flymake-mode-line-indicator)
                    mouse-face mode-line-highlight
                    help-echo
                    ,(concat (format "%s known backends\n" (length known))

bug#33740: [PATCH] Customizable flymake mode-line indicator

[João Távora]

Andrii Kolomoiets <andreyk.mad@gmail.com> writes:

> Hi,
>
> I would like to hide Flymake label in mode line leaving just counters.
>
> Customizable mode line indicator like in this patch can solve my issue
> and can help to those wanting to keep their mode line cleaner.
>
>
> diff --git a/lisp/progmodes/flymake.el b/lisp/progmodes/flymake.el
> index 7b100da..477abdd 100644
> --- a/lisp/progmodes/flymake.el
> +++ b/lisp/progmodes/flymake.el
> @@ -220,6 +220,10 @@ Specifically, start it when the saved buffer is actually displayed."
>    :version "26.1"
>    :type 'boolean)
>
> +(defcustom flymake-mode-line-indicator "Flymake"
> +  "Mode label in mode-line."
> +  :type 'string)
> +
> (when (fboundp 'define-fringe-bitmap)
>    (define-fringe-bitmap 'flymake-double-exclamation-mark
>      (vector #b00000000
> @@ -1152,7 +1156,7 @@ default) no filter is applied."
>                                        diags-by-type)))
>                       (flymake--backend-state-diags state)))
>               flymake--backend-state)
> -    `((:propertize " Flymake"
> +    `((:propertize ,(format " %s" flymake-mode-line-indicator)
>                     mouse-face mode-line-highlight
>                     help-echo
>                     ,(concat (format "%s known backends\n" (length known))

Looks good, though I would prefer if the defcustom was a format-string
where %s would be substituted by the error counts.  That way you could
even get rid of the braces or use something else.

João

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Štěpán Němec]

Could we have a fix for this installed already, please?

-- 
Štěpán

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Lars Ingebrigtsen]

João Távora <joaotavora@gmail.com> writes:

> Looks good, though I would prefer if the defcustom was a format-string
> where %s would be substituted by the error counts.  That way you could
> even get rid of the braces or use something else.

Below is a proof-of-this-concept-not-working when done via the normal
format-spec machinery.  :-)

I thought we could just put text properties on strings we feed to the
mode-line machinery, but it seems like these don't survive?  Do I
remember vaguely there being a long-running bug report about that
problem?  I thought it had been fixed by now.

Anybody remember?

diff --git a/lisp/progmodes/flymake.el b/lisp/progmodes/flymake.el
index 6d47c8bb17..00c941ca5d 100644
--- a/lisp/progmodes/flymake.el
+++ b/lisp/progmodes/flymake.el
@@ -1166,6 +1166,15 @@ flymake--mode-line-format
 
 (put 'flymake--mode-line-format 'risky-local-variable t)
 
+(defcustom flymake-mode-line-indicator-format " Flymake%s[%e %w %n]"
+  "Format to use for the Flymake mode line indicator.
+The following format characters can be used:
+
+%s: The status.
+%e: The number of errors.
+%w: The number of warnings.
+%n: The number of notes."
+  :type 'string)
 
 (defun flymake--mode-line-format ()
   "Produce a pretty minor mode indicator."
@@ -1183,71 +1192,74 @@ flymake--mode-line-format
                                       diags-by-type)))
                      (flymake--backend-state-diags state)))
              flymake--backend-state)
-    `((:propertize " Flymake"
-                   mouse-face mode-line-highlight
-                   help-echo
-                   ,(concat (format "%s known backends\n" (length known))
-                            (format "%s running\n" (length running))
-                            (format "%s disabled\n" (length disabled))
-                            "mouse-1: Display minor mode menu\n"
-                            "mouse-2: Show help for minor mode")
-                   keymap
-                   ,(let ((map (make-sparse-keymap)))
-                      (define-key map [mode-line down-mouse-1]
-                        flymake-menu)
-                      (define-key map [mode-line mouse-2]
-                        (lambda ()
-                          (interactive)
-                          (describe-function 'flymake-mode)))
-                      map))
-      ,@(pcase-let ((`(,ind ,face ,explain)
-                     (cond ((null known)
-                            '("?" mode-line "No known backends"))
-                           (some-waiting
-                            `("Wait" compilation-mode-line-run
-                              ,(format "Waiting for %s running backend(s)"
-                                       (length some-waiting))))
-                           (all-disabled
-                            '("!" compilation-mode-line-run
-                              "All backends disabled"))
-                           (t
-                            '(nil nil nil)))))
-          (when ind
-            `((":"
-               (:propertize ,ind
-                            face ,face
-                            help-echo ,explain
-                            keymap
-                            ,(let ((map (make-sparse-keymap)))
-                               (define-key map [mode-line mouse-1]
-                                 'flymake-switch-to-log-buffer)
-                               map))))))
-      ,@(unless (or all-disabled
-                    (null known))
-          (cl-loop
-           with types = (hash-table-keys diags-by-type)
-           with _augmented = (cl-loop for extra in '(:error :warning)
-                                      do (cl-pushnew extra types
-                                                     :key #'flymake--severity))
-           for type in (cl-sort types #'> :key #'flymake--severity)
-           for diags = (gethash type diags-by-type)
-           for face = (flymake--lookup-type-property type
-                                                     'mode-line-face
-                                                     'compilation-error)
-           when (or diags
-                    (cond ((eq flymake-suppress-zero-counters t)
-                           nil)
-                          (flymake-suppress-zero-counters
-                           (>= (flymake--severity type)
-                               (warning-numeric-level
-                                flymake-suppress-zero-counters)))
-                          (t t)))
-           collect `(:propertize
-                     ,(format "%d" (length diags))
-                     face ,face
-                     mouse-face mode-line-highlight
-                     keymap
-                     ,(let ((map (make-sparse-keymap))
+    (format-spec
+     (propertize flymake-mode-line-indicator-format
+                 'mouse-face 'mode-line-highlight
+                 'help-echo
+                 (concat (format "%s known backends\n" (length known))
+                         (format "%s running\n" (length running))
+                         (format "%s disabled\n" (length disabled))
+                         "mouse-1: Display minor mode menu\n"
+                         "mouse-2: Show help for minor mode")
+                 'keymap
+                 (let ((map (make-sparse-keymap)))
+                   (define-key map [mode-line down-mouse-1]
+                     flymake-menu)
+                   (define-key map [mode-line mouse-2]
+                     (lambda ()
+                       (interactive)
+                       (describe-function 'flymake-mode)))
+                   map))
+     (cons
+      (cons ?s (cl-destructuring-bind
+                   (ind face explain)
+                   (cond ((null known)
+                          '("?" mode-line "No known backends"))
+                         (some-waiting
+                          `("Wait" compilation-mode-line-run
+                            ,(format "Waiting for %s running backend(s)"
+                                     (length some-waiting))))
+                         (all-disabled
+                          '("!" compilation-mode-line-run
+                            "All backends disabled"))
+                         (t
+                          '(nil nil nil)))
+                 (when ind
+                   (concat
+                    ":"
+                    (propertize ind
+                                'face face
+                                'help-echo explain
+                                'keymap
+                                (let ((map (make-sparse-keymap)))
+                                  (define-key map [mode-line mouse-1]
+                                    'flymake-switch-to-log-buffer)
+                                  map))))))
+      (cl-loop
+       with types = (hash-table-keys diags-by-type)
+       with _augmented = (cl-loop for extra in '(:error :warning)
+                                  do (cl-pushnew extra types
+                                                 :key #'flymake--severity))
+       for type in (cl-sort types #'> :key #'flymake--severity)
+       for diags = (gethash type diags-by-type)
+       for face = (flymake--lookup-type-property type
+                                                 'mode-line-face
+                                                 'compilation-error)
+       when (or diags
+                (cond ((eq flymake-suppress-zero-counters t)
+                       nil)
+                      (flymake-suppress-zero-counters
+                       (>= (flymake--severity type)
+                           (warning-numeric-level
+                            flymake-suppress-zero-counters)))
+                      (t t)))
+       collect (cons (elt (format "%s" type) 1)
+                     (propertize
+                      (format "%d" (length diags))
+                      'face face
+                      'mouse-face 'mode-line-highlight
+                      'keymap
+                      (let ((map (make-sparse-keymap))
                             (type type))
                         (define-key map (vector 'mode-line
                                                 mouse-wheel-down-event)
@@ -1262,8 +1274,8 @@ flymake--mode-line-format
                             (with-selected-window (posn-window (event-start event))
                               (flymake-goto-next-error 1 (list type) t))))
                         map)
-                     help-echo
-                     ,(concat (format "%s diagnostics of type %s\n"
+                      'help-echo
+                      (concat (format "%s diagnostics of type %s\n"
                                       (propertize (format "%d"
                                                           (length diags))
                                                   'face face)
@@ -1271,14 +1283,7 @@ flymake--mode-line-format
                                                   'face face))
                               (format "%s/%s: previous/next of this type"
                                       mouse-wheel-down-event
-                                      mouse-wheel-up-event)))
-           into forms
-           finally return
-           `((:propertize "[")
-             ,@(cl-loop for (a . rest) on forms by #'cdr
-                        collect a when rest collect
-                        '(:propertize " "))
-             (:propertize "]")))))))
+                                      mouse-wheel-up-event)))))))))
 
 ;;; Diagnostics buffer
 

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Tue, 17 Sep 2019 00:22:08 +0200
> Cc: 33740@debbugs.gnu.org, Andrii Kolomoiets <andreyk.mad@gmail.com>
> 
> I thought we could just put text properties on strings we feed to the
> mode-line machinery, but it seems like these don't survive?

You need to do it "wisely", then they do survive.

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> I thought we could just put text properties on strings we feed to the
>> mode-line machinery, but it seems like these don't survive?
>
> You need to do it "wisely", then they do survive.

What does the wisdom entail?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: joaotavora@gmail.com,  33740@debbugs.gnu.org,  andreyk.mad@gmail.com
> Date: Tue, 17 Sep 2019 13:57:34 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I thought we could just put text properties on strings we feed to the
> >> mode-line machinery, but it seems like these don't survive?
> >
> > You need to do it "wisely", then they do survive.
> 
> What does the wisdom entail?

Apply the properties judiciously to specific parts of the mode-line
string, not wholesale to all of it.

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Apply the properties judiciously to specific parts of the mode-line
> string, not wholesale to all of it.

That's what I did (or tried to do).  I basically made the function
return something like

(concat "foo" (propertize "bar" 'face 'bold) "zot")

but the "bar" remained non-bold in the mode line.  If that's supposed to
work, then there's something else wrong with my code, I guess?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: joaotavora@gmail.com,  33740@debbugs.gnu.org,  andreyk.mad@gmail.com
> Date: Tue, 17 Sep 2019 14:22:27 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Apply the properties judiciously to specific parts of the mode-line
> > string, not wholesale to all of it.
> 
> That's what I did (or tried to do).  I basically made the function
> return something like
> 
> (concat "foo" (propertize "bar" 'face 'bold) "zot")
> 
> but the "bar" remained non-bold in the mode line.  If that's supposed to
> work, then there's something else wrong with my code, I guess?

Most probably, but a bare-bones minimal Lisp to run and investigate
will be appreciated.

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Most probably, but a bare-bones minimal Lisp to run and investigate
> will be appreciated.

Here's a simple one:

(setq my-format (concat " foo " (propertize " bar " 'face 'bold) " zot "))
(setq mode-line-format (append mode-line-format (list 'my-format)))

I get " foo bar zot " at the end of the mode line without any faces.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Most probably, but a bare-bones minimal Lisp to run and investigate
>> will be appreciated.
>
> Here's a simple one:
>
> (setq my-format (concat " foo " (propertize " bar " 'face 'bold) " zot "))
> (setq mode-line-format (append mode-line-format (list 'my-format)))
>
> I get " foo bar zot " at the end of the mode line without any faces.

I did something as radical as actually reading the doc string to
mode-line-format, and doing this

(put 'my-format 'risky-local-variable t)

makes this work as expected.  Then I guess I can proceed with the
original flymake feature implementation.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I did something as radical as actually reading the doc string to
> mode-line-format, and doing this
>
> (put 'my-format 'risky-local-variable t)
>
> makes this work as expected.  Then I guess I can proceed with the
> original flymake feature implementation.

But... no.

As a test case, go to any .el file in Emacs and say `M-x flymake-mode',
and you'll get a lighter in the minor modes in the mode lines saying
something like " Flymake[0 3 17]" or whatever.

Then try this:

(setq flymake--mode-line-format (concat (propertize " bar " 'face 'bold) "foo"))

Both "bar" and "foo" will be bold in the mode line.

(setq flymake--mode-line-format (concat "foo" (propertize " bar " 'face 'bold)))

Neither "foo" nor "bar" will be bold.

So it seems like whatever is computing the mode line is somehow copying
the faces from the first character in the lighter string and applies
them to the entire lighter?  Very confusing.

This does not happen outside of the minor modes in the mode line (i.e.,
if I add an element outside of the minor modes, text properties are not
overwritten this way).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Then try this:
>
> (setq flymake--mode-line-format (concat (propertize " bar " 'face 'bold) "foo"))
>
> Both "bar" and "foo" will be bold in the mode line.

I...  think I know why this is happening.

Mixing the two ways of specifying text properties isn't really allowed.

`mode-line-modes' has this:

 (:propertize
  ("" minor-mode-alist)
  mouse-face mode-line-highlight help-echo "Minor mode\nmouse-1: Display minor m
  ...

display_mode_element does this for strings:

	    Lisp_Object oprops, aelt;
	    oprops = Ftext_properties_at (make_fixnum (0), elt);

	    /* If the starting string's properties are not what
	       we want, translate the string.  Also, if the string
	       is risky, do that anyway.  */

	    if (NILP (Fequal (props, oprops)) || risky)
	      {
		/* If the starting string has properties,
		   merge the specified ones onto the existing ones.  */
		if (! NILP (oprops) && !risky)

So we basically do exactly what I was seeing -- overwrite the entire
string's text properties with the text property in the first character
of the string.

But!

This is only done if the string is inside a (:propertize ...) clause,
because this is only done of props is passed in, which (if I read the
code correctly) only happens if that's done.

But the code in that function could be clearer -- I don't really
understand why this is done at all.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> But the code in that function could be clearer -- I don't really
> understand why this is done at all.

		aelt = Fassoc (elt, mode_line_proptrans_alist, Qnil);
		if (! NILP (aelt) && !NILP (Fequal (props, XCDR (aelt))))
		  {
		    /* AELT is what we want.  Move it to the front
		       without consing.  */
		    elt = XCAR (aelt);
		    mode_line_proptrans_alist
		      = move_elt_to_front (aelt, mode_line_proptrans_alist);
		  }
		else
		  {
		    Lisp_Object tem;

		    /* If AELT has the wrong props, it is useless.
		       so get rid of it.  */


Oh, this entire thing is just so that we can maintain a cache of text
properties and avoid some consing?  And if we have a cache, then all the
characters in the element has to have the same text properties.  I
wonder whether all this is really warranted...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 33740@debbugs.gnu.org,  joaotavora@gmail.com,  andreyk.mad@gmail.com
> Date: Thu, 19 Sep 2019 18:23:01 +0200
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > But the code in that function could be clearer -- I don't really
> > understand why this is done at all.
> 
> 		aelt = Fassoc (elt, mode_line_proptrans_alist, Qnil);
> 		if (! NILP (aelt) && !NILP (Fequal (props, XCDR (aelt))))
> 		  {
> 		    /* AELT is what we want.  Move it to the front
> 		       without consing.  */
> 		    elt = XCAR (aelt);
> 		    mode_line_proptrans_alist
> 		      = move_elt_to_front (aelt, mode_line_proptrans_alist);
> 		  }
> 		else
> 		  {
> 		    Lisp_Object tem;
> 
> 		    /* If AELT has the wrong props, it is useless.
> 		       so get rid of it.  */
> 
> 
> Oh, this entire thing is just so that we can maintain a cache of text
> properties and avoid some consing?  And if we have a cache, then all the
> characters in the element has to have the same text properties.

Yes.

> I wonder whether all this is really warranted...

It is.  Redrawing the mode line is a very frequent redisplay thing, so
optimizing the heck out of it is justified.

That's what I meant when I said "wisely": you need to create faces in
advance, and take care to have each individual string you use to be of
a uniform face.  And don't use propertize.

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> It is.  Redrawing the mode line is a very frequent redisplay thing, so
> optimizing the heck out of it is justified.

In the simple case where the mode line element is a string, I can
definitely see that it's warranted.  In the Flymake case, where the
value is (:eval (flymake--mode-line-format)), which returns a long and
complex (:propertize) form that's then interpreted by this machinery --
it's pessimal.

> That's what I meant when I said "wisely": you need to create faces in
> advance, and take care to have each individual string you use to be of
> a uniform face.  And don't use propertize.

Most modes do not have dynamic lighters, and using (:propertize) forms
is a fine solution.  For something like Flymake, that updates its
lighter every time the mode line is redrawn, it just doesn't make much
sense.  If Flymake could just return a properly propertized string, then
that would be a lot more efficient (both cons-wise and time wise) having
it return this form (which I've lightly edited to elide the keymaps):

((:propertize " Flymake" mouse-face mode-line-highlight help-echo "3 known backends\n2 running\n1 disabled\nmouse-1: Display minor mode menu\nmouse-2: Show help for minor mode" keymap ...)
 (:propertize "[")
 (:propertize "0" face compilation-error mouse-face mode-line-highlight keymap ..
	      help-echo
	      #("0 diagnostics of type :error\nmouse-4/mouse-5: previous/next of this type" 0 1
		(face compilation-error)
		22 28
		(face compilation-error)))
 (:propertize " ")
 (:propertize "0" face compilation-warning mouse-face mode-line-highlight keymap ...
	      help-echo
	      #("0 diagnostics of type :warning\nmouse-4/mouse-5: previous/next of this type" 0 1
		(face compilation-warning)
		22 30
		(face compilation-warning)))
 (:propertize " ")
 (:propertize "14" face compilation-info mouse-face mode-line-highlight keymap ...
	      help-echo
	      #("14 diagnostics of type :note\nmouse-4/mouse-5: previous/next of this type" 0 2
		(face compilation-info)
		23 28
		(face compilation-info)))
 (:propertize "]"))

If there was a way to tell display_mode_element "don't do the caching
stuff on this element", then Flymake could just return a propertized
string and display_mode_element would have to do a whole lot less
processing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 33740@debbugs.gnu.org,  joaotavora@gmail.com,  andreyk.mad@gmail.com
> Date: Fri, 20 Sep 2019 14:32:00 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It is.  Redrawing the mode line is a very frequent redisplay thing, so
> > optimizing the heck out of it is justified.
> 
> In the simple case where the mode line element is a string, I can
> definitely see that it's warranted.  In the Flymake case, where the
> value is (:eval (flymake--mode-line-format)), which returns a long and
> complex (:propertize) form that's then interpreted by this machinery --
> it's pessimal.

No, it isn't.  If I'm not mistaken, we have bug reports regarding
flickering of mode lines, including under Flymake.

If we want to have a richer set of indicators for Flymake, may I
suggest considering alternative methods of indicating stuff, and
leaving the poor-old crammed mode line alone?

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> If we want to have a richer set of indicators for Flymake, may I
> suggest considering alternative methods of indicating stuff, and
> leaving the poor-old crammed mode line alone?

No, we don't want a richer set of indicators -- a user requested being
allowed to customise it (to remove stuff from it), and I tried to do
that via the `format-spec' machinery.

But that can't be used, since display_mode_element requires us to return
a complex list that it re-interprets instead of being able to just give
it a string that it'll display.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33740: [PATCH] Customizable flymake mode-line indicator

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]

On Mon, Sep 16, 2019 at 11:22 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:

> João Távora <joaotavora@gmail.com> writes:
>
> > Looks good, though I would prefer if the defcustom was a format-string
> > where %s would be substituted by the error counts.  That way you could
> > even get rid of the braces or use something else.
>
> Below is a proof-of-this-concept-not-working when done via the normal
> format-spec machinery.  :-)
>

Thanks, Lars.  I'm away from my emacs dev machine so I can't read
the diff very carefully, but if you want to risk it, go ahead and push,
because I
like the defcustom spec and I see you've kept the default. A short entry
in NEWS and the Flymake manual is probably worth it (but you can skip
the latter).

There are arbitrary errors levels in this flymake (not just error warning
and note). But those are the main ones and anyway we can always
add more format machinery later.

I see a lot of changed lines, but most of them are probably whitespace.
Is there some diff format which elides those?

João

[-- Attachment #2: Type: text/html, Size: 1603 bytes --]

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Lars Ingebrigtsen]

João Távora <joaotavora@gmail.com> writes:

> Thanks, Lars.  I'm away from my emacs dev machine so I can't read the
> diff very carefully, but if you want to risk it, go ahead and push,
> because I like the defcustom spec and I see you've kept the default. A
> short entry in NEWS and the Flymake manual is probably worth it (but
> you can skip the latter).

Well, it doesn't quite work yet, so it's a bit premature.  :-)

> There are arbitrary errors levels in this flymake (not just error warning 
> and note). But those are the main ones and anyway we can always
> add more format machinery later.

Hm, is there a list of all the error levels?  If not, I think the
approach I took in the patch is probably misguided (what with %e for
"error" and stuff).  

> I see a lot of changed lines, but most of them are probably whitespace.

Yes, it's mostly whitespace due to rearranging the way the strings are
computed.

> Is there some diff format which elides those?

I'm not sure?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33740: [PATCH] Customizable flymake mode-line indicator

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 1885 bytes --]

On Wed, Sep 18, 2019 at 2:40 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:

> João Távora <joaotavora@gmail.com> writes:
>
> > Thanks, Lars.  I'm away from my emacs dev machine so I can't read the
> > diff very carefully, but if you want to risk it, go ahead and push,
> > because I like the defcustom spec and I see you've kept the default. A
> > short entry in NEWS and the Flymake manual is probably worth it (but
> > you can skip the latter).
>
> Well, it doesn't quite work yet, so it's a bit premature.  :-)
>

I see, what's wrong with it?


> > There are arbitrary errors levels in this flymake (not just error
> warning
> > and note). But those are the main ones and anyway we can always
> > add more format machinery later.
>
> Hm, is there a list of all the error levels?  If not, I think the
> approach I took in the patch is probably misguided (what with %e for
> "error" and stuff).
>

There isn't a list of error levels, there are just severities. There are
some built-in flymake _categories_ linked to the symbols :error, :warning
and
:note that connect these symbols with some preset severity.

But flymake can work with annotations of arbitrary severities with some
user-specified meaning. Hence errors, warnings, notes etc are just
annotations of severities 3, 2, 1, respectively. This was tied to
warning-numeric-level, which predates flymake.

So I see "%e" as a shortcut for, say, "%3a" (number of annotations
of severity 3), which is no problem imo. "%na" is the thing that could
be implemented later...


> > I see a lot of changed lines, but most of them are probably whitespace.
>
> Yes, it's mostly whitespace due to rearranging the way the strings are
> computed.
>
> > Is there some diff format which elides those?
>
> I'm not sure?
>

I think git diff -w does something to that effect.

João Távora

[-- Attachment #2: Type: text/html, Size: 2891 bytes --]

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Lars Ingebrigtsen]

João Távora <joaotavora@gmail.com> writes:

>  Well, it doesn't quite work yet, so it's a bit premature.  :-)
>
> I see, what's wrong with it? 

I'm not sure -- there's something about the way Emacs renders the minor
mode lighters that doesn't quite preserve the text properties.  That'll
have to be fixed first...  if indeed that's the problem and I'm not just
doing something stupid here somehow.

> But flymake can work with annotations of arbitrary severities with some 
> user-specified meaning. Hence errors, warnings, notes etc are just
> annotations of severities 3, 2, 1, respectively. This was tied to 
> warning-numeric-level, which predates flymake.

Right, I see.  

> So I see "%e" as a shortcut for, say, "%3a" (number of annotations 
> of severity 3), which is no problem imo. "%na" is the thing that could
> be implemented later...

But the problem I see here is that the "unknown" annotations can't
really be specified in the format string and will therefore not be
shown.

If we have

(defvar flymake-mode-line-indicator-format " Flymake%s[%e %w %n]")

then we've enumerated all the annotations the user will ever see, and
new ones won't appear.

So I think specifying it on this detailed level isn't the path to go,
but instead we'll have

(defvar flymake-mode-line-indicator-format " Flymake%s[%a]")

where "%a" is "all the annotations".  I think that's flexible enough --
it doesn't allow the user to change the order of the annotations
individually, but I don't think that's really needed, either...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33740: [PATCH] Customizable flymake mode-line indicator

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 2683 bytes --]

On Thu, Sep 19, 2019 at 4:39 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:

>
> I'm not sure -- there's something about the way Emacs renders the minor
> mode lighters that doesn't quite preserve the text properties.  That'll
> have to be fixed first...  if indeed that's the problem and I'm not just
> doing something stupid here somehow.
>

OK. And this is what you're discussing with Eli in the side thread, I
suppose.


> > So I see "%e" as a shortcut for, say, "%3a" (number of annotations
> > of severity 3), which is no problem imo. "%na" is the thing that could
> > be implemented later...
>
> But the problem I see here is that the "unknown" annotations can't
> really be specified in the format string and will therefore not be
> shown.
>

...unless he sets flymake-mode-line-indicator-format buffer-locally
or globally or something.

And to be clear, he may not see them _summarized_ in the mode line,
which is not the same as saying he is not seeing them.

I think using non-standard severities should be possible
(that's why I added them), but reasonably rare, so I think the extra effort
of
changing flymake-mode-line-indicator-format for those cases is in
proportion.

But read to the end of the mail for another idea.

it doesn't allow the user to change the order of the annotations
> individually, but I don't think that's really needed, either...


On the contrary, I think this is what is requested. Not only change
the order,  but the display paraphernalia around it, for mode-line
loving users.

There is something that we might be forgetting, and which might bridge the
gap between our views.

Currently, notes (diagnostics of severity 1) are only shown in the mode-line
summary if they total >= 0. This is hardcoded, but the behaviour should be
configurable, too.

So, along with "%e" we should probably have something like "%!e". The
former would mean "replace with number of errors if this number is greater
than 0", the latter being "replace with number of errors, even if 0".

The default value for the proposed defcustom would be

"Flymake[%!e %!w %n]"

which mirrors the current behaviour. Now, supposing there are some
new annotations with arbitrary severities, we could use the non-! form
to include them and keep the default value working. Maybe "%>e"
could mean "put all annotations more severe than 3 here".  Or something
like that.

We should also do something about whitespace.  I lean towards
somehow(TM) munching whitespace so that "Flymake[%!e %!w %n]"
becomes "Flymake[42 42<no whitespace here>]" if there are 0 notes.

Hope this isn't becoming very complicated.

João.

[-- Attachment #2: Type: text/html, Size: 4140 bytes --]

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Lars Ingebrigtsen]

João Távora <joaotavora@gmail.com> writes:

> On Thu, Sep 19, 2019 at 4:39 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
>  I'm not sure -- there's something about the way Emacs renders the minor
>  mode lighters that doesn't quite preserve the text properties.  That'll
>  have to be fixed first...  if indeed that's the problem and I'm not just
>  doing something stupid here somehow.
>
> OK. And this is what you're discussing with Eli in the side thread, I suppose. 

Yes, and it doesn't seem like looks very positively on the possibility
of allowing the minor mode lighters of being strings with text
properties, so my suggested rewrite is a no-go.  But if we move the
status from the minor mode lighter to mode-line-process, then it'd
work...  And perhaps that's a more logical place, anyway?

> Currently, notes (diagnostics of severity 1) are only shown in the mode-line
> summary if they total >= 0. This is hardcoded, but the behaviour should be
> configurable, too.
>
> So, along with "%e" we should probably have something like "%!e". The 
> former would mean "replace with number of errors if this number is greater 
> than 0", the latter being "replace with number of errors, even if 0".
>
> The default value for the proposed defcustom would be
>
> "Flymake[%!e %!w %n]"

`format-spec' doesn't allow two-character specs, but %E/%e would work...

> which mirrors the current behaviour. Now, supposing there are some
> new annotations with arbitrary severities, we could use the non-! form
> to include them and keep the default value working. Maybe "%>e" 
> could mean "put all annotations more severe than 3 here".  Or something
> like that.

Having a spec for "all the rest of the annotations" is possible, but
seems a bit odd, interface wise...

> We should also do something about whitespace.  I lean towards 
> somehow(TM) munching whitespace so that "Flymake[%!e %!w %n]"
> becomes "Flymake[42 42<no whitespace here>]" if there are 0 notes.
>
> Hope this isn't becoming very complicated.

Only slightly.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Juri Linkov]

> But if we move the status from the minor mode lighter to mode-line-process,
> then it'd work...  And perhaps that's a more logical place, anyway?

A more logical place would be in the same place where errors
are displayed by compilation-mode, i.e. mode-line-process indeed.
From compile.el:

              (setq mode-line-process
                    '((:propertize ":%s" face compilation-mode-line-run)
                      compilation-mode-line-errors))

bug#33740: [PATCH] Customizable flymake mode-line indicator

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 652 bytes --]

On Sun, Sep 22, 2019 at 10:09 PM Juri Linkov <juri@linkov.net> wrote:

> > But if we move the status from the minor mode lighter to
> mode-line-process,
> > then it'd work...  And perhaps that's a more logical place, anyway?
>
> A more logical place would be in the same place where errors
> are displayed by compilation-mode, i.e. mode-line-process indeed.
>

+1 from me, no objections.  Indeed flymake is a kind of incremental
compilation, so it makes perfect sense... not least because I can't
possibly see the need of ever enabling flymake in a compilation-mode
buffer (but this is Emacs so I probably should shut up now...)

João

[-- Attachment #2: Type: text/html, Size: 1017 bytes --]

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Lars Ingebrigtsen]

João Távora <joaotavora@gmail.com> writes:

> +1 from me, no objections.  Indeed flymake is a kind of incremental 
> compilation, so it makes perfect sense... not least because I can't 
> possibly see the need of ever enabling flymake in a compilation-mode 
> buffer (but this is Emacs so I probably should shut up now...)

They can probably coexist, I think?  That is, both of them can add to
the variable buffer-locally.  Perhaps.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33740: [PATCH] Customizable flymake mode-line indicator

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 1517 bytes --]

On Sat, Sep 21, 2019 at 8:54 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:

>
> work...  And perhaps that's a more logical place, anyway?
>

Yup.

> The default value for the proposed defcustom would be
> >
> > "Flymake[%!e %!w %n]"
>
> `format-spec' doesn't allow two-character specs, but %E/%e would work...
>

Fine with me.


> > which mirrors the current behaviour. Now, supposing there are some
> > new annotations with arbitrary severities, we could use the non-! form
> > to include them and keep the default value working. Maybe "%>e"
> > could mean "put all annotations more severe than 3 here".  Or something
> > like that.
>
> Having a spec for "all the rest of the annotations" is possible, but
> seems a bit odd, interface wise...
>

It's really "all the annotations for which you selected a non-standard
severity", but they can be of many types. So the use case for this might
be smaller than you think.  Also, one reason I can think of for selecting
a non-standard severity for your custom diagnostic type might be precisely
to hide it from the mode-line.

And if 'format-spec' is ever enhanced to allow numeric stuff, then we can
fine tune %a into something like %<integer>a or something.

> We should also do something about whitespace.  I lean towards
> > somehow(TM) munching whitespace so that "Flymake[%!e %!w %n]"
> > becomes "Flymake[42 42<no whitespace here>]" if there are 0 notes.
> >
> > Hope this isn't becoming very complicated.
>
> Only slightly.  :-)


But is it complicated enough? :-)

[-- Attachment #2: Type: text/html, Size: 2663 bytes --]

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Lars Ingebrigtsen]

João Távora <joaotavora@gmail.com> writes:

> It's really "all the annotations for which you selected a non-standard 
> severity", but they can be of many types. So the use case for this might
> be smaller than you think.  Also, one reason I can think of for selecting 
> a non-standard severity for your custom diagnostic type might be precisely 
> to hide it from the mode-line.

Makes sense.  I'll try to implement this, but probably not right away.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Noam Postavsky]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Yes, it's mostly whitespace due to rearranging the way the strings are
> computed.
>
>> Is there some diff format which elides those?
>
> I'm not sure?

You can pass --ignore-all-space (aka -w) to git diff (although the
result might not work for git apply).

https://git-scm.com/docs/git-diff#Documentation/git-diff.txt--w

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Lars Ingebrigtsen]

João Távora <joaotavora@gmail.com> writes:

> Looks good, though I would prefer if the defcustom was a format-string
> where %s would be substituted by the error counts.  That way you could
> even get rid of the braces or use something else.

I've now altered format-spec to (optionally) return a list of strings,
which makes the previously proposed patch work, so I've now pushed it
(after rebasing it).  It seems to work fine in my test cases, but it
hasn't been tested extensively.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I've now altered format-spec to (optionally) return a list of strings,
> which makes the previously proposed patch work, so I've now pushed it
> (after rebasing it).  It seems to work fine in my test cases, but it
> hasn't been tested extensively.

(João, if you could have a look over the resulting code change (which is
mostly just indentation changes, but also changes a lot of the quoting),
that'd be nice.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33740: [PATCH] Customizable flymake mode-line indicator

[João Távora]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> I've now altered format-spec to (optionally) return a list of strings,
>> which makes the previously proposed patch work, so I've now pushed it
>> (after rebasing it).  It seems to work fine in my test cases, but it
>> hasn't been tested extensively.
>
> (João, if you could have a look over the resulting code change (which is
> mostly just indentation changes, but also changes a lot of the quoting),
> that'd be nice.)

The first thing I notice is that the indicator is completely gone.
I.e. I can't see any flymake indications in the mode-line.  Is that
intended, or am I doing something wrong?  Did you test this?

I tried with

   src/emacs -Q -f flymake-mode

Before your change, one sees error thingies in the mode-line, after your
change one doesn't.  Perhaps it wouldn't be a bad idea to revert and
stage these ideas in a side branch?

João

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Lars Ingebrigtsen]

[-- Attachment #1: Type: text/plain, Size: 398 bytes --]

João Távora <joaotavora@gmail.com> writes:

> The first thing I notice is that the indicator is completely gone.
> I.e. I can't see any flymake indications in the mode-line.  Is that
> intended, or am I doing something wrong?  Did you test this?
>
> I tried with
>
>    src/emacs -Q -f flymake-mode

Yes, my test case was

src/emacs -Q lisp/abbrev.el -f flymake-mode

And I get:


[-- Attachment #2: Type: image/png, Size: 13383 bytes --]

[-- Attachment #3: Type: text/plain, Size: 104 bytes --]


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33740: [PATCH] Customizable flymake mode-line indicator

[João Távora]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> I've now altered format-spec to (optionally) return a list of strings,
>> which makes the previously proposed patch work, so I've now pushed it
>> (after rebasing it).  It seems to work fine in my test cases, but it
>> hasn't been tested extensively.
>
> (João, if you could have a look over the resulting code change (which is
> mostly just indentation changes, but also changes a lot of the quoting),
> that'd be nice.)

I've just reverted the patch: it is seriously flawed.  I don't know if
"format-spec" allows this, but the previous indicators semantics were to
omit some counters (notably the notes counter) completely if the count
was 0.  This is why when opening the *scratch* buffer, which has 0
notes, the function you touched now exits non-locally with an error.

I'm not sure you've taken these details into account, and they're quite
an important feature that I don't think we can afford to lose.

So better put the patch in a side branch and decide if we want to
overhaul format-spec to allow for these things, or maybe just use the
more powerful existing mode-line language for this, perhaps breaking up
that big function into well-behaved pieces that users can compose.

Thanks,
João

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Lars Ingebrigtsen]

João Távora <joaotavora@gmail.com> writes:

> So better put the patch in a side branch and decide if we want to
> overhaul format-spec to allow for these things, or maybe just use the
> more powerful existing mode-line language for this, perhaps breaking up
> that big function into well-behaved pieces that users can compose.

Well, the request was for being able to customise the flymake mode-line
indicator, which isn't really feasible by asking the user to write mode
line specs.

But I don't really care one way or the other -- it's up to you, and I
won't pursue this matter any further.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33740: [PATCH] Customizable flymake mode-line indicator

[João Távora]

Tue, Dec 29, 2020 at 2:22 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
> João Távora <joaotavora@gmail.com> writes:
>
> > So better put the patch in a side branch and decide if we want to
> > overhaul format-spec to allow for these things, or maybe just use the
> > more powerful existing mode-line language for this, perhaps breaking up
> > that big function into well-behaved pieces that users can compose.
>
> Well, the request was for being able to customise the flymake mode-line
> indicator, which isn't really feasible by asking the user to write mode
> line specs.

How is it more feasible to ask her to write such customizations
inside a string than asking her to write the same customizations
in a symbolic expression?

> But I don't really care one way or the other -- it's up to you, and I
> won't pursue this matter any further.

I'm sorry, but the patch you pushed is crucially flawed, it simply
banishes the indicator in every file without diagnostics in the
"note" category.  This is plain to see in many Elisp files, but is
not only for Elisp, it affects Eglot and likely other uses that
rely on Flymake.  Since I don't know how to fix your "format-spec"
mini-language in the very short term, I hope you understand I
had to revert your patch.

In other words, the problem at hand doesn't get any simpler
just by choosing less powerful language. Either we make
the language more powerful, or we choose to solve a narrower
problem.

I don't understand your "don't care" comment.  You don't care
for enhancing format-spec to allow for conditional formattings.
Or you don't care for Flymake or what?

João

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Lars Ingebrigtsen]

João Távora <joaotavora@gmail.com> writes:

> How is it more feasible to ask her to write such customizations
> inside a string than asking her to write the same customizations
> in a symbolic expression?

Format spec strings is the common idiom for customising display stuff in
Emacs.

> I don't understand your "don't care" comment.  You don't care
> for enhancing format-spec to allow for conditional formattings.

Whether Flymake offers a way to customise the lighter (or not) is up to
you.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33740: [PATCH] Customizable flymake mode-line indicator

[João Távora]

On Wed, Dec 30, 2020 at 3:22 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
> João Távora <joaotavora@gmail.com> writes:
>
> > How is it more feasible to ask her to write such customizations
> > inside a string than asking her to write the same customizations
> > in a symbolic expression?
>
> Format spec strings is the common idiom for customising display stuff in
> Emacs.

Not all of this "stuff" obviously, only the fraction of it that is trivial.
Case in point, the very commonly customized mode-line.
I appreciate the effort to try to move this along, but if you'd
be more aware of Flymake's mode-line mechanics, you'd
see the format-spec function is underpowered currently

I mean, it _could_ become more powerful. See CL:FORMAT for
example (some love it, some hate it, I respect and use it on
occasion).  It could do the job easily, because it has conditional
formatting:

http://www.lispworks.com/documentation/HyperSpec/Body/22_cgb.htm

So, unless format spec grows something similar, it simply isn't the
tool for the job. What growth? See the end of:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33740#71

in this thread for a possible start.

> > I don't understand your "don't care" comment.  You don't care
> > for enhancing format-spec to allow for conditional formattings.
>
> Whether Flymake offers a way to customise the lighter (or not) is up to
> you.

I've started work on a `flymake-mode-line`  customizable var, where
users can add and removed pre-baked pieces to control the main
indicator, counters, brackets, etc.  If you're interested in enhancing
format-spec, let me know, else I'll continue this approach.

João

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Wed, 30 Dec 2020 09:28:22 +0000
> Cc: 33740@debbugs.gnu.org, Andrii Kolomoiets <andreyk.mad@gmail.com>
> 
> I mean, it _could_ become more powerful. See CL:FORMAT for
> example (some love it, some hate it, I respect and use it on
> occasion).  It could do the job easily, because it has conditional
> formatting:

The mode-line constructs also support conditionals, so I don't think I
follow you here.

bug#33740: [PATCH] Customizable flymake mode-line indicator

[João Távora]

On Wed, Dec 30, 2020 at 8:16 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: João Távora <joaotavora@gmail.com>
> > Date: Wed, 30 Dec 2020 09:28:22 +0000
> > Cc: 33740@debbugs.gnu.org, Andrii Kolomoiets <andreyk.mad@gmail.com>
> >
> > I mean, it _could_ become more powerful. See CL:FORMAT for
> > example (some love it, some hate it, I respect and use it on
> > occasion).  It could do the job easily, because it has conditional
> > formatting:
>
> The mode-line constructs also support conditionals, so I don't think I
> follow you here.

Yes, mode-line constructs are what I'm using right now and what
I'm going to use to give users an interface.  Lars was suggesting
that format strings are the preferred customization method, and they
could become an alternative. But currently, Emacs's format-spec
falls well short of what is required.  It could become more powerful,
like CL:FORMAT, or not. Until then, mode-line constructs.

João

bug#33740: [PATCH] Customizable flymake mode-line indicator

[João Távora]

I finally did this work.  Check it out in master.  If you think it's acceptable
we can bump the Flymake version to GNU Elpa.

Happy new year (soon at least),
João

On Wed, Dec 30, 2020 at 9:13 PM João Távora <joaotavora@gmail.com> wrote:
>
> On Wed, Dec 30, 2020 at 8:16 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > From: João Távora <joaotavora@gmail.com>
> > > Date: Wed, 30 Dec 2020 09:28:22 +0000
> > > Cc: 33740@debbugs.gnu.org, Andrii Kolomoiets <andreyk.mad@gmail.com>
> > >
> > > I mean, it _could_ become more powerful. See CL:FORMAT for
> > > example (some love it, some hate it, I respect and use it on
> > > occasion).  It could do the job easily, because it has conditional
> > > formatting:
> >
> > The mode-line constructs also support conditionals, so I don't think I
> > follow you here.
>
> Yes, mode-line constructs are what I'm using right now and what
> I'm going to use to give users an interface.  Lars was suggesting
> that format strings are the preferred customization method, and they
> could become an alternative. But currently, Emacs's format-spec
> falls well short of what is required.  It could become more powerful,
> like CL:FORMAT, or not. Until then, mode-line constructs.
>
> João



-- 
João Távora

bug#33740: [PATCH] Customizable flymake mode-line indicator

[Lars Ingebrigtsen]

João Távora <joaotavora@gmail.com> writes:

> I finally did this work.  Check it out in master.  If you think it's
> acceptable we can bump the Flymake version to GNU Elpa.

Sure; looks good.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33740: [PATCH] Customizable flymake mode-line indicator

[João Távora]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> João Távora <joaotavora@gmail.com> writes:
>
>> I finally did this work.  Check it out in master.  If you think it's
>> acceptable we can bump the Flymake version to GNU Elpa.
>
> Sure; looks good.

Done.  Bumped to Flymake to 1.1.0, should be in GNU Elpa soon.

João