unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: "Paul W. Rankin" <hello@paulwrankin.com>
Cc: 20674@debbugs.gnu.org
Subject: bug#20674: linum-mode overwrites existing margin width
Date: Thu, 28 May 2015 17:36:35 +0300	[thread overview]
Message-ID: <83d21kydjg.fsf@gnu.org> (raw)
In-Reply-To: <1432787576.1045910.280092697.36DC47ED@webmail.messagingengine.com>

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





  reply	other threads:[~2015-05-28 14:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-27  7:56 bug#20674: linum-mode overwrites existing margin width Paul W. Rankin
2015-05-27 15:50 ` Eli Zaretskii
2015-05-28  4:32   ` Paul W. Rankin
2015-05-28 14:36     ` Eli Zaretskii [this message]
2015-05-28 18:30 ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83d21kydjg.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=20674@debbugs.gnu.org \
    --cc=hello@paulwrankin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).