bug#20674: linum-mode overwrites existing margin width

bug#20674: linum-mode overwrites existing margin width

[Paul W. Rankin]

I set the window left margin to 25 columns, then activated linum-mode,
which sets the left margin to 3 columns (to accommodate the number of
figures in the total line numbers).

Expected behaviour:

linum-mode should only expand left margin as needed, not
overwrite/shrink it.

Example steps to reproduce:

$ emacs -Q

;; in *scratch* buffer

M-: (set-window-margins (selected-window) N) ;; where N is any number > 1

;; window margins are set to N columns.

M-x linum-mode

;; left window margin is reduced to 1 column

Suggestions to remedy:

Either linum-mode.el ~ L167 should be changed to accommodate existing
margin width, setting width to the maximum of existing or calculated
value, or the function should test whether the calculated width exceeds
the current margin width, and only update the window if necessary.

bug#20674: linum-mode overwrites existing margin width

[Eli Zaretskii]

> From: "Paul W. Rankin" <hello@paulwrankin.com>
> Date: Wed, 27 May 2015 17:56:03 +1000
> 
> I set the window left margin to 25 columns, then activated linum-mode,
> which sets the left margin to 3 columns (to accommodate the number of
> figures in the total line numbers).
> 
> Expected behaviour:
> 
> linum-mode should only expand left margin as needed, not
> overwrite/shrink it.

I think linum-mode is incompatible with any other means of putting
anything inside the display margins, because it actually writes
there.  The width of the margin is just the tip of the iceberg,
because at best you will have margins whose contents are overwritten
by linum-mode.

bug#20674: linum-mode overwrites existing margin width

[Paul W. Rankin]

On Thu, 28 May 2015, at 01:50 AM, Eli Zaretskii wrote:
> I think linum-mode is incompatible with any other means of putting
> anything inside the display margins, because it actually writes
> there.  The width of the margin is just the tip of the iceberg,
> because at best you will have margins whose contents are overwritten
> by linum-mode.

The incompatibility was found in a minor mode I maintain called
olivetti.el, which only sets the window margin widths in order to centre
the text body, it does not display anything within the margins.

In theory, linum-mode.el should be compatible with because it should
only require increasing the margin width on an as-needed basis.

bug#20674: linum-mode overwrites existing margin width

[Eli Zaretskii]

> From: "Paul W. Rankin" <hello@paulwrankin.com>
> Cc: 20674@debbugs.gnu.org
> Date: Thu, 28 May 2015 14:32:56 +1000
> 
> > I think linum-mode is incompatible with any other means of putting
> > anything inside the display margins, because it actually writes
> > there.  The width of the margin is just the tip of the iceberg,
> > because at best you will have margins whose contents are overwritten
> > by linum-mode.
> 
> The incompatibility was found in a minor mode I maintain called
> olivetti.el, which only sets the window margin widths in order to centre
> the text body, it does not display anything within the margins.
> 
> In theory, linum-mode.el should be compatible with because it should
> only require increasing the margin width on an as-needed basis.

Linum-mode is evil: it wants total control of the left margin.  Not
only does it enlarge the margin width as it sees fit, it also makes it
smaller and even resets it back to zero upon certain events, such as
changing the buffer's major mode.

So making linum-mode compatible with other modes that change the
margin width would require to record, in every buffer (or maybe even
every window) the value of the margin width before linum-mode was
turned on, and then take that value in consideration when linum-mode
wants to make any change to the margin width.  And then we will no
doubt hear from someone who has linum-mode turned on by default, in
which case there's no opportunity to record the initial margin width,
and we will have to make set-window-margins be aware of linum-mode in
some way, so it could do what you want.

Is this hassle justified for covering only use cases like yours, where
the "other" mode puts nothing in the margins?  We are clearly talking
about making a subset of margin users somewhat less incompatible with
linum-mode, and we are building that on very shaky foundations.

And even if we decide these complications are worthwhile, there will
be problems when linum-mode wants a margin that is wider than what
your mode sets, because linum-mode only changes the left margin, so
your mode will then be unable to keep the text centered and of the
required width, right?  So your mode will be semi-broken by linum-mode
anyway.

Bottom line: this makes very little sense to me.

May I suggest that you switch olivetti.el to using other display
features, such as line-prefix and wrap-prefix, instead?  (You can keep
the right margin, if you want, since linum-mode does not try to usurp
that one.)  Or just declare that your mode is incompatible with
linum-mode.

bug#20674: linum-mode overwrites existing margin width

[Stefan Monnier]

> Either linum-mode.el ~ L167 should be changed to accommodate existing
> margin width, setting width to the maximum of existing or calculated
> value, or the function should test whether the calculated width exceeds
> the current margin width, and only update the window if necessary.

You might like to try the development version of nlinum.el where I've
implemented something like that.

http://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/packages/nlinum/nlinum.el


        Stefan