From: Samuel Wales <email@example.com>
To: Jack Kamm <firstname.lastname@example.org>
Subject: Re: [RFC PATCH] Changes to pop-up source buffers
Date: Sat, 18 Jan 2020 11:56:53 -0700 [thread overview]
Message-ID: <CAJcAo8swShVYTRbkU5ddacbwxA8qxdwyHjGqq1PTiVEEnkmG2g@mail.gmail.com> (raw)
i can't comment on your ideas at all, but just have one concern, which
maybe could trip up others like me. namely, pop-to-buffer, as stated
in its very docstring, prefers not the same window.
if i remember correctly, this is the window management problem i have
been struggling with since 2002.
for me, trying to get commands or functions that call pop-to-buffer to
behave as i need them to, which is to say, for them to use the full
(and same) window for accessibility reasons,* has been so unfixable in
the past that i had to give up.
i've resorted to brittle uses of defadvice, putting up with the rare
completion windows that should work not working, heavy-handed
overly-general solutions with things like same-window-buffer-names,
etc. just to get them to behave. the nuclear option is redefinitions.
the result is a whole file full of kludges that partly work.
i know in this case i could possibly use yet another defadvice. i
also know that recent version of emacs have a complex, new layer of
window management functions, which have evolved, and which i tried to
understand but just did not. so they are useless to me.
packages like shackle do the opposite of what i need. and are
workarounds. and could end up unsupported at any time.
i guess i just wanted to point out that i, personally, hate
pop-to-buffer? assuming this is the same issue i have been strugglign
with for 18 years.
of course there are hardcoded other-windowness, also, maybe like in
occur and help buffers. but pop-to-buffer if i recall correctly is
the cause of most of these problems.
well, for what it's worth, those are my tangential comments. please
carry on. probably you have good reasons and i should not interfere.
but i do not look forward to working around them. kludge file will
* only exceptions possible are things like rare cases with temporary
completion windows, sometimes.
On 1/18/20, Jack Kamm <email@example.com> wrote:
> This patch changes some implementation details of
> org-src-switch-to-buffer and org-edit-src-exit, to more consistently use
> pop-to-buffer to open the source buffer, and quit-restore-window to
> close it. It also adds a new default option to org-src-window-setup.
> I'll explain some details and motivation for this now.
> First, on killing the source buffer. Currently, we kill it with
> kill-buffer, then restore the previous saved window configuration with
> set-window-configuration. The downside is that, if changes to the
> windows were made while editing the source buffer, for example if a new
> window is opened to refer to some other file, then these changes will be
> lost after the original window configuration is restored.
> By contrast, this patch uses quit-restore-window to close the source
> window, which won't affect other windows that may have been
> changed. quit-restore-window is also smart enough to decide whether the
> source window should be deleted (if the source buffer was popped up in a
> new window), or whether the window should be kept and switched to some
> previous buffer (if the source buffer was popped up on an existing
> Next, I changed org-src-window-setup to consistently use pop-to-buffer
> to create the source window. This is needed for quit-restore-window to
> figure out whether to delete the source window. Otherwise, if we
> separately create the window and switch to it, then quit-restore-window
> won't know whether the window was previously used for something else.
> Finally, I added a new default option to org-src-window-setup, to use
> the user's default configuration of display-buffer. Personally, I have
> configured my own display-buffer-base-action and would like org-babel to
> use it. Also, if a user is not satisfied with any of the options in
> org-src-window-setup, this allows them to use their own configuration.
> In most cases, the new default for org-src-window-setup will behave
> similarly to the previous default (reorganize-frame). It will only
> behave differently when 3 or more windows are currently open.
> A final advantage I'd like to note for pop-to-buffer and
> quit-restore-window, is that these are the mechanisms used by many
> built-in Emacs functions to pop up and close windows, such as *Help*
> There was one previous option for org-src-window-setup,
> reorganize-frame, that I couldn't reimplement using pop-to-buffer. That
> option required keeping around some logic for deleting windows and
> restoring the configuration.
> I tested the new implementation for org-src-switch-to-buffer, for all
> options of org-src-window-setup, and it appears to work correctly. I
> tested this on Emacs 26.3.
The Kafka Pandemic
What is misopathy?
The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.
next prev parent reply other threads:[~2020-01-18 18:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-18 17:33 [RFC PATCH] Changes to pop-up source buffers Jack Kamm
2020-01-18 18:56 ` Samuel Wales [this message]
2020-01-18 19:27 ` Jack Kamm
2020-01-19 2:46 ` Samuel Wales
2020-01-19 3:24 ` Kyle Meyer
2020-01-19 17:13 ` Jack Kamm
2020-01-21 4:10 ` Kyle Meyer
2020-01-22 5:06 ` Jack Kamm
2020-01-25 4:18 ` Kyle Meyer
2020-01-19 5:07 ` stardiviner
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:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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
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).