[Top][All Lists]

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

Re: Window splitting issues with margins

From: Joost Kremers
Subject: Re: Window splitting issues with margins
Date: Thu, 12 Nov 2015 22:38:38 +0100
User-agent: mu4e 0.9.13; emacs

On Do, Nov 12 2015, Eli Zaretskii <address@hidden> wrote:
>> Date: Thu, 12 Nov 2015 15:31:08 +0100
>> From: martin rudalics <address@hidden>
>> 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.



[1] E.g., here:


and here:


Joost Kremers
Life has its moments

reply via email to

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