something like linum.el ought to be added

something like linum.el ought to be added

[Joe Wells]

The approach to line numbering in linum.el seems to work well and
seems to be fast and robust.  I suggest it would be a good idea to
officially add it, or something like it, to Emacs.

This would allow line numbering like many other programs do, with a
line number prefixed to each line on the left.  The current
line-number-mode is not what many users want.

The linum.el file can be found at:

  http://stud4.tuwien.ac.at/~e0225855/linum/linum.html

I suggest the following improvement to linum.el be considered:

• The line number should be put in its own face; linum.el puts it in
  the face default.

• The line number should be put in the display margins.  This would
  allow better display of long lines that wrap around.  The code in
  linum.el appears to be making some attempt to do this, but doesn't
  seem to actually use the margins.

I hope this suggestion is useful.

-- 
Joe

Re: something like linum.el ought to be added

[Leo]

On 2007-09-09 11:04 +0100, Joe Wells wrote:
> The approach to line numbering in linum.el seems to work well and
> seems to be fast and robust.  I suggest it would be a good idea to
> officially add it, or something like it, to Emacs.
>
> This would allow line numbering like many other programs do, with a
> line number prefixed to each line on the left.  The current
> line-number-mode is not what many users want.
>
> The linum.el file can be found at:
>
>   http://stud4.tuwien.ac.at/~e0225855/linum/linum.html

I think it is an excellent addition to Emacs. This feature has been
requested for many years now.

> I suggest the following improvement to linum.el be considered:
>
> • The line number should be put in its own face; linum.el puts it in
>   the face default.
>
> • The line number should be put in the display margins.  This would
>   allow better display of long lines that wrap around.  The code in
>   linum.el appears to be making some attempt to do this, but doesn't
>   seem to actually use the margins.
>
> I hope this suggestion is useful.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

=>             "(require 'cl) considered harmful" considered harmful
=>           http://dto.freeshell.org/blog/blog-2007-09-07-2323.html

Re: something like linum.el ought to be added

[Richard Stallman]

    The linum.el file can be found at:

      http://stud4.tuwien.ac.at/~e0225855/linum/linum.html

It looks interesting.  Is it efficient enough?  It reassigns overlays
to all the visible lines after every command, and that might be
painfully slow.

It might as well delete ALL the overlays it has made, rather than just
those for the visible lines.  Preserving overlays on the other parts
of the buffer won't things speed up, and could waste a lot of space
and maybe also cause slowdown by having so many overlays.

It would be much better if it worked from after-change-functions, and
reassigned overlays only for the lines that really need it.

Anyone want to work on that?

    ? The line number should be put in its own face; linum.el puts it in
      the face default.

    ? The line number should be put in the display margins.  This would
      allow better display of long lines that wrap around.  The code in
      linum.el appears to be making some attempt to do this, but doesn't
      seem to actually use the margins.

I agree those are good ideas.

Re: something like linum.el ought to be added

[Markus Triska]

Richard Stallman <rms@gnu.org> writes:

> Is it efficient enough?

Many users have reported good success, and it works well for me too.
Please let me know if it doesn't work for you.

> Preserving overlays on the other parts of the buffer won't things
> speed up

Since those overlays can be reused when re-visiting the parts of the
buffer they were created for, this can speed things up since it avoids
re-creation of overlays and intermediate garbage collection.

> It would be much better if it worked from after-change-functions, and
> reassigned overlays only for the lines that really need it.

Line numbers should also be updated after scrolling, M-x goto-line and
many other functions that change the visible portion. The current
method is more reliable and works, I hope, sufficiently well.

> I agree those are good ideas.

Implemented in version 0.9b, available from the given link.

Re: something like linum.el ought to be added

[David Kastrup]

Markus Triska <markus.triska@gmx.at> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> Is it efficient enough?
>
> Many users have reported good success, and it works well for me too.
> Please let me know if it doesn't work for you.
>
>> Preserving overlays on the other parts of the buffer won't things
>> speed up
>
> Since those overlays can be reused when re-visiting the parts of the
> buffer they were created for, this can speed things up since it avoids
> re-creation of overlays and intermediate garbage collection.

A large number of overlays is slowing down every operation in the
buffer.  Having a set of 50 or so that is only adjusted upon redraw
should be the fastest option for that reason.  If the overlay creation
is time-critical, one might move keep some off-screen overlays in a
separate list for reuse and detach them from the buffer temporarily.

But I doubt it would be worth the trouble.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: something like linum.el ought to be added

[Markus Triska]

David Kastrup <dak@gnu.org> writes:

> A large number of overlays is slowing down every operation in the
> buffer.  Having a set of 50 or so that is only adjusted upon redraw
> should be the fastest option for that reason.

