unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Joost Kremers <joostkremers@fastmail.fm>
To: martin rudalics <rudalics@gmx.at>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Re: Window splitting issues with margins
Date: Wed, 25 Nov 2015 20:53:27 +0100	[thread overview]
Message-ID: <877fl5lutk.fsf@fastmail.fm> (raw)
In-Reply-To: <5654B9C9.6010503@gmx.at>


On Di, Nov 24 2015, martin rudalics <rudalics@gmx.at> wrote:
> I think we agree that ‘nlinum-mode’ and ‘visual-fill-column-mode’ have
> to file their requests via ‘set-window-margins’ and the latter uses the
> maximum value requested.  All this is simple until the moment when the
> mode that requested the current maximum size gets turned off.
>
> In any case I would maintain a window parameter as a list of requested
> margin widths like ((4 . 0) (40 . 40)).  Basically there are then two
> ways to handle this: Let ‘set-window-margins’ decide or let the modes
> agree among themselves.
>
> For the former, when a mode gets turned off it calls, for example,
> (set-window-margins nil -40 -40) and ‘set-window-margins’ decides that
> there is one contender less for a left margin width of 40 and a right
> margin width of 40 and it may have to set new widths.  -0 might require
> special care.
>
> Having the modes agree among themselves means that a mode that wants to
> change the margins has to consult that parameter, add its own value to
> it and only if its own value is larger than the current value, use it in
> a call to ‘set-window-margins’.  When a mode is turned off, it has to
> remove its value from the window parameter, and possibly call
> ‘set-window-margins’ with the new largest value.
>
> WDYT?

One question that came up while reading this is whether it is possible
for two modes to display something in the (same) margin. If yes, your
proposal will probably not work right. If we have, say, nlinum-mode
requesting a left margin of 4 and some-other-mode requesting a margin of
2, also in order to display something there, the window parameter would
be ((4 . 0) (2 . 0)). Then the actual left margin width should not be
(max 4 2) but (+ 4 2).

writeroom-mode is different, however, because it just wants the margins
to be a certain width, regardless of what other packages display in them.

I would probably use a window parameter that stores the requested margin
widths in an alist with the requesting modes as keys, e.g.:

((nlinum 4 . 0) (some-other-mode 2 . 0))

(The symbol can be freely chosen by the mode, but it should obviously be
properly prefixed.) `set-window-margins' then sets the margins to the
sum of the requested values.

As a special case, the symbol can also be t, which indicates that the
associated widths are not additive but minimum widths. This is what
writeroom-mode would use. So if the window parameter has the value:

((nlinum 4 . 0) (some-other-mode 2 . 0) (t 40 . 40))

a call to set-window-margins would set the margins to (40 . 40), because
4+2=6 and 6<40. But if it has the value:

((nlinum 4 . 0) (some-other-mode 2 . 0) (t 4 . 4))

`set-window-margins' would set the margins to (6 . 4), because
nlinum-mode and some-other-mode request a total width of 6, while the
minimum width is 4.

This would require adding an additional argument to set-window-margins
for the symbol to be used as a key in the window-margin alist. If the
symbol is left out, set-window-margins would behave in the old way,
setting window margins to absolute values and ignoring the window-margin
alist.

Anyway, all of this probably only makes sense if it's actually possible
for two modes to display something in the same margin without
interfering with each other.


-- 
Joost Kremers
Life has its moments



  reply	other threads:[~2015-11-25 19:53 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
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 [this message]
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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=877fl5lutk.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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).