Re: [RFC PATCH] Changes to pop-up source buffers

[Samuel Wales]

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
grow.


* only exceptions possible are things like rare cases with temporary
completion windows, sometimes.


On 1/18/20, Jack Kamm <address@hidden> 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
> window).
>
> 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*
> windows.
>
> 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?
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.