all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* linum.el?
@ 2007-10-31  9:40 Juanma Barranquero
  2007-10-31 15:47 ` linum.el? Stefan Monnier
                   ` (2 more replies)
  0 siblings, 3 replies; 35+ messages in thread
From: Juanma Barranquero @ 2007-10-31  9:40 UTC (permalink / raw)
  To: Emacs Devel

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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2007-10-31  9:40 linum.el? Juanma Barranquero
@ 2007-10-31 15:47 ` Stefan Monnier
  2007-10-31 23:58 ` linum.el? Richard Stallman
  2007-11-13 17:28 ` linum.el? Juanma Barranquero
  2 siblings, 0 replies; 35+ messages in thread
From: Stefan Monnier @ 2007-10-31 15:47 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: Emacs Devel

> 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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2007-10-31  9:40 linum.el? Juanma Barranquero
  2007-10-31 15:47 ` linum.el? Stefan Monnier
@ 2007-10-31 23:58 ` Richard Stallman
  2007-11-01  1:39   ` linum.el? Juanma Barranquero
  2007-11-13 17:28 ` linum.el? Juanma Barranquero
  2 siblings, 1 reply; 35+ messages in thread
From: Richard Stallman @ 2007-10-31 23:58 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: emacs-devel

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?

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2007-10-31 23:58 ` linum.el? Richard Stallman
@ 2007-11-01  1:39   ` Juanma Barranquero
       [not found]     ` <E1J6Y7I-0002zs-C9@fencepost.gnu.org>
  0 siblings, 1 reply; 35+ messages in thread
From: Juanma Barranquero @ 2007-11-01  1:39 UTC (permalink / raw)
  To: rms; +Cc: emacs-devel

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.

^ permalink raw reply related	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2007-10-31  9:40 linum.el? Juanma Barranquero
  2007-10-31 15:47 ` linum.el? Stefan Monnier
  2007-10-31 23:58 ` linum.el? Richard Stallman
@ 2007-11-13 17:28 ` Juanma Barranquero
  2 siblings, 0 replies; 35+ messages in thread
From: Juanma Barranquero @ 2007-11-13 17:28 UTC (permalink / raw)
  To: Emacs Devel

[Two weeks later...]

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

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

             Juanma

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
       [not found]     ` <E1J6Y7I-0002zs-C9@fencepost.gnu.org>
@ 2007-12-26 16:09       ` Markus Triska
  2007-12-26 23:28         ` linum.el? Stefan Monnier
  2007-12-27 13:42         ` linum.el? Richard Stallman
  0 siblings, 2 replies; 35+ messages in thread
From: Markus Triska @ 2007-12-26 16:09 UTC (permalink / raw)
  To: rms; +Cc: Juanma Barranquero, emacs-devel

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?

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2007-12-26 16:09       ` linum.el? Markus Triska
@ 2007-12-26 23:28         ` Stefan Monnier
  2007-12-27  0:06           ` linum.el? Juanma Barranquero
  2007-12-27 18:24           ` linum.el? Richard Stallman
  2007-12-27 13:42         ` linum.el? Richard Stallman
  1 sibling, 2 replies; 35+ messages in thread
From: Stefan Monnier @ 2007-12-26 23:28 UTC (permalink / raw)
  To: Markus Triska; +Cc: Juanma Barranquero, rms, emacs-devel

> 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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2007-12-26 23:28         ` linum.el? Stefan Monnier
@ 2007-12-27  0:06           ` Juanma Barranquero
  2007-12-27 18:24             ` linum.el? Richard Stallman
  2007-12-29  7:22             ` linum.el? Stefan Monnier
  2007-12-27 18:24           ` linum.el? Richard Stallman
  1 sibling, 2 replies; 35+ messages in thread
From: Juanma Barranquero @ 2007-12-27  0:06 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: rms, Markus Triska, emacs-devel

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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2007-12-26 16:09       ` linum.el? Markus Triska
  2007-12-26 23:28         ` linum.el? Stefan Monnier
@ 2007-12-27 13:42         ` Richard Stallman
  2007-12-27 19:18           ` linum.el? Markus Triska
  1 sibling, 1 reply; 35+ messages in thread
From: Richard Stallman @ 2007-12-27 13:42 UTC (permalink / raw)
  To: Markus Triska; +Cc: lekktu, emacs-devel

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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2007-12-26 23:28         ` linum.el? Stefan Monnier
  2007-12-27  0:06           ` linum.el? Juanma Barranquero
@ 2007-12-27 18:24           ` Richard Stallman
  2007-12-29  7:26             ` linum.el? Stefan Monnier
  1 sibling, 1 reply; 35+ messages in thread
From: Richard Stallman @ 2007-12-27 18:24 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: lekktu, markus.triska, emacs-devel

    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.

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2007-12-27  0:06           ` linum.el? Juanma Barranquero
@ 2007-12-27 18:24             ` Richard Stallman
  2008-01-20 23:50               ` linum.el? Juanma Barranquero
  2007-12-29  7:22             ` linum.el? Stefan Monnier
  1 sibling, 1 reply; 35+ messages in thread
From: Richard Stallman @ 2007-12-27 18:24 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: monnier, markus.triska, emacs-devel

    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.

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2007-12-27 13:42         ` linum.el? Richard Stallman
@ 2007-12-27 19:18           ` Markus Triska
  2007-12-28 13:55             ` linum.el? Richard Stallman
  0 siblings, 1 reply; 35+ messages in thread
