From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Better handling of window margins
Date: Fri, 04 Dec 2015 08:22:26 -0500 [thread overview]
Message-ID: <jwv7fkupd8z.fsf-monnier+Inbox@gnu.org> (raw)
In-Reply-To: <83d1umiq9u.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 04 Dec 2015 10:14:53 +0200")
>> WRT to sizing the margin, I think if we want to "do it right" it'd make
>> sense to provide an Elisp-layer that defines two functions which could
>> look like:
>> (window-margin-register OWNER SIZING-DESCRIPTOR)
>> and
>> (window-margin-unregister OWNER)
>> so those two functions can appropriately combine the SIZING-DESCRIPTORS
>> still active.
> Not sure why window-margin-register and window-margin-unregister
> couldn't be set-window-margins with additional arguments.
Because we want this to be flexible, so it's better written in Elisp, so
it's an extra layer, so it's another function. set-window-margins then
becomes an internal function that we'd encourage people to stop using.
>> Not sure what SIZING-DESCRIPTOR should look like (it could be
>> a function which takes a size and returns a new size).
> I don't think such a function can be implemented by any particular
> mode, because a mode only knows well what it needs from the margins,
> it has no better idea about other modes' needs than the rest of Emacs.
That's the point of having SIZING-DESCRIPTOR be a function: it receives
a description of the margin chosen by "all other users" and adjusts it
according to its own needs.
> functions for it. To say nothing of the fact that having more than
> one function again raises a problem of in what order to apply them,
> and what would be the results of applying conflicting functions in any
> order.
We'd push this responsibility on the package authors.
If SIZING-DESCRIPTOR just returns the sum (or the max) of the provided
size and its own use, ordering doesn't matter, for example.
And for the remaining cases we could rely on add-function's `depth' to
impose a particular ordering.
Stefan
next prev parent reply other threads:[~2015-12-04 13:22 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-01 21:28 Better handling of window margins Joost Kremers
2015-12-02 8:23 ` martin rudalics
2015-12-02 13:41 ` Eli Zaretskii
2015-12-02 17:43 ` martin rudalics
2015-12-02 17:53 ` Eli Zaretskii
2015-12-02 18:11 ` martin rudalics
2015-12-03 6:49 ` Eli Zaretskii
2015-12-03 18:16 ` martin rudalics
2015-12-03 20:09 ` Eli Zaretskii
2015-12-03 20:43 ` Stefan Monnier
2015-12-04 8:14 ` Eli Zaretskii
2015-12-04 13:22 ` Stefan Monnier [this message]
2015-12-04 14:46 ` Eli Zaretskii
2015-12-04 17:30 ` Stefan Monnier
2015-12-04 18:45 ` Eli Zaretskii
2015-12-04 20:55 ` Stefan Monnier
2015-12-04 21:13 ` Eli Zaretskii
2015-12-04 21:33 ` Stefan Monnier
2015-12-05 7:56 ` Eli Zaretskii
2015-12-05 15:17 ` Stefan Monnier
2015-12-05 15:49 ` Eli Zaretskii
2015-12-06 4:27 ` Stefan Monnier
2015-12-06 5:02 ` John Wiegley
2015-12-06 16:10 ` Eli Zaretskii
2015-12-06 20:24 ` Yuri Khan
2015-12-07 3:32 ` Eli Zaretskii
2015-12-07 10:35 ` Yuri Khan
2015-12-07 16:39 ` Eli Zaretskii
2015-12-07 0:29 ` John Wiegley
2015-12-07 16:24 ` Eli Zaretskii
2015-12-07 17:35 ` John Wiegley
2015-12-07 17:38 ` Achim Gratz
2015-12-07 17:41 ` John Wiegley
2015-12-07 17:50 ` Achim Gratz
2015-12-07 17:36 ` Stefan Monnier
2015-12-07 17:39 ` John Wiegley
2015-12-07 18:42 ` Stefan Monnier
2015-12-07 19:14 ` John Wiegley
2015-12-04 8:07 ` martin rudalics
2015-12-04 9:42 ` Eli Zaretskii
2015-12-04 10:21 ` martin rudalics
2015-12-04 15:34 ` Eli Zaretskii
2015-12-04 16:56 ` martin rudalics
2015-12-04 18:34 ` Eli Zaretskii
2015-12-04 19:23 ` martin rudalics
2015-12-02 19:52 ` Joost Kremers
2015-12-03 7:17 ` Eli Zaretskii
2015-12-02 19:55 ` Joost Kremers
2015-12-03 7:21 ` Eli Zaretskii
2015-12-04 12:49 ` John Wiegley
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=jwv7fkupd8z.fsf-monnier+Inbox@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/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.