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#12867: 24.3.50; easy-to-repro crash involving mode line Date: Mon, 12 Nov 2012 10:16:55 -0800 Message-ID: <42FD6C9E3CE4497C860CC8BA17FB1DE5@us.oracle.com> References: <77CAAFE4D0CE4DD98476C996E3158648@us.oracle.com> <83obj2x218.fsf@gnu.org> <83ehjywvx9.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 1352744266 4732 80.91.229.3 (12 Nov 2012 18:17:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Nov 2012 18:17:46 +0000 (UTC) Cc: 12867@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 19:17:56 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 1TXya3-0004hO-Bm for geb-bug-gnu-emacs@m.gmane.org; Mon, 12 Nov 2012 19:17:55 +0100 Original-Received: from localhost ([::1]:45393 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXyZt-0004h4-MW for geb-bug-gnu-emacs@m.gmane.org; Mon, 12 Nov 2012 13:17:45 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:50963) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXyZo-0004gM-JE for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2012 13:17:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TXyZl-0007ck-GH for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2012 13:17:40 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53860) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXyZl-0007ca-DH for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2012 13:17:37 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TXyaA-0007sw-6O for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2012 13:18: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 18:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12867 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12867-submit@debbugs.gnu.org id=B12867.135274425130274 (code B ref 12867); Mon, 12 Nov 2012 18:18:02 +0000 Original-Received: (at 12867) by debbugs.gnu.org; 12 Nov 2012 18:17:31 +0000 Original-Received: from localhost ([127.0.0.1]:35878 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TXyZf-0007sF-6b for submit@debbugs.gnu.org; Mon, 12 Nov 2012 13:17:31 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:45294) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TXyZc-0007s6-0K for 12867@debbugs.gnu.org; Mon, 12 Nov 2012 13:17:29 -0500 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qACIGxwS022823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Nov 2012 18:17:00 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qACIGux5018051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Nov 2012 18:16:58 GMT Original-Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qACIGusj029688; Mon, 12 Nov 2012 12:16:56 -0600 Original-Received: from dradamslap1 (/130.35.178.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Nov 2012 10:16:56 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83ehjywvx9.fsf@gnu.org> Thread-Index: Ac3A/ndW5rS7HkajQuSJI145p/UedwAACKsA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] 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:66809 Archived-At: > > That is, %l triggers redisplay when the current line > > changes. It is that triggering that I miss otherwise; > > it is not evaluating to produce the right > > display (e.g. using :eval), once redisplay is triggered. > > So you want to be able to trigger redisplay of the mode line at will, > without being forced to have a line number display on the mode line, > is that it? > > Or do you only want to trigger redisplay of mode line when the current > line changes? The latter. > If the latter, then what is so special about changing the > current line that you want mode line redisplayed only at that time? See the code I pointed you to (but I explain below). I show users info that pertains to the line they are on. IOW, that info changes as the line changes. It is not the line number itself that they want to see in this context. It is info about what is in the current line compared to info in other lines. The info relates to numbers of particular kinds of marks used in a bookmarks listing, and in particular the number of the current-line's mark of each kind relative to the total number of that kind. The doc string of the function I pointed you to says: Show, in mode line, information about the current bookmark-list display. The information includes the sort order and the number of marked, flagged (for deletion), tagged, temporary, annotated, and modified bookmarks currently shown. For each number indication: If the current line has the indicator (e.g. mark, flag) and there are others with the same indicator listed after it, then show `N/M', where N is the number indicated through the current line and M is the total number indicated. > > Yes, I could instead use, say, `post-command-hook' and > > `force-mode-line-update' if the line changes. But %l triggers > > mode-line redisplay on line changes, and it seems to me better > > to let it do the triggering than to call `count-lines' in > > a Lisp function on `post-command-hook'. > > Yes, post-command-hook is ugly and expensive. But you should know > that %l is not ideal either: e.g., if display of the line numbers is > disabled because the file is too large or the lines are too long, and > Emacs displays "???" instead of the number, I think mode line is not > redisplayed when the current line changes. Again, because Emacs tries > very hard to avoid this costly redisplay. I see - good to know. I don't expect it will be a problem here, but I'll keep an eye out. Any idea what size buffers lead to such behavior? I don't expect users to have gigantic bookmark-list displays, but you never know, and it's a good idea to know what the (approximate) threshold is. > > I will be glad to find a way to simplify the code and > > remove this ugly little hack. Suggestions welcome. > > A user option sounds like the right approach. Do you mean at the level of my code, or are you thinking about an enhancement for Emacs? The rest of your text leads me to think the latter. If not, I'm not sure what kind of option you have in mind here. > But we should first formulate the conditions under which this > redisplay will be performed. If we're talking about my use case then it is each time the current line changes. > Doing that only when the line number changes sounds too > ad-hoc to me. Can we come up with something more general? E.g., > would redisplaying the mode line on _every_ redisplay cycle (under the > new option) be acceptable? I don't follow you. Probably that's because I don't know what the option that you envision is for. Perhaps (dunno whether this is related to what you're thinking or off the map) we could have a user function get called on every redisplay cycle. It would (a) determine whether to redisplay the mode line and (b) perhaps also say how. Dunno. > Anyway, it looks like this discussion should continue in another bug > report, as the crash is solved. OK. Do you want to formulate the bug subject? You have a better idea than I what you are envisioning as a possible solution. Or I can file a bug (enhancement request) with subject "trigger mode-line redisplay on line change" or some such. > Did you try the syntax used in bindings.el? It's ",(propertize ...", > perhaps that's what you should do as well to make the text invisible. I tried that. > > What is not so obvious is that you can automatically update > > anything at all in the mode line when the cursor changes line, > > as long as you include %l somewhere in the `mode-line-format'. > > IOW, %l triggers mode-line redisplay when you change lines, > > and your mode-line code can take advantage of that. (But you > > must show the line number as well.) > > Yes, and there are other complications (see above about "???"), all of > them artifacts of the implementation details. I don't think this > should be documented, because it can change without notice. OK.