From: Kyle Meyer <firstname.lastname@example.org> To: Jack Kamm <email@example.com>, firstname.lastname@example.org Subject: Re: [RFC PATCH] Changes to pop-up source buffers Date: Tue, 21 Jan 2020 04:10:20 +0000 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> Jack Kamm <email@example.com> 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 options. I think > this is less likely to disrupt existing workflows or introduce > accidental bugs. > > What do you think of using this smaller patch instead? The more restricted patch is fine by me. I suppose that to some degree [*] the main benefit of this patch is that it offers an option that calls quit-restore-window. For example, without this patch, you can already configure things with display-buffer-alist when org-src-window-setup is set to `current-window'. Say with (add-to-list 'display-buffer-alist '("^\\*Org Src" . (display-buffer-at-bottom))) On exit, though, the window that was popped up remains. And that makes me think that the current options that go through a simple display-buffer-based call (current-window and other-window) would benefit from calling quit-restore-window like your `plain` option does. If you agree, perhaps it's worth adding another patch on top that does that. [*] "to some degree" because the option added by your patch has the advantage that it'd work with display-buffer-base-action too. Plus, I think it's good to have a dedicated option that points to display-buffer-alist/display-buffer-base-action. > As an aside, in case we do decide to re-implement some of the display > options, now or in future, I did have a slight discrepancy from the > behavior you describe for split-window-right: > >> Quickly testing, this has a slight change in behavior. If there is >> already a window below the current Org buffer window, the new source >> window will be popped up below the _other_ window rather than the Org >> buffer. I think this could be fixed (and the code in general >> simplified) by using display-buffer-below-selected. > > On my own system, the window pops up below the existing Org buffer, even > if I have several existing horizontal splits. I'm not sure why. Hmm, weird. I tried again (Emacs 26.3, vanilla config) and still see the behavior I reported. Oh well. > Subject: [PATCH] org-src: Add option 'plain to org-src-window-setup > > * lisp/org-src.el (org-src-window-setup): Add option 'plain for > org-src-window-setup, that uses vanilla display-buffer to show the > source window. My only minor nitpick is that, in the places you write “'plain”, it be more common to drop the leading quote, as `plain' and ~plain~ already suggest a symbol. (No need to reroll for that if no one else requests changes; I'll touch it up when applying.) I'll wait another day or so for others to comment before applying. Thanks.
next prev parent reply other threads:[~2020-01-21 4:11 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 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 [this message] 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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).