all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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



  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.