From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#31027: 27.0.50; xref, tags-location-ring equivalent Date: Thu, 5 Apr 2018 01:14:14 +0300 Message-ID: References: <4540850e-1f76-22d9-cf7b-bd680eb34c6b@yandex.ru> <399191a7-2570-75da-d9b7-12ca8172dc4e@yandex.ru> <871sfubsda.fsf@mail.linkov.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1522879992 6649 195.159.176.226 (4 Apr 2018 22:13:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 4 Apr 2018 22:13:12 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 Cc: "Charles A. Roelli" , 31027@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Apr 05 00:13:08 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 1f3qeQ-0001db-UP for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Apr 2018 00:13:07 +0200 Original-Received: from localhost ([::1]:34312 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f3qgW-0006nE-Dn for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Apr 2018 18:15:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40436) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f3qgM-0006lr-7N for bug-gnu-emacs@gnu.org; Wed, 04 Apr 2018 18:15:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f3qgI-00089E-S2 for bug-gnu-emacs@gnu.org; Wed, 04 Apr 2018 18:15:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:59082) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f3qgI-000890-O1 for bug-gnu-emacs@gnu.org; Wed, 04 Apr 2018 18:15:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f3qgI-0004qI-IO for bug-gnu-emacs@gnu.org; Wed, 04 Apr 2018 18:15:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 04 Apr 2018 22:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31027 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 31027-submit@debbugs.gnu.org id=B31027.152288006518553 (code B ref 31027); Wed, 04 Apr 2018 22:15:02 +0000 Original-Received: (at 31027) by debbugs.gnu.org; 4 Apr 2018 22:14:25 +0000 Original-Received: from localhost ([127.0.0.1]:38746 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3qfg-0004pB-Pj for submit@debbugs.gnu.org; Wed, 04 Apr 2018 18:14:24 -0400 Original-Received: from mail-wr0-f177.google.com ([209.85.128.177]:33206) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3qff-0004oy-PA for 31027@debbugs.gnu.org; Wed, 04 Apr 2018 18:14:24 -0400 Original-Received: by mail-wr0-f177.google.com with SMTP id z73so25165257wrb.0 for <31027@debbugs.gnu.org>; Wed, 04 Apr 2018 15:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=rWIsMjWR7t8Eor4GSr1+S+8Ezr481qGb/GdFrDqhaS8=; b=r39X06x9RaSkIsE4+UL/o7A3drXwJOD0WoK62ty8ZBZySmuXTFQg83ifz5ldIIlN8F 6ELq4VQ47XtVPoCtMNTCZ54smJvAy+ec9/2r/nqInjbTfZqtiMZRw9VGalSVn9ppqDBm fl6lQ4neILEIcHi0Iu5Pxshg4SKDr7HA/1BgIV0oPqtjenLAeIxFTawohw3dpOFTcYag yOObi/tJYudbgIjs49ox6AW1iCulnORlTS5LCwS8n+4oooJCXObYmeNJAMFPCofjqsBA 0FwhzgIS2LA+GLN2+GppxjZcjChcDryVddBGKxvsXZGUvTOCDJvM5ckHTNKDkC+v0oBt LZMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rWIsMjWR7t8Eor4GSr1+S+8Ezr481qGb/GdFrDqhaS8=; b=dGAI82tsJoLlHDqAUzaf6y1djHv9jkb1EuSX7p2SUw8ISYpGpc+2MduIGRhuDZXES+ zdCD9JuRQGBlR8JMkldE8XuE5f/3PDtPhPPUPakAO5HSqMGDqrHdO2BEP4ZfUEu2eO55 nTKZ7g0KvI7L8zgZs67W2G3ijbEr2GIbekAqsr0VqcXTqWRf8OUhLzOezVAmvEfvCHUy 57jDDf5AslUa+8Pro++06r+fjFS4TKkMi3MU2BBuPjWMAo3cQ1qPfydV0d7pIPEoV0z0 eo5kA7hZg0svZBLxfwqjwS0WDH1rC6cDIPM45Q10t/4y/2Hctwie8TSwY/ETcIXkPoTg D6Ew== X-Gm-Message-State: AElRT7GVR7BMl8d8a27TPlrIPCwfbF5m9coIfTMe1zgHbq4cVBueiPtY TsflplHFs/kSe44ZiDxwNH+yUvF0 X-Google-Smtp-Source: AIpwx4/flRMhOkp5RKd2yIAqw3k4ZVFlE4m+VNdik0mHW1dRY84wtpspa8p/SeT0onS5h9uqJNfIoA== X-Received: by 10.223.185.114 with SMTP id b47mr13508423wrg.238.1522880057401; Wed, 04 Apr 2018 15:14:17 -0700 (PDT) Original-Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id o17sm3879121wrc.71.2018.04.04.15.14.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 15:14:16 -0700 (PDT) In-Reply-To: <871sfubsda.fsf@mail.linkov.net> Content-Language: en-US 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:144909 Archived-At: On 4/4/18 11:59 PM, Juri Linkov wrote: >> Whether next-error-function is going to be local or not, is subject to >> discussion, see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20489 and >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30674. > > I have a wish to close these overgrown bugreports and redesign this feature > from scratch ;) The newer one is not so overgrown yet. I do wish we revert the part where next-error-function is buffer local, though, and then you could design this possibility as a user option. We discussed the approaches, but it comes out pretty complex no matter the way you look at it. >>> navigate to other "errors". An "xref-location-ring" would be simpler. >> >> What's simpler about that? You'd need some new commands to use it as >> well, right? > > Is the idea to use a ring of next-error capable buffers? > So that the next-error command in the current buffer > will return a list of all potentially next-error capable buffers > and allow the user to select the required one. Umm, I don't think the request is anything so ambitious. Charles has been asking for a ring to store the navigation locations visited by xref only.