unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#33740: [PATCH] Customizable flymake mode-line indicator
@ 2018-12-14  9:19 Andrii Kolomoiets
  2019-01-04 20:27 ` João Távora
  0 siblings, 1 reply; 44+ messages in thread
From: Andrii Kolomoiets @ 2018-12-14  9:19 UTC (permalink / raw)
  To: 33740

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))




^ permalink raw reply related	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2018-12-14  9:19 bug#33740: [PATCH] Customizable flymake mode-line indicator Andrii Kolomoiets
@ 2019-01-04 20:27 ` João Távora
  2019-06-22 14:15   ` Štěpán Němec
                     ` (2 more replies)
  0 siblings, 3 replies; 44+ messages in thread
From: João Távora @ 2019-01-04 20:27 UTC (permalink / raw)
  To: Andrii Kolomoiets; +Cc: 33740

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





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-01-04 20:27 ` João Távora
@ 2019-06-22 14:15   ` Štěpán Němec
  2019-09-16 22:22   ` Lars Ingebrigtsen
  2020-12-29  2:12   ` Lars Ingebrigtsen
  2 siblings, 0 replies; 44+ messages in thread
From: Štěpán Němec @ 2019-06-22 14:15 UTC (permalink / raw)
  To: João Távora; +Cc: 33740, Andrii Kolomoiets


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

-- 
Štěpán





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-01-04 20:27 ` João Távora
  2019-06-22 14:15   ` Štěpán Němec
@ 2019-09-16 22:22   ` Lars Ingebrigtsen
  2019-09-17  6:09     ` Eli Zaretskii
  2019-09-17 14:07     ` João Távora
  2020-12-29  2:12   ` Lars Ingebrigtsen
  2 siblings, 2 replies; 44+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-16 22:22 UTC (permalink / raw)
  To: João Távora; +Cc: 33740, Andrii Kolomoiets

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





^ permalink raw reply related	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-09-16 22:22   ` Lars Ingebrigtsen
@ 2019-09-17  6:09     ` Eli Zaretskii
  2019-09-17 11:57       ` Lars Ingebrigtsen
  2019-09-17 14:07     ` João Távora
  1 sibling, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2019-09-17  6:09 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 33740, joaotavora, andreyk.mad

> 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.





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-09-17  6:09     ` Eli Zaretskii
@ 2019-09-17 11:57       ` Lars Ingebrigtsen
  2019-09-17 12:13         ` Eli Zaretskii
  0 siblings, 1 reply; 44+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-17 11:57 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 33740, joaotavora, andreyk.mad

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





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-09-17 11:57       ` Lars Ingebrigtsen
@ 2019-09-17 12:13         ` Eli Zaretskii
  2019-09-17 12:22           ` Lars Ingebrigtsen
  0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2019-09-17 12:13 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 33740, joaotavora, andreyk.mad

> 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.





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-09-17 12:13         ` Eli Zaretskii
@ 2019-09-17 12:22           ` Lars Ingebrigtsen
  2019-09-17 12:44             ` Eli Zaretskii
  0 siblings, 1 reply; 44+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-17 12:22 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 33740, joaotavora, andreyk.mad

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





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-09-17 12:22           ` Lars Ingebrigtsen
@ 2019-09-17 12:44             ` Eli Zaretskii
  2019-09-18 13:38               ` Lars Ingebrigtsen
  0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2019-09-17 12:44 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 33740, joaotavora, andreyk.mad

> 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.





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-09-16 22:22   ` Lars Ingebrigtsen
  2019-09-17  6:09     ` Eli Zaretskii
@ 2019-09-17 14:07     ` João Távora
  2019-09-18 13:40       ` Lars Ingebrigtsen
  1 sibling, 1 reply; 44+ messages in thread
From: João Távora @ 2019-09-17 14:07 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 33740, Andrii Kolomoiets