I see what you mean; the main complication is that existing overlays
can still be necessary in other windows that show the same buffer. So
making all overlays available for (re-)consumption would entail
walking all visible windows and adjusting (new or existing) overlays
where necessary, which is not a clear improvement over the current
approach (i.e., keeping overlays in place once they are created, and
only changing those in the visible portion of the current window), in
particular since the number of overlays seems to be no problem so far.

Re: something like linum.el ought to be added

[Davis Herring]

> I see what you mean; the main complication is that existing overlays
> can still be necessary in other windows that show the same buffer. So
> making all overlays available for (re-)consumption would entail
> walking all visible windows and adjusting (new or existing) overlays
> where necessary, which is not a clear improvement over the current
> approach (i.e., keeping overlays in place once they are created, and
> only changing those in the visible portion of the current window), in
> particular since the number of overlays seems to be no problem so far.

If you only change them in the visible portion of the current window, does
that mean that line-number overlays in other windows on the same buffer
would never be updated (so long as they remained unselected)?  Even if,
say, an insertion had changed all the line numbers visible in another
window?

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: something like linum.el ought to be added

[Markus Triska]

"Davis Herring" <herring@lanl.gov> writes:

> If you only change them in the visible portion of the current window, does
> that mean that line-number overlays in other windows on the same buffer
> would never be updated (so long as they remained unselected)?

Yes, that's currently the case; I am now looking into what Richard
suggests, which should solve this too.

Re: something like linum.el ought to be added

[Richard Stallman]

    I see what you mean; the main complication is that existing overlays
    can still be necessary in other windows that show the same buffer.

That is true.

								       So
    making all overlays available for (re-)consumption would entail
    walking all visible windows and adjusting (new or existing) overlays
    where necessary,

Indeed, the after-change-functions hook will need to deal with
all the windows.  That is not very hard, with buffer-window-list.

If each overlay records which windows it is meant for, the
window-scroll-functions can could delete and redo only those that
pertain to the current window.  Each window will run the
window-scroll-functions to recompute the overlays it needs.

(We can add a primitive to select overlays based on a certain
property value, to make that faster.)

We could also add this as a display feature.
It might not be very hard.

Re: something like linum.el ought to be added

[Joe Wells]

Richard Stallman <rms@gnu.org> writes:

>     I see what you mean; the main complication is that existing overlays
>     can still be necessary in other windows that show the same buffer.
>
> That is true.
>
> 								       So
>     making all overlays available for (re-)consumption would entail
>     walking all visible windows and adjusting (new or existing) overlays
>     where necessary,
>
> Indeed, the after-change-functions hook will need to deal with
> all the windows.  That is not very hard, with buffer-window-list.
>
> If each overlay records which windows it is meant for, the
> window-scroll-functions can could delete and redo only those that
> pertain to the current window.  Each window will run the
> window-scroll-functions to recompute the overlays it needs.

And the “window” overlay property can allow the overlays for the
different windows to be completely independent of each other.  There
could be two overlays for a given line and only one would be displayed
in each window.

> (We can add a primitive to select overlays based on a certain
> property value, to make that faster.)

Like next-single-property-change except for overlays instead of text
properties?

> We could also add this as a display feature.
> It might not be very hard.

By the way, it might help if there was an easier interface to the data
returned by (format-mode-line "%l" WINDOW).  That cached information
is potentially a big speedup, but hard to access in a nice way.

-- 
Joe

Re: something like linum.el ought to be added

[David Kastrup]

Joe Wells <jbw@macs.hw.ac.uk> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> (We can add a primitive to select overlays based on a certain
>> property value, to make that faster.)
>
> Like next-single-property-change except for overlays instead of text
> properties?

There is next-single-char-property-change.

But maybe Richard was rather thinking about a more discriminative form
of overlays-at.

-- 
David Kastrup

Re: something like linum.el ought to be added

[Richard Stallman]

    > If each overlay records which windows it is meant for, the
    > window-scroll-functions can could delete and redo only those that
    > pertain to the current window.  Each window will run the
    > window-scroll-functions to recompute the overlays it needs.

    And the ?window? overlay property can allow the overlays for the
    different windows to be completely independent of each other.  There
    could be two overlays for a given line and only one would be displayed
    in each window.

It could be used for that, in another feature where that was needed.
However, each line's number is the same in all windows, so linum
doesn't need to do this.

    > (We can add a primitive to select overlays based on a certain
    > property value, to make that faster.)

    Like next-single-property-change except for overlays instead of text
    properties?

The same basic idea, yes, but a different interface might be more
suitable here.

    But maybe Richard was rather thinking about a more discriminative form
    of overlays-at.

