linum.el?

linum.el?

[Juanma Barranquero]

What's the status wrt adding linum.el?

AFAICS, discussion died off after Markus proposed a new
`window-bottom-change-functions' hook (which Richard OK'ed, but has
not been installed) and Stefan talked about generalizing jit-lock.

Even if the current version of linum.el (0.9w) is not perfect (I've
seen a couple of non-easily-reproducible update bugs) it works well
and it's quite useful; installing it would help to iron out the
remaining bugs.

             Juanma

Re: linum.el?

[Stefan Monnier]

> Even if the current version of linum.el (0.9w) is not perfect (I've
> seen a couple of non-easily-reproducible update bugs) it works well
> and it's quite useful; installing it would help to iron out the
> remaining bugs.

Agreed,


        Stefan

Re: linum.el?

[Richard Stallman]

The discussions focused on drawbacks and how to fix them, and we made
some progress.  I don't remember after all this time which drawbacks
remain to be fixed.  Can you remind us?

    `window-bottom-change-functions' hook (which Richard OK'ed, but has
    not been installed)

Can you post this code again?

Which drawbacks in linum would this enable to be fixed,
and which other drawbacks would remain?

Re: linum.el?

[Juanma Barranquero]

On 11/1/07, Richard Stallman <rms@gnu.org> wrote:

> I don't remember after all this time which drawbacks
> remain to be fixed.  Can you remind us?

Markus can explain it better, but as far as I remember, linum.el is
too slow when allout-mode or outline-mode are active.

> Can you post this code again?

Attached after the signature.

> Which drawbacks in linum would this enable to be fixed,

Markus: "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."

You: "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?"

> and which other drawbacks would remain?

The only one I've seen is that, in very infrequent cases, linum.el
does not update some line numbers after adding or deleting lines. That
may be related to the fact that I use a custom format function. Other
than that, linum.el works very well and it's more than fast enough.

             Juanma


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) <window-bottom-change-functions>: New hook.


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,10 @@ 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: /* Functions to call when the bottom of the window changes.  */);
+  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: linum.el?

[Markus Triska]

Richard Stallman <rms@gnu.org> writes:

> can linum.el do the job using `set-window-redisplay-end-trigger'
> instead of this hook?

It doesn't seem so to me.

> Does it work?

In the DEFVAR_LISP line, I think it should read "&Vwindow..." instead of
"Vwindow...". Also, the new approach doesn't necessarily reach a
fixpoint, i.e., the number of restarts can be unbounded.

> Second, the code will run this hook whenever there is any possibility
> that the text to be displayed has changed for any reason.

It still fails to trigger (at least) on widening and when jumping to the
beginning of buffers. Could it be changed to trigger then too?

Re: linum.el?

[Stefan Monnier]

> It still fails to trigger (at least) on widening and when jumping to the
> beginning of buffers. Could it be changed to trigger then too?

I still firmly believe that these cases should be handled via jit-lock
and/or fontification-functions and/or some extension of them.


        Stefan

Re: linum.el?

[Juanma Barranquero]

On Dec 27, 2007 12:28 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I still firmly believe that these cases should be handled via jit-lock
> and/or fontification-functions and/or some extension of them.

FWIW, I still firmly believe that we should include linum.el now, as
it works quite well, and worry later about optimizations and such.

             Juanma

Re: linum.el?

[Richard Stallman]

    FWIW, I still firmly believe that we should include linum.el now, as
    it works quite well, and worry later about optimizations and such.

I won't object.

Re: linum.el?

[Juanma Barranquero]

On Dec 27, 2007 7:24 PM, Richard Stallman <rms@gnu.org> wrote:

>     FWIW, I still firmly believe that we should include linum.el now, as
>     it works quite well, and worry later about optimizations and such.
>
> I won't object.

I'll commit linum.el (version 0.9wx) in the trunk in a few days, if no
one objects.

             Juanma

Re: linum.el?

[Juanma Barranquero]

On Jan 21, 2008 12:50 AM, Juanma Barranquero <lekktu@gmail.com> wrote:

> I'll commit linum.el (version 0.9wx) in the trunk in a few days, if no
> one objects.

I've installed linum.el in the trunk. It works also in 22.X. Should we
add it there too?

             Juanma

Re: linum.el?

[Miles Bader]

"Juanma Barranquero" <lekktu@gmail.com> writes:
> I've installed linum.el in the trunk. It works also in 22.X. Should we
> add it there too?

Could people stop adding new features to the 22.x branch?

Thanks,

-Miles

-- 
.Numeric stability is probably not all that important when you're guessing.

Re: linum.el?

[Juanma Barranquero]

On Jan 30, 2008 4:03 AM, Miles Bader <miles.bader@necel.com> wrote:

> Could people stop adding new features to the 22.x branch?

That's a nice answer to my asking...

BTW, where were you when socks.el, css-mode.el, vera-mode.el,
vc-hg.el, vc-git.el, vc-bzr.el, vc-mtn.el, verilog-mode.el and
blank-mode.el were added to the EMACS_22_BASE branch?

             Juanma

Re: linum.el?

[Miles Bader]

"Juanma Barranquero" <lekktu@gmail.com> writes:
>> Could people stop adding new features to the 22.x branch?
>
> where were you when socks.el, css-mode.el, vera-mode.el,
> vc-hg.el, vc-git.el, vc-bzr.el, vc-mtn.el, verilog-mode.el and
> blank-mode.el were added to the EMACS_22_BASE branch?

My point precisely.

-Miles

-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

Re: linum.el?

[Juanma Barranquero]

On Jan 30, 2008 2:25 PM, Miles Bader <miles@gnu.org> wrote:

> My point precisely.

I get your point. I don't get why the irate answer to my question,
when other packages have been installed without so much as a comment.

             Juanma

Re: linum.el?

[Miles Bader]

"Juanma Barranquero" <lekktu@gmail.com> writes:
> I get your point. I don't get why the irate answer to my question,
> when other packages have been installed without so much as a comment.

Nothing to do with you or "linum.el" in particular.  I suppose it's that
you were kind enough to ask rather explicitly in a message I happened to
read.  If most of that other stuff was ever discussed (I suppose it must
have been), it seems to have been in the tail ends of random threads I'd
long ago stopped reading...

-Miles

-- 
Idiot, n. A member of a large and powerful tribe whose influence in human
affairs has always been dominant and controlling.

Re: linum.el?

[Richard Stallman]

    > Could people stop adding new features to the 22.x branch?

    That's a nice answer to my asking...

    BTW, where were you when socks.el, css-mode.el, vera-mode.el,
    vc-hg.el, vc-git.el, vc-bzr.el, vc-mtn.el, verilog-mode.el and
    blank-mode.el were added to the EMACS_22_BASE branch?

It's not out of the question to add a modular new feature to Emacs
22.2.  If it can't break anything else, it isn't risky.  But we may
not want to add any more of them now, since we want to start
pretesting it now.

Re: linum.el?

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> It's not out of the question to add a modular new feature to Emacs
> 22.2.  If it can't break anything else, it isn't risky.

I've found that even "modular" new features can be pretty annoying in
merging to the trunk -- even if they start out the same on both the
trunk and branch, many files seem to nevertheless generate a lot of
merge conflicts.  Often this is because people make the same change in
different ways on the trunk and on the branch (for instance, due to a
certain function being usable on the trunk but not on the branch).

New features seem to be a bigger problem in this regard than the
majority of the code-base, probably because they tend to get more
development.

-Miles

-- 
Bacchus, n. A convenient deity invented by the ancients as an excuse for
getting drunk.

Re: linum.el?

[Juanma Barranquero]

On Jan 30, 2008 10:00 PM, Miles Bader <miles@gnu.org> wrote:

> I've found that even "modular" new features can be pretty annoying in
> merging to the trunk -- even if they start out the same on both the
> trunk and branch, many files seem to nevertheless generate a lot of
> merge conflicts.

Miles, I know you shoulder most, if not all, the work in merging the
branches and the trunk, so I understand you position.

But the criteria for whether a package belongs to the release branch
or not should be mostly about its readiness and general usefulness.
How difficult is to maintain the branches synchronized it's IMHO
secondary (*only* as a criterion for inclusion, I hasten to repeat;
I'm not slighting you or the work you do).

That said, in the particular case of linum.el I don't have a strong
opinion for or against it being in 22.2. I find it useful and stable,
but I don't know if it is generally useful enough to merit increasing
your workload.

             Juanma

Re: linum.el?

[Miles Bader]

"Juanma Barranquero" <lekktu@gmail.com> writes:
> Miles, I know you shoulder most, if not all, the work in merging the
> branches and the trunk, so I understand you position.
>
> But the criteria for whether a package belongs to the release branch
> or not should be mostly about its readiness and general usefulness.
> How difficult is to maintain the branches synchronized it's IMHO
> secondary (...)

I understand that.

I think some of the "new features" on the release branch are important
(for instance, better support for modern VCS tools), but others have
quite honestly been extremely marginal.  To be honest, as far as I can
see the criteria for putting stuff on the release branch has more less
been "Eh, why not?"

I don't ask that the release be compromised to make my life easier --
but I also don't think it be a bad thing to pay a bit more heed to the
idea that the release branch is mainly for bug fixes and important
feature updates.

-Miles

-- 
Kilt, n. A costume sometimes worn by Scotchmen [sic] in America and Americans
in Scotland.

Re: linum.el?

[Juanma Barranquero]

On Jan 30, 2008 11:13 PM, Miles Bader <miles@gnu.org> wrote:

> I don't ask that the release be compromised to make my life easier --
> but I also don't think it be a bad thing to pay a bit more heed to the
> idea that the release branch is mainly for bug fixes and important
> feature updates.

I agree with you. The trouble is, with Emacs releases so infrequent,
people often feels compelled to include new features in the release
branch because otherwise they could take years to appear in a released
Emacs. I know that's the reason I suggested including linum.el in the
branch.

             Juanma

Re: linum.el?

[Richard Stallman]

    I've found that even "modular" new features can be pretty annoying in
    merging to the trunk -- even if they start out the same on both the
    trunk and branch, many files seem to nevertheless generate a lot of
    merge conflicts.

Most of the time I don't think we should make the decision about
installing something in Emacs 22 just based on that.

Re: linum.el?

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     I've found that even "modular" new features can be pretty annoying in
>     merging to the trunk -- even if they start out the same on both the
>     trunk and branch, many files seem to nevertheless generate a lot of
>     merge conflicts.
>
> Most of the time I don't think we should make the decision about
> installing something in Emacs 22 just based on that.

Sure, but it demonstrates that even stuff which is apparently "safe"
may have repercussions if installed.

Some of the stuff installed wasn't very important, but installed simply
because there seemed to be no downside to doing so; I think increase
maintenance burden is a downside though.

-Miles

-- 
`There are more things in heaven and earth, Horatio,
 Than are dreamt of in your philosophy.'