[-- 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 --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-09-17 12:44             ` Eli Zaretskii
@ 2019-09-18 13:38               ` Lars Ingebrigtsen
  2019-09-18 14:09                 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 44+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-18 13:38 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 33740, joaotavora, andreyk.mad

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





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-09-17 14:07     ` João Távora
@ 2019-09-18 13:40       ` Lars Ingebrigtsen
  2019-09-18 13:59         ` João Távora
  2019-09-18 14:02         ` Noam Postavsky
  0 siblings, 2 replies; 44+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-18 13:40 UTC (permalink / raw)
  To: João Távora; +Cc: 33740, Andrii Kolomoiets

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





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-09-18 13:40       ` Lars Ingebrigtsen
@ 2019-09-18 13:59         ` João Távora
  2019-09-19 15:39           ` Lars Ingebrigtsen
  2019-09-18 14:02         ` Noam Postavsky
  1 sibling, 1 reply; 44+ messages in thread
From: João Távora @ 2019-09-18 13:59 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 33740, Andrii Kolomoiets

[-- 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 --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-09-18 13:40       ` Lars Ingebrigtsen
  2019-09-18 13:59         ` João Távora
@ 2019-09-18 14:02         ` Noam Postavsky
  1 sibling, 0 replies; 44+ messages in thread
From: Noam Postavsky @ 2019-09-18 14:02 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 33740, João Távora, Andrii Kolomoiets

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





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-09-18 13:38               ` Lars Ingebrigtsen
@ 2019-09-18 14:09                 ` Lars Ingebrigtsen
  2019-09-19 15:28                   ` Lars Ingebrigtsen
  0 siblings, 1 reply; 44+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-18 14:09 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 33740, joaotavora, andreyk.mad

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





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-09-18 14:09                 ` Lars Ingebrigtsen
@ 2019-09-19 15:28                   ` Lars Ingebrigtsen
  2019-09-19 15:55                     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 44+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-19 15:28 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 33740, joaotavora, andreyk.mad

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





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-09-18 13:59         ` João Távora
@ 2019-09-19 15:39           ` Lars Ingebrigtsen
  2019-09-20 13:07             ` João Távora
  0 siblings, 1 reply; 44+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-19 15:39 UTC (permalink / raw)
  To: João Távora; +Cc: 33740, Andrii Kolomoiets

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





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-09-19 15:28                   ` Lars Ingebrigtsen
@ 2019-09-19 15:55                     ` Lars Ingebrigtsen
  2019-09-19 16:23                       ` Lars Ingebrigtsen
  0 siblings, 1 reply; 44+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-19 15:55 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 33740, joaotavora, andreyk.mad

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





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-09-19 15:55                     ` Lars Ingebrigtsen
@ 2019-09-19 16:23                       ` Lars Ingebrigtsen
  2019-09-19 17:26                         ` Eli Zaretskii
  0 siblings, 1 reply; 44+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-19 16:23 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 33740, joaotavora, andreyk.mad

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





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-09-19 16:23                       ` Lars Ingebrigtsen
@ 2019-09-19 17:26                         ` Eli Zaretskii
  2019-09-20 12:32                           ` Lars Ingebrigtsen
  0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2019-09-19 17:26 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 33740, joaotavora, andreyk.mad

> 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.





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-09-19 17:26                         ` Eli Zaretskii
@ 2019-09-20 12:32                           ` Lars Ingebrigtsen
  2019-09-20 13:06                             ` Eli Zaretskii
  0 siblings, 1 reply; 44+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-20 12:32 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 33740, joaotavora, andreyk.mad

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





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-09-20 12:32                           ` Lars Ingebrigtsen
@ 2019-09-20 13:06                             ` Eli Zaretskii
  2019-09-20 13:13                               ` Lars Ingebrigtsen
  0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2019-09-20 13:06 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 33740, joaotavora, andreyk.mad

> 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?





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-09-19 15:39           ` Lars Ingebrigtsen
@ 2019-09-20 13:07             ` João Távora
  2019-09-21  7:54               ` Lars Ingebrigtsen
  0 siblings, 1 reply; 44+ messages in thread
From: João Távora @ 2019-09-20 13:07 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 33740, Andrii Kolomoiets

[-- 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 --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-09-20 13:06                             ` Eli Zaretskii
@ 2019-09-20 13:13                               ` Lars Ingebrigtsen
  0 siblings, 0 replies; 44+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-20 13:13 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 33740, joaotavora, andreyk.mad

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





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-09-20 13:07             ` João Távora
@ 2019-09-21  7:54               ` Lars Ingebrigtsen
  2019-09-22 20:55                 ` Juri Linkov
  2019-09-23  9:25                 ` João Távora
  0 siblings, 2 replies; 44+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-21  7:54 UTC (permalink / raw)
  To: João Távora; +Cc: 33740, Andrii Kolomoiets

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





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-09-21  7:54               ` Lars Ingebrigtsen
@ 2019-09-22 20:55                 ` Juri Linkov
  2019-09-23  9:18                   ` João Távora
  2019-09-23  9:25                 ` João Távora
  1 sibling, 1 reply; 44+ messages in thread
From: Juri Linkov @ 2019-09-22 20:55 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 33740, João Távora, Andrii Kolomoiets

> 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))





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-09-22 20:55                 ` Juri Linkov
@ 2019-09-23  9:18                   ` João Távora
  2019-09-23 18:10                     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 44+ messages in thread
From: João Távora @ 2019-09-23  9:18 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Lars Ingebrigtsen, 33740, Andrii Kolomoiets

[-- 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 --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-09-21  7:54               ` Lars Ingebrigtsen
  2019-09-22 20:55                 ` Juri Linkov
@ 2019-09-23  9:25                 ` João Távora
  2019-09-23 18:11                   ` Lars Ingebrigtsen
  1 sibling, 1 reply; 44+ messages in thread
From: João Távora @ 2019-09-23  9:25 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 33740, Andrii Kolomoiets

[-- 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 --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-09-23  9:18                   ` João Távora
@ 2019-09-23 18:10                     ` Lars Ingebrigtsen
  0 siblings, 0 replies; 44+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-23 18:10 UTC (permalink / raw)
  To: João Távora; +Cc: 33740, Andrii Kolomoiets, Juri Linkov

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





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-09-23  9:25                 ` João Távora
@ 2019-09-23 18:11                   ` Lars Ingebrigtsen
  0 siblings, 0 replies; 44+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-23 18:11 UTC (permalink / raw)
  To: João Távora; +Cc: 33740, Andrii Kolomoiets

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





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2019-01-04 20:27 ` João Távora
  2019-06-22 14:15   ` Štěpán Němec
  2019-09-16 22:22   ` Lars Ingebrigtsen
@ 2020-12-29  2:12   ` Lars Ingebrigtsen
  2020-12-29  2:19     ` Lars Ingebrigtsen
  2 siblings, 1 reply; 44+ messages in thread
From: Lars Ingebrigtsen @ 2020-12-29  2:12 UTC (permalink / raw)
  To: João Távora; +Cc: 33740, Andrii Kolomoiets

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





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2020-12-29  2:12   ` Lars Ingebrigtsen
@ 2020-12-29  2:19     ` Lars Ingebrigtsen
  2020-12-29 13:52       ` João Távora
  2020-12-29 14:18       ` João Távora
  0 siblings, 2 replies; 44+ messages in thread
From: Lars Ingebrigtsen @ 2020-12-29  2:19 UTC (permalink / raw)
  To: João Távora; +Cc: 33740, Andrii Kolomoiets

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





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2020-12-29  2:19     ` Lars Ingebrigtsen
@ 2020-12-29 13:52       ` João Távora
  2020-12-29 14:14         ` Lars Ingebrigtsen
  2020-12-29 14:18       ` João Távora
  1 sibling, 1 reply; 44+ messages in thread
From: João Távora @ 2020-12-29 13:52 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 33740, Andrii Kolomoiets

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







^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2020-12-29 13:52       ` João Távora
@ 2020-12-29 14:14         ` Lars Ingebrigtsen
  0 siblings, 0 replies; 44+ messages in thread
From: Lars Ingebrigtsen @ 2020-12-29 14:14 UTC (permalink / raw)
  To: João Távora; +Cc: 33740, Andrii Kolomoiets

[-- 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

^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2020-12-29  2:19     ` Lars Ingebrigtsen
  2020-12-29 13:52       ` João Távora
@ 2020-12-29 14:18       ` João Távora
  2020-12-29 14:22         ` Lars Ingebrigtsen
  1 sibling, 1 reply; 44+ messages in thread
From: João Távora @ 2020-12-29 14:18 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 33740, Andrii Kolomoiets

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









^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2020-12-29 14:18       ` João Távora
@ 2020-12-29 14:22         ` Lars Ingebrigtsen
  2020-12-29 15:13           ` João Távora
  0 siblings, 1 reply; 44+ messages in thread
From: Lars Ingebrigtsen @ 2020-12-29 14:22 UTC (permalink / raw)
  To: João Távora; +Cc: 33740, Andrii Kolomoiets

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





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2020-12-29 14:22         ` Lars Ingebrigtsen
@ 2020-12-29 15:13           ` João Távora
  2020-12-30  3:22             ` Lars Ingebrigtsen
  0 siblings, 1 reply; 44+ messages in thread
From: João Távora @ 2020-12-29 15:13 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 33740, Andrii Kolomoiets

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





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2020-12-29 15:13           ` João Távora
@ 2020-12-30  3:22             ` Lars Ingebrigtsen
  2020-12-30  9:28               ` João Távora
  0 siblings, 1 reply; 44+ messages in thread
From: Lars Ingebrigtsen @ 2020-12-30  3:22 UTC (permalink / raw)
  To: João Távora; +Cc: 33740, Andrii Kolomoiets

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





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2020-12-30  3:22             ` Lars Ingebrigtsen
@ 2020-12-30  9:28               ` João Távora
  2020-12-30 20:16                 ` Eli Zaretskii
  0 siblings, 1 reply; 44+ messages in thread
From: João Távora @ 2020-12-30  9:28 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 33740, Andrii Kolomoiets

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





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2020-12-30  9:28               ` João Távora
@ 2020-12-30 20:16                 ` Eli Zaretskii
  2020-12-30 21:13                   ` João Távora
  0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2020-12-30 20:16 UTC (permalink / raw)
  To: João Távora; +Cc: larsi, 33740, andreyk.mad

> 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.





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2020-12-30 20:16                 ` Eli Zaretskii
@ 2020-12-30 21:13                   ` João Távora
  2020-12-31 14:05                     ` João Távora
  0 siblings, 1 reply; 44+ messages in thread
From: João Távora @ 2020-12-30 21:13 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 33740, Andrii Kolomoiets

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





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2020-12-30 21:13                   ` João Távora
@ 2020-12-31 14:05                     ` João Távora
  2021-01-01 10:56                       ` Lars Ingebrigtsen
  0 siblings, 1 reply; 44+ messages in thread
From: João Távora @ 2020-12-31 14:05 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 33740-done, Andrii Kolomoiets

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





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2020-12-31 14:05                     ` João Távora
@ 2021-01-01 10:56                       ` Lars Ingebrigtsen
  2021-01-02 11:27                         ` João Távora
  0 siblings, 1 reply; 44+ messages in thread
From: Lars Ingebrigtsen @ 2021-01-01 10:56 UTC (permalink / raw)
  To: João Távora; +Cc: 33740-done, Andrii Kolomoiets

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





^ permalink raw reply	[flat|nested] 44+ messages in thread

* bug#33740: [PATCH] Customizable flymake mode-line indicator
  2021-01-01 10:56                       ` Lars Ingebrigtsen
@ 2021-01-02 11:27                         ` João Távora
  0 siblings, 0 replies; 44+ messages in thread
From: João Távora @ 2021-01-02 11:27 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 33740, Andrii Kolomoiets

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






^ permalink raw reply	[flat|nested] 44+ messages in thread

end of thread, other threads:[~2021-01-02 11:27 UTC | newest]

Thread overview: 44+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-12-14  9:19 bug#33740: [PATCH] Customizable flymake mode-line indicator Andrii Kolomoiets
2019-01-04 20:27 ` João Távora
2019-06-22 14:15   ` Štěpán Němec
2019-09-16 22:22   ` Lars Ingebrigtsen
2019-09-17  6:09     ` Eli Zaretskii
2019-09-17 11:57       ` Lars Ingebrigtsen
2019-09-17 12:13         ` Eli Zaretskii
2019-09-17 12:22           ` Lars Ingebrigtsen
2019-09-17 12:44             ` Eli Zaretskii
2019-09-18 13:38               ` Lars Ingebrigtsen
2019-09-18 14:09                 ` Lars Ingebrigtsen
2019-09-19 15:28                   ` Lars Ingebrigtsen
2019-09-19 15:55                     ` Lars Ingebrigtsen
2019-09-19 16:23                       ` Lars Ingebrigtsen
2019-09-19 17:26                         ` Eli Zaretskii
2019-09-20 12:32                           ` Lars Ingebrigtsen
2019-09-20 13:06                             ` Eli Zaretskii
2019-09-20 13:13                               ` Lars Ingebrigtsen
2019-09-17 14:07     ` João Távora
2019-09-18 13:40       ` Lars Ingebrigtsen
2019-09-18 13:59         ` João Távora
2019-09-19 15:39           ` Lars Ingebrigtsen
2019-09-20 13:07             ` João Távora
2019-09-21  7:54               ` Lars Ingebrigtsen
2019-09-22 20:55                 ` Juri Linkov
2019-09-23  9:18                   ` João Távora
2019-09-23 18:10                     ` Lars Ingebrigtsen
2019-09-23  9:25                 ` João Távora
2019-09-23 18:11                   ` Lars Ingebrigtsen
2019-09-18 14:02         ` Noam Postavsky
2020-12-29  2:12   ` Lars Ingebrigtsen
2020-12-29  2:19     ` Lars Ingebrigtsen
2020-12-29 13:52       ` João Távora
2020-12-29 14:14         ` Lars Ingebrigtsen
2020-12-29 14:18       ` João Távora
2020-12-29 14:22         ` Lars Ingebrigtsen
2020-12-29 15:13           ` João Távora
2020-12-30  3:22             ` Lars Ingebrigtsen
2020-12-30  9:28               ` João Távora
2020-12-30 20:16                 ` Eli Zaretskii
2020-12-30 21:13                   ` João Távora
2020-12-31 14:05                     ` João Távora
2021-01-01 10:56                       ` Lars Ingebrigtsen
2021-01-02 11:27                         ` João Távora

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).