[Top][All Lists]

[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: Fri, 13 Nov 2015 08:32:57 +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: Thu, 12 Nov 2015 12:23:02 +0000
>> The problem popped up in darkroom.el which is in ELPA. The margins
>> aren't correctly in any situation intermingling calls to M-x linum-mode
>> and M-x darkroom-mode.
>> This patch to linum.el appears to work nicely, and probably fixes stuff
>> for other margin-setting extensions, but I'd like a review from the
>> maintainer or someone else more knowledgeable:
> Thanks.
> I'm not familiar with darkroom-mode.  Can you tell in more detail what
> problem your patch attempts to solve?

Sure, darkroom-mode (and many other "writeroom" clones) hide visual
distractions to simulate an 1980's text-processing experience. :-) In
Emacs that means adjusting the left and right margins to center the text
on a narrower section of the window.

So, if you `M-x linum-mode` after `M-x darkroom-mode` you almost
immediately lose the left margin that darkroom-mode set: it now now only
shows the linum line numbers numbers.

Similarly, if you `M-x darkroom-mode` after `M-x linum-mode`,
`darkroom-mode` can't set the margin.

Other problems happen when exiting those modes.

Read on for some explanation regarding the workings of the patch, or
read the patch itself.

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

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.

In fact, this pattern of multiple extensions/commands competing for a
Emacs setting is relatively common, I wonder we could abstract some more
generic solution... 

João Távora

reply via email to

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