From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#12872: 24.2; Provide a feature to trigger mode-line redisplay Date: Mon, 12 Nov 2012 14:17:38 -0800 Message-ID: References: <837gpqwuai.fsf@gnu.org> <831ufywqnh.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1352758725 3017 80.91.229.3 (12 Nov 2012 22:18:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Nov 2012 22:18:45 +0000 (UTC) Cc: 12872@debbugs.gnu.org To: "'Eli Zaretskii'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 12 23:18:55 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TY2LG-0002x7-8J for geb-bug-gnu-emacs@m.gmane.org; Mon, 12 Nov 2012 23:18:54 +0100 Original-Received: from localhost ([::1]:53352 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TY2L6-0005s3-JP for geb-bug-gnu-emacs@m.gmane.org; Mon, 12 Nov 2012 17:18:44 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:47084) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TY2L1-0005di-DS for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2012 17:18:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TY2Ky-00083k-Bi for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2012 17:18:39 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54395) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TY2Ky-00083g-8U for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2012 17:18:36 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TY2LO-0006oI-C4 for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2012 17:19:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Nov 2012 22:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12872 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12872-submit@debbugs.gnu.org id=B12872.135275869226121 (code B ref 12872); Mon, 12 Nov 2012 22:19:02 +0000 Original-Received: (at 12872) by debbugs.gnu.org; 12 Nov 2012 22:18:12 +0000 Original-Received: from localhost ([127.0.0.1]:36413 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TY2KZ-0006nF-Gx for submit@debbugs.gnu.org; Mon, 12 Nov 2012 17:18:11 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:27422) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TY2KX-0006n8-9W for 12872@debbugs.gnu.org; Mon, 12 Nov 2012 17:18:10 -0500 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qACMHedG004991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Nov 2012 22:17:41 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qACMHeeS015702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Nov 2012 22:17:40 GMT Original-Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qACMHdJm029375; Mon, 12 Nov 2012 16:17:39 -0600 Original-Received: from dradamslap1 (/130.35.178.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Nov 2012 14:17:39 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <831ufywqnh.fsf@gnu.org> Thread-Index: Ac3BDmAfwShX+PVcSw68LoCe627F6AAEkCEw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Spam-Score: 0.6 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-Spam-Score: 0.6 (/) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:66838 Archived-At: > > > Would it be good enough to redisplay whenever point moves, and let > > > your code you run from :eval decide whether the text on > > > the mode line needs to be changed? I think this will be a more > > > general solution. > > > > Yes, it would be good enough. > > > > But the advantage that I'm supposing %l has is that the > > line-counting is done in C, as part of the display engine. > > What do you need the line number for, in your code? Sorry, I misspoke. I didn't mean line-counting, I meant determining whether the current line has changed. I don't need the line number. > You are aware that under certain conditions, the mode line can > be redisplayed although point didn't move at all? Yes, of course. > > If my code had to check whether the line has changed then > > it would do that in Lisp. Not saying that's a big deal. > > But it still looks to me like the %l triggering is convenient. > > Yes, but you want to be independent of it, i.e. even when %l is not in > the mode line format. Yes, that was my suggestion: separate (a) triggering mode-line redisplay upon current-line change from (b) what to display in that case. %l ties the two together, displaying the current line number when the line # changes. > > Perhaps the option could handle both cases: the general > > point-change case and the more particular line-change case, > > depending on the option value? > > We could do that, yes. > > > BTW, why would this be a user option, rather than just a > > variable that code can bind? The use case for users is not > > too clear to me. > > Yes, a variable sounds better. > > > Anyway, I don't have much to say about what should be done > > for this enhancement. > > Some wizardry with flags that control which redisplay optimizations > can be used. Sounds good. I wonder (without being very familiar with the mode-line %-constructs, so maybe speaking nonsense) whether it might be useful to add specific %-constructs (or variables?) that say when (i.e., in what contexts) to trigger mode-line redisplay. They would be in addition to the existing %-constructs that either (a) simply provide particular data and format it or (b) combine such data+formatting with a triggering condition. An example of (a) is %b. An example of (b) is %l (it displays the line number and triggers redisplay when the line # changes). An example of what I'm suggesting would be to add, say, %d for triggering redisplay whenever point changes and, say, %L for triggering redisplay whenever the current line changes. (Just picked %d and %L arbitrarily.) With the addition of such redisplay-triggering %-constructs, type (b) combinations would no longer be strictly needed, but could be kept for convenience and compatibility. If more than one triggering %-construct applied at any time, they would each be used. E.g., if we had a construct that triggered redisplay when the buffer size changed (just to give an example), say %B, then if the mode line contained both %B and %L then its redisplay would be triggered whenever the current line changed and whenever the buffer size changed. Just throwing this out. No idea whether it makes any sense at all. If it makes no or little sense, no need to point out particulars of why (unless you want to), - I trust your judgment on that.