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: Fri, 4 Jan 2019 07:41:38 +0000 Message-ID: References: <87a7ktqqx7.fsf@mail.linkov.net> <9215183d-0a44-88b5-5b3c-d0da31f749ad@yandex.ru> <878t02egph.fsf@mail.linkov.net> <878t011lch.fsf@mail.linkov.net> <87va35z95v.fsf@gmail.com> <87pntdxp3l.fsf@mail.linkov.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000006568a057e9d0375" X-Trace: blaine.gmane.org 1546587615 511 195.159.176.226 (4 Jan 2019 07:40:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 4 Jan 2019 07:40:15 +0000 (UTC) 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 Fri Jan 04 08:40:11 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 1gfK5P-0008Q2-QH for geb-bug-gnu-emacs@m.gmane.org; Fri, 04 Jan 2019 08:40:08 +0100 Original-Received: from localhost ([127.0.0.1]:60146 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gfK7W-0001y1-Q1 for geb-bug-gnu-emacs@m.gmane.org; Fri, 04 Jan 2019 02:42:18 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:49072) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gfK7K-0001xw-Kn for bug-gnu-emacs@gnu.org; Fri, 04 Jan 2019 02:42:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gfK7G-0006NY-FR for bug-gnu-emacs@gnu.org; Fri, 04 Jan 2019 02:42:06 -0500 Original-Received: from debbugsout.gnu.org ([209.51.188.43]:43077) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gfK7G-0006N6-9x for bug-gnu-emacs@gnu.org; Fri, 04 Jan 2019 02:42:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gfK7F-00030D-T2 for bug-gnu-emacs@gnu.org; Fri, 04 Jan 2019 02:42:01 -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: Fri, 04 Jan 2019 07:42: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.154658771711526 (code B ref 33870); Fri, 04 Jan 2019 07:42:01 +0000 Original-Received: (at 33870) by debbugs.gnu.org; 4 Jan 2019 07:41:57 +0000 Original-Received: from localhost ([127.0.0.1]:46188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gfK7B-0002zp-3d for submit@debbugs.gnu.org; Fri, 04 Jan 2019 02:41:57 -0500 Original-Received: from mail-qt1-f182.google.com ([209.85.160.182]:44812) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gfK78-0002zd-VC for 33870@debbugs.gnu.org; Fri, 04 Jan 2019 02:41:55 -0500 Original-Received: by mail-qt1-f182.google.com with SMTP id n32so39469094qte.11 for <33870@debbugs.gnu.org>; Thu, 03 Jan 2019 23:41:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PZ51PVPioEzD+gLbkEMonEFWjapW0TN/zrepZXjPWQQ=; b=IsAJ7DVmNDWByZ3zGmtM2L8S4zDXTQ3IdR84+XVDAW1beuvKdkdab6mQ2VLpUkF0ev R95A8gexWtcDF1/piimJB1LAejmmIBS3tvnhIgMWc7ZRViRQlyD/pF2GoWPgkO75TtrR weIK7FaiBEHM1p5RQr4+qrqkEMXIo38hVDyGiTJ3lwHKIWwwEN4mxqxvFYK/vBAIbXBn FdIZmYXNw9tDe6DFsrsFrCY+En4BVO4dZp8z9O59pQJYZIqNoDDCnoGh5nTDxczdKJTQ tNBLWwSFT5NruTpdWQhjTPPtzBIIzmdAumM++a9GrUdq1/W2yF2hhAOTE2sK9FrSU1LB +hjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PZ51PVPioEzD+gLbkEMonEFWjapW0TN/zrepZXjPWQQ=; b=Qa7/COTgZhJQRwMksDBR6nROQBub8+PCYz/ML0wDbDSzSOT/X8HfbCduK1uPrW0Jlc RuA8hDyf2Nw+e7WMHHBpXKM1ZmRtmDs79+OE1mXFForqgsDUrLaspqVuQofeug2UMJPN NbHCc366TYQzVfSmSEcsWjb8tSzVIbf+sVqcnYh2gA+dIkmPqiv6u2/Dc8EWYR55Wepj YhoRvC1rVdgp25ZiCITT+JoV8izPi3/VX1ppHZeMOEUf3mf3GHiNzS52GwM9OF43L1zg hQK4fG1k1HeSLnxMmLWfYFoIiVL9M6FqunBWUk/kfLI6AACGEeohQVAkVbvIOG9SG/h2 vKyg== X-Gm-Message-State: AJcUukc99eJm3LdTEs1TJ3Mea9W4aQGm5NdzTHAwNZuuUWorfAvSvppP K/G1O5wFGdifJidx2hU68vI/ciyyS0bTtuqi520= X-Google-Smtp-Source: ALg8bN7MD52+9VVLsJcyPcdwxVRqS4AadqLOvGRppclsJA9HYASo1xZdGveFtgf8mbLLXQPaPskmBQ7IKMkFh73BHR8= X-Received: by 2002:a0c:d4a7:: with SMTP id u36mr48311526qvh.38.1546587709263; Thu, 03 Jan 2019 23:41:49 -0800 (PST) In-Reply-To: <87pntdxp3l.fsf@mail.linkov.net> 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] [fuzzy] 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:154129 Archived-At: --00000000000006568a057e9d0375 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 4, 2019, 00:16 Juri Linkov I don't know. Can I get back the original behaviour easily? If so, > > how? > This should be easy using a new display action. > Ok. Make sure to include that in your next patch, and make it the default. > > > I ask because the assumption that xref-find-definitions produces a smal= l > > 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) > > In my experience 10 lines is an exception. Even with more lines the > completions-like xref window remain pretty usable. I'm trying to tell your that your experience which seems limited to xref in emacs lisp, is not a good measure of how xref-find-definitions is used in the wild. xref-find-definitions came from something called slime-find-definitions, and has mostly its UI. SLIME is a CL IDE where 100+ long complicated definitions are the norm, not the exception. And one day SLIME could decide to use xref.el. > 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. > > I agree, window--display-buffer is more public towards other packages > and could be renamed. > Good. Include this in your next patch. >>> Perhaps you want > > And can you create one such composite display action that brings exactl= y > > the current *xref* behaviour? Or does one such thing already exist? > > It's as easy as moving components of the particular display action > from the recent patch into a separate function. > OK. Actually the request was about making xref windows more configurable. > I could rename the subject if necessary, or create a separate request > for more discussion. > Don't change subject, create a separate request. Submit a second patch that makes xref windows configurable and leaves the default UI unchanged. Then install that patch closing this bug. In the separate discussion we can continue the discussion of the UI changes you want. Actually I should have made this separation clearly earlier. Jo=C3=A3o > --00000000000006568a057e9d0375 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, = Jan 4, 2019, 00:16 Juri Linkov <juri@= linkov.net wrote:

