* RE: make-progress-reporter suggestions: 'modeline and customizableprogress-reporter--pulse-characters
2011-02-23 20:56 ` Chong Yidong
@ 2011-02-23 21:28 ` Drew Adams
2011-02-23 21:35 ` make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters Ted Zlatanov
` (4 subsequent siblings)
5 siblings, 0 replies; 54+ messages in thread
From: Drew Adams @ 2011-02-23 21:28 UTC (permalink / raw)
To: 'Chong Yidong', 'Michael Albinus'; +Cc: ding, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters
2011-02-23 20:56 ` Chong Yidong
2011-02-23 21:28 ` make-progress-reporter suggestions: 'modeline and customizableprogress-reporter--pulse-characters Drew Adams
@ 2011-02-23 21:35 ` Ted Zlatanov
2011-02-23 21:48 ` Global indicators (was: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters) Julien Danjou
` (3 subsequent siblings)
5 siblings, 0 replies; 54+ messages in thread
From: Ted Zlatanov @ 2011-02-23 21:35 UTC (permalink / raw)
To: emacs-devel; +Cc: ding
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
^ permalink raw reply [flat|nested] 54+ messages in thread* Global indicators (was: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters)
2011-02-23 20:56 ` Chong Yidong
2011-02-23 21:28 ` make-progress-reporter suggestions: 'modeline and customizableprogress-reporter--pulse-characters Drew Adams
2011-02-23 21:35 ` make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters Ted Zlatanov
@ 2011-02-23 21:48 ` Julien Danjou
2011-02-24 0:05 ` Global indicators Chong Yidong
2011-02-23 21:53 ` make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters Eli Zaretskii
` (2 subsequent siblings)
5 siblings, 1 reply; 54+ messages in thread
From: Julien Danjou @ 2011-02-23 21:48 UTC (permalink / raw)
To: Chong Yidong; +Cc: Michael Albinus, ding, emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: Global indicators
2011-02-23 21:48 ` Global indicators (was: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters) Julien Danjou
@ 2011-02-24 0:05 ` Chong Yidong
2011-02-24 0:13 ` Drew Adams
` (2 more replies)
0 siblings, 3 replies; 54+ messages in thread
From: Chong Yidong @ 2011-02-24 0:05 UTC (permalink / raw)
To: Michael Albinus; +Cc: ding, emacs-devel
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.
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: Global indicators
2011-02-24 0:05 ` Global indicators Chong Yidong
@ 2011-02-24 0:13 ` Drew Adams
2011-02-24 11:02 ` Julien Danjou
2011-02-24 16:50 ` Ted Zlatanov
2 siblings, 0 replies; 54+ messages in thread
From: Drew Adams @ 2011-02-24 0:13 UTC (permalink / raw)
To: 'Chong Yidong', 'Michael Albinus'; +Cc: ding, emacs-devel
> > 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...)
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Global indicators
2011-02-24 0:05 ` Global indicators Chong Yidong
2011-02-24 0:13 ` Drew Adams
@ 2011-02-24 11:02 ` Julien Danjou
2011-02-24 11:12 ` Miles Bader
2011-02-24 12:37 ` David Kastrup
2011-02-24 16:50 ` Ted Zlatanov
2 siblings, 2 replies; 54+ messages in thread
From: Julien Danjou @ 2011-02-24 11:02 UTC (permalink / raw)
To: Chong Yidong; +Cc: Michael Albinus, ding, emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Global indicators
2011-02-24 11:02 ` Julien Danjou
@ 2011-02-24 11:12 ` Miles Bader
2011-02-24 11:42 ` Julien Danjou
2011-02-24 12:37 ` David Kastrup
1 sibling, 1 reply; 54+ messages in thread
From: Miles Bader @ 2011-02-24 11:12 UTC (permalink / raw)
To: Chong Yidong; +Cc: Michael Albinus, ding, emacs-devel
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.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Global indicators
2011-02-24 11:12 ` Miles Bader
@ 2011-02-24 11:42 ` Julien Danjou
2011-02-24 12:56 ` joakim
0 siblings, 1 reply; 54+ messages in thread
From: Julien Danjou @ 2011-02-24 11:42 UTC (permalink / raw)
To: Miles Bader; +Cc: Chong Yidong, Michael Albinus, ding, emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Global indicators
2011-02-24 11:42 ` Julien Danjou
@ 2011-02-24 12:56 ` joakim
2011-02-25 2:41 ` Miles Bader
0 siblings, 1 reply; 54+ messages in thread
From: joakim @ 2011-02-24 12:56 UTC (permalink / raw)
To: Miles Bader; +Cc: Chong Yidong, Michael Albinus, ding, emacs-devel
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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Global indicators
2011-02-24 12:56 ` joakim
@ 2011-02-25 2:41 ` Miles Bader
0 siblings, 0 replies; 54+ messages in thread
From: Miles Bader @ 2011-02-25 2:41 UTC (permalink / raw)
To: joakim; +Cc: Chong Yidong, Michael Albinus, ding, emacs-devel
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"]
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Global indicators
2011-02-24 11:02 ` Julien Danjou
2011-02-24 11:12 ` Miles Bader
@ 2011-02-24 12:37 ` David Kastrup
2011-02-24 13:56 ` Julien Danjou
1 sibling, 1 reply; 54+ messages in thread
From: David Kastrup @ 2011-02-24 12:37 UTC (permalink / raw)
To: emacs-devel; +Cc: ding
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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Global indicators
2011-02-24 0:05 ` Global indicators Chong Yidong
2011-02-24 0:13 ` Drew Adams
2011-02-24 11:02 ` Julien Danjou
@ 2011-02-24 16:50 ` Ted Zlatanov
2 siblings, 0 replies; 54+ messages in thread
From: Ted Zlatanov @ 2011-02-24 16:50 UTC (permalink / raw)
To: emacs-devel; +Cc: ding
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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters
2011-02-23 20:56 ` Chong Yidong
` (2 preceding siblings ...)
2011-02-23 21:48 ` Global indicators (was: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters) Julien Danjou
@ 2011-02-23 21:53 ` Eli Zaretskii
2011-02-24 16:37 ` Ted Zlatanov
2011-02-23 22:04 ` David Kastrup
2011-02-25 13:56 ` make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters Michael Albinus
5 siblings, 1 reply; 54+ messages in thread
From: Eli Zaretskii @ 2011-02-23 21:53 UTC (permalink / raw)
To: Chong Yidong; +Cc: michael.albinus, ding, emacs-devel
> 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?
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters
2011-02-23 21:53 ` make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters Eli Zaretskii
@ 2011-02-24 16:37 ` Ted Zlatanov
0 siblings, 0 replies; 54+ messages in thread
From: Ted Zlatanov @ 2011-02-24 16:37 UTC (permalink / raw)
To: emacs-devel; +Cc: ding
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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters
2011-02-23 20:56 ` Chong Yidong
` (3 preceding siblings ...)
2011-02-23 21:53 ` make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters Eli Zaretskii
@ 2011-02-23 22:04 ` David Kastrup
2011-02-24 0:38 ` Ted Zlatanov
2011-02-25 13:56 ` make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters Michael Albinus
5 siblings, 1 reply; 54+ messages in thread
From: David Kastrup @ 2011-02-23 22:04 UTC (permalink / raw)
To: emacs-devel; +Cc: ding
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
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters
2011-02-23 22:04 ` David Kastrup
@ 2011-02-24 0:38 ` Ted Zlatanov
2011-02-24 1:27 ` make-progress-reporter suggestions: 'modeline and customizableprogress-reporter--pulse-characters Drew Adams
2011-02-24 2:01 ` make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters Chong Yidong
0 siblings, 2 replies; 54+ messages in thread
From: Ted Zlatanov @ 2011-02-24 0:38 UTC (permalink / raw)
To: emacs-devel; +Cc: ding
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
^ permalink raw reply [flat|nested] 54+ messages in thread
* RE: make-progress-reporter suggestions: 'modeline and customizableprogress-reporter--pulse-characters
2011-02-24 0:38 ` Ted Zlatanov
@ 2011-02-24 1:27 ` Drew Adams
2011-02-24 2:01 ` make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters Chong Yidong
1 sibling, 0 replies; 54+ messages in thread
From: Drew Adams @ 2011-02-24 1:27 UTC (permalink / raw)
To: 'Ted Zlatanov', emacs-devel; +Cc: ding
> 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.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters
2011-02-24 0:38 ` Ted Zlatanov
2011-02-24 1:27 ` make-progress-reporter suggestions: 'modeline and customizableprogress-reporter--pulse-characters Drew Adams
@ 2011-02-24 2:01 ` Chong Yidong
2011-02-24 3:15 ` Ted Zlatanov
1 sibling, 1 reply; 54+ messages in thread
From: Chong Yidong @ 2011-02-24 2:01 UTC (permalink / raw)
To: Ted Zlatanov; +Cc: ding, emacs-devel
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).
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters
2011-02-24 2:01 ` make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters Chong Yidong
@ 2011-02-24 3:15 ` Ted Zlatanov
2011-02-24 16:55 ` Stefan Monnier
0 siblings, 1 reply; 54+ messages in thread
From: Ted Zlatanov @ 2011-02-24 3:15 UTC (permalink / raw)
To: emacs-devel; +Cc: ding
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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters
2011-02-24 3:15 ` Ted Zlatanov
@ 2011-02-24 16:55 ` Stefan Monnier
2011-02-24 17:45 ` Drew Adams
2011-02-24 18:05 ` Global indicators (was: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters) Ted Zlatanov
0 siblings, 2 replies; 54+ messages in thread
From: Stefan Monnier @ 2011-02-24 16:55 UTC (permalink / raw)
To: Ted Zlatanov; +Cc: emacs-devel, ding
> 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
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters
2011-02-24 16:55 ` Stefan Monnier
@ 2011-02-24 17:45 ` Drew Adams
2011-02-24 18:05 ` Global indicators (was: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters) Ted Zlatanov
1 sibling, 0 replies; 54+ messages in thread
From: Drew Adams @ 2011-02-24 17:45 UTC (permalink / raw)
To: 'Stefan Monnier', 'Ted Zlatanov'; +Cc: ding, emacs-devel
> 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)
^ permalink raw reply [flat|nested] 54+ messages in thread
* Global indicators (was: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters)
2011-02-24 16:55 ` Stefan Monnier
2011-02-24 17:45 ` Drew Adams
@ 2011-02-24 18:05 ` Ted Zlatanov
2011-02-24 19:56 ` Global indicators Michael Albinus
1 sibling, 1 reply; 54+ messages in thread
From: Ted Zlatanov @ 2011-02-24 18:05 UTC (permalink / raw)
To: ding; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Global indicators
2011-02-24 18:05 ` Global indicators (was: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters) Ted Zlatanov
@ 2011-02-24 19:56 ` Michael Albinus
2011-03-01 18:25 ` Ted Zlatanov
2011-03-28 18:44 ` Ted Zlatanov
0 siblings, 2 replies; 54+ messages in thread
From: Michael Albinus @ 2011-02-24 19:56 UTC (permalink / raw)
To: Ted Zlatanov; +Cc: ding, emacs-devel
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.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Global indicators
2011-02-24 19:56 ` Global indicators Michael Albinus
@ 2011-03-01 18:25 ` Ted Zlatanov
2011-03-28 18:44 ` Ted Zlatanov
1 sibling, 0 replies; 54+ messages in thread
From: Ted Zlatanov @ 2011-03-01 18:25 UTC (permalink / raw)
To: ding; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Global indicators
2011-02-24 19:56 ` Global indicators Michael Albinus
2011-03-01 18:25 ` Ted Zlatanov
@ 2011-03-28 18:44 ` Ted Zlatanov
2011-09-28 13:56 ` Ted Zlatanov
1 sibling, 1 reply; 54+ messages in thread
From: Ted Zlatanov @ 2011-03-28 18:44 UTC (permalink / raw)
To: ding; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Global indicators
2011-03-28 18:44 ` Ted Zlatanov
@ 2011-09-28 13:56 ` Ted Zlatanov
2011-09-28 14:12 ` Stefan Monnier
0 siblings, 1 reply; 54+ messages in thread
From: Ted Zlatanov @ 2011-09-28 13:56 UTC (permalink / raw)
To: emacs-devel; +Cc: ding
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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: make-progress-reporter suggestions: 'modeline and customizable progress-reporter--pulse-characters
2011-02-23 20:56 ` Chong Yidong
` (4 preceding siblings ...)
2011-02-23 22:04 ` David Kastrup
@ 2011-02-25 13:56 ` Michael Albinus
5 siblings, 0 replies; 54+ messages in thread
From: Michael Albinus @ 2011-02-25 13:56 UTC (permalink / raw)
To: Chong Yidong; +Cc: ding, emacs-devel
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.
^ permalink raw reply [flat|nested] 54+ messages in thread