emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Samuel Wales <samologist@gmail.com>
To: Jack Kamm <jackkamm@gmail.com>
Cc: emacs-orgmode@gnu.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)
In-Reply-To: <87eevw7jqk.fsf@gmail.com>

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 <jackkamm@gmail.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
> 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.

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

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

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJcAo8swShVYTRbkU5ddacbwxA8qxdwyHjGqq1PTiVEEnkmG2g@mail.gmail.com \
    --to=samologist@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=jackkamm@gmail.com \
    --subject='Re: [RFC PATCH] Changes to pop-up source buffers' \
    /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

Code repositories for project(s) associated with this inbox:

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

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