From: martin rudalics <rudalics@gmx.at>
To: joakim@verona.se
Cc: Leo <sdl.web@gmail.com>,
Stefan Monnier <monnier@IRO.UMontreal.CA>,
emacs-devel@gnu.org
Subject: Re: Annoying window/frame-configuration registers
Date: Tue, 29 Mar 2011 15:15:46 +0200 [thread overview]
Message-ID: <4D91DB82.8050104@gmx.at> (raw)
In-Reply-To: <m38vvyjj05.fsf@verona.se>
> Cool, I can start to use the branch then. Would simply using the branch
> in daily work be enough of a test?
For some features like window splitting, resizing, and deleting the
answer is yes. Others features like side windows or atomic windows are
completely new so it would make sense to check the Elisp manual sections
on these first.
> I still have the original use case that we did the "window group" patch
> for. Does your branch cover the case of having multiple window groups
> and pinnable windows?
It's mostly in what I call "side windows" now. I'm currently working on
a more expanded version of this but what there is in the branch should
be enough to start working. In particular, it should suffice to
implement ECB without any advices and similar tricks.
>> PS: Some changes in the `display-buffer' department are guaranteed to
>> break existing code.
>
> Are clients supposed to adopt or the other way around?
Adopt. There are two major changes:
(1) All `display-buffer' related options have been concentrated in one
single option called `display-buffer-alist'. Obviously, this
affects users as well but there is a function to convert a user's
settings to values for the new option.
(2) The semantics of the second and third argument of `display-buffer'
have completely changed their meaning. This will affect mostly
components like calendar, gdb, gnus, org-mode and calculator. I
have changed the code in most other clients already.
The other changes I made should not be noticeable in daily work. But
since my workflow is quite different from that of other people there's a
chance that I have broken some standard behavior. That's what I would
need testers for.
martin
next prev parent reply other threads:[~2011-03-29 13:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-28 15:51 Annoying window/frame-configuration registers Leo
2011-03-28 18:12 ` Stefan Monnier
2011-03-29 0:37 ` Leo
2011-03-29 0:39 ` Lennart Borgman
2011-03-29 8:34 ` martin rudalics
2011-03-29 9:41 ` joakim
2011-03-29 9:53 ` martin rudalics
2011-03-29 10:52 ` joakim
2011-03-29 13:15 ` martin rudalics [this message]
2011-03-28 18:14 ` Eli Zaretskii
2011-03-29 0:15 ` Leo
2011-03-29 8:31 ` martin rudalics
2011-03-28 18:51 ` martin rudalics
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=4D91DB82.8050104@gmx.at \
--to=rudalics@gmx.at \
--cc=emacs-devel@gnu.org \
--cc=joakim@verona.se \
--cc=monnier@IRO.UMontreal.CA \
--cc=sdl.web@gmail.com \
/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.