From: Markus Triska @ 2007-12-27 19:18 UTC (permalink / raw)
  To: rms; +Cc: lekktu, emacs-devel

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.

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2007-12-27 19:18           ` linum.el? Markus Triska
@ 2007-12-28 13:55             ` Richard Stallman
  2007-12-28 20:22               ` linum.el? Markus Triska
  0 siblings, 1 reply; 35+ messages in thread
From: Richard Stallman @ 2007-12-28 13:55 UTC (permalink / raw)
  To: Markus Triska; +Cc: lekktu, emacs-devel

    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?

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2007-12-28 13:55             ` linum.el? Richard Stallman
@ 2007-12-28 20:22               ` Markus Triska
  2007-12-29  7:31                 ` linum.el? Stefan Monnier
  2007-12-29 13:51                 ` linum.el? Richard Stallman
  0 siblings, 2 replies; 35+ messages in thread
From: Markus Triska @ 2007-12-28 20:22 UTC (permalink / raw)
  To: rms; +Cc: lekktu, emacs-devel

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.

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2007-12-27  0:06           ` linum.el? Juanma Barranquero
  2007-12-27 18:24             ` linum.el? Richard Stallman
@ 2007-12-29  7:22             ` Stefan Monnier
  1 sibling, 0 replies; 35+ messages in thread
From: Stefan Monnier @ 2007-12-29  7:22 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: rms, Markus Triska, emacs-devel

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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2007-12-27 18:24           ` linum.el? Richard Stallman
@ 2007-12-29  7:26             ` Stefan Monnier
  2007-12-29 17:48               ` linum.el? Richard Stallman
  0 siblings, 1 reply; 35+ messages in thread
From: Stefan Monnier @ 2007-12-29  7:26 UTC (permalink / raw)
  To: rms; +Cc: lekktu, markus.triska, emacs-devel

>     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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2007-12-28 20:22               ` linum.el? Markus Triska
@ 2007-12-29  7:31                 ` Stefan Monnier
  2007-12-29 13:51                 ` linum.el? Richard Stallman
  1 sibling, 0 replies; 35+ messages in thread
From: Stefan Monnier @ 2007-12-29  7:31 UTC (permalink / raw)
  To: Markus Triska; +Cc: lekktu, rms, emacs-devel

> 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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2007-12-28 20:22               ` linum.el? Markus Triska
  2007-12-29  7:31                 ` linum.el? Stefan Monnier
@ 2007-12-29 13:51                 ` Richard Stallman
  1 sibling, 0 replies; 35+ messages in thread
From: Richard Stallman @ 2007-12-29 13:51 UTC (permalink / raw)
  To: Markus Triska; +Cc: lekktu, emacs-devel

Ok, I will install the new hook.

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2007-12-29  7:26             ` linum.el? Stefan Monnier
@ 2007-12-29 17:48               ` Richard Stallman
  2008-01-02  2:12                 ` linum.el? Stefan Monnier
  0 siblings, 1 reply; 35+ messages in thread