Re: linum.el?

[Stefan Monnier]

>> I still firmly believe that these cases should be handled via jit-lock
>> and/or fontification-functions and/or some extension of them.

> FWIW, I still firmly believe that we should include linum.el now, as
> it works quite well, and worry later about optimizations and such.

Oh yes, that as well,


        Stefan

Re: linum.el?

[Richard Stallman]

    I still firmly believe that these cases should be handled via jit-lock
    and/or fontification-functions and/or some extension of them.

If that works, I have nothing against it.  But I think it will be
difficult to go that way.  fontification works with text properties,
and linum.el uses overlays.

I don't think we want to use text properties for linum.el.  When you
copy fontified text into a buffer that allows arbitrary faces, it
stays fontified, and that is the right thing.  But we don't want it to
bring along line numbers from another buffer.

Re: linum.el?

[Stefan Monnier]

>     I still firmly believe that these cases should be handled via jit-lock
>     and/or fontification-functions and/or some extension of them.

> If that works, I have nothing against it.  But I think it will be
> difficult to go that way.  fontification works with text properties,
> and linum.el uses overlays.

That's irrelevant: `fontification-functions' uses 1 text property
(`fontified') to determine what's been fontified.  Whether the
"fontification" itself uses text-properties or overlays or bananas
doesn't matter as long as it's behavior is consistent with the behavior
of the `fontified' text property.  `glasses-mode' has been using
jit-lock together with overlays just fine.


        Stefan

Re: linum.el?

[Richard Stallman]

      `glasses-mode' has been using
    jit-lock together with overlays just fine.

What happens if you enable Glasses mode and Font Lock mode?
Do they manage to both work together using jit-lock?

Re: linum.el?

[Stefan Monnier]

>       `glasses-mode' has been using
>     jit-lock together with overlays just fine.

> What happens if you enable Glasses mode and Font Lock mode?
> Do they manage to both work together using jit-lock?

Yes, of course,


        Stefan

Re: linum.el?

[Richard Stallman]

    > What happens if you enable Glasses mode and Font Lock mode?
    > Do they manage to both work together using jit-lock?

    Yes, of course,

Interesting.  In that case, I agree that linum.el can also share this
mechanism.

I think we need to document this mechanism prominently in the Lisp
Manual.  jit-lock-register is not mentioned there at all.  Can you
write some text which is accurate?  Then I could polish it up for the
Lisp Manual.

Re: linum.el?

[Richard Stallman]

    > can linum.el do the job using `set-window-redisplay-end-trigger'
    > instead of this hook?

    It doesn't seem so to me.

Why doesn't it work?  It seems to be intended for this job.

    In the DEFVAR_LISP line, I think it should read "&Vwindow..." instead of
    "Vwindow...". Also, the new approach doesn't necessarily reach a
    fixpoint, i.e., the number of restarts can be unbounded.

That is true.  The code should probably set a flag so that the hook
doesn't run a second time; that will be right as long as the hook
functions are sufficiently tame, and if they aren't, at least it
won't mess up internally.

    It still fails to trigger (at least) on widening and when jumping to the
    beginning of buffers. Could it be changed to trigger then too?

That surprises me; it seems to be trying to detect that.

I think we should first try to make `set-window-redisplay-end-trigger'
do the job, because if it does, it will do a better (more efficient)
job.  Why do you think that won't work?  If you're right, I'll work more
on this patch.

Re: linum.el?

[Markus Triska]

Richard Stallman <rms@gnu.org> writes:

> Why doesn't it work?  It seems to be intended for this job.

For instance, how can `set-window-redisplay-end-trigger' be used to
generally and reliably trigger in the following cases?

*) widen a narrowed region
*) expand a collapsed thread in Gnus and similar programs
*) expand a tree in outline-mode, allout-mode and similar modes

> If you're right, I'll work more on this patch.

Thank you! Such a hook which reliably triggers in above cases and also
subsumes scrolling, window resizing, and insertion of new lines can be
very advantageous for other (new) modes as well.

Re: linum.el?

[Richard Stallman]

    For instance, how can `set-window-redisplay-end-trigger' be used to
    generally and reliably trigger in the following cases?

    *) widen a narrowed region
    *) expand a collapsed thread in Gnus and similar programs
    *) expand a tree in outline-mode, allout-mode and similar modes

