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, 27 Dec 2018 00:05:47 +0000 Message-ID: <87imzfhm04.fsf@gmail.com> References: <87a7ktqqx7.fsf@mail.linkov.net> <9215183d-0a44-88b5-5b3c-d0da31f749ad@yandex.ru> <87imzfkhb4.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 1545869116 7375 195.159.176.226 (27 Dec 2018 00:05:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 27 Dec 2018 00:05:16 +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 Dec 27 01:05:12 2018 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 1gcJAk-0001l7-Fw for geb-bug-gnu-emacs@m.gmane.org; Thu, 27 Dec 2018 01:05:10 +0100 Original-Received: from localhost ([127.0.0.1]:48801 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gcJCq-0007sl-R8 for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Dec 2018 19:07:20 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:44732) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gcJCf-0007se-3y for bug-gnu-emacs@gnu.org; Wed, 26 Dec 2018 19:07:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gcJCY-0001eI-EB for bug-gnu-emacs@gnu.org; Wed, 26 Dec 2018 19:07:08 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52170) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gcJCY-0001du-8R for bug-gnu-emacs@gnu.org; Wed, 26 Dec 2018 19:07:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gcJCY-0006vt-1e for bug-gnu-emacs@gnu.org; Wed, 26 Dec 2018 19:07: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, 27 Dec 2018 00:07: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.154586916626587 (code B ref 33870); Thu, 27 Dec 2018 00:07:01 +0000 Original-Received: (at 33870) by debbugs.gnu.org; 27 Dec 2018 00:06:06 +0000 Original-Received: from localhost ([127.0.0.1]:38055 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gcJBb-0006uh-2d for submit@debbugs.gnu.org; Wed, 26 Dec 2018 19:06:06 -0500 Original-Received: from mail-wr1-f47.google.com ([209.85.221.47]:46616) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gcJBV-0006uA-Ly for 33870@debbugs.gnu.org; Wed, 26 Dec 2018 19:06:01 -0500 Original-Received: by mail-wr1-f47.google.com with SMTP id l9so16823033wrt.13 for <33870@debbugs.gnu.org>; Wed, 26 Dec 2018 16:05:57 -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=LHkgvBI+47baCsknxQfRBg4dbuHUUTe6HUFbOjFU2nU=; b=L0zoaEt/Ekt55Xi1um5NMhgIUumTM7qGjOdEMVunCpRKBhq95EKI9MOL8fmp6e9Qzf HPcjWhdMut/Bih2I0jkYyx1+49L7lgfR24oESyunqcbULw4V+oGboiF+bI7FxWZQ+wKc 22wY47lSMKfqkyjMxOGq0U22k1r1pPeXt/q21ySna8DaKfQltmf54DqJWgx4Iaj2fEuD tj+qjF4TCu/6T0Gm8UxCPlhyX+QlucXZovCKJ1kdERiziqv/FCD87PQLBl9ypILZ3Oio snmJOXIL8Xe3XXmM526f+eJsy9vrjGX62qaQ+o4ShscMVJScd/LiK2ZbqCAaWQ5NGGhW Of5g== 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=LHkgvBI+47baCsknxQfRBg4dbuHUUTe6HUFbOjFU2nU=; b=fmrcEehP7kpFEZqCvEdDdtr2zaJ5VcYMeR1TtLEFduE02xYLHXKbgY2dt3ZtyytXaR fmr8d7vxPXB694ZFXArAAE5lM5FyCNIxpgm1WDfPJgxOX0YcfS+IhB59fT9h/63ehD4w QKOrYz+c+l9UYm4+qpr/oZYdU4V3PxrLSSMOm7wRiwOv89+y6NjRDAj8hOXsDgGl7GrG nuCPjsH3Q78bcjEkrRlHteiBDTlzgBRugytMZsn9Hlg0ACxvYKWg7Qhg7q+dlsk8nxKn cVBb5D1TsYlP2uMwesRXbo3gOCmHzFYglN3c+sbS1UyKSpwOMePO4bFnEkerAPpKez17 0UJg== X-Gm-Message-State: AJcUukctq2wNyyV2xSqpFcgr1l/y3x996XvLYVbDwciBWE7yTdwNs1vp 59DL86TvM4aXXYkc5nRSstwA1O+0 X-Google-Smtp-Source: ALg8bN7z/5CTtoIwSBRTVOxk8GWn7G98YNKLUzq/BhUtWppuLJK8bDREVWznB4eL/U8wjanG6zp6gQ== X-Received: by 2002:adf:9542:: with SMTP id 60mr19451790wrs.60.1545869151753; Wed, 26 Dec 2018 16:05:51 -0800 (PST) Original-Received: from lolita.yourcompany.com ([89.180.159.15]) by smtp.gmail.com with ESMTPSA id e9sm22461442wro.16.2018.12.26.16.05.50 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 26 Dec 2018 16:05:51 -0800 (PST) In-Reply-To: <87imzfkhb4.fsf@mail.linkov.net> (Juri Linkov's message of "Thu, 27 Dec 2018 01:18:55 +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:153882 Archived-At: Juri Linkov writes: > I don't understand what does this "keep original window intent" mean. > Please explain. Hi Juri. You can read up the whole bug here: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D28814 I quote from that thread: Here are two very simple Emacs -Q recipes that demonstrate [the bug] =20=20=20=20=20 emacs -Q C-x 3 [split-window-right] C-x 2 [split-window-below] M-. xref-backend-definitions RET [xref-find-definitions] C-n [next-line] RET [xref-goto-xref] =20=20=20=20=20 Expected the definition to be found in the original window where I pressed M-. but instead it was found in another. Another case: =20=20=20=20=20 emacs -Q C-x 4 . xref-backend-definitions RET [xref-find-definitions-other-wi= ndow] C-n RET =20=20=20=20=20 Expected the definition to be found in some other window, different from the one I pressed M-. on. Instead went to the same one. Also, in both situations, expected the window configuration to be the same as if I had searched for, say, xref-backend-functions [which only has a single definition]. The bugfix makes these two recipes work like expected (that is the "Expected the definition" sentence is now fulfilled). We want to make sure this is not broken. > I want to understand how it is different from other modes that display > a buffer in another window, such as e.g. after `C-x C-b' > (list-buffers) typing `C-o' displays the buffer in another window, or > e.g. typing `C-o' in the Dired buffer opens it in another window, and > many other cases. *Before* pressing C-x C-b, you probably had no expectations as to what window should be used to display your decision. But M-. you have: M-. means "use the same window", C-x 4 . means use "other window" and C-x 5 . means "other frame". Crucially, the existance or not of multiple loci of the (something that generally cannot be known in advange) shouldn't influence the results of "other window" or "other frame" intention. So, by default, if display-* variables not are set specially by the user, then final product of those two recipes should stay the same and, more importantly, the principle that I described in the previous paragraph should hold. >> However here's a tangent that might affect the decision. >> Is there any impediment to making xref.el a core ELPA >> package? I can see some advantages... The reason I bring >> this up here is that using very new elisp in a file can reduce >> the usefulness of that goal, which in this case would be >> to bring new xref features to users of Emacs 26.1/26.2. >> Perhaps it is already using post-26 features in which case >> the ship has sailed. In that case, disregard this tangent. > > Display actions have been in Emacs for a long time customizable > by `display-buffer-alist', so if you need some specific logic, > it's easy to implement the corresponding display action > that can be overridden by the users. I know that. I think either I or you missed something in this paragraph. Let me put it like this: are you planning to use, in master's xref.el a new Elisp feature (a new function, argument to a function, or a new semantics of a specific argument) that would make loading that file in Emacs 26.1 fail in some way or other? If master's xref.el works in 26.1 before your changes, and not anymore after your changes, then the possibility of putting xref.el in ELPA as a "core" package is lost. (But perhaps that possibility is not desirable to begin with, so this is why I said this was a tangent). Jo=C3=A3o