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 09:09:43 -0800 Message-ID: References: <77CAAFE4D0CE4DD98476C996E3158648@us.oracle.com> <83obj2x218.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 1352740246 32052 80.91.229.3 (12 Nov 2012 17:10:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Nov 2012 17:10: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 18:10: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 1TXxXD-0006PO-Rj for geb-bug-gnu-emacs@m.gmane.org; Mon, 12 Nov 2012 18:10:56 +0100 Original-Received: from localhost ([::1]:60403 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXxX4-0005gc-3h for geb-bug-gnu-emacs@m.gmane.org; Mon, 12 Nov 2012 12:10:46 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:51456) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXxWy-0005fr-Mr for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2012 12:10:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TXxWv-00052p-L6 for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2012 12:10:40 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53753) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXxWv-00052g-HH for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2012 12:10:37 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TXxXK-0006Kf-Ds for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2012 12:11: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 17:11: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.135274021924292 (code B ref 12867); Mon, 12 Nov 2012 17:11:02 +0000 Original-Received: (at 12867) by debbugs.gnu.org; 12 Nov 2012 17:10:19 +0000 Original-Received: from localhost ([127.0.0.1]:35771 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TXxWc-0006Jk-TG for submit@debbugs.gnu.org; Mon, 12 Nov 2012 12:10:19 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:25546) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TXxWY-0006Ja-Nf for 12867@debbugs.gnu.org; Mon, 12 Nov 2012 12:10:17 -0500 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qACH9lfN010119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Nov 2012 17:09:48 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qACH9i35010000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Nov 2012 17:09:46 GMT Original-Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qACH9iCr005984; Mon, 12 Nov 2012 11:09:44 -0600 Original-Received: from dradamslap1 (/130.35.178.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Nov 2012 09:09:44 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83obj2x218.fsf@gnu.org> Thread-Index: Ac3A7Ac/IbCl2jHaT1e5J8JI36UcYwAACjLw 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: -2.1 (--) 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:66803 Archived-At: > > I want to use the fact that a %l construct in the mode line > > enables you to do something dynamic when the cursor moves to > > another line. > > May I inquire why you don't use the (:eval FORM) construct? IIUC, > this does exactly what you want and is supported since Emacs 21.1. I do use (:eval FORM), including in connection with this particular code. I have so far not seen how to use it to do what %l does wrt cursor movement among lines. 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. The code I use is here, if you are interested - see functions `bmkp-bmenu-mode-line' and `bmkp-bmenu-mode-line-string' (they are both short - I can include them in the bug thread, if you prefer): http://www.emacswiki.org/emacs-en/download/bookmark%2b-bmu.el I will be glad to find a way to simplify the code and remove this ugly little hack. Suggestions welcome. 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'. I don't have a problem using either approach, but for now I prefer the %l approach. With the workaround I use it does the job fine. I just wish there were a way to get its line-change triggering of redisplay without its attendant line-number display. > > 1. The %l construct must be present in the `mode-line-format'. > > 2. Its resulting line-number text must not have property > > `invisible'. > > The need to redisplay the mode line on every move of point is a killer > of many redisplay optimizations. It is also potentially expensive by > itself, because it requires Emacs to count lines, something that is > not an easy operation in Emacs, which sees the buffer text as a linear > array of characters, not a series of lines. So the display engine > tries very hard to avoid redisplaying the mode line if it decides that > the line number does not need to appear. I understand. But somehow it DTRT, for %l, at least. What I am missing (in my current knowledge) is how to make the display engine redisplay the mode line when the current line changes, without my using %l. (I mean just using `mode-line-format', not calling `force-mode-line-update' explicitly, from, say, `post-command-hook'.) %l takes care of that redisplay triggering, but it also shows the line number. I want the redisplay triggering without also showing the line number (I show other info instead). > This is probably the explanation for what you see. Still, it is not > entirely clear to me what "must" means in this context, so please show > the mode-line spec you tried and tell what didn't work when 1 or 2 > above was not true. Maybe there's something else involved. Not entirely sure I remember all that I tried. Trying the following now shows that the " (line)" part of the text is made invisible but the line number itself is not: (defun foo () (set (make-local-variable 'mode-line-position) '(:propertize "%l (line)" invisible t)) (set (make-local-variable 'mode-line-format) '(("" mode-name mode-line-position)))) I thought that something I tried earlier using text property `invisible' made all of the text invisible, including the line #, but also broke the dynamic update wrt current line. Perhaps I was mistaken about that - perhaps the code I was testing just led to an error that somehow prevented the %l formatted text from being used at all. Dunno. (The symptom was that the line number did not appear in the mode line, and the mode line was not updated wrt current-line changes. And I did not get the *invalid* mode-line-format display that typically indicates a mode-line display/formatting error.) But at any rate, trying the code above you can see that it does not make the line number itself disappear. Shouldn't it? Or perhaps I am missing something and there is a simple way to make that text invisible? > > Besides fixing the crash, it would be great if I did not > > have to resort to such an ugly hack in the first place. > > > > Presumably, this feature of dynamic line-sensitive updating > > is buried in the bowels of Emacs C code, so not available to > > Lisp users to tweak. Must this feature really be tied to an > > actual display of the line number? If so, can't we at least > > make that text invisible? > > If :eval doesn't fit the bill, please tell why. I have no idea why. > If there's need to make changes in the display engine to support > the feature you want to implement, I'd prefer to invest the energy > in providing a clean solution, rather than making mode-line-position > serve as a back door for such ugly hacks. Fine by me. > > Regardless, it would also be good if this feature (line-sensitive > > updating) were documented. I could find nothing that even > > hinted at it. > > Sorry, I don't understand: what is undocumented? If you are talking > about refreshing mode-line-position, then shouldn't it be obvious that > it's refreshed on every move of point? The %l spec is documented. It is clear enough that if you move the cursor to another line then the line # shown in the mode line gets updated automatically (from %l, by the redisplay code). So far, so good. 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.) I don't know an easier way to get that redisplay-on-line-change triggering behavior. You mentioned using :eval, but AFAICT that is not enough (or perhaps is not so simple/obvious). I do use :eval to format the mode-line info dynamically, but line-sensitive redisplay is not _triggered_ unless I also add %l. Once I add that, then the :eval I have DTRT, showing the right info that is pertinent to the current line. I would be pleased to learn that I am just missing something simple.