It isn't meant to handle those cases.  Just the case of displaying text
that was previously off the end of the window.  I thought that was the
only remaining case that needed to be handled.

    Thank you! Such a hook which reliably triggers in above cases and also
    subsumes scrolling, window resizing, and insertion of new lines can be
    very advantageous for other (new) modes as well.

The problem with the new hook is that it will trigger on
ALL editing commands, as well as scrolling.  The only thing that
won't trigger it is cursor motion.  So it seems like a very inefficient
way to handle linum.  For instance, when you insert text, its hook
will run after every self-inserting character.

Isn't that going to be painful?

Re: linum.el?

[Markus Triska]

Richard Stallman <rms@gnu.org> writes:

> The problem with the new hook is that it will trigger on ALL editing
> commands, as well as scrolling. The only thing that won't trigger it
> is cursor motion.

That's already an improvement over the current situation, which is to
trigger after EVERY command by default. This in itself seems to be fast
enough for many users already, and the new hook makes it faster still.

> Isn't that going to be painful?

The new hook will cover an important middle ground between a hook that
is too eager (post-command-hook) and a set of various non-obvious hooks
that make it impossible not to miss cases. Also, I hope that it can fix
other issues: For example, I currently delay updates of line numbers
(for 0 seconds) to give Emacs a chance for updates after M-x goto-line
and possibly other cases after which the display seems not to be
up-to-date in post-command-hook. This delay is noticable (if you know
that it exists), and I hope the new hook makes it unnecessary.

Re: linum.el?

[Stefan Monnier]

> The new hook will cover an important middle ground between a hook that
> is too eager (post-command-hook) and a set of various non-obvious hooks
> that make it impossible not to miss cases. Also, I hope that it can fix

There should really only need to be 2 hooks: one to add linums to text,
and another to flush that info when it goes out-of-date.
I.e. jit-lock and before/after-change-functions.


        Stefan

Re: linum.el?

[Richard Stallman]

Ok, I will install the new hook.

Re: linum.el?

[Juanma Barranquero]

[Two weeks later...]

On 10/31/07, Juanma Barranquero <lekktu@gmail.com> wrote:

> What's the status wrt adding linum.el?

             Juanma