From: Stefan Monnier <monnier@iro.umontreal.ca>
To: martin rudalics <rudalics@gmx.at>
Cc: emacs-devel@gnu.org
Subject: window-size constraints (was: bug#410: 23.0.60; display-buffer regression)
Date: Sat, 14 Jun 2008 11:31:14 -0400 [thread overview]
Message-ID: <jwvfxrgf3km.fsf-monnier+emacsbugreports@gnu.org> (raw)
In-Reply-To: <4853920E.9020106@gmx.at> (martin rudalics's message of "Sat, 14 Jun 2008 11:40:30 +0200")
> I'd like to make the window code resilient in a way that applications
> like calendar can naturally set `window-size-fixed'. As a consequence,
> `display-buffer' wouldn't change the calendar window's size even it were
> larger than the new window. Setting `window-size-fixed' can currently
> result in unexpected behavior. Fixing this is non-trivial.
> Also I'd like to give `split-height-threshold' and `window-min-height'
> buffer-local semantics and maybe add a `window-max-height' variable so
> to do `fit-window-to-buffer' and `shrink-window-if-larger-than-buffer'
> implicitly during each window configuration change. `window-min-height'
> equalling `window-max-height' for a particular buffer would then imply
> `window-size-fixed' for that buffer.
> Eventually, a user should be able to change window configurations
> arbitrarily with the calendar window always keeping its original size
> (unless there's no other way, obviously).
I think we should go in the direction of "constraints", which would take
the form of Elisp functions. Every configuration change would
correspond to adding&removing constraints, and then try and solve the
resulting CSP. Constraints would come with priorities so that in the
case the CSP has no solution, we can choose which constraint(s)
to break, or alternatively, the satisfaction of a constraint would not be
boolean, so the goal would be to try and maximize the satisfaction.
While writing the balance-window-area code, I went through several
iterations, and some of them just tried to move window-boundaries in
arbitrary ways, then measure the "balance-factor" (basically, the
window-area variance) and little by little move towards
a local optimium.
Also, I have some uninstalled code that uses
window-configuration-change-hook to preserve the
`balance-window-area'ness of a frame when windows are created/deleted.
Stefan
next prev parent reply other threads:[~2008-06-14 15:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-13 22:04 bug#410: 23.0.60; display-buffer regression Stephen Berman
2008-06-14 9:40 ` martin rudalics
2008-06-14 15:31 ` Stefan Monnier [this message]
2008-06-14 22:06 ` window-size constraints martin rudalics
2008-06-15 2:01 ` Stefan Monnier
2008-06-15 8:37 ` martin rudalics
2008-06-14 22:34 ` bug#410: 23.0.60; display-buffer regression Stephen Berman
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=jwvfxrgf3km.fsf-monnier+emacsbugreports@gnu.org \
--to=monnier@iro.umontreal.ca \
--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 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.