From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/77231 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel,gmane.emacs.gnus.general Subject: RE: make-progress-reporter suggestions: 'modeline and customizableprogress-reporter--pulse-characters Date: Wed, 23 Feb 2011 13:28:05 -0800 Message-ID: References: <87ei76yi1x.fsf@lifelogs.com> <87lj1ergg5.fsf@gmx.de><87ipwi3hjm.fsf@lifelogs.com> <87fwrmr6gf.fsf@gmx.de><8739nm1u6n.fsf_-_@lifelogs.com> <878vxdxfzw.fsf@lifelogs.com> <87fwrj6j18.fsf@gmx.de> <87zkpp43s2.fsf@gmx.de><87aaho0yi1.fsf@lifelogs.com> <87ipwb5fcc.fsf@gnus.org><87fwrf87f3.fsf@gmx.de> <87tyfuh3l3.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1298496512 20521 80.91.229.12 (23 Feb 2011 21:28:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 23 Feb 2011 21:28:32 +0000 (UTC) Cc: ding@gnus.org, emacs-devel@gnu.org To: "'Chong Yidong'" , "'Michael Albinus'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 23 22:28:27 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PsMG2-0000Rn-KN for ged-emacs-devel@m.gmane.org; Wed, 23 Feb 2011 22:28:26 +0100 Original-Received: from localhost ([127.0.0.1]:55081 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PsMG2-0002OJ-1f for ged-emacs-devel@m.gmane.org; Wed, 23 Feb 2011 16:28:26 -0500 Original-Received: from [140.186.70.92] (port=57210 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PsMFw-0002JT-0X for emacs-devel@gnu.org; Wed, 23 Feb 2011 16:28:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PsMFu-0001XU-R4 for emacs-devel@gnu.org; Wed, 23 Feb 2011 16:28:19 -0500 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:45866) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PsMFu-0001XI-M3 for emacs-devel@gnu.org; Wed, 23 Feb 2011 16:28:18 -0500 Original-Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p1NLSBVv017132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Feb 2011 21:28:12 GMT Original-Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p1NHdSO6023560; Wed, 23 Feb 2011 21:28:10 GMT Original-Received: from abhmt018.oracle.com by acsmt354.oracle.com with ESMTP id 1032182651298496484; Wed, 23 Feb 2011 13:28:04 -0800 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 23 Feb 2011 13:28:04 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87tyfuh3l3.fsf@stupidchicken.com> Thread-Index: AcvTnGv4aaj+6taNRwau89JubUaMNgAAYg4w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4D657BEB.00FA:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 148.87.113.121 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:136409 gmane.emacs.gnus.general:77231 Archived-At: > 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.