> I don't know.=C2=A0 Can I get back the original behaviour easily?= =C2=A0 If so,
> how?
This should be easy using a new display action.


= Ok. Make sure to include that in your next patch, and make it the default.<= /div>

> I ask because the assumption that xref-find-definitions produces a sma= ll
> number of lines is really quite brittle.=C2=A0 Generic functions can h= ave
> many, many methods.=C2=A0 In Emacs, cl-print-object has 10 definitions= lines,
> but that could/should easily grow as anyone who devises a new type of<= br> > object can write a cl-print-object for it.=C2=A0 In a Common Lisp syst= em
> CL:PRINT-OBJECT usually has a ton of methods (and I'm trying to wr= ite a
> CL IDE that uses xref.el)

In my experience 10 lines is an exception.=C2=A0 Even with more lines the completions-like xref window remain pretty usable.
=

I'm trying to tell your t= hat your experience which seems limited to xref in emacs lisp, is not a goo= d measure of how xref-find-definitions is used in the wild. xref-find-defin= itions came from something called slime-find-definitions, and has mostly it= s UI. SLIME is a CL IDE=C2=A0 where 100+ long complicated definitions are t= he norm, not the exception.=C2=A0 And one day SLIME could decide to use xre= f.el.

> If it&= #39;s part of the API, it should really be named
> window-display-buffer.=C2=A0 I'm just making sure it isn't an = implementation
> detail for which Martin reserve the to change at any time.

I agree, window--display-buffer is more public towards other packages
and could be renamed.

Good. Include this in your next patch.

>>> Perhaps you want=C2=A0
> And can you create one such composite display action that brings exact= ly
> the current *xref* behaviour?=C2=A0 Or does one such thing already exi= st?

It's as easy as moving components of the particular display action
from the recent patch into a separate function.

OK.
<= br>
Actually the request was about making xref windows more configurable.
I could rename the subject if necessary, or create a separate request
for more discussion.

Don't change subject, create a separate request. Su= bmit a second patch that makes xref windows configurable and leaves the def= ault UI unchanged. Then install that patch closing this bug. In the separat= e discussion we can continue the discussion of the UI changes you want.

Actually I should have made= this separation clearly earlier.

Jo=C3=A3o
--00000000000006568a057e9d0375--