From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#33870: 27.0.50; xref-goto-xref not configurable Date: Wed, 09 Jan 2019 08:14:53 -0500 Message-ID: References: <87a7ktqqx7.fsf@mail.linkov.net> <9215183d-0a44-88b5-5b3c-d0da31f749ad@yandex.ru> <878t02egph.fsf@mail.linkov.net> <874lak9kr0.fsf@mail.linkov.net> <87zhscklhq.fsf@gmail.com> <5C346C76.4050803@gmx.at> <5C34BBE4.8060705@gmx.at> <5C34E14F.40804@gmx.at> <5C35C6E3.6000300@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1547040306 7898 195.159.176.226 (9 Jan 2019 13:25:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 9 Jan 2019 13:25:06 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: 33870@debbugs.gnu.org, Juri Linkov , =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , Dmitry Gutov To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 09 14:25:01 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ghDqv-0001uP-1C for geb-bug-gnu-emacs@m.gmane.org; Wed, 09 Jan 2019 14:25:01 +0100 Original-Received: from localhost ([127.0.0.1]:38443 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ghDt1-0006QH-VW for geb-bug-gnu-emacs@m.gmane.org; Wed, 09 Jan 2019 08:27:12 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:48245) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ghDhM-0005WW-4A for bug-gnu-emacs@gnu.org; Wed, 09 Jan 2019 08:15:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ghDhG-0004l9-Id for bug-gnu-emacs@gnu.org; Wed, 09 Jan 2019 08:15:08 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51595) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ghDhG-0004kp-Eb for bug-gnu-emacs@gnu.org; Wed, 09 Jan 2019 08:15:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ghDhF-0004tR-UL for bug-gnu-emacs@gnu.org; Wed, 09 Jan 2019 08:15:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 09 Jan 2019 13:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33870 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 33870-submit@debbugs.gnu.org id=B33870.154703970018789 (code B ref 33870); Wed, 09 Jan 2019 13:15:01 +0000 Original-Received: (at 33870) by debbugs.gnu.org; 9 Jan 2019 13:15:00 +0000 Original-Received: from localhost ([127.0.0.1]:50876 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ghDhE-0004sz-3f for submit@debbugs.gnu.org; Wed, 09 Jan 2019 08:15:00 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:48692) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ghDh9-0004sn-VH for 33870@debbugs.gnu.org; Wed, 09 Jan 2019 08:14:58 -0500 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x09DErw7020434; Wed, 9 Jan 2019 08:14:54 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id A26EE6AAF2; Wed, 9 Jan 2019 08:14:53 -0500 (EST) In-Reply-To: <5C35C6E3.6000300@gmx.at> (martin rudalics's message of "Wed, 09 Jan 2019 11:03:15 +0100") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6457=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6457> : inlines <6992> : streams <1809581> : uri <2777273> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:154289 Archived-At: >> I haven't looked in detail, but this seems to make it less trivial to >> just add a new action alist parameter: it should default to `t` if we >> matched in display-buffer-alist but to nil if we only rely on >> display-buffer-base-action? > I'm missing you here. An ALIST argument is equally passed to all > buffer display actions regardless of whether they are specifed by > 'display-buffer-base-action' or by someone else. It's their choice > whether they want to obey or disregard it. The same currently holds > for 'display-buffer-mark-dedicated'. Never mind, I was confused. >> Also, some (all?) let-bindings of display-buffer-mark-dedicated should > I don't see any such bindings in our current code base. lisp/dired.el: (display-buffer-mark-dedicated 'soft)) lisp/epa.el: (let ((display-buffer-mark-dedicated 'soft)) lisp/minibuffer.el: (display-buffer-mark-dedicated 'soft)) > I attach a patch of my proposed changes. After applying that I have > no more objections against renaming 'window--display-buffer' any way > people want. LGTM. See some comment/question below. Stefan > @@ -958,7 +957,11 @@ window--make-major-side-window > ;; window and not make a new parent window unless needed. > (window-combination-resize 'side) > (window-combination-limit nil) > - (window (split-window-no-error next-to nil on-side))) > + (window (split-window-no-error next-to nil on-side)) > + (alist (if (or display-buffer-mark-dedicated > + (assq 'dedicated alist)) > + alist > + (cons '(dedicated . side) alist)))) Hmm... the old code used (or display-buffer-mark-dedicated 'side), so when display-buffer-mark-dedicated is non-nil but (assq 'dedicated alist) is nil, I think we need to use (cons `(dedicated . ,display-buffer-mark-dedicated) alist), no? Or rather: (alist (if (assq 'dedicated alist) alist (cons `(dedicated . ,(or display-buffer-mark-dedicated 'side)) alist)))) WDYT? BTW, this code reappears a second time in your patch, but I haven't checked if the same reasoning applies there.