From: Samuel Wales <firstname.lastname@example.org>
To: Carsten Dominik <email@example.com>
Subject: Re: pop-up-windows
Date: Thu, 28 May 2009 15:49:08 -0700 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On Wed, May 6, 2009 at 05:14, Carsten Dominik <email@example.com> wrote:
> I do not use display-buffer in Org, because the results are
> so unpredictable for different users precisely because there
> is a plethora of options and hooks that do modify the behavior.
> This makes it difficult to create a consistent interface, at
> least in my opinion.
I think this might be a question of whether you want a consistent
interface for org across all users (e.g. for helping people debug
issues) vs. a consistent interface across all of emacs for a single
user. Respecting pop-up-windows IMO achieves the latter (although as
you poiint out, you can set variables and hooks in org for the most
I did check coding standards; I expected the variable to be mentioned,
but it isn't, so it's merely an informal standard. But I am sometimes
having to fix the behavior of parts of emacs that don't respect
pop-up-windows, including, strangely (and non-fixably) help mode
>> Export dispatch and agenda dispatch should probably respect
>> the variable because context usually does not add to the
>> decision being made (among other reasons). They do not
>> currently respect it.
> I don't think this is an issue. These commands make the
> buffer as large as needed to display their entire content.
> If necessary they will remove the other window. So with a
> large font, they can use the whole frame.
True. Respecting pop-up-windows here is merely to avoid surprises for
those who use it consistently.
>> org-complete is currently problematic because it
>> inadvertently respects the variable. It changes to the
>> completions buffer, and then the completion keys do not
> I don't understand. What is the problem?
Try setting pop-up-windows to nil, and completing. You will find that
you get a completions buffer. Normally in completion, you can add
another key and complete again. But in the completions buffer you
cannot. This is a case where splitting the windows regardless of
pop-up-windows would be useful. That or allowing the completions
buffer to be active.
>> This should probably either ignore the variable or accept the
>> completion keys. However, I do not use it, so I have not
>> tried it much.
Out of order:
>> In org, todo state selection and tag selection should
>> probably ignore the variable, provided that the window
>> height contains the buffer. The context is useful, so it's
>> OK to split the window.
> Exactly, this is what drove me crazy and toward
> abandoning pop-to-buffer and display-buffer entirely.
Not sure why you need to abandon them entirely instead of just for these two?
Again, however, this is a minor consistency issue since you can use
variables and hooks to achieve the same result. It is just for new
users to not have to find them.
Myalgic encephalomyelitis denialism is causing death and severe suffering
worse than MS. Conflicts of interest are destroying science. Anybody can
get the disease at any time permanently. Do science and justice matter to
prev parent reply other threads:[~2009-05-28 22:49 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-25 3:44 pop-up-windows Samuel Wales
2009-05-06 12:14 ` pop-up-windows Carsten Dominik
2009-05-28 22:49 ` Samuel Wales [this message]
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:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
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).