[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH] Changes to pop-up source buffers
Re: [RFC PATCH] Changes to pop-up source buffers
Sat, 18 Jan 2020 11:56:53 -0700
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 <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
> 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.