Kyle Meyer writes:
>> Subject: [PATCH] org-src: Add option 'plain to org-src-window-setup
> I'll wait another day or so for others to comment before applying.
I've applied this patch (with the mentioned tweaks) and the second patch
(with a slight expansion of the commit message).
Thanks.
> I suppose that to some degree [*] the main benefit of this patch is that
> it offers an option that calls quit-restore-window.
Yes, I agree with this. Setting org-src-window-setup to other-window
was almost good enough for me -- it even respected
display-buffer-base-action -- except that it
Jack Kamm writes:
> My main motivation was to use my own display-buffer configuration to
> show the source buffer. So I've rewritten the patch to be smaller and
> more conservative, just adding a "plain" option to org-src-window-setup,
> and not changing the implementation of any existing
Hi Kyle,
Thanks for taking the time to do a thorough review of the patch, I found
your response (especially the many examples you included) to be very
illuminating.
I agree that relying more on display-buffer-based functions is good, but
in retrospect I may have been over-eager, especially since
> 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.
I agree to use =pop-to-buffer=. Propose too.
>
> There was one previous option for
Jack Kamm writes:
> 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.
> [...]
On 1/18/20, Jack Kamm wrote:
> What setting of org-src-window-setup are you using? If it is
> "current-window" or "reorganize-frame", this patch shouldn't affect you
> at all, as those implementations are left the same.
you're right, i have that set to current-window, as you might expect.
and it
Hi Sam,
> 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.
Thank you for raising this, I wasn't
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.