From: Richard Stallman @ 2007-12-29 17:48 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: lekktu, markus.triska, emacs-devel

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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2007-12-29 17:48               ` linum.el? Richard Stallman
@ 2008-01-02  2:12                 ` Stefan Monnier
  2008-01-03  9:50                   ` linum.el? Richard Stallman
  0 siblings, 1 reply; 35+ messages in thread
From: Stefan Monnier @ 2008-01-02  2:12 UTC (permalink / raw)
  To: rms; +Cc: lekktu, markus.triska, emacs-devel

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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2008-01-02  2:12                 ` linum.el? Stefan Monnier
@ 2008-01-03  9:50                   ` Richard Stallman
  0 siblings, 0 replies; 35+ messages in thread
From: Richard Stallman @ 2008-01-03  9:50 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: lekktu, markus.triska, emacs-devel

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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2007-12-27 18:24             ` linum.el? Richard Stallman
@ 2008-01-20 23:50               ` Juanma Barranquero
  2008-01-30  2:07                 ` linum.el? Juanma Barranquero
  0 siblings, 1 reply; 35+ messages in thread
From: Juanma Barranquero @ 2008-01-20 23:50 UTC (permalink / raw)
  To: rms; +Cc: monnier, markus.triska, emacs-devel

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

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2008-01-20 23:50               ` linum.el? Juanma Barranquero
@ 2008-01-30  2:07                 ` Juanma Barranquero
  2008-01-30  3:03                   ` linum.el? Miles Bader
  0 siblings, 1 reply; 35+ messages in thread
From: Juanma Barranquero @ 2008-01-30  2:07 UTC (permalink / raw)
  To: rms; +Cc: Emacs Devel

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




^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2008-01-30  2:07                 ` linum.el? Juanma Barranquero
@ 2008-01-30  3:03                   ` Miles Bader
  2008-01-30  3:18                     ` linum.el? Juanma Barranquero
  0 siblings, 1 reply; 35+ messages in thread
From: Miles Bader @ 2008-01-30  3:03 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: rms, Emacs Devel

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




^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2008-01-30  3:03                   ` linum.el? Miles Bader
@ 2008-01-30  3:18                     ` Juanma Barranquero
  2008-01-30 13:25                       ` linum.el? Miles Bader
  2008-01-30 20:52                       ` linum.el? Richard Stallman
  0 siblings, 2 replies; 35+ messages in thread
From: Juanma Barranquero @ 2008-01-30  3:18 UTC (permalink / raw)
  To: Miles Bader; +Cc: rms, Emacs Devel

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




^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2008-01-30  3:18                     ` linum.el? Juanma Barranquero
@ 2008-01-30 13:25                       ` Miles Bader
  2008-01-30 14:53                         ` linum.el? Juanma Barranquero
  2008-01-30 20:52                       ` linum.el? Richard Stallman
  1 sibling, 1 reply; 35+ messages in thread
From: Miles Bader @ 2008-01-30 13:25 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: rms, Emacs Devel

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




^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2008-01-30 13:25                       ` linum.el? Miles Bader
@ 2008-01-30 14:53                         ` Juanma Barranquero
  2008-01-30 17:01                           ` linum.el? Miles Bader
  0 siblings, 1 reply; 35+ messages in thread
From: Juanma Barranquero @ 2008-01-30 14:53 UTC (permalink / raw)
  To: Miles Bader; +Cc: rms, Emacs Devel

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




^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2008-01-30 14:53                         ` linum.el? Juanma Barranquero
@ 2008-01-30 17:01                           ` Miles Bader
  0 siblings, 0 replies; 35+ messages in thread
From: Miles Bader @ 2008-01-30 17:01 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: rms, Emacs Devel

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




^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2008-01-30  3:18                     ` linum.el? Juanma Barranquero
  2008-01-30 13:25                       ` linum.el? Miles Bader
@ 2008-01-30 20:52                       ` Richard Stallman
  2008-01-30 21:00                         ` linum.el? Miles Bader
  1 sibling, 1 reply; 35+ messages in thread
From: Richard Stallman @ 2008-01-30 20:52 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: emacs-devel, miles

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




^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2008-01-30 20:52                       ` linum.el? Richard Stallman
@ 2008-01-30 21:00                         ` Miles Bader
  2008-01-30 21:27                           ` linum.el? Juanma Barranquero
  2008-01-31 18:51                           ` linum.el? Richard Stallman
  0 siblings, 2 replies; 35+ messages in thread
From: Miles Bader @ 2008-01-30 21:00 UTC (permalink / raw)
  To: rms; +Cc: Juanma Barranquero, emacs-devel

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.




^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2008-01-30 21:00                         ` linum.el? Miles Bader
@ 2008-01-30 21:27                           ` Juanma Barranquero
  2008-01-30 22:13                             ` linum.el? Miles Bader
  2008-01-31 18:51                           ` linum.el? Richard Stallman
  1 sibling, 1 reply; 35+ messages in thread
From: Juanma Barranquero @ 2008-01-30 21:27 UTC (permalink / raw)
  To: Miles Bader; +Cc: rms, emacs-devel

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




^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2008-01-30 21:27                           ` linum.el? Juanma Barranquero
@ 2008-01-30 22:13                             ` Miles Bader
  2008-01-30 22:33                               ` linum.el? Juanma Barranquero
  0 siblings, 1 reply; 35+ messages in thread
