[Top][All Lists]

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

Re: Better handling of window margins

From: John Wiegley
Subject: Re: Better handling of window margins
Date: Fri, 04 Dec 2015 07:49:25 -0500
User-agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.5 (darwin)

>>>>> Joost Kremers <address@hidden> writes:

> In two recent threads, one here ("Window splitting issues with margins") and
> one on bugs.gnu.emacs (bug 22009), some issues were discussed with window
> margins that could stand improvement. Two issues specifically came up[...]

Hi Joost,

I appreciate your willingness to grapple with this problem. Something feels
overly complex, however, about trying to satisfy the needs of various modes
(linum, darkroom, etc) in this way. It sounds you are trying to adapt an
existing mechanism to a specific need, but this will lead to both a more
complex mechanism, and more unmet needs in future.

This all makes me wonder whether our notion of "window" has become outdated,
based on what new authors are trying to make Emacs do. Richard has long wanted
better WYSIWYG behavior from Emacs, and these issues seem to underscore our
lack of support for such behavior.

Perhaps what we need is a richer notion of "window", with multiple sub-areas,
some for content, some for positioning, etc. This would make it possible to
define exactly what the appearance of a window should be, at a pixel level.
Given such a mechanism, fringes and margins would be distinguished merely as
different display areas within a window, rather than being the first-class
entities they are now. (For example, variables like `fringes-outside-margins'
would not be necessary, if one were able to manipulate such display areas in a
general fashion).

I strongly want to avoid extending the APIs of long-standing capabilities --
such as windows and frames -- just to make new features possible, or to enable
cooperation among non-core modes. If we're going to submit to that sort of
pain, it's worth considering what sort of design we'd if we had the freedom to
do it all over again. Then we can think of how to adapt such a clean-slate
approach into our existing environment.

John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Attachment: signature.asc
Description: PGP signature

reply via email to

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