auth-source-search: annoying messages

auth-source-search: annoying messages

[Miles Bader]

Recently, my message log is filled with stuff like:

   ...
   auth-source-search: found 0 results (max 1/1) in [object auth-source-backend "~/.authinfo.gpg" netrc "~/.authinfo.gpg" t t t auth-source-netrc-create auth-source-netrc-search] matching (:port "pop3" :user ... :host ... :max 1)
   auth-source-search: found 1 CACHED results matching (:max 1 :host ... :port ("119" "nntp"))
   ...

These messages don't seem useful to the user, and look like left-over
debugging code ... how about removing them before the release?

-Miles


-- 
Cannon, n. An instrument employed in the rectification of national boundaries.

Re: auth-source-search: annoying messages

[Ted Zlatanov]

On Thu, 17 Feb 2011 12:36:09 +0900 Miles Bader <miles.bader.fz@renesas.com> wrote: 

MB> Recently, my message log is filled with stuff like:
MB>    ...
MB>    auth-source-search: found 0 results (max 1/1) in [object
MB> auth-source-backend "~/.authinfo.gpg" netrc "~/.authinfo.gpg" t t t
MB> auth-source-netrc-create auth-source-netrc-search] matching (:port
MB> "pop3" :user ... :host ... :max 1)
MB>    auth-source-search: found 1 CACHED results matching (:max 1 :host ... :port ("119" "nntp"))
MB>    ...

MB> These messages don't seem useful to the user, and look like left-over
MB> debugging code ... how about removing them before the release?

Sorry about that.  It's off by default in the Gnus trunk now.

We can actually use something besides `message' to issue these notices.
It may be useful so the user can tell their authinfo files are being
searched.  Does Emacs have a way to do this, like progress-reporter but
less noisy?  A spinning icon or something in the modeline?  That would
be pretty nifty.

Thanks
Ted

Re: auth-source-search: annoying messages

[Michael Albinus]

Ted Zlatanov <tzz@lifelogs.com> writes:

> We can actually use something besides `message' to issue these notices.
> It may be useful so the user can tell their authinfo files are being
> searched.  Does Emacs have a way to do this, like progress-reporter but
> less noisy?  A spinning icon or something in the modeline?  That would
> be pretty nifty.

(setq pr (make-progress-reporter ""))
(while t (progress-reporter-update pr))

> Thanks
> Ted

Best regards, Michael.

Re: auth-source-search: annoying messages

[Ted Zlatanov]

On Thu, 17 Feb 2011 13:30:50 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> Ted Zlatanov <tzz@lifelogs.com> writes:
>> We can actually use something besides `message' to issue these notices.
>> It may be useful so the user can tell their authinfo files are being
>> searched.  Does Emacs have a way to do this, like progress-reporter but
>> less noisy?  A spinning icon or something in the modeline?  That would
>> be pretty nifty.

MA> (setq pr (make-progress-reporter ""))
MA> (while t (progress-reporter-update pr))

But that uses the minibuffer.  I was hoping for something less
noticeable, like `line-number-mode' but with the progress-reporter
spinner taking up one char width in the modeline.

Ted

Re: auth-source-search: annoying messages

[Michael Albinus]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I was hoping for something less noticeable, like `line-number-mode'
> but with the progress-reporter spinner taking up one char width in the
> modeline.

Nice idea. Could be "%/" (or similar) in `mode-line-format'. If
existing, progress-reporter spins in the modeline instead of the
minibuffer.

> Ted

Best regards, Michael.

make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters (was: auth-source-search: annoying messages)

[Ted Zlatanov]

On Thu, 17 Feb 2011 17:06:40 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I was hoping for something less noticeable, like `line-number-mode'
>> but with the progress-reporter spinner taking up one char width in the
>> modeline.

MA> Nice idea. Could be "%/" (or similar) in `mode-line-format'. If
MA> existing, progress-reporter spins in the modeline instead of the
MA> minibuffer.

How about (showing both proposed use cases)

