From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#33870: 27.0.50; xref-goto-xref not configurable Date: Thu, 03 Jan 2019 22:08:28 +0000 Message-ID: <87va35z95v.fsf@gmail.com> References: <87a7ktqqx7.fsf@mail.linkov.net> <9215183d-0a44-88b5-5b3c-d0da31f749ad@yandex.ru> <878t02egph.fsf@mail.linkov.net> <878t011lch.fsf@mail.linkov.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1546553243 16644 195.159.176.226 (3 Jan 2019 22:07:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 3 Jan 2019 22:07:23 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: 33870@debbugs.gnu.org, Dmitry Gutov To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jan 03 23:07:19 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1gfB90-00045m-5D for geb-bug-gnu-emacs@m.gmane.org; Thu, 03 Jan 2019 23:07:14 +0100 Original-Received: from localhost ([127.0.0.1]:58440 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gfBB7-00028D-1K for geb-bug-gnu-emacs@m.gmane.org; Thu, 03 Jan 2019 17:09:25 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:41173) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gfBAp-0001yf-FM for bug-gnu-emacs@gnu.org; Thu, 03 Jan 2019 17:09:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gfBAl-0003aV-KT for bug-gnu-emacs@gnu.org; Thu, 03 Jan 2019 17:09:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49469) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gfBAk-0003a6-Es for bug-gnu-emacs@gnu.org; Thu, 03 Jan 2019 17:09:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gfBAk-0001sC-5n for bug-gnu-emacs@gnu.org; Thu, 03 Jan 2019 17:09:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 03 Jan 2019 22:09:02 +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.15465533207161 (code B ref 33870); Thu, 03 Jan 2019 22:09:02 +0000 Original-Received: (at 33870) by debbugs.gnu.org; 3 Jan 2019 22:08:40 +0000 Original-Received: from localhost ([127.0.0.1]:46047 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gfBAN-0001rQ-UZ for submit@debbugs.gnu.org; Thu, 03 Jan 2019 17:08:40 -0500 Original-Received: from mail-wm1-f49.google.com ([209.85.128.49]:37738) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gfBAM-0001rC-9X for 33870@debbugs.gnu.org; Thu, 03 Jan 2019 17:08:38 -0500 Original-Received: by mail-wm1-f49.google.com with SMTP id g67so31594797wmd.2 for <33870@debbugs.gnu.org>; Thu, 03 Jan 2019 14:08:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=p0oXj3H6fSALBRcKNSRxc7h+O8q8FZ7q9SXvd19pn3s=; b=DdVqwrIEUYdM/yp9jWJiGFiyTT3bCFOLHNh1UHoUhAe24sr9MxB6Px4tHc4m7TeUxG VBwUX8OYtDDeOvEfeDFnQepvo9erNIe+sGr6z7qq6quKt/udAlToQoKY5h3Whb76FK9/ nldbp16uJSMhPAOJ39CEkwuP78QVufn923zy/nWnnx6LlN2zDIciL9bMSdeIAftwezSh ZJk5mOQAuXDJHAe7zzdmAIW8zIJcFUedgtq0TQ5BjtHeFX/bJkIx9DHCmrCLNXwBLZuz CnX7TXReAKnlOUT1qTx8NFG8y57eWcaEY+dznOWszqw9pOU3QENn+ObEZSqjgaeCWUHN oAQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=p0oXj3H6fSALBRcKNSRxc7h+O8q8FZ7q9SXvd19pn3s=; b=bwOtoYR8voftoawfhYzfjY99uVjOtBtbzeQ1lgMMVFWt0jORZlGWDeODzH89ncsY3M 5sOFLFtdZ2VlcQxpAqQEf/jdFOtapkZlGaqlq3gR2URIwvVbvspHi7HInH2BZJ4wzIYg Okif50BvjYr/2UKedyutbnkc49nk/EAqw3e//6PTi9xvV0agVi6qB+JChLjLydvs6tw1 iVYnDNL0UjuBK3bnafGbYVE8ijs+nmZidkz/Fegn2OqtgE8luLBdmUWL0MPyFWHh39VI Uj2H7hwWXpOaoWP9g6nSIIic6OvPDA7NKoxy/RsTT5k4ITKQ899CQ3hwZ+Ba7fhbCQHN YDYA== X-Gm-Message-State: AJcUukesZ1f2n/x53ic9bAnF9vQ+TqLpfzWQwDPsAo5G1o4iazISP83T hjQ3gV55ASW7gyP6KlIOcmh1+8EDVNY= X-Google-Smtp-Source: ALg8bN6G3+opYg07jjDZ5llkWFYRgkUiTlpkQjfOvMW7wiVOCaw05xBVD2Zu2AYCewQbuHAD6TnDXw== X-Received: by 2002:a7b:c5d1:: with SMTP id n17mr15269558wmk.152.1546553312257; Thu, 03 Jan 2019 14:08:32 -0800 (PST) Original-Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id k135sm67818637wmd.42.2019.01.03.14.08.30 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 03 Jan 2019 14:08:31 -0800 (PST) In-Reply-To: <878t011lch.fsf@mail.linkov.net> (Juri Linkov's message of "Thu, 03 Jan 2019 23:29:18 +0200") 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: 208.118.235.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:154113 Archived-At: Juri Linkov writes: > (with-selected-window (display-buffer buf action) > with just > (pop-to-buffer buf action) > > but I'm not sure about this change because it could change the current > behavior. Didn't test, but that would be bad. Is this small reduction worth it? >>> 2. makes the xref buffer non-obtrusive like *Completions* >>> in xref--show-xref-buffer; > What do you think about allowing only xref-find-definitions > to display a narrow xref window below the original window? I don't know. Can I get back the original behaviour easily? If so, how? I ask because the assumption that xref-find-definitions produces a small number of lines is really quite brittle. Generic functions can have many, many methods. In Emacs, cl-print-object has 10 definitions lines, but that could/should easily grow as anyone who devises a new type of object can write a cl-print-object for it. In a Common Lisp system CL:PRINT-OBJECT usually has a ton of methods (and I'm trying to write a CL IDE that uses xref.el) >>> - (display-buffer buf action)) >>> + `(,(lambda (buf alist) >>> + (window--display-buffer buf xref--original-windo= w 'reuse alist))))))) >>> >> >> Using internal "--" symbols from window.el is a temporary solution I >> hope. > > Actually this function is not quite internal. It's intended to be used > in display actions implemented by packages. Hmmm, it's used only in lisp/window.el, where it hails from, and in lisp/windmove.el, where you added it recently. If it's part of the API, it should really be named window-display-buffer. I'm just making sure it isn't an implementation detail for which Martin reserve the to change at any time. >> Again, too many --, and seems like a lot of repetition from window.el. > The distinction between internal and public window functions is quite > fuzzy. It shouldn't be. If a package A uses -- from package B, either A is going to break soon, or B's API is insufficient. >> Perhaps you want window.el to export a function that encapsulates >> all/some of this cruft to pass as ACTION. > Yes, creating a composite display action would be a good thing to do. And can you create one such composite display action that brings exactly the current *xref* behaviour? Or does one such thing already exist? >> Naming that function would be the hardest problem (best I could do is >> display-buffer-use-completions-like-window). > Or when naming by not its usage but what it does: > display-buffer-below-and-resize. OK. Better, I guess (if that's really what it does). >> Or maybe put that function in xref.el. But as I said above, I think we >> also need a function that brings back the current default. > I propose to use the new function only for xref-find-definitions. OK, but I would say this is a separate request: * This bug is about making the xref.el window-popping behaviour configurable using display-buffer-alist&friends while keeping the UI. That goal is now apparently within reach; * The goal of changing the default UI for a certain part of xref-* commands is a different one, which I don't necessarily oppose, but it should be discussed and implemented separately. Jo=C3=A3o