Rather, a more discriminative form of overlays-in.

Re: something like linum.el ought to be added

[Markus Triska]

Richard Stallman <rms@gnu.org> writes:

> Indeed, the after-change-functions hook will need to deal with
> all the windows.  That is not very hard, with buffer-window-list.

Yes, that's how I'm doing it now; update is now also added to several
other hooks. One oversight in Emacs is, I think, that the functions in
window-size-change-functions are invoked as regular functions in
xdisp.c, therefore making the hook buffer-local currently results in
an error (due to 't'). I'm thus modifying the global hook for now.

> (We can add a primitive to select overlays based on a certain
> property value, to make that faster.)

Thanks; however, the current approach in version 0.9m is already so
fast that no new primitives seem to be necessary (for linum.el).

Re: something like linum.el ought to be added

[Stefan Monnier]

> Yes, that's how I'm doing it now; update is now also added to several
> other hooks. One oversight in Emacs is, I think, that the functions in
> window-size-change-functions are invoked as regular functions in
> xdisp.c, therefore making the hook buffer-local currently results in
> an error (due to 't'). I'm thus modifying the global hook for now.

I think your code should rely on fontification-functions instead of fiddling
with things like window-size-change-functions.  It may very well be that
fontification-functions doesn't work quite right for you, tho (basically it
was defined for jit-lock and I believe that putting more than one function
on it won't work right, so maybe you'd want to use jit-lock-register
instead).


        Stefan

Re: something like linum.el ought to be added

[Joe Wells]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Yes, that's how I'm doing it now; update is now also added to several
>> other hooks. One oversight in Emacs is, I think, that the functions in
>> window-size-change-functions are invoked as regular functions in
>> xdisp.c, therefore making the hook buffer-local currently results in
>> an error (due to 't'). I'm thus modifying the global hook for now.
>
> I think your code should rely on fontification-functions instead of fiddling
> with things like window-size-change-functions.  It may very well be that
> fontification-functions doesn't work quite right for you, tho (basically it
> was defined for jit-lock and I believe that putting more than one function
> on it won't work right, so maybe you'd want to use jit-lock-register
> instead).

Some comments on the idea of relying on fontification-functions:

I think linum.el should work even if the user has font-locking turned
off, so it shouldn't depend on jit-lock.el (unless jit-lock can be
used without turning font-locking on?).  Anyway, the whole
font-locking subsystem is also quite hard to understand, so it seems
unwise to me to get linum.el tied up in that complexity.  And
font-locking is oriented toward fontifying the entire buffer
eventually while with line numbering you probably only want to keep
active overlays for the displayed region.

And it seems it would be hard for fontification-functions will work
well with linum.el as a separate user from jit-lock.el, because they
would both be competing for control of the same fontified property.
So, for example, if stealth background fontification fontified some
region, it would (I think?) place a non-nil value on the fontified
property of that region, and then when that region was displayed by
scrolling there would be nothing to trigger the line numbering.

I hope these comments are helpful.

-- 
Joe

Re: something like linum.el ought to be added

[Stefan Monnier]

> Some comments on the idea of relying on fontification-functions:

> I think linum.el should work even if the user has font-locking turned
> off, so it shouldn't depend on jit-lock.el (unless jit-lock can be
> used without turning font-locking on?).  Anyway, the whole
> font-locking subsystem is also quite hard to understand, so it seems
> unwise to me to get linum.el tied up in that complexity.  And
> font-locking is oriented toward fontifying the entire buffer
> eventually while with line numbering you probably only want to keep
> active overlays for the displayed region.

You may want to take another look at jit-lock-register.  Or glasses-mode for
that matter (the only other user of jit-lock currently besides font-lock).

But yes: jit-lock is oriented towards fontifying the whole buffer, which is
not what linum.el wants to do (and actually glasses-mode would probably
rather be like linum.el).

> And it seems it would be hard for fontification-functions will work
> well with linum.el as a separate user from jit-lock.el, because they
> would both be competing for control of the same fontified property.
> So, for example, if stealth background fontification fontified some
> region, it would (I think?) place a non-nil value on the fontified
> property of that region, and then when that region was displayed by
> scrolling there would be nothing to trigger the line numbering.

Yes, that's the problem I hinted at which makes it pretty much impossible to
use multiple functions on fontification-functions.

So I think it's fine for linum.el to use something else, but I do think it's
a good opportunity also to revisit this jit-lock and fontification-functions
business to try and come up with a good solution.

Maybe a solution is to change jit-lock by having it distinguish between
clients that would rather keep everything fontified (full clients) and those
that would rather only keep the displayed part fontified (light clients).

