emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PATCH: make linum.el play nicely with other margin-setting extension


From: João Távora
Subject: Re: PATCH: make linum.el play nicely with other margin-setting extensions
Date: Sun, 15 Nov 2015 14:19:59 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (darwin)

Eli Zaretskii <address@hidden> writes:

>> From: address@hidden (João Távora)
>> Date: Fri, 13 Nov 2015 08:32:57 +0000
>> Cc: address@hidden, address@hidden
>> 
>> linum.el uses the left margin to make just enough to show numbered
>> indicators. The gist of this patch is: if there is enough space there
>> already, linum.el won't set the left margin width.
>> 
>> But if it does, it records that fact in a window parameter, to check
>> later, when turning off linum-mode, if resetting the margin is
>> needed. In this situation, resetting the margin is only needed if
>> linum-mode was the only extension to touch it, otherwise one considers
>> that some other extension or interactive "set-margins" call touched the
>> margins.
>> 
>> The way I implemented "some other extension ... touched the margins" is
>> an equal test of current margins vs remembered set margins.
>> 
>> It seems robust enough for now, but ideally linum-mode would know that
>> "his" margins have been overriden interactively or by some other
>> extension, and decide in accordance.
>
> Thanks for the explanations.  Could you please look at nlinum.el (in
> ELPA) and see whether its solution to this problem is better, or at
> least not worse, and satisfies the needs of darkroom-mode?  If so, I'd
> rather we adopted the nlinum solution in linum as well.
>
Just did that. It's Stefan's commit
77c062f41bfe20d5a7a259beeda1c2a26b95f5d0 to elpa.git (curiously not
included in the freshly package-install'ed nlinum.el, but maybe that's
intentional).

It seems basically the same thing as the patch I originally proposed,
only Stefan's a bit more convoluted, so perhaps I'm not reading it
correctly.

Anyway, I say it's "basically the same"" because both patches fail in
the following situation. The reason is that nlinum.el is not as "noisy"
as linum.el (as Martin noticed elsewhere in this thread):

   M-x nlinum-mode   ;; good, line numbers
   M-x darkroom-mode ;; good, line-numbers + darkroom margins
   M-x darkroom-mode ;; oops, no line-numbers OR darkroom margins, even
                     ;; after a bit of scrolling (linum works here)
   C-x 2             ;; change the window configuration, or force
                     ;; nlinum--setup-window somehow, and line-numbers
                     ;; restored

Also notice Stefan's comment

-  ;; FIXME: The interaction between different uses of the margin is
-  ;; problematic.  We should have a way for different packages to indicate (and
-  ;; change) their preference independently.

Meaning that we do need to find a way to p *both* nlinum.el and
darkroom.el to use some kind of ownership-awareness scheme.

I'm discussing such a scheme with Martin (and Juanma). 

João





reply via email to

[Prev in Thread] Current Thread [Next in Thread]