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

[Ted Zlatanov <tzz@lifelogs.com>]

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