Then add a jit-lock-clear-unused thingy that would go and flush all the
non-displayed data of the light clients and then set fontified to nil (so
that jit-lock gets to know when those need to be prepared for display), but
also set jit-lock-fontified to t (so that jit-lock knows that this was
already fontified w.r.t full clients, so only light clients need to be
called).


        Stefan

motivation for recent bug reports on overlays and properties like before-string, display, after-string, and face (was: linum.el and display properties)

[Joe Wells]

Markus Triska <markus.triska@gmx.at> writes:

> Hi Joe,
>
> I've been (loosely) following your recent bug-reports on
> Emacs-devel;

I hope you don't mind that I CC emacs-devel for my reply.  I think it
might help people to understand better why I've been trying to use
this stuff.

> is it correct that fixing these problems will also help linum.el?

Possibly.  I suspect linum.el is probably affected by the problem
where an overlay's before-string is affected by the face of the
character in the buffer after the overlay start (which isn't even
inside the overlay in the case of a zero-length overlay like linum.el
uses).

> Also, what exactly is it that you want to do with LaTeX and folding?

I've been making the code in tex-fold.el work better with the code in
preview.el (latex-preview).  (Both of these are part of AUCTeX.)  The
code in tex-fold allows viewing something like

  \textbf{XYZ \textit{ABC} 123}

as:

  XYZ ABC 123

This picks up anything that font-latex.el has already done, so the
appropriate fonts will be used.  In this case, that means the XYZ and
123 will be in bold font, and the ABC will be in bold italic font.

The code in preview.el allows viewing something like

  $\Omega^2_3$

as an image in the buffer, so you can see what the TeX typesetting
will look like.  It looks roughly like Ω²₃, except that the
superscript will be directly above the subscript, and it will use the
TeX fonts.

However, without any of the changes I have been making, these don't
work together, so you can get

  \textbf{XYZ $\Omega^2_3$ 123}

to display as either

  XYZ $\Omega^2_3$ 123

(where the XYZ and 123 are in bold font) or as

  \textbf{XYZ Ω²₃ 123}

but not as

  XYZ Ω²₃ 123

which is the most desired version.

If you want to see for yourself, I posted a version of my changes to
the auctex-devel mailing list.  (I've continued to work on making them
better since then.)

> Thank you for pursuing these issues!

Sure.  I'm just trying to use the text and overlay properties as they
are documented.  :-)

-- 
Joe

Re: something like linum.el ought to be added

[Richard Stallman]

    I think your code should rely on fontification-functions instead of fiddling
    with things like window-size-change-functions.

`fontification-functions' can't be used for linum because the C code
checks explicitly for a `fontified' property before calling those
functions.  In effect, those functions have to put on `fontified'
properties in order to make this mechanism work right.  And they should
only do that if they are doing fontification.

If there is the existing hooks don't do the job well, it would be nice
to improve them so as to make them better for programs like this

RE: something like linum.el ought to be added

[brianjiang]

Hi Markus,

I downloaded the newest version of the linum.el from the web (version 0.9n), and find that the line number doesn't work well in some folding function (e.g., outline mode). It can be reproduced by the following steps:

1. emacs -Q
2. load the linum.el
3. C-h n  to open the NEW.
3. M-x linum-mode
4. Click menu: Hide -> Hide Sublevel

Then some lines have no line number shown.

Regards,
Brian

-----Original Message-----
From: emacs-devel-bounces+brianjiang=gdnt.com.cn@gnu.org [mailto:emacs-devel-bounces+brianjiang=gdnt.com.cn@gnu.org] On Behalf Of Markus Triska
Sent: 2007年9月14日 1:06
To: rms@gnu.org
Cc: jbw@macs.hw.ac.uk; emacs-devel@gnu.org
Subject: Re: something like linum.el ought to be added

Richard Stallman <rms@gnu.org> writes:

> Indeed, the after-change-functions hook will need to deal with all the 
> windows.  That is not very hard, with buffer-window-list.

Yes, that's how I'm doing it now; update is now also added to several other hooks. One oversight in Emacs is, I think, that the functions in window-size-change-functions are invoked as regular functions in xdisp.c, therefore making the hook buffer-local currently results in an error (due to 't'). I'm thus modifying the global hook for now.

> (We can add a primitive to select overlays based on a certain property 
> value, to make that faster.)

Thanks; however, the current approach in version 0.9m is already so fast that no new primitives seem to be necessary (for linum.el).



_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: something like linum.el ought to be added

[Markus Triska]

<brianjiang@gdnt.com.cn> writes:

> Then some lines have no line number shown.

Thanks, I can reproduce it; please try 0.9o, which should fix it.

Re: something like linum.el ought to be added

[Juanma Barranquero]

Could I suggest also passing to the linum-format function (if any) the
total number of lines in the buffer (or the visible region)?

`linum-update-window' only needs to compute it once, while the
linum-format function is called for each line and would have to do
convoluted things to cache it (and somehow detect buffer changes).

     Juanma