(setq pr1 (make-progress-reporter 'modeline))
(setq pr4 (make-progress-reporter 'modeline 0 100))
(while t 
  (progress-reporter-update pr1)
  (progress-reporter-update pr4))

to work in conjunction with a %/ in the modeline?  The idea is that it
is guaranteed to be 1 or log10(max)+2 characters (non-numeric or
numeric) wide in this mode and it won't make any noise in the echo area.

Another suggestion for progress-reporter--pulse-characters for both
modeline and regular use: there are some Unicode glyphs which could be
used if the font supports them:
http://en.wikipedia.org/wiki/Harvey_Balls#Harvey_Balls_in_Unicode

Maybe progress-reporter--pulse-characters could be customizable with
some presets like the above.

Ted

Re: auth-source-search: annoying messages

[Stefan Monnier]

> We can actually use something besides `message' to issue these notices.
> It may be useful so the user can tell their authinfo files are being
> searched.

I don't think it's a good idea.  If we go down this path, we may also
want to add messages about "looking up gnus-secondary-methods",
"taking a look at gnus-nntp-server", ...


        Stefan

Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters

[Michael Albinus]

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

Ted Zlatanov <tzz@lifelogs.com> writes:

> How about (showing both proposed use cases)
>
> (setq pr1 (make-progress-reporter 'modeline))
> (setq pr4 (make-progress-reporter 'modeline 0 100))
> (while t 
>   (progress-reporter-update pr1)
>   (progress-reporter-update pr4))
>
> to work in conjunction with a %/ in the modeline?  The idea is that it
> is guaranteed to be 1 or log10(max)+2 characters (non-numeric or
> numeric) wide in this mode and it won't make any noise in the echo area.

As proof of concept the appended patch. I don't use a special "%/"
format in the modeline; instead of there is `mode-line-progress-reporter'
which can be placed somewhere in `mode-line-format' (I've done it after
`mode-line-remote').

You call

(setq pr (make-progress-reporter))
(while t (progress-reporter-update pr))

No text in `make-progress-reporter' would be the modeline indicator;
a text based progress reporter still writes in the minibuffer:

(setq pr (make-progress-reporter ""))
(while t (progress-reporter-update pr))

> Another suggestion for progress-reporter--pulse-characters for both
> modeline and regular use: there are some Unicode glyphs which could be
> used if the font supports them:
> http://en.wikipedia.org/wiki/Harvey_Balls#Harvey_Balls_in_Unicode
>
> Maybe progress-reporter--pulse-characters could be customizable with
> some presets like the above.

That's for later.

> Ted

Best regards, Michael.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 2481 bytes --]

=== modified file 'lisp/bindings.el'
--- lisp/bindings.el	2011-01-25 04:08:28 +0000
+++ lisp/bindings.el	2011-02-17 20:37:34 +0000
@@ -254,9 +254,13 @@
   "Mode-line flag to show if default-directory for current buffer is remote.")
 ;;;###autoload
 (put 'mode-line-remote 'risky-local-variable t)
-
 (make-variable-buffer-local 'mode-line-remote)
 
+(defvar mode-line-progress-reporter nil
+  "Mode-line control for spinning progress-reporter.")
+;;;###autoload
+(put 'mode-line-progress-reporter 'risky-local-variable t)
+
 ;; Actual initialization is below.
 (defvar mode-line-position nil
   "Mode-line control for displaying the position in the buffer.
@@ -326,6 +330,7 @@
 	 'mode-line-client
 	 'mode-line-modified
 	 'mode-line-remote
+	 'mode-line-progress-reporter
 	 'mode-line-frame-identification
 	 'mode-line-buffer-identification
 	 (propertize "   " 'help-echo help-echo)

=== modified file 'lisp/subr.el'
--- lisp/subr.el	2011-02-01 21:37:12 +0000
+++ lisp/subr.el	2011-02-17 21:31:24 +0000
@@ -3486,7 +3486,7 @@
 	    (>= value (car reporter))) ; For numerical reporter
     (progress-reporter-do-update reporter value)))
 
-(defun make-progress-reporter (message &optional min-value max-value
+(defun make-progress-reporter (&optional message min-value max-value
 				       current-value min-change min-time)
   "Return progress reporter object for use with `progress-reporter-update'.
 
@@ -3553,6 +3553,7 @@
 	 (min-value    (aref parameters 1))
 	 (max-value    (aref parameters 2))
 	 (text         (aref parameters 3))
+	 (min-time     (aref parameters 5))
 	 (current-time (float-time))
 	 (enough-time-passed
 	  ;; See if enough time has passed since the last update.
@@ -3591,10 +3592,20 @@
 	   (let ((index (mod (1+ (car reporter)) 4))
 		 (message-log-max nil))
 	     (setcar reporter index)
-	     (message "%s %s"
-		      text
-		      (aref progress-reporter--pulse-characters
-			    index)))))))
+	     (if text
+		 ;; Write into the minibuffer
+		 (message "%s %s"
+			  text
+			  (aref progress-reporter--pulse-characters
+				index))
+	       ;; Update modeline
+	       (let ((mode-line-progress-reporter
+		      (list (propertize
+			     (aref progress-reporter--pulse-characters index)
+			     'mouse-face 'mode-line-highlight)))
+		     mode-line-remote)
+		 (force-mode-line-update)
+		 (sit-for min-time t))))))))
 
 (defun progress-reporter-done (reporter)
   "Print reporter's message followed by word \"done\" in echo area."

Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters

[Tom Tromey]

>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:

Ted> I was hoping for something less noticeable, like `line-number-mode'
Ted> but with the progress-reporter spinner taking up one char width in the
Ted> modeline.

MA> Nice idea. Could be "%/" (or similar) in `mode-line-format'. If
MA> existing, progress-reporter spins in the modeline instead of the
MA> minibuffer.

[...]
Ted> Another suggestion for progress-reporter--pulse-characters for both
Ted> modeline and regular use: there are some Unicode glyphs which could be
Ted> used if the font supports them:
Ted> http://en.wikipedia.org/wiki/Harvey_Balls#Harvey_Balls_in_Unicode

How about propertizing the the mode-line so that the background color
changes from left to right as the task progresses?

Tom

Re: auth-source-search: annoying messages

[Ted Zlatanov]

On Thu, 17 Feb 2011 15:17:48 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> We can actually use something besides `message' to issue these notices.
>> It may be useful so the user can tell their authinfo files are being
>> searched.

SM> I don't think it's a good idea.  If we go down this path, we may also
SM> want to add messages about "looking up gnus-secondary-methods",
SM> "taking a look at gnus-nntp-server", ...

I don't mean to add messages but a less intrusive way to report
progress.  The rationale is the same as `make-progress-reporter' itself,
it's a general facility and not for auth-source.el specifically.  If it
supports icons, we could stack different ones to tell the user what's
going on.  So I proposed the 'modeline approach in a separate thread
here.

It would be nice if Gnus showed progress like that, actually.  There's
many Gnus parts that show numeric progress in the minibuffer
(e.g. nnimap downloads) that could be less noisy.

Ted

Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters

[Ted Zlatanov]

On Fri, 18 Feb 2011 07:47:00 -0700 Tom Tromey <tromey@redhat.com> wrote: 

>>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:
Ted> I was hoping for something less noticeable, like `line-number-mode'
Ted> but with the progress-reporter spinner taking up one char width in the
Ted> modeline.

MA> Nice idea. Could be "%/" (or similar) in `mode-line-format'. If
MA> existing, progress-reporter spins in the modeline instead of the
MA> minibuffer.

Tom> [...]
Ted> Another suggestion for progress-reporter--pulse-characters for both
Ted> modeline and regular use: there are some Unicode glyphs which could be
Ted> used if the font supports them:
Ted> http://en.wikipedia.org/wiki/Harvey_Balls#Harvey_Balls_in_Unicode

Tom> How about propertizing the the mode-line so that the background color
Tom> changes from left to right as the task progresses?

That would look really nice in a small area but the whole thing would be
annoying: it's a big area (the effect is distracting when magnified) and
the text may become illegible as the background changes.  So maybe the
`progress-reporter--pulse-characters' can be propertized with different
background colors instead.

Ted

Re: auth-source-search: annoying messages

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> It would be nice if Gnus showed progress like that, actually.  There's
> many Gnus parts that show numeric progress in the minibuffer
> (e.g. nnimap downloads) that could be less noisy.

Yeah, a general progress bar (in the mode line) would be really nice
when downloading things or generating a large summary buffer.  Showing
"25% done" (etc) in the echo area works, but it's kinda more distracting
than it needs to be.  (And overwrites any "real" messages that may be
displayed.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: auth-source-search: annoying messages

[Stefan Monnier]

SM> I don't think it's a good idea.  If we go down this path, we may also
SM> want to add messages about "looking up gnus-secondary-methods",
SM> "taking a look at gnus-nntp-server", ...
[...]
> It would be nice if Gnus showed progress like that, actually.  There's
> many Gnus parts that show numeric progress in the minibuffer
> (e.g. nnimap downloads) that could be less noisy.

Maybe I misunderstand: for me the authentication part is instantaneous,
which is why it doesn't seem to warrant any kind of progress indication.

The act of connecting does take time, but this one already has messages
telling me what's going on.
So maybe the issue is that your authentication steps somehow take up
more time?


        Stefan

Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters

[Michael Albinus]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Tom> How about propertizing the the mode-line so that the background color
> Tom> changes from left to right as the task progresses?

That would be an invasive patch: the modeline string is known only in
xdisp.c, and we would need to change it there.

> That would look really nice in a small area but the whole thing would be
> annoying: it's a big area (the effect is distracting when magnified) and
> the text may become illegible as the background changes.  So maybe the
> `progress-reporter--pulse-characters' can be propertized with different
> background colors instead.

The small appended patch allows alsy symbols as first argument of
`make-progress-reporter. If this argument is a string, the progress
reporter still uses the minibuffer. If the argument is a symbol (used in
`mode-line-format'), the respective part of the modeline is updated.

See the examples:

--8<---------------cut here---------------start------------->8---
;; Use harvey balls for progress.
(setq pr1 (make-progress-reporter 'mode-line-remote))
(let ((progress-reporter--pulse-characters
       '["\u25F7" "\u25F6" "\u25F5" "\u25F4"]))
  (while t (progress-reporter-update pr1)))
--8<---------------cut here---------------end--------------->8---

--8<---------------cut here---------------start------------->8---
;; Let the buffer name blink.
(setq pr2 (make-progress-reporter 'mode-line-buffer-identification))
(let ((progress-reporter--pulse-characters
       (vector '(:propertize "%12b" face mode-line-buffer-id)
	       '(:propertize "%12b" face font-lock-warning-face))))
    (while t (progress-reporter-update pr2)))
--8<---------------cut here---------------end--------------->8---

> Ted

Best regards, Michael.

Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters

[Michael Albinus]

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

Michael Albinus <michael.albinus@gmx.de> writes:

> The small appended patch allows alsy symbols as first argument of
> `make-progress-reporter. If this argument is a string, the progress
> reporter still uses the minibuffer. If the argument is a symbol (used in
> `mode-line-format'), the respective part of the modeline is updated.
>
> See the examples:
>
> ;; Use harvey balls for progress.
> (setq pr1 (make-progress-reporter 'mode-line-remote))
> (let ((progress-reporter--pulse-characters
>        '["\u25F7" "\u25F6" "\u25F5" "\u25F4"]))
>   (while t (progress-reporter-update pr1)))
>
> ;; Let the buffer name blink.
> (setq pr2 (make-progress-reporter 'mode-line-buffer-identification))
> (let ((progress-reporter--pulse-characters
>        (vector '(:propertize "%12b" face mode-line-buffer-id)
> 	       '(:propertize "%12b" face font-lock-warning-face))))
>     (while t (progress-reporter-update pr2)))

Oops, patch forgotten. Appended.

>> Ted

Best regards, Michael.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1318 bytes --]

*** /tmp/ediff2346l1x	2011-02-20 12:32:15.324458002 +0100
--- /home/albinus/src/emacs/lisp/subr.el	2011-02-20 12:16:16.294458002 +0100
***************
*** 3588,3600 ****
  		 (message "%s" text)))))
  	  ;; Pulsing indicator
  	  (enough-time-passed
! 	   (let ((index (mod (1+ (car reporter)) 4))
  		 (message-log-max nil))
  	     (setcar reporter index)
! 	     (message "%s %s"
! 		      text
! 		      (aref progress-reporter--pulse-characters
! 			    index)))))))
  
  (defun progress-reporter-done (reporter)
    "Print reporter's message followed by word \"done\" in echo area."
--- 3588,3608 ----
  		 (message "%s" text)))))
  	  ;; Pulsing indicator
  	  (enough-time-passed
! 	   (let ((index (mod (1+ (car reporter))
! 			     (length progress-reporter--pulse-characters)))
  		 (message-log-max nil))
  	     (setcar reporter index)
! 	     (if (stringp text)
! 		 ;; Write into the minibuffer
! 		 (message "%s %s"
! 			  text
! 			  (aref progress-reporter--pulse-characters index))
! 	       ;; Update modeline
! 	       (eval
! 		`(let (((make-local-variable ,text)
! 			(aref progress-reporter--pulse-characters index)))
! 		   (force-mode-line-update)
! 		   (sit-for 0)))))))))
  
  (defun progress-reporter-done (reporter)
    "Print reporter's message followed by word \"done\" in echo area."

Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters

[Tom Tromey]

Tom> How about propertizing the the mode-line so that the background color
Tom> changes from left to right as the task progresses?

Michael> That would be an invasive patch: the modeline string is known only in
Michael> xdisp.c, and we would need to change it there.

I think you could save the old mode line and replace it with an :eval
form that calls format-mode-line and then propertizes it.

I agree with Ted that it might not always be great.  But I was only
proposing it as a option, not as the only way.

Tom

Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters

[Michael Albinus]

Tom Tromey <tromey@redhat.com> writes:

> Tom> How about propertizing the the mode-line so that the background color
> Tom> changes from left to right as the task progresses?
>
> Michael> That would be an invasive patch: the modeline string is known only in
> Michael> xdisp.c, and we would need to change it there.
>
> I think you could save the old mode line and replace it with an :eval
> form that calls format-mode-line and then propertizes it.

Ah, yes. I was not aware of `format-mode-line'. It also works with my
proposed patch, and the following snippet:

--8<---------------cut here---------------start------------->8---
(defun blink-mode-line ()
  (let*	((pos (mod count (length mlf))))
    (setq count (1+ count))
    (concat (substring mlf 0 pos)
	    (propertize (substring mlf pos (1+ pos)) 'face '(:inverse-video t))
	    (substring mlf (1+ pos) (length mlf)))))

(setq count 0
      pr (make-progress-reporter 'mode-line-format))

(let ((mlf (format-mode-line mode-line-format t))
      (progress-reporter--pulse-characters (vector '(:eval (blink-mode-line)))))
  (while t (progress-reporter-update pr)))
--8<---------------cut here---------------end--------------->8---

> I agree with Ted that it might not always be great.  But I was only
> proposing it as a option, not as the only way.

Yes, it doesn't look so good.

> Tom

Best regards, Michael.

Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters

[Ted Zlatanov]

On Mon, 21 Feb 2011 19:54:21 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> Ah, yes. I was not aware of `format-mode-line'. It also works with my
MA> proposed patch, and the following snippet:
MA> (defun blink-mode-line ()
MA>   (let*	((pos (mod count (length mlf))))
MA>     (setq count (1+ count))
MA>     (concat (substring mlf 0 pos)
MA> 	    (propertize (substring mlf pos (1+ pos)) 'face '(:inverse-video t))
MA> 	    (substring mlf (1+ pos) (length mlf)))))

MA> (setq count 0
MA>       pr (make-progress-reporter 'mode-line-format))

MA> (let ((mlf (format-mode-line mode-line-format t))
MA>       (progress-reporter--pulse-characters (vector '(:eval (blink-mode-line)))))
MA>   (while t (progress-reporter-update pr)))

On Fri, 18 Feb 2011 17:33:16 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

SM> Ted wrote:
>> It would be nice if Gnus showed progress like that, actually.  There's
>> many Gnus parts that show numeric progress in the minibuffer
>> (e.g. nnimap downloads) that could be less noisy.

SM> Maybe I misunderstand: for me the authentication part is instantaneous,
SM> which is why it doesn't seem to warrant any kind of progress indication.

SM> The act of connecting does take time, but this one already has
SM> messages telling me what's going on.  So maybe the issue is that
SM> your authentication steps somehow take up more time?

But *if* it takes a long time that indicates problems.  The Secrets API
backend in auth-source.el, for instance, is much slower than the netrc
backend.

On Fri, 18 Feb 2011 14:04:14 -0800 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@lifelogs.com> writes:

>> It would be nice if Gnus showed progress like that, actually.  There's
>> many Gnus parts that show numeric progress in the minibuffer
>> (e.g. nnimap downloads) that could be less noisy.

LI> Yeah, a general progress bar (in the mode line) would be really nice
LI> when downloading things or generating a large summary buffer.  Showing
LI> "25% done" (etc) in the echo area works, but it's kinda more distracting
LI> than it needs to be.  (And overwrites any "real" messages that may be
LI> displayed.)

Can you try Michael's patch and example I cited and see if it works for
you?  I think it's OK and if you are happy with it, should go into
Emacs.

I brought the discussion back under this thread because the other one's
subject ("auth-source-search: annoying messages") was not as
appropriate.  Sorry for the confusion this may cause.

Thanks
Ted

Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Can you try Michael's patch and example I cited and see if it works for
> you?  I think it's OK and if you are happy with it, should go into
> Emacs.

I haven't tried the patch, but perhaps it could go in and then I could
try it?  :-)  I'm leaving for London tomorrow, so I'm just making a
quick sweep of the Gnus mail...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters

[Michael Albinus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>> Can you try Michael's patch and example I cited and see if it works for
>> you?  I think it's OK and if you are happy with it, should go into
>> Emacs.
>
> I haven't tried the patch, but perhaps it could go in and then I could
> try it?  :-)

I'm waiting, whether there is resistance to that change (Stefan?
Chong?). If there is no opposition, I'll install the patch next weekend
in the trunk.

> I'm leaving for London tomorrow, so I'm just making a quick sweep of
> the Gnus mail...

Have a nice time, and best regards, Michael.

Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters

[Ted Zlatanov]

On Wed, 23 Feb 2011 09:46:40 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> Lars Ingebrigtsen <larsi@gnus.org> writes:
>> Ted Zlatanov <tzz@lifelogs.com> writes:
>> 
>>> Can you try Michael's patch and example I cited and see if it works for
>>> you?  I think it's OK and if you are happy with it, should go into
>>> Emacs.
>> 
>> I haven't tried the patch, but perhaps it could go in and then I could
>> try it?  :-)

MA> I'm waiting, whether there is resistance to that change (Stefan?
MA> Chong?). If there is no opposition, I'll install the patch next weekend
MA> in the trunk.

Please do it sooner.  We can revert it, right?  And it doesn't break
anything AFAIK.  Maybe there could be a way, though, of testing for the
feature.  (featurep progress-reportert-modeline)?

Ted

Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters

[Michael Albinus]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Wed, 23 Feb 2011 09:46:40 +0100 Michael Albinus
> <michael.albinus@gmx.de> wrote:
>
> MA> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>> Ted Zlatanov <tzz@lifelogs.com> writes:
>>> 
>>>> Can you try Michael's patch and example I cited and see if it works for
>>>> you?  I think it's OK and if you are happy with it, should go into
>>>> Emacs.
>>> 
>>> I haven't tried the patch, but perhaps it could go in and then I could
>>> try it?  :-)
>
> MA> I'm waiting, whether there is resistance to that change (Stefan?
> MA> Chong?). If there is no opposition, I'll install the patch next weekend
> MA> in the trunk.
>
> Please do it sooner.  We can revert it, right?  And it doesn't break
> anything AFAIK.  Maybe there could be a way, though, of testing for the
> feature.  (featurep progress-reportert-modeline)?

OK, I'll try to collect the bits it for commit. A new feature might not
be necessary, `progress-reporter--pulse-characters' is new in Emacs 24
and you could check for it.

> Ted

Best regards, Michael.

Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters

[Ted Zlatanov]

On Wed, 23 Feb 2011 16:59:19 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Please do it sooner.  We can revert it, right?  And it doesn't break
>> anything AFAIK.  Maybe there could be a way, though, of testing for the
>> feature.  (featurep progress-reportert-modeline)?

MA> OK, I'll try to collect the bits it for commit. A new feature might not
MA> be necessary, `progress-reporter--pulse-characters' is new in Emacs 24
MA> and you could check for it.

That seems like a maintenance problem waiting to happen.  I'd rather
look for a new feature or function directly related to the patch.

Ted

Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters

[Chong Yidong]

Michael Albinus <michael.albinus@gmx.de> writes:

> I'm waiting, whether there is resistance to that change (Stefan?
> Chong?). If there is no opposition, I'll install the patch next
> weekend in the trunk.

I'm dubious about the idea.  The mode-line is supposed to show
information about one window, while the progress-reporter is a global
indicator, so conceptually it's not a good fit.

What do we do if the user switches windows while the progress reporter
is spinning?  Does the current window take over the spinning?  Or do
inactive mode-lines spin too?  (That would be annoying.)

Global indicators, especially transient ones, ought to use the echo
area.

Using the background of the echo area as a progress bar would be nice,
but that may need some redisplay engine changes.  (It won't be annoying
if the color changes are muted enough, and I believe there are many GUI
applications that do something similar.)

If that's too hard, how about reserving the first character in the echo
area for a spinner instead?

RE: make-progress-reporter suggestions: 'modeline and customizableprogress-reporter--pulse-characters

[Drew Adams]

> I'm dubious about the idea.  The mode-line is supposed to show
> information about one window, while the progress-reporter is a global
> indicator, so conceptually it's not a good fit.

FWIW, I'm not crazy about the idea either.  It should at least be optional
(under both program and user control).

(However, wrt mode-line info: a global minor mode can have a lighter, in which
case it will appear in all windows.)

> What do we do if the user switches windows while the progress reporter
> is spinning?  Does the current window take over the spinning?  Or do
> inactive mode-lines spin too?  (That would be annoying.)
> 
> Global indicators, especially transient ones, ought to use the echo
> area.

Hm. The echo area shows only when the minibuffer does not show.  Would this be
like `message' output, which is erased and doesn't come back, or would it resume
after being preempted by the minibuffer?  (I certainly hope it would not appear
during minibuffer input.)

In any case, why would this be a global indicator?  What if someone wants to
apply it to show the progress of more than one thing?  This sounds far too
general - akin to just an hourglass pointer.

If we really must have something like this, let it be limited to a particular
buffer (show the buffer if you're interested in following the progress; don't
show it when you don't want to see it).  Optionally show the buffer in a
separate frame - it could be as small as you like (e.g tooltip-like, with no
decoration).

And if it is done that way it could (if the appropriate data is available)
indicate relative progress - e.g. a tiny progress bar instead of a tiny spinner.

At least let this feature be configurable with different appearances to indicate
the (possibly simultaneous) progress of different things.

> Using the background of the echo area as a progress bar would be nice,
> but that may need some redisplay engine changes.  (It won't 
> be annoying if the color changes are muted enough, and I believe there 
> are many GUI applications that do something similar.)

Again, I would certainly want to be sure that it will go away when the
minibuffer is active.

Even in that case I don't think changing the background color is a good idea.
Some users might have a standalone minibuffer (+echo area) frame with their
chosen background, and they might even modify that background dynamically to
indicate other things.

The echo area is for punctual output to the user, not for longstanding display.
I think it is the wrong place for this kind of thing.  I would sooner see it in
a mode line than the echo area.  But I agree with you that it might not be
related to any particular existing window.

> If that's too hard, how about reserving the first character 
> in the echo area for a spinner instead?

Again, hopefully this would not affect the minibuffer.
That's my main concern here - touches pas au minibuffer.


FWIW - All in all, personally I would find this feature a distraction.  I would
be one user who would turn it off.  YAGNI.

Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters

[Ted Zlatanov]

On Wed, 23 Feb 2011 15:56:56 -0500 Chong Yidong <cyd@stupidchicken.com> wrote: 

CY> Michael Albinus <michael.albinus@gmx.de> writes:
>> I'm waiting, whether there is resistance to that change (Stefan?
>> Chong?). If there is no opposition, I'll install the patch next
>> weekend in the trunk.

CY> I'm dubious about the idea.  The mode-line is supposed to show
CY> information about one window, while the progress-reporter is a global
CY> indicator, so conceptually it's not a good fit.

My modeline has shown the time and the date for many years, so "global"
data is not unprecedented there.  I think it's the right place: always
present, unobtrusive, and won't interfere with normal echo area usage.

CY> What do we do if the user switches windows while the progress reporter
CY> is spinning?  Does the current window take over the spinning?  Or do
CY> inactive mode-lines spin too?  (That would be annoying.)

The active modeline should take over.  I don't know if Michael's patch
does that, I didn't check.

CY> Using the background of the echo area as a progress bar would be nice,
CY> but that may need some redisplay engine changes.  (It won't be annoying
CY> if the color changes are muted enough, and I believe there are many GUI
CY> applications that do something similar.)

I think it would be distracting.  The echo area is big and the user is
often looking for messages there.  The intent is to show progress
without noise in the echo area.

CY> If that's too hard, how about reserving the first character in the echo
CY> area for a spinner instead?

That could work but I think it would be distracting since regular
messages show up in the echo area too.  Really, the modeline seems like
the best place to me.  It "feels" like a classis GUI status bar.  Could
you try Michael's patch for yourself?

Since the modeline progress indicator will be disabled by default, I
think it's a low-risk improvement to Emacs.  It also requires no C-level
changes, I think.

Ted

Global indicators (was: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters)

[Julien Danjou]

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

On Wed, Feb 23 2011, Chong Yidong wrote:

> Global indicators, especially transient ones, ought to use the echo
> area.

This is a more general problem. There's no space for global indicator in
Emacs, e.g. display-time, erc-track etc "abuses" mode-line because they
have no other choice. Using the echo area which is transient does not
seems like the right thing to do.

Unless somone add a non transient part to it. That would be awesome.

> If that's too hard, how about reserving the first character in the echo
> area for a spinner instead?

Why not rather a full part of the echo area for all the global
indicators that should be there rather than in the mode-line?

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Wed, 23 Feb 2011 15:56:56 -0500
> Cc: ding@gnus.org, emacs-devel@gnu.org
> 
> Using the background of the echo area as a progress bar would be nice,
> but that may need some redisplay engine changes.

You mean, like ebrowse.el does?

Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> Michael Albinus <michael.albinus@gmx.de> writes:
>
>> I'm waiting, whether there is resistance to that change (Stefan?
>> Chong?). If there is no opposition, I'll install the patch next
>> weekend in the trunk.
>
> I'm dubious about the idea.  The mode-line is supposed to show
> information about one window, while the progress-reporter is a global
> indicator, so conceptually it's not a good fit.

The "Compiling" indicator is of the same nature, and nobody complained
about it yet.

-- 
David Kastrup

Re: Global indicators

[Chong Yidong]

Julien Danjou <julien@danjou.info> writes:

>> Global indicators, especially transient ones, ought to use the echo
>> area.
>
> This is a more general problem. There's no space for global indicator in
> Emacs, e.g. display-time, erc-track etc "abuses" mode-line because they
> have no other choice. Using the echo area which is transient does not
> seems like the right thing to do.
>
> Unless somone add a non transient part to it. That would be awesome.
>
>> If that's too hard, how about reserving the first character in the echo
>> area for a spinner instead?
>
> Why not rather a full part of the echo area for all the global
> indicators that should be there rather than in the mode-line?

I think this is a good idea.  How about putting such indicators on the
right-hand side of the echo area, justified to the right?  We could give
it a slightly less prominent face to distinguish it from ordinary echo
area messages.

One I can think of is that it might get confusing if echo area messages
start to overlap the indicator area (especially multi-line messages).
And how this would interact with the minibuffer is not clear.


One more thing: we could put a GTK spinner object (GtkSpinner) on the
right edge of the GTK tool bar.  I haven't looked into the details, but
the required code changes probably won't be too challenging.

Re: Global indicators

[Drew Adams]

> > Why not rather a full part of the echo area for all the global
> > indicators that should be there rather than in the mode-line?
> 
> I think this is a good idea.  How about putting such indicators on the
> right-hand side of the echo area, justified to the right?  We 
> could give it a slightly less prominent face to distinguish it
> from ordinary echo area messages.
> 
> One I can think of is that it might get confusing if echo 
> area messages start to overlap the indicator area (especially
> multi-line messages). And how this would interact with the
> minibuffer is not clear.

I think it's not such a great idea, for the reasons I gave before.  Just one
opinion.

> One more thing: we could put a GTK spinner object (GtkSpinner) on the
> right edge of the GTK tool bar.  I haven't looked into the 
> details, but the required code changes probably won't be too challenging.

That might be OK.  Why not find a way to use any animated GIFs (or free
equivalent) on the tool bar?  Code could then indicate whatever progress or
other activity it liked in whatever way it liked, changing the graphic as needed
etc.  (And a user who wasn't interested could hide the toolbar.)

Of course with such additions it wouldn't be just a tool bar anymore.  (That
would be OK by me...)

Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters

[Ted Zlatanov]

On Wed, 23 Feb 2011 19:05:43 -0500 Chong Yidong <cyd@stupidchicken.com> wrote: 

CY> Julien Danjou <julien@danjou.info> writes:

>> Why not rather a full part of the echo area for all the global
>> indicators that should be there rather than in the mode-line?

CY> I think this is a good idea.  How about putting such indicators on the
CY> right-hand side of the echo area, justified to the right?  We could give
CY> it a slightly less prominent face to distinguish it from ordinary echo
CY> area messages.

CY> One I can think of is that it might get confusing if echo area messages
CY> start to overlap the indicator area (especially multi-line messages).
CY> And how this would interact with the minibuffer is not clear.

...if only there was an area that doesn't overlap messages or the
minibuffer...  :) Really, looking at Emacs visually, I can't see any
other area more appropriate than the mode line.  Maybe the fringe area?
But the mode line has a chance to work in text mode too.  Only the echo
area can compete with that but with the other messages there it will
become visual spaghetti.

CY> One more thing: we could put a GTK spinner object (GtkSpinner) on the
CY> right edge of the GTK tool bar.  I haven't looked into the details, but
CY> the required code changes probably won't be too challenging.

...but that's worse!  A GTK spinner is not a part of the editor the user
can customize.  The user can't move it around or format it differently
or assign a different pulse character set to it.  And it won't work in
text mode.

I would prefer not to use the tool bar.  It steals vertical space and
(to me) serves no practical purpose.

On Wed, 23 Feb 2011 13:28:05 -0800 "Drew Adams" <drew.adams@oracle.com> wrote: 

DA> If we really must have something like this, let it be limited to a particular
DA> buffer (show the buffer if you're interested in following the progress; don't
DA> show it when you don't want to see it).  Optionally show the buffer in a
DA> separate frame - it could be as small as you like (e.g tooltip-like, with no
DA> decoration).

That's a LOT of work for a simple effect.  What's the benefit of more
than 1 spinning indicator in a single-threaded editor?  At best they are
distracting.  What's an example where it would be useful?

DA> FWIW - All in all, personally I would find this feature a distraction.  I would
DA> be one user who would turn it off.  YAGNI.

OK, so you're against it.  Why spend so much time giving suggestions for
something you won't use?

Ted

RE: make-progress-reporter suggestions: 'modeline and customizableprogress-reporter--pulse-characters

[Drew Adams]

> What's the benefit of more than 1 spinning indicator in a
> single-threaded editor?  At best they are
> distracting.  What's an example where it would be useful?

Uh, I thought this was supposed to be a kind of progress indicator, in
particular for an async process.  Forgive me for not reading the thread in
detail, if that's not the case.

But if that is the case, then can't you imagine wanting to know the status of
more than one activity in progress?  Whether those activities are carried out
truly in parallel is beside the point.  Surely you can launch more than one
process (grep, compile, download,...) and want to know the progress of each.
Whether things are done in one thread or 1000 seems irrelevant here.

Again, if I misunderstood the aim, milles excuses.

But we do agree about one thing, at least from the sound of it: "at _best_ they
are distracting".  Even with N=1, I would add.

> DA> FWIW - All in all, personally I would find this feature a 
> DA> distraction.  I would be one user who would turn it off.  YAGNI.
> 
> OK, so you're against it.  Why spend so much time giving 
> suggestions for something you won't use?

To prevent your co-opting and cluttering up the mode line, minibuffer, echo
area, etc. with a spinning, blinking, shining, sparkling, or flashing fishing
lure.

For that reason, my main argument has been for users to be able to turn it off.
But I would also like to see it kept out of such areas by default.  Making such
annoying bling an option, turned off by default, is fine with me, wherever you
might enjoy sticking it.

I suggested using a separate small buffer window/frame (no decoration, like a
tooltip), so the location could be wherever you want - and the indicator
wouldn't take over any of the important candidate spots named so far.  Just one
idea among many discussed.  None of them sound very good to me so far.

There's really no reason to give this a fixed, a priori position anywhere - it's
not logically associated with the fringe (no special line), the echo area (not
punctual feedback), the minibuffer, the toolbar, or a mode line.  It doesn't
necessarily belong anywhere in particular.  So my thought was to let the
location be programmable or user customizable - a separate frame.

Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters

[Chong Yidong]

Ted Zlatanov <tzz@lifelogs.com> writes:

> DA> If we really must have something like this, let it be limited to a
> DA> particular buffer (show the buffer if you're interested in
> DA> following the progress; don't show it when you don't want to see
> DA> it).  Optionally show the buffer in a separate frame - it could be
> DA> as small as you like (e.g tooltip-like, with no decoration).
>
> That's a LOT of work for a simple effect.  What's the benefit of more
> than 1 spinning indicator in a single-threaded editor?  At best they are
> distracting.  What's an example where it would be useful?

We could add a feature to progress reporters, optionally binding the
reporter to a specific buffer.  For the subset of uses of the progress
reporter that concern activities specific to a particular buffer, this
would allow the progress reporter to be used to update the mode-line for
windows showing that buffer.

That would solve the question of which mode-line to use for displaying
the spinner.  (It won't address the general problem of global
indicators, though.)

> ...if only there was an area that doesn't overlap messages or the
> minibuffer...  :) Really, looking at Emacs visually, I can't see any
> other area more appropriate than the mode line.  Maybe the fringe
> area?  But the mode line has a chance to work in text mode too.  Only
> the echo area can compete with that but with the other messages there
> it will become visual spaghetti.

One problem that our mode-lines are fairly bursting at the seams.  In
the Message buffer where I'm typing this, it's up 90 columns wide,
overflowing the available space on my 85-column Emacs frame.

Another problem is that when you have lots of windows, each with its own
mode-line, mode-lines become much less appealing locations for global
indicators.  Ideally, you want to be able to glance at the same spot on
the Emacs frame, regardless of which window is active.  (Using the
mode-line to show the date, battery life, etc. is problematic for the
same reason).

Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters

[Ted Zlatanov]

On Wed, 23 Feb 2011 21:01:35 -0500 Chong Yidong <cyd@stupidchicken.com> wrote: 

CY> Ted Zlatanov <tzz@lifelogs.com> writes:
DA> If we really must have something like this, let it be limited to a
DA> particular buffer (show the buffer if you're interested in
DA> following the progress; don't show it when you don't want to see
DA> it).  Optionally show the buffer in a separate frame - it could be
DA> as small as you like (e.g tooltip-like, with no decoration).
>> 
>> That's a LOT of work for a simple effect.  What's the benefit of more
>> than 1 spinning indicator in a single-threaded editor?  At best they are
>> distracting.  What's an example where it would be useful?

CY> We could add a feature to progress reporters, optionally binding the
CY> reporter to a specific buffer.  For the subset of uses of the progress
CY> reporter that concern activities specific to a particular buffer, this
CY> would allow the progress reporter to be used to update the mode-line for
CY> windows showing that buffer.

OK, let's do it that way.  Are you happy with the way Michael's patch
specifies it with %/?

>> ...if only there was an area that doesn't overlap messages or the
>> minibuffer...  :) Really, looking at Emacs visually, I can't see any
>> other area more appropriate than the mode line.  Maybe the fringe
>> area?  But the mode line has a chance to work in text mode too.  Only
>> the echo area can compete with that but with the other messages there
>> it will become visual spaghetti.

CY> One problem that our mode-lines are fairly bursting at the seams.  In
CY> the Message buffer where I'm typing this, it's up 90 columns wide,
CY> overflowing the available space on my 85-column Emacs frame.

CY> Another problem is that when you have lots of windows, each with its own
CY> mode-line, mode-lines become much less appealing locations for global
CY> indicators.  Ideally, you want to be able to glance at the same spot on
CY> the Emacs frame, regardless of which window is active.  (Using the
CY> mode-line to show the date, battery life, etc. is problematic for the
CY> same reason).

I see.  It's the curse of UI flexibility.  Thanks for explaining.  Do
you want me and Michael to revise the patch to add the multiple buffer
and anything else?  Or throw out the whole idea?

On Wed, 23 Feb 2011 17:27:12 -0800 "Drew Adams" <drew.adams@oracle.com> wrote: 

>> What's the benefit of more than 1 spinning indicator in a
>> single-threaded editor?  At best they are distracting.  What's an
>> example where it would be useful?

DA> Uh, I thought this was supposed to be a kind of progress indicator, in
DA> particular for an async process.  Forgive me for not reading the thread in
DA> detail, if that's not the case.

It's a general progress and activity indicator (in the first case with
numeric arguments, in the second case without them).  Please see
Michael's patch.

DA> But if that is the case, then can't you imagine wanting to know the status of
DA> more than one activity in progress?  Whether those activities are carried out
DA> truly in parallel is beside the point.  Surely you can launch more than one
DA> process (grep, compile, download,...) and want to know the progress of each.
DA> Whether things are done in one thread or 1000 seems irrelevant here.

I think it's visually cumbersome.  But I see Chong Yidong's point about
the modelines and will go with the multiple approach.

DA> But we do agree about one thing, at least from the sound of it: "at _best_ they
DA> are distracting".  Even with N=1, I would add.

DA> FWIW - All in all, personally I would find this feature a 
DA> distraction.  I would be one user who would turn it off.  YAGNI.
>> 
>> OK, so you're against it.  Why spend so much time giving 
>> suggestions for something you won't use?

DA> To prevent your co-opting and cluttering up the mode line, minibuffer, echo
DA> area, etc. with a spinning, blinking, shining, sparkling, or flashing fishing
DA> lure.

Whoa.  The proposal and Michael's patch require the user to specify %/
in the modeline format.  I'm trying to do something useful (indicate
progress in a compact way that doesn't interfere with the echo area's
contents), not "co-opt" anything.  You're overreacting.

Ted

Re: Global indicators

[Julien Danjou]

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

On Thu, Feb 24 2011, Chong Yidong wrote:

> One more thing: we could put a GTK spinner object (GtkSpinner) on the
> right edge of the GTK tool bar.  I haven't looked into the details, but
> the required code changes probably won't be too challenging.

Yeah, having Emacs widgets based on Gtk spinner and progress bars would
be awesome, in general.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Global indicators

[Miles Bader]

Julien Danjou <julien@danjou.info> writes:
>> One more thing: we could put a GTK spinner object (GtkSpinner) on the
>> right edge of the GTK tool bar.  I haven't looked into the details, but
>> the required code changes probably won't be too challenging.
>
> Yeah, having Emacs widgets based on Gtk spinner and progress bars would
> be awesome, in general.

I agree, but I'd kinda like them _without_ a toolbar too (I like shiny
little widgets in general, but the toolbar is a big waste of space)
... :]

-miles

-- 
Conservative, n. A statesman enamored of existing evils, as opposed to a
Liberal, who wants to replace them with new ones.

Re: Global indicators

[Julien Danjou]

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

On Thu, Feb 24 2011, Miles Bader wrote:

> I agree, but I'd kinda like them _without_ a toolbar too (I like shiny
> little widgets in general, but the toolbar is a big waste of space)
> ... :]

Ah right. I just realize it seems no GTK widgets are used in buffer. Has
anyone ever tried to replace the various widgets (e.g. the buttons used
by custom), with GTK+ ones?

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Global indicators

[David Kastrup]

Julien Danjou <julien@danjou.info> writes:

> On Thu, Feb 24 2011, Chong Yidong wrote:
>
>> One more thing: we could put a GTK spinner object (GtkSpinner) on the
>> right edge of the GTK tool bar.  I haven't looked into the details, but
>> the required code changes probably won't be too challenging.
>
> Yeah, having Emacs widgets based on Gtk spinner and progress bars would
> be awesome, in general.

Perhaps it is an indication of my progressed age that I can't reliably
tell whether you are being sarcastic.

-- 
David Kastrup

Re: Global indicators

[joakim]

Julien Danjou <julien@danjou.info> writes:

> On Thu, Feb 24 2011, Miles Bader wrote:
>
>> I agree, but I'd kinda like them _without_ a toolbar too (I like shiny
>> little widgets in general, but the toolbar is a big waste of space)
>> ... :]
>
> Ah right. I just realize it seems no GTK widgets are used in buffer. Has
> anyone ever tried to replace the various widgets (e.g. the buttons used
> by custom), with GTK+ ones?

I have a branch on savannah called "xwidget" which allows for that sort
of thing. I had a look the other day at it again and it worked worse
than usual though for some reason. Its none-trivial and theres a readme
in the branch that explains why.

-- 
Joakim Verona

Re: Global indicators

[Julien Danjou]

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

On Thu, Feb 24 2011, David Kastrup wrote:

> Perhaps it is an indication of my progressed age that I can't reliably
> tell whether you are being sarcastic.

Hehe. I was not.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters

[Ted Zlatanov]

On Wed, 23 Feb 2011 23:53:24 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Chong Yidong <cyd@stupidchicken.com>
>> Date: Wed, 23 Feb 2011 15:56:56 -0500
>> Cc: ding@gnus.org, emacs-devel@gnu.org
>> 
>> Using the background of the echo area as a progress bar would be nice,
>> but that may need some redisplay engine changes.

EZ> You mean, like ebrowse.el does?

I tried it:

(dotimes (i 100)
  (sleep-for 1)
  (ebrowse-show-progress (format "%d" i)))

It seems pretty good to me.  It still interferes with regular mesages,
though.  So maybe it should be (optionally) used by
make-progress-reporter but it's not as good as a user-specified location
in the modeline.

Ted

Re: Global indicators

[Ted Zlatanov]

On Wed, 23 Feb 2011 19:05:43 -0500 Chong Yidong <cyd@stupidchicken.com> wrote: 

CY> Julien Danjou <julien@danjou.info> writes:
>> Why not rather a full part of the echo area for all the global
>> indicators that should be there rather than in the mode-line?

CY> I think this is a good idea.  How about putting such indicators on the
CY> right-hand side of the echo area, justified to the right?  We could give
CY> it a slightly less prominent face to distinguish it from ordinary echo
CY> area messages.

You know you're reinventing the icon tray, right? :)

Ted

Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters

[Stefan Monnier]

> OK, let's do it that way.  Are you happy with the way Michael's patch
> specifies it with %/?

I don't think we need a C-level change for this feature, so no %/.
Instead, we should use a Lisp variable.

CY> Another problem is that when you have lots of windows, each with its own
CY> mode-line, mode-lines become much less appealing locations for global
CY> indicators.  Ideally, you want to be able to glance at the same spot on
CY> the Emacs frame, regardless of which window is active.  (Using the
CY> mode-line to show the date, battery life, etc. is problematic for the
CY> same reason).

Yes, to me *that* is the problem with the global indicators: Emacs does
not have a "global" anything in general: it may have several frames,
none of which is more important than the other.

So I think the way to add global indicators will have to go through an
indirection: create a global thingy, and then let the user decide where
to display it (e.g. I'd display it in my minibuffer-only frame), and of
course it will sometimes be displayed more than once (e.g. I have one
minibuffer-only frame per display).


        Stefan

Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters

[Drew Adams]

> Yes, to me *that* is the problem with the global indicators: 
> Emacs does not have a "global" anything in general: it may
> have several frames, none of which is more important than the other.

Some might be more important to a program or user, but yes, there is little way
to enforce or demonstrate such intention.

One thing that might be nice, if possible (depends perhaps on the window mgr)
would be to have a frame parameter (or other way to specify) to make a frame be
"always on top" - at least relative to frames that don't specify this (i.e.
maybe no specified order among the always-on-top frames).  And perhaps there
could be a choice between on top wrt other Emacs frames and on top wrt
window-mgr windows in general.

Since you can put nearly anything you like in a frame (subtle/gaudy, small/large
animated/still), and some frames (e.g. tooltips) can even dispense with
decoration (title bar etc.), this would enable lots of kinds (appearances) of
global thingies.  Their positions and appearances could be controlled at will -
completely open.

> So I think the way to add global indicators will have to go through an
> indirection: create a global thingy,

I'd say global thingies, unless you meant create a global thingy _type_, which
could be instantiated for multiple thingies (instances).

Again, a frame comes close, and being able to make a frame stay visible (on
top)would help.

> and then let the user decide where to display it

it -> them (would be my suggestion)

Global indicators (was: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters)

[Ted Zlatanov]

On Thu, 24 Feb 2011 11:55:10 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> OK, let's do it that way.  Are you happy with the way Michael's patch
>> specifies it with %/?

SM> I don't think we need a C-level change for this feature, so no %/.
SM> Instead, we should use a Lisp variable.

That's fine.

CY> Another problem is that when you have lots of windows, each with its own
CY> mode-line, mode-lines become much less appealing locations for global
CY> indicators.  Ideally, you want to be able to glance at the same spot on
CY> the Emacs frame, regardless of which window is active.  (Using the
CY> mode-line to show the date, battery life, etc. is problematic for the
CY> same reason).

SM> Yes, to me *that* is the problem with the global indicators: Emacs does
SM> not have a "global" anything in general: it may have several frames,
SM> none of which is more important than the other.

SM> So I think the way to add global indicators will have to go through an
SM> indirection: create a global thingy, and then let the user decide where
SM> to display it (e.g. I'd display it in my minibuffer-only frame), and of
SM> course it will sometimes be displayed more than once (e.g. I have one
SM> minibuffer-only frame per display).

Are you going to propose an API and some specifics of what functionality
these indicators will offer and where and how they can be attached, or
do you want me and Michael to come up with something?

I really hope we make the indicators text-based so they work in text mode.

Thanks
Ted

Re: Global indicators

[Michael Albinus]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Thu, 24 Feb 2011 11:55:10 -0500 Stefan Monnier
> <monnier@iro.umontreal.ca> wrote:
>
>>> OK, let's do it that way.  Are you happy with the way Michael's patch
>>> specifies it with %/?
>
> SM> I don't think we need a C-level change for this feature, so no %/.
> SM> Instead, we should use a Lisp variable.
>
> That's fine.

My latest version of the patch didn't use the "%/" formatter. Instead
of, I did allow to specify a symbol, which would get the rotating values
of `progress-reporter--pulse-characters'. This symbol could be part of
`mode-line-format', but this is not mandatory.

I gave two examples, where it would make sense to use the modeline
instead of the echo area:

* You could change `mode-line-remote' by a spinning character, indicating
  that Tramp is busy, not dead.

* You could replace the face of `mode-line-buffer-identification',
  indicating some actions in the corresponding buffer.

But of course, it might be better to indicate also other places for
indicators but echo area and modeline.

> CY> Another problem is that when you have lots of windows, each with its own
> CY> mode-line, mode-lines become much less appealing locations for global
> CY> indicators.  Ideally, you want to be able to glance at the same spot on
> CY> the Emacs frame, regardless of which window is active.  (Using the
> CY> mode-line to show the date, battery life, etc. is problematic for the
> CY> same reason).

I agree that we shall not add more indicators to the modeline. But
animating existing ones might be useful.

> Are you going to propose an API and some specifics of what functionality
> these indicators will offer and where and how they can be attached, or
> do you want me and Michael to come up with something?

Same question here.

> I really hope we make the indicators text-based so they work in text mode.

1+.

Gtk-based indicators are a good thing, but they shall have alternatives
applicable with "emacs -nw".

> Thanks
> Ted

Best regards, Michael.

Re: Global indicators

[Miles Bader]

joakim@verona.se writes:
>> Ah right. I just realize it seems no GTK widgets are used in buffer. Has
>> anyone ever tried to replace the various widgets (e.g. the buttons used
>> by custom), with GTK+ ones?
>
> I have a branch on savannah called "xwidget" which allows for that sort
> of thing. I had a look the other day at it again and it worked worse
> than usual though for some reason. Its none-trivial and theres a readme
> in the branch that explains why.

It might be easier to embed them in non-buffer locations, e.g., the echo
area though, right?

-Miles

-- 
My spirit felt washed.  With blood.  [Eli Shin, on "The Passion of the Christ"]

Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters

[Michael Albinus]

Chong Yidong <cyd@stupidchicken.com> writes:

> I'm dubious about the idea.  The mode-line is supposed to show
> information about one window, while the progress-reporter is a global
> indicator, so conceptually it's not a good fit.

As I have explained in another message, I propose to allow symbols for
the identification of the place where to show the progress. These
symbols could belong to the modeline. These symbols shall be made buffer-local.

But then it isn't a global indicator anymore, indeed.

> Global indicators, especially transient ones, ought to use the echo
> area.

This would still be possible.

> If that's too hard, how about reserving the first character in the echo
> area for a spinner instead?

This might interfere with minibuffers.

Re: Global indicators

[Ted Zlatanov]

On Thu, 24 Feb 2011 20:56:26 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Are you going to propose an API and some specifics of what functionality
>> these indicators will offer and where and how they can be attached, or
>> do you want me and Michael to come up with something?

MA> Same question here.

Stefan and Chong, please let us know.  I think this is a very necessary
feature and we can't proceed without knowing if you want us to design it
or not.

I think it would be most productive to let me and Michael put something
in the trunk and see if it's useful.  If not we'll revert it.  Michael's
design can be extended to support other locations besides the modeline.

Thanks
Ted

Re: Global indicators

[Ted Zlatanov]

On Thu, 24 Feb 2011 20:56:26 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 

MA> Ted Zlatanov <tzz@lifelogs.com> writes:

>> Are you going to propose an API and some specifics of what functionality
>> these indicators will offer and where and how they can be attached, or
>> do you want me and Michael to come up with something?

MA> Same question here.

Stefan, it's been a month, does that mean we can proceed with our own
API or do you still want to give us some direction for the proposed
global indicators for Emacs?  I'm not rushing you, only wanted to check
that this thread hasn't been dropped.

Thanks
Ted

Re: Global indicators

[Ted Zlatanov]

On Mon, 28 Mar 2011 13:44:46 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Thu, 24 Feb 2011 20:56:26 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 
MA> Ted Zlatanov <tzz@lifelogs.com> writes:

>>> Are you going to propose an API and some specifics of what functionality
>>> these indicators will offer and where and how they can be attached, or
>>> do you want me and Michael to come up with something?

MA> Same question here.

TZ> Stefan, it's been a month, does that mean we can proceed with our own
TZ> API or do you still want to give us some direction for the proposed
TZ> global indicators for Emacs?  I'm not rushing you, only wanted to check
TZ> that this thread hasn't been dropped.

Another reminder.  We had some more recent discussions about global
indicators so it's a feature Emacs should provide in some form.  Has
anyone thought about the topic?  Do you want Michael and me to restate
our proposal?

Thanks
Ted

Re: Global indicators

[Stefan Monnier]

>>>> Are you going to propose an API and some specifics of what functionality
>>>> these indicators will offer and where and how they can be attached, or
>>>> do you want me and Michael to come up with something?

I hope you can come up with something.


        Stefan

Re: Global indicators

[Ted Zlatanov]

On Wed, 28 Sep 2011 10:12:49 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>>>>> Are you going to propose an API and some specifics of what functionality
>>>>> these indicators will offer and where and how they can be attached, or
>>>>> do you want me and Michael to come up with something?

SM> I hope you can come up with something.

As a starting point, could you look at
http://permalink.gmane.org/gmane.emacs.devel/136277 where Michael posted
a patch proposing a simple API and implementing it?

Ted