GNU bug report logs - #12867
24.3.50; easy-to-repro crash involving mode line

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12867 in the body.
You can then email your comments to 12867 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.3.50; easy-to-repro crash involving mode line
Date: Sun, 11 Nov 2012 19:52:09 -0800

emacs -Q
 
(defun foo ()
  (set (make-local-variable 'mode-line-position)
       '("%99l (line)"))
  (set (make-local-variable 'mode-line-format)
       '(("" mode-name mode-line-position))))
 
M-: (foo)
 
No problem.  The line number is shown at the far right, padded on the
left (see bug #12866).  You might need to widen the window/frame to see
it.  But no problem.
 
Now change 99 to 999 and repeat M-: (foo).  Still no problem.  Now, no
matter how big you make the window or how small you make the font, the
line number has probably moved off the screen at the right, so you no
longer see it.  Good (what I wanted).
 
Now change the value to 9999.  Crash.
 

Background, FWIW:
 
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.  This
works very well, except for one thing (besides the corner-case crash
reported here): you must SHOW the line number.
 
By "show the line number", I mean:
 
1. The %l construct must be present in the `mode-line-format'.
2. Its resulting line-number text must not have property `invisible'.
 
Dunno why, but that's what seems to be the case.  So, since my use of
this dynamic display does not really have anything to do with showing
the line number, and I do not want to show it, I looked for another way
to remove it.
 
I first moved it off to the right a bit, so it didn't get in the way too
much.  Then I discovered that even though the text must not be
`invisible' (why?) it is fine if the text is off the screen to the
right.  As a final step, I tried using a very large padding number, just
for good measure.  That produced the crash.
 
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?
 
Regardless, it would also be good if this feature (line-sensitive
updating) were documented.  I could find nothing that even hinted at it.
 

[As Emacs 24 crashes sooner or later, seemingly randomly, for each
session I have, it is a pleasure to be able to report a
simple-to-reproduce crash, for once.]
 
In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
 of 2012-11-05 on MS-W7-DANI
Bzr revision: 110809 lekktu <at> gmail.com-20121105172930-a5gn0bwi4lndchhw
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -I../../libs/libXpm-3.5.10/include -I../../libs/libXpm-3.5.10/src
 -I../../libs/libpng-1.2.37-lib/include -I../../libs/zlib-1.2.5
 -I../../libs/giflib-4.1.4-1-lib/include
 -I../../libs/jpeg-6b-4-lib/include
 -I../../libs/tiff-3.8.2-1-lib/include
 -I../../libs/libxml2-2.7.8-w32-bin/include/libxml2
 -I../../libs/gnutls-3.0.9-w32-bin/include
 -I../../libs/libiconv-1.9.2-1-lib/include'
 

Message #8 received at 12867 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 12867 <at> debbugs.gnu.org
Subject: Re: bug#12867: 24.3.50; easy-to-repro crash involving mode line
Date: Mon, 12 Nov 2012 17:40:35 +0200

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Date: Sun, 11 Nov 2012 19:52:09 -0800
> 
> emacs -Q
>  
> (defun foo ()
>   (set (make-local-variable 'mode-line-position)
>        '("%99l (line)"))
>   (set (make-local-variable 'mode-line-format)
>        '(("" mode-name mode-line-position))))
>  
> M-: (foo)
>  
> No problem.  The line number is shown at the far right, padded on the
> left (see bug #12866).  You might need to widen the window/frame to see
> it.  But no problem.
>  
> Now change 99 to 999 and repeat M-: (foo).  Still no problem.  Now, no
> matter how big you make the window or how small you make the font, the
> line number has probably moved off the screen at the right, so you no
> longer see it.  Good (what I wanted).
>  
> Now change the value to 9999.  Crash.

Fixed in revision 110850 on the emacs-24 branch.  (The value 999 was
already too large, btw, it just didn't cause an immediate crash by
sheer luck.  The maximum width is 4 times the width of the frame, and
with the above revision, you are limited to that maximum.)

> 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.

> 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.

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.

> 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.  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.

> 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?

Message #11 received at 12867 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 12867 <at> debbugs.gnu.org
Subject: RE: bug#12867: 24.3.50; easy-to-repro crash involving mode line
Date: Mon, 12 Nov 2012 09:09:43 -0800

> > 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.

Message #14 received at 12867 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12867 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#12867: 24.3.50; easy-to-repro crash involving mode line
Date: Mon, 12 Nov 2012 18:31:53 +0100

> 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 think it would make sense to use a cache for maintaining line numbers.

martin

Message #17 received at 12867 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 12867 <at> debbugs.gnu.org
Subject: Re: bug#12867: 24.3.50; easy-to-repro crash involving mode line
Date: Mon, 12 Nov 2012 19:52:34 +0200

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <12867 <at> debbugs.gnu.org>
> Date: Mon, 12 Nov 2012 09:09:43 -0800
> 
> 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?  If the latter, then what is so special about changing
the current line that you want mode line redisplayed only at that
time?

> 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 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.  But we should first
formulate the conditions under which this redisplay will be
performed.  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?

Anyway, it looks like this discussion should continue in another bug
report, as the crash is solved.

> (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?

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.

> 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.

Message #20 received at 12867 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 12867 <at> debbugs.gnu.org
Subject: RE: bug#12867: 24.3.50; easy-to-repro crash involving mode line
Date: Mon, 12 Nov 2012 10:16:55 -0800

> > 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.

Message #23 received at 12867 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 12867 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#12867: 24.3.50; easy-to-repro crash involving mode line
Date: Mon, 12 Nov 2012 20:19:01 +0200

> Date: Mon, 12 Nov 2012 18:31:53 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: Drew Adams <drew.adams <at> oracle.com>, 12867 <at> debbugs.gnu.org
> 
>  > 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 think it would make sense to use a cache for maintaining line numbers.

We already do, but maybe not as extensively as you may have in mind.
See the base_line_pos member of 'struct window'.

There's also region-cache.c, which we could use for that.  But before
we do, Someone(TM) should time the thing and see if it's worth our
while to make that cache.

Message #26 received at 12867 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 12867 <at> debbugs.gnu.org
Subject: Re: bug#12867: 24.3.50; easy-to-repro crash involving mode line
Date: Mon, 12 Nov 2012 20:35:00 +0200

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <12867 <at> debbugs.gnu.org>
> Date: Mon, 12 Nov 2012 10:16:55 -0800
> 
> > 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?

Buffers that have more lines than line-number-display-limit or lines
wider than line-number-display-limit-width.

> > > 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.

I mean a new option, an enhancement.

> > 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.

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.

> > 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?

Done: bug #12872.  Let's continue there.

Message #29 received at 12867 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 12867 <at> debbugs.gnu.org
Subject: Re: bug#12867: 24.3.50; easy-to-repro crash involving mode line
Date: Mon, 12 Nov 2012 15:55:34 -0500

> We already do, but maybe not as extensively as you may have in mind.
> See the base_line_pos member of 'struct window'.
> There's also region-cache.c, which we could use for that.  But before
> we do, Someone(TM) should time the thing and see if it's worth our
> while to make that cache.

FWIW, I recently added such a cache (in Elisp) to nlinum.el, and on my
test case (largish file with C-v/M-v style scrolling) the difference was
very significant (but the previous code had no cache at all, not even
base_line_pos).


        Stefan

Message #32 received at 12867 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 12867 <at> debbugs.gnu.org
Subject: Re: bug#12867: 24.3.50; easy-to-repro crash involving mode line
Date: Tue, 13 Nov 2012 09:22:20 +0100

> FWIW, I recently added such a cache (in Elisp) to nlinum.el, and on my
> test case (largish file with C-v/M-v style scrolling) the difference was
> very significant (but the previous code had no cache at all, not even
> base_line_pos).

So we now already have a syntax-ppss cache and a nlinum cache.  Couldn't
we maintain one cache per buffer, updated by one and the same algorithm?
That algorithm would parse syntax when requested, for example, by
font-locking.  Newlines would be always parsed.  Cache invalidation
would happen as present.

martin

Message #35 received at 12867 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: monnier <at> iro.umontreal.ca, 12867 <at> debbugs.gnu.org
Subject: Re: bug#12867: 24.3.50; easy-to-repro crash involving mode line
Date: Tue, 13 Nov 2012 14:52:54 +0200

> Date: Tue, 13 Nov 2012 09:22:20 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: Eli Zaretskii <eliz <at> gnu.org>, 12867 <at> debbugs.gnu.org
> 
>  > FWIW, I recently added such a cache (in Elisp) to nlinum.el, and on my
>  > test case (largish file with C-v/M-v style scrolling) the difference was
>  > very significant (but the previous code had no cache at all, not even
>  > base_line_pos).
> 
> So we now already have a syntax-ppss cache and a nlinum cache.  Couldn't
> we maintain one cache per buffer, updated by one and the same algorithm?

These two cache different information, so making such a cache
efficient is not very trivial.

At least for nlinum, if it were to use some Lisp binding of
find_next_newline_no_quit (there's no such binding at this time, but
it wouldn't be hard to provide one), they could use a newline cache
provided by region-cache.c for free.

Message #38 received at 12867 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: monnier <at> iro.umontreal.ca, 12867 <at> debbugs.gnu.org
Subject: Re: bug#12867: 24.3.50; easy-to-repro crash involving mode line
Date: Tue, 13 Nov 2012 14:50:35 +0100

> These two cache different information, so making such a cache
> efficient is not very trivial.

They share two important properties: (1) They must be accurate for the
same buffer locations (the window that has to be fontified contains the
`point' whose line-number we want to know) and (2) they are usually
invalidated by the same sets of buffer modifications.

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.