Re: something like linum.el ought to be added

[Markus Triska]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> `linum-update-window' only needs to compute it once, while the
> linum-format function is called for each line and would have to do
> convoluted things to cache it (and somehow detect buffer changes).

It need not be convoluted: What you probably want instead is a
linum-before-line-numbering-hook, where users can compute everything
their format function needs. Is that it?

Re: something like linum.el ought to be added

[Juanma Barranquero]

On 9/15/07, Markus Triska <markus.triska@gmx.at> wrote:

> It need not be convoluted: What you probably want instead is a
> linum-before-line-numbering-hook, where users can compute everything
> their format function needs. Is that it?

That would be even better, yes.

             Juanma

Re: something like linum.el ought to be added

[Richard Stallman]

    >> Is it efficient enough?
    >
    > Many users have reported good success, and it works well for me too.
    > Please let me know if it doesn't work for you.

I'd like some people here that have slow machines to try it and
report whether it is fast enough to be usable for them.

    A large number of overlays is slowing down every operation in the
    buffer.  Having a set of 50 or so that is only adjusted upon redraw
    should be the fastest option for that reason.  If the overlay creation
    is time-critical, one might move keep some off-screen overlays in a
    separate list for reuse and detach them from the buffer temporarily.

Those sound like improvements.

Re: something like linum.el ought to be added

[Richard Stallman]

    > Preserving overlays on the other parts of the buffer won't things
    > speed up

    Since those overlays can be reused when re-visiting the parts of the
    buffer they were created for, this can speed things up since it avoids
    re-creation of overlays and intermediate garbage collection.

Someone pointed out that you can use the same set of overlays
regardless of the buffer position.

    Line numbers should also be updated after scrolling, M-x goto-line and
    many other functions that change the visible portion.

That is true.  But you can do that by putting a hook onto
window-scroll-functions.  That plus after-change-functions let you get
a call for every event that could make it necessary.

Take a look at jit-lock.el and see how it determines when
to act and where.  linum.el can do it the same way.

Re: something like linum.el ought to be added

[Markus Triska]

There is a new version, 0.9f, which fixes all concerns raised so far
in this thread. Please let me know if it breaks anything for you.

Re: something like linum.el ought to be added

[martin rudalics]

> There is a new version, 0.9f, which fixes all concerns raised so far
> in this thread. Please let me know if it breaks anything for you.

When the same buffer appears in more than one window the `walk-windows'
in `linum-configuration-change' together with

         (mapc #'linum-update-window
               (get-buffer-window-list linum-buffer nil 'visible)))

seems to update line numbers twice when the same buffer is displayed in
more than one window.  Why do you want to update numbers on any but the
selected frame here?  Also, after scrolling it should be sufficient to
consider the scrolled window only.  The `string-match' in
`linum-after-change' should become `string-match-p' to avoid clobbering
match data.

Re: something like linum.el ought to be added

[Markus Triska]

martin rudalics <rudalics@gmx.at> writes:

> seems to update line numbers twice when the same buffer is displayed in
> more than one window.

Changed in 0.9h.

> Why do you want to update numbers on any but the selected frame
> here?

Because I found cases where the previous command created a frame with
a buffer that must have its line numbers shown, yet was not selected.

> Also, after scrolling it should be sufficient to consider the
> scrolled window only.

No: The scrolled window can use overlays that another window needs.

> The `string-match' in `linum-after-change' should become
> `string-match-p' to avoid clobbering match data.

Changed.

Re: something like linum.el ought to be added

[martin rudalics]

 >>Why do you want to update numbers on any but the selected frame
 >>here?
 >
 >
 > Because I found cases where the previous command created a frame with
 > a buffer that must have its line numbers shown, yet was not selected.

Then you'd have to update line numbers in `after-make-frame-functions'
too.

 >>Also, after scrolling it should be sufficient to consider the
 >>scrolled window only.
 >
 >
 > No: The scrolled window can use overlays that another window needs.

Not if the other window displays another buffer.  For the same buffer
this can be easily handled by giving overlays a window property.

An aside: Sometimes configuration, buffer text, and some window start
position change within one and the same command.  Did you check whether
this cause line number updating run two, three times after the command?

Re: something like linum.el ought to be added

[Markus Triska]

martin rudalics <rudalics@gmx.at> writes:

> Then you'd have to update line numbers in `after-make-frame-functions'