From: Miles Bader @ 2008-01-30 22:13 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: rms, emacs-devel

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




^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2008-01-30 22:13                             ` linum.el? Miles Bader
@ 2008-01-30 22:33                               ` Juanma Barranquero
  0 siblings, 0 replies; 35+ messages in thread
From: Juanma Barranquero @ 2008-01-30 22:33 UTC (permalink / raw)
  To: Miles Bader; +Cc: rms, emacs-devel

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




^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2008-01-30 21:00                         ` linum.el? Miles Bader
  2008-01-30 21:27                           ` linum.el? Juanma Barranquero
@ 2008-01-31 18:51                           ` Richard Stallman
  2008-01-31 22:05                             ` linum.el? Miles Bader
  1 sibling, 1 reply; 35+ messages in thread
From: Richard Stallman @ 2008-01-31 18:51 UTC (permalink / raw)
  To: Miles Bader; +Cc: lekktu, emacs-devel

    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.





^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: linum.el?
  2008-01-31 18:51                           ` linum.el? Richard Stallman
@ 2008-01-31 22:05                             ` Miles Bader
  0 siblings, 0 replies; 35+ messages in thread
From: Miles Bader @ 2008-01-31 22:05 UTC (permalink / raw)
  To: rms; +Cc: lekktu, emacs-devel

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




^ permalink raw reply	[flat|nested] 35+ messages in thread

end of thread, other threads:[~2008-01-31 22:05 UTC | newest]

Thread overview: 35+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-10-31  9:40 linum.el? Juanma Barranquero
2007-10-31 15:47 ` linum.el? Stefan Monnier
2007-10-31 23:58 ` linum.el? Richard Stallman
2007-11-01  1:39   ` linum.el? Juanma Barranquero
     [not found]     ` <E1J6Y7I-0002zs-C9@fencepost.gnu.org>
2007-12-26 16:09       ` linum.el? Markus Triska
2007-12-26 23:28         ` linum.el? Stefan Monnier
2007-12-27  0:06           ` linum.el? Juanma Barranquero
2007-12-27 18:24             ` linum.el? Richard Stallman
2008-01-20 23:50               ` linum.el? Juanma Barranquero
2008-01-30  2:07                 ` linum.el? Juanma Barranquero
2008-01-30  3:03                   ` linum.el? Miles Bader
2008-01-30  3:18                     ` linum.el? Juanma Barranquero
2008-01-30 13:25                       ` linum.el? Miles Bader
2008-01-30 14:53                         ` linum.el? Juanma Barranquero
2008-01-30 17:01                           ` linum.el? Miles Bader
2008-01-30 20:52                       ` linum.el? Richard Stallman
2008-01-30 21:00                         ` linum.el? Miles Bader
2008-01-30 21:27                           ` linum.el? Juanma Barranquero
2008-01-30 22:13                             ` linum.el? Miles Bader
2008-01-30 22:33                               ` linum.el? Juanma Barranquero
2008-01-31 18:51                           ` linum.el? Richard Stallman
2008-01-31 22:05                             ` linum.el? Miles Bader
2007-12-29  7:22             ` linum.el? Stefan Monnier
2007-12-27 18:24           ` linum.el? Richard Stallman
2007-12-29  7:26             ` linum.el? Stefan Monnier
2007-12-29 17:48               ` linum.el? Richard Stallman
2008-01-02  2:12                 ` linum.el? Stefan Monnier
2008-01-03  9:50                   ` linum.el? Richard Stallman
2007-12-27 13:42         ` linum.el? Richard Stallman
2007-12-27 19:18           ` linum.el? Markus Triska
2007-12-28 13:55             ` linum.el? Richard Stallman
2007-12-28 20:22               ` linum.el? Markus Triska
2007-12-29  7:31                 ` linum.el? Stefan Monnier
2007-12-29 13:51                 ` linum.el? Richard Stallman
2007-11-13 17:28 ` linum.el? Juanma Barranquero

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.