all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Joost Kremers <joostkremers@fastmail.fm>
To: Eli Zaretskii <eliz@gnu.org>
Cc: martin rudalics <rudalics@gmx.at>, emacs-devel@gnu.org
Subject: Re: Window splitting issues with margins
Date: Thu, 12 Nov 2015 22:38:38 +0100	[thread overview]
Message-ID: <8737wax5i9.fsf@fastmail.fm> (raw)
In-Reply-To: <83twori3n3.fsf@gnu.org>


On Do, Nov 12 2015, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 12 Nov 2015 15:31:08 +0100
>> From: martin rudalics <rudalics@gmx.at>
>> 
>> Deciding when and how to auto-adjust margins is not trivial.
>
> I'm not sure margins should be auto-adjusted at all.  Whatever
> application sets up those margins, they most probably need all that
> space, and Emacs should not second guess such applications.  For
> example, linum-mode sets the margin just wide enough to display the
> longest line number; make the margin smaller, and the numbers will be
> truncated.  That's a bug in my book.

Perhaps what is needed is for a mode that uses the margins to be able to
specify a minimum size for them, so that a window-resize can take that
into account. That would allow other modes to use the margin flexibly.

In fact, IIUC this is sorta what the patch that João Távora posted
earlier tries to do, but inside linum-mode. I have a package
writeroom-mode that is similar to his darkroom-mode and I've received
similar bug reports saying that writeroom-mode and linum-mode don't play
nice together.[1]

What writeroom-mode and darkroom-mode both do is use the margins to
display the text of a buffer in the center of the window, to create a
"distraction-free writing environment", as it's called. writeroom-mode
lets you specify the width of the text and adjusts the margins to make
that happen. (Actually, it uses visual-fill-column to do that.) With
every window resize, the margins are readjusted. So there's no
requirement that the margins have a minimum width, the width depends on
whatever the window width happens to be.

linum-mode seems to assume that no-one else is using the margins and
simply sets the left margin to the width it needs for itself. It'd be
great if linum-mode (or any other mode of course) would be able to
specify that it needs the left margin to be at least n characters wide
and if there were an easy way for other packages to respect this.

If it would also be possible to specify a margin width without locking
it, then this could help with the issue I posted about. If it's known
that parts of the margins are reserved, while others are not, the
window-splitting functions know what part of the margins they can safely
assume will be adjusted.

Perhaps an example to make things clearer: assume a window width of 200
characters. I want my text to be 80 chars wide and centered, so the left
and right margins need to be (200-80)/2 = 60 each. Package X sets the
margins to 60, but doesn't lock them. linum-mode says it needs a left
margin of at least 4, so a width of 4 chars is locked. Now, the window
is split and window-splittable-p must determine if the window can be
split horizontally. Currently, it will base its judgement on the width
of the text area, which is 80, the result being `nil' for 'no, the
window cannot be split horizontally'. If a mode could "lock" part of the
margin, it would know that it can assume a width of 200-4 = 196 and
return `t' for 'yes, the window can be split horizontally'. The window
is split and package X (through `window-configuration-change-hook')
adjusts the margins.

HTH

Joost




[1] E.g., here:

https://github.com/joostkremers/writeroom-mode/issues/20

and here:

https://github.com/joostkremers/writeroom-mode/issues/12

-- 
Joost Kremers
Life has its moments



  reply	other threads:[~2015-11-12 21:38 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-12 13:04 Window splitting issues with margins Joost Kremers
2015-11-12 14:31 ` martin rudalics
2015-11-12 16:28   ` Eli Zaretskii
2015-11-12 21:38     ` Joost Kremers [this message]
2015-11-13  8:04       ` martin rudalics
2015-11-13  8:40       ` Eli Zaretskii
2015-11-13 10:01         ` martin rudalics
2015-11-13 13:54           ` Eli Zaretskii
2015-11-13 14:53             ` martin rudalics
2015-11-13 18:34               ` Eli Zaretskii
2015-11-12 22:14   ` Joost Kremers
2015-11-13  8:04     ` martin rudalics
2015-11-13  8:43       ` Eli Zaretskii
2015-11-13 10:02         ` martin rudalics
2015-11-14 20:34         ` Joost Kremers
2015-11-16 15:53           ` Eli Zaretskii
2015-11-16 16:56             ` Joost Kremers
2015-11-16 18:56               ` martin rudalics
2015-11-16 20:11                 ` Joost Kremers
2015-11-17  8:35                   ` martin rudalics
2015-11-19 13:46                     ` Joost Kremers
2015-11-20  8:21                       ` martin rudalics
2015-11-25 13:10                         ` Joost Kremers
2015-11-24 12:59                       ` Joost Kremers
2015-11-24 19:26                         ` martin rudalics
2015-11-25 19:53                           ` Joost Kremers
2015-11-26  8:23                             ` martin rudalics
2015-11-26 15:46                               ` Eli Zaretskii
2015-11-26 16:58                                 ` martin rudalics
2015-11-26 17:13                                   ` Eli Zaretskii
2015-11-26 18:04                                     ` martin rudalics
2015-11-26 18:32                                       ` Eli Zaretskii
2015-11-27  8:26                                         ` martin rudalics
2015-11-27  9:00                                           ` Eli Zaretskii
2015-11-28 10:22                                             ` martin rudalics
2015-11-28 11:13                                               ` Eli Zaretskii
2015-11-14 20:47       ` Joost Kremers
2015-11-16 17:02         ` John Wiegley
2015-11-16 10:51       ` Yuri Khan

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

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

  git send-email \
    --in-reply-to=8737wax5i9.fsf@fastmail.fm \
    --to=joostkremers@fastmail.fm \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=rudalics@gmx.at \
    /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 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.