Yes, that would also be an option; the current way subsumes more
specialized cases like this with little overhead.

> An aside: Sometimes configuration, buffer text, and some window start
> position change within one and the same command.  Did you check whether
> this cause line number updating run two, three times after the command?

No; generally, I found updates to be so fast that this, even if it
should occur, is not a concern. Also, when line numbers for a window
are updated twice in a row, all overlays are already created and in
the right place, so it is even less noticable than starting anew.

Re: something like linum.el ought to be added

[Juanma Barranquero]

On 9/10/07, Markus Triska <markus.triska@gmx.at> wrote:

> Line numbers should also be updated after scrolling, M-x goto-line and
> many other functions that change the visible portion. The current
> method is more reliable and works, I hope, sufficiently well.

If you line-number a narrowed buffer and then widen it, the newly
visible lines are not numbered until C-l or cursor movement, etc.

             Juanma

Re: something like linum.el ought to be added

[Markus Triska]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> If you line-number a narrowed buffer and then widen it, the newly
> visible lines are not numbered until C-l or cursor movement, etc.

Yes, and I also found it's not enough to update line numbers in
window-size-change-functions, configuration-change-hook, and
after-change-functions; one should also do it in hs-...-hook,
allout-..., outline-..., and many others.

I have for now reinstated the original behaviour: Line numbers are
(also) updated in post-command-hook. However, one can set linum-eager
to `nil' to obtain more conservative updates, at the price of
potentially missing some changes. Use C-l or scroll in such cases.

Re: something like linum.el ought to be added

[Juanma Barranquero]

On 9/15/07, Markus Triska <markus.triska@gmx.at> wrote:

> I have for now reinstated the original behaviour: Line numbers are
> (also) updated in post-command-hook.

Aha, it works now.

All in all, linum seems to work quite well. It should be committed to
the repository (IMHO).

             Juanma

Re: something like linum.el ought to be added

[Richard Stallman]

    Yes, and I also found it's not enough to update line numbers in
    window-size-change-functions, configuration-change-hook, and
    after-change-functions; one should also do it in hs-...-hook,
    allout-..., outline-..., and many others.

I think that means we need to add a suitable hook which redisplay can
call to inform Lisp code that visibility changes may have altered the
position of the bottom of the window.

The hook could be called by redisplay_window,
if current_matrix_up_to_date_p is zero.

Would someone like to try implementing this?

Re: something like linum.el ought to be added

[Markus Triska]

Richard Stallman <rms@gnu.org> writes:

> Would someone like to try implementing this?

A first try follows. In addition, here is a version of linum.el that
depends on the patch and seems to work as intended:

   http://stud4.tuwien.ac.at/~e0225855/linum/linum-cvs.el

Other versions are of course still available from the project page.

2007-09-16  Markus Triska  <markus.triska@gmx.at>

	* xdisp.c (redisplay_window): Invoke new hook,
	window-bottom-change-functions, when visibility changes may have
	altered the position of the bottom of the window.
	(syms_of_xdisp): add window-bottom-change-functions

diff --git a/src/xdisp.c b/src/xdisp.c
index 618a538..80b973c 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -232,6 +232,7 @@ extern Lisp_Object Qhelp_echo;
 
 Lisp_Object Qoverriding_local_map, Qoverriding_terminal_local_map;
 Lisp_Object Qwindow_scroll_functions, Vwindow_scroll_functions;
+Lisp_Object Qwindow_bottom_change_functions, Vwindow_bottom_change_functions;
 Lisp_Object Qredisplay_end_trigger_functions, Vredisplay_end_trigger_functions;
 Lisp_Object Qinhibit_point_motion_hooks;
 Lisp_Object QCeval, QCfile, QCdata, QCpropertize;
@@ -12880,6 +12881,10 @@ redisplay_window (window, just_this_one_p)
        && XFASTINT (w->last_modified) >= MODIFF
        && XFASTINT (w->last_overlay_modified) >= OVERLAY_MODIFF);
 
+  if (!current_matrix_up_to_date_p
+      && !NILP(Vwindow_bottom_change_functions))
+      safe_run_hooks (Qwindow_bottom_change_functions);
+
   buffer_unchanged_p
     = (!NILP (w->window_end_valid)
        && !current_buffer->clip_changed
@@ -23866,6 +23871,9 @@ syms_of_xdisp ()
   staticpro (&Qwindow_scroll_functions);
   Qwindow_scroll_functions = intern ("window-scroll-functions");
 
+  staticpro (&Qwindow_bottom_change_functions);
+  Qwindow_bottom_change_functions = intern ("window-bottom-change-functions");
+
   staticpro (&Qredisplay_end_trigger_functions);
   Qredisplay_end_trigger_functions = intern ("redisplay-end-trigger-functions");
 
@@ -24173,6 +24181,11 @@ and its new display-start position.  Note that the value of `window-end'
 is not valid when these functions are called.  */);
   Vwindow_scroll_functions = Qnil;
 
