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: Tue, 13 Nov 2012 07:38:45 -0800 Message-ID: <147CB8FB2F7B4B83A18C26B553085D76@us.oracle.com> References: <837gpqwuai.fsf@gnu.org> <831ufywqnh.fsf@gnu.org> <83vcdaupbs.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 1352821181 8410 80.91.229.3 (13 Nov 2012 15:39:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 13 Nov 2012 15:39:41 +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 Tue Nov 13 16:39:51 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 1TYIac-0007SS-N1 for geb-bug-gnu-emacs@m.gmane.org; Tue, 13 Nov 2012 16:39:50 +0100 Original-Received: from localhost ([::1]:59588 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYIaT-0008Lx-4P for geb-bug-gnu-emacs@m.gmane.org; Tue, 13 Nov 2012 10:39:41 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:41985) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYIaO-0008LD-KI for bug-gnu-emacs@gnu.org; Tue, 13 Nov 2012 10:39:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TYIaL-0003EW-I1 for bug-gnu-emacs@gnu.org; Tue, 13 Nov 2012 10:39:36 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:56815) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYIaL-0003EQ-Ei for bug-gnu-emacs@gnu.org; Tue, 13 Nov 2012 10:39:33 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TYIap-0000RA-88 for bug-gnu-emacs@gnu.org; Tue, 13 Nov 2012 10:40:03 -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: Tue, 13 Nov 2012 15:40: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.13528211671625 (code B ref 12872); Tue, 13 Nov 2012 15:40:02 +0000 Original-Received: (at 12872) by debbugs.gnu.org; 13 Nov 2012 15:39:27 +0000 Original-Received: from localhost ([127.0.0.1]:38831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYIaF-0000QA-0d for submit@debbugs.gnu.org; Tue, 13 Nov 2012 10:39:27 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:34684) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYIaB-0000Q1-Tv for 12872@debbugs.gnu.org; Tue, 13 Nov 2012 10:39:25 -0500 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qADFcnK3027446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Nov 2012 15:38:50 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qADFcm7B023900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Nov 2012 15:38:49 GMT Original-Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qADFcmQW022325; Tue, 13 Nov 2012 09:38:48 -0600 Original-Received: from dradamslap1 (/10.159.163.96) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Nov 2012 07:38:48 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83vcdaupbs.fsf@gnu.org> Thread-Index: Ac3BUwohK3mBmDazRfuk20ZOYBXxjQAXVHxA 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:66874 Archived-At: > > 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. > > What would be the advantages of such a feature? Since the mode line > format is not even consulted in order to decide whether or not to > redisplay the mode line (because its processing is very non-trivial, > what with all the propertize stuff and Lisp expressions going on there > even in the standard value), we will need internal variables to shadow > these constructs anyway. > > Having variables or maybe a plist of the mode line format allows > easier access to this information, and is IMO more Lispy than hiding > the information in some % magic. I agree that (local) variables make more sense than %-constructs. That was part of my suggestion. I don't know much about how these things work. Even from my point of view, ignoring what I didn't know, including the reasons you gave, variables make more sense, because we are not replacing the %-construct with anything, in context - IOW, the positions of the new %-constructs in `mode-line-format' would be irrelevant. Consider my suggestion to be just to have some easy way to specify mode-line redisplay triggering conditions, so users can easily separate triggering from the mode-line format/content. So for the case that motivated this, you would be able to separate the two %l effects: triggering and line-# content. Having different variables (or plist keywords) to specify different triggering contexts would be one way. [Someone else might prefer that we come up with a single monster variable a la `buffer-display-alist' ;-).]