unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: joostkremers@fastmail.fm, emacs-devel@gnu.org
Subject: Re: Better handling of window margins
Date: Fri, 04 Dec 2015 17:34:07 +0200	[thread overview]
Message-ID: <83fuzigrdc.fsf@gnu.org> (raw)
In-Reply-To: <56616922.4030609@gmx.at>

> Date: Fri, 04 Dec 2015 11:21:22 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: joostkremers@fastmail.fm, emacs-devel@gnu.org
> 
>  > And how will this help in deciding how to split a window, when you
>  > cannot predict how the margins will change (or _whether_ they will
>  > change) as result of the split?
> 
> We never can predict such things.  For ‘linum-mode’ the display-width of
> a window's margin will change when you show another buffer in that
> window and that other buffer has 10000 lines and the buffer you showed
> before has 5.
> 
> If ‘split-window’ is supposed to show the buffer of the original window,
> the display-width of the margin is not supposed to change.  And that's
> everything ‘split-window’ can care about.  If we are going to display
> another buffer in the new window, all bets are off.

I agree.  But if we only care about showing the same buffer case, then
we do really need to consider only the width of the text area when we
decide whether to split horizontally or vertically, right?  Moreover,
even when another buffer is shown in one of the two windows, the
window that continues to display the original buffer should still have
reasonable width of its text area, right?  And the only way to
guarantee the latter is to consider the width of only the text area,
excluding the margins.

>  > We are still talking about splitting windows here, right?
> 
> And about resizing windows, right?

I wasn't aware that resizing windows was part of the use cases
considered by this discussion.  How is it relevant?  What decisions
during resizing depend on the margins?

>  > OK, but how does this lead to "modes will also have to intervene every
>  > time we set a window's fringes" part?
> 
> Because the decision whether we can enlarge the fringes of a window is
> also based on the size of the window's margins (see set_window_fringes).

You mean, when the window is so thin that it cannot allow to be any
thinner?  Yes, but that's a marginal (pun intended) use case.  By
contrast, splitting a window with margins is not.

> So if a mode should be allowed to affect the behavior of ‘split-window’
> based on how it wants its margins to behave in the old or new window, it
> should be also allowed to affect the behavior of ‘set-window-fringes’,
> for example, by reducing the margin-width when enlarging a fringe.

Maybe so, but that's much less important, IMO.




  reply	other threads:[~2015-12-04 15:34 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
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 [this message]
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

  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=83fuzigrdc.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=joostkremers@fastmail.fm \
    --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).