+  DEFVAR_LISP ("window-bottom-change-functions", &Vwindow_bottom_change_functions,
+    doc: /* List of functions to call when visibility changes may have altered
+the position of the bottom of the window. */);
+  Vwindow_bottom_change_functions = Qnil;
+
   DEFVAR_LISP ("redisplay-end-trigger-functions", &Vredisplay_end_trigger_functions,
     doc: /* Functions called when redisplay of a window reaches the end trigger.
 Each function is called with two arguments, the window and the end trigger value.

Re: something like linum.el ought to be added

[Richard Stallman]

It looks good, except for minor nits.  It can be installed, with these
nits fixed.

    +  if (!current_matrix_up_to_date_p
    +      && !NILP(Vwindow_bottom_change_functions))
    +      safe_run_hooks (Qwindow_bottom_change_functions);

It needs a space between NILP and the paren.

    +  DEFVAR_LISP ("window-bottom-change-functions", &Vwindow_bottom_change_functions,
    +    doc: /* List of functions to call when visibility changes may have altered
    +the position of the bottom of the window. */);

The first line of that doc string (like every doc string) should stand
on its own.

Re: something like linum.el ought to be added

[Stefan Monnier]

>     Yes, and I also found it's not enough to update line numbers in
>     window-size-change-functions, configuration-change-hook, and
>     after-change-functions; one should also do it in hs-...-hook,
>     allout-..., outline-..., and many others.

> I think that means we need to add a suitable hook which redisplay can
> call to inform Lisp code that visibility changes may have altered the
> position of the bottom of the window.

OTOH, using jit-lock would make this unnecessary.
After all, the progression of linum.el follows the one from lazy-lock.el to
jit-lock.el (lazy-lock suffered from the same problems with outline-mode,
as a matter of fact).


        Stefan

Re: something like linum.el ought to be added

[Richard Stallman]

    > I think that means we need to add a suitable hook which redisplay can
    > call to inform Lisp code that visibility changes may have altered the
    > position of the bottom of the window.

    OTOH, using jit-lock would make this unnecessary.

jit-lock implements a specific functionality, fontification, and
nothing else.

I thought that the hooks used by jit-lock ought to be sufficient
for linum as well.  But it turns out they are not, because
the code to run Vfontification_functions checks specifically
for the `fontified' property.

We could add another similar hook, or a more general mechanism to
implement similar hooks for various uses.  But I think that is the
wrong way to go, because it depends on putting text properties on the
text, to indicate which parts have been processed.  (Fontified, in the
case of jit-lock.)

We don't want linum to put on text properties to say where it has
put the line numbers.  So I think my idea of using the same hooks
jit-lock uses was a mistake.

We seem to have another solution, which I suggested and Markus Triska
implemened. 

RE: something like linum.el ought to be added

[brianjiang]

sometimes we can use outline- or hs- and others functions to hide a lot of lines.  it seems linum mode create/move overlays for every line between window-start and window-end. So even the line is already hide, linum still create/move overlay for it. If there are many line hiden within the window, it will consume a lot of memory, also impact the performance/efficience of the linum mode.  Is it possible to avoid the create linum overly for the invisible line? 

-----Original Message-----
From: emacs-devel-bounces+brianjiang=gdnt.com.cn@gnu.org [mailto:emacs-devel-bounces+brianjiang=gdnt.com.cn@gnu.org] On Behalf Of Richard Stallman
Sent: 2007年9月17日 11:59
To: Stefan Monnier
Cc: lekktu@gmail.com; markus.triska@gmx.at; emacs-devel@gnu.org
Subject: Re: something like linum.el ought to be added


    > I think that means we need to add a suitable hook which redisplay can
    > call to inform Lisp code that visibility changes may have altered the
    > position of the bottom of the window.

    OTOH, using jit-lock would make this unnecessary.

jit-lock implements a specific functionality, fontification, and nothing else.

I thought that the hooks used by jit-lock ought to be sufficient for linum as well.  But it turns out they are not, because the code to run Vfontification_functions checks specifically for the `fontified' property.

We could add another similar hook, or a more general mechanism to implement similar hooks for various uses.  But I think that is the wrong way to go, because it depends on putting text properties on the text, to indicate which parts have been processed.  (Fontified, in the case of jit-lock.)

We don't want linum to put on text properties to say where it has put the line numbers.  So I think my idea of using the same hooks jit-lock uses was a mistake.

We seem to have another solution, which I suggested and Markus Triska implemened. 


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: something like linum.el ought to be added

[Stefan Monnier]

> sometimes we can use outline- or hs- and others functions to hide a lot of
> lines.  it seems linum mode create/move overlays for every line between
> window-start and window-end. So even the line is already hide, linum still
> create/move overlay for it. If there are many line hiden within the
> window, it will consume a lot of memory, also impact the
> performance/efficience of the linum mode.  Is it possible to avoid the
> create linum overly for the invisible line? 

Ahem.... can you say "jit-lock"?


        Stefan

Re: something like linum.el ought to be added

[Stefan Monnier]

>> I think that means we need to add a suitable hook which redisplay can
>> call to inform Lisp code that visibility changes may have altered the
>> position of the bottom of the window.

>     OTOH, using jit-lock would make this unnecessary.

> jit-lock implements a specific functionality, fontification, and
> nothing else.

Not exactly.  It turns the low-level fontification-function functionality
into a higher-level one that can then be used by font-lock to
do fontification.  It can also be used by other packages to do other things
(e.g. glasses-mode).

> I thought that the hooks used by jit-lock ought to be sufficient
> for linum as well.  But it turns out they are not, because
> the code to run Vfontification_functions checks specifically
> for the `fontified' property.

I believe they are sufficient, but jit-lock needs to be extended to offer the
feature required by linum.el.


        Stefan

Re: something like linum.el ought to be added

[Richard Stallman]

    > I thought that the hooks used by jit-lock ought to be sufficient
    > for linum as well.  But it turns out they are not, because
    > the code to run Vfontification_functions checks specifically
    > for the `fontified' property.

    I believe they are sufficient, but jit-lock needs to be extended to offer the
    feature required by linum.el.

jit-lock is controlled by the `fontified' property.
We do not want linum to alter text properties,
so it can't use jit-lock.

Re: something like linum.el ought to be added

[Stefan Monnier]

>> I thought that the hooks used by jit-lock ought to be sufficient
>> for linum as well.  But it turns out they are not, because
>> the code to run Vfontification_functions checks specifically
>> for the `fontified' property.

>     I believe they are sufficient, but jit-lock needs to be extended to
>     offer the feature required by linum.el.

> jit-lock is controlled by the `fontified' property.  We do not want linum
> to alter text properties, so it can't use jit-lock.

I do not follow.  I have a pretty good idea of how jit-lock could be
modified to provide just the necessary functionality.  linum.el would keep
using overlays (just like glasses-mode does already in conjunction with
jit-lock, by the way).


        Stefan

Re: something like linum.el ought to be added

[Richard Stallman]

    > jit-lock is controlled by the `fontified' property.  We do not want linum
    > to alter text properties, so it can't use jit-lock.

    I do not follow.

`jit-lock-function' is called from the hook `fontification-functions',
which is run from `handle_fontified_prop', which is called when
there is a change in the `fontified' property.  So it seems that everything
is caontrolled by that property.

Did I misunderstand that code?

		      I have a pretty good idea of how jit-lock could be
    modified to provide just the necessary functionality.

How would you modify it?

Re: something like linum.el ought to be added

[Stefan Monnier]

>> jit-lock is controlled by the `fontified' property.  We do not want linum
>> to alter text properties, so it can't use jit-lock.

>     I do not follow.

> `jit-lock-function' is called from the hook `fontification-functions',
> which is run from `handle_fontified_prop', which is called when
> there is a change in the `fontified' property.  So it seems that everything
> is caontrolled by that property.

> Did I misunderstand that code?

No you have it right.  But I don't think the conclusion follows from that.

I don't have time right now to go into the details,


        Stefan

Re: something like linum.el ought to be added

[martin rudalics]

 > It looks interesting.  Is it efficient enough?  It reassigns overlays
 > to all the visible lines after every command, and that might be
 > painfully slow.

The only way to make this fast is implementing it in the redisplay code.

 > It might as well delete ALL the overlays it has made, rather than just
 > those for the visible lines.  Preserving overlays on the other parts
 > of the buffer won't things speed up, and could waste a lot of space
 > and maybe also cause slowdown by having so many overlays.

I think the overlay handling part is OK and cannot be improved much.  It
might profit from recentering overlays but I'm not sure where.

 > It would be much better if it worked from after-change-functions, and
 > reassigned overlays only for the lines that really need it.

The only way `after-change-functions' could be used here is to
invalidate entries of a line numbers cache.  Such a cache should be
useful for `line-number-mode' too.  If you have enabled both
`linum-mode' and `line-number-mode' you'd `count-lines' twice from bob
for each redisplay.