From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: emacs-devel@gnu.org
Subject: Re: Documenting buffer display
Date: Mon, 22 Oct 2018 22:27:11 +0300 [thread overview]
Message-ID: <831s8hu6i8.fsf@gnu.org> (raw)
In-Reply-To: <5BCE21AC.6030904@gmx.at> (message from martin rudalics on Mon, 22 Oct 2018 21:14:52 +0200)
> Date: Mon, 22 Oct 2018 21:14:52 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
>
> >> While this would be appropriate for 'switch-to-buffer-other-window' it
> >> may be wrong for 'pop-to-buffer-same-window' as soon as the user has
> >> customized 'display-buffer-alist'. We can't avoid the garden path of
> >> 'display-buffer' here and elsewhere.
> >
> > I don't think we cannot avoid it, we just need to qualify what I wrote
> > with the "not customized" caveat. Nothing a single sentence couldn't
> > fix.
>
> Trevor Murphy on emacs-devel
>
> I just noticed that `find-dired' and friends use `switch-to-buffer' as
> a subroutine. Since this does not go through the `display-buffer'
> mechanism, it’s really hard for me to control where Emacs displays the
> Find buffer. I’m currently advising `find-dired' to use
> `pop-to-buffer' instead.
>
> to which Stefan replied
>
> There's pop-to-buffer-same-window.
>
> Which means that people want 'pop-to-buffer-same-window' instead
> because they can customize it to display the buffer in _another_
> window.
I must be missing something: using pop-to-buffer-SAME-window to
display a buffer in ANOTHER window? How can that make sense?
> Which further means that a "not customized" caveat would be
> counterproductive here.
All I meant was to add something like "by default" to the doc string.
I don't see how that could be wrong, all Stefan's advice
notwithstanding.
We shouldn't shoot ourselves in the foot by being afraid that complex
enough customizations could invalidate the documentation.
> Any explanation of what 'pop-to-buffer-same-window' does without
> referring the reader to 'display-buffer' is misleading, at the very
> least.
I obviously disagree, as I did just that, and I object calling the
current text "misleading".
next prev parent reply other threads:[~2018-10-22 19:27 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-20 12:20 Documenting buffer display martin rudalics
2018-10-20 13:21 ` Eli Zaretskii
2018-10-20 18:02 ` martin rudalics
2018-10-21 12:56 ` Eli Zaretskii
2018-10-22 9:06 ` martin rudalics
2018-10-22 13:55 ` Eli Zaretskii
2018-10-22 19:14 ` martin rudalics
2018-10-22 19:27 ` Eli Zaretskii [this message]
2018-10-23 8:58 ` martin rudalics
2018-10-23 11:26 ` Pierre-Yves Luyten
2018-10-23 13:45 ` martin rudalics
2018-10-23 17:40 ` Stefan Monnier
2018-10-23 14:04 ` Drew Adams
2018-10-23 18:18 ` martin rudalics
2018-10-23 15:18 ` Eli Zaretskii
2018-10-23 18:23 ` martin rudalics
2018-10-23 19:07 ` Eli Zaretskii
2018-10-24 9:44 ` martin rudalics
2018-10-24 14:48 ` Eli Zaretskii
2018-10-24 17:40 ` martin rudalics
2018-10-24 18:25 ` Eli Zaretskii
2018-10-25 20:42 ` Juri Linkov
2018-10-23 15:52 ` Alan Mackenzie
2018-10-23 18:25 ` martin rudalics
2018-11-08 19:25 ` martin rudalics
2018-10-22 1:39 ` Michael Welsh Duggan
2018-10-22 5:54 ` Eli Zaretskii
2018-10-20 15:22 ` Drew Adams
2018-10-20 18:02 ` martin rudalics
2018-10-20 18:24 ` Drew Adams
2018-10-21 8:22 ` martin rudalics
2018-11-04 9:06 ` martin rudalics
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=831s8hu6i8.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=rudalics@gmx.at \
/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
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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.