From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Documenting buffer display Date: Mon, 22 Oct 2018 22:27:11 +0300 Message-ID: <831s8hu6i8.fsf@gnu.org> References: <5BCB1D82.3020108@gmx.at> <834ldgvjmj.fsf@gnu.org> <5BCB6DAE.30209@gmx.at> <83mur7tq4f.fsf@gnu.org> <5BCD92FF.8070905@gmx.at> <838t2qt79v.fsf@gnu.org> <5BCE21AC.6030904@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1540236345 27513 195.159.176.226 (22 Oct 2018 19:25:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 22 Oct 2018 19:25:45 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 22 21:25:41 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gEfpb-0006yT-Gg for ged-emacs-devel@m.gmane.org; Mon, 22 Oct 2018 21:25:39 +0200 Original-Received: from localhost ([::1]:36827 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gEfrh-0005mG-Sw for ged-emacs-devel@m.gmane.org; Mon, 22 Oct 2018 15:27:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51450) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gEfrb-0005ly-FM for emacs-devel@gnu.org; Mon, 22 Oct 2018 15:27:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gEfrV-0000zQ-JX for emacs-devel@gnu.org; Mon, 22 Oct 2018 15:27:43 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60502) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gEfrQ-0000qB-Dk; Mon, 22 Oct 2018 15:27:36 -0400 Original-Received: from [176.228.60.248] (port=3122 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gEfrI-0004wZ-1S; Mon, 22 Oct 2018 15:27:27 -0400 In-reply-to: <5BCE21AC.6030904@gmx.at> (message from martin rudalics on Mon, 22 Oct 2018 21:14:52 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:230573 Archived-At: > Date: Mon, 22 Oct 2018 21:14:52 +0200 > From: martin rudalics > 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".