From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: conflicting uses of next-error-function (was: UI inconveniences with M-.) Date: Wed, 29 Apr 2015 09:23:13 -0400 Message-ID: References: <83zja6b3tc.fsf@gnu.org> <54A24079.4020902@yandex.ru> <54A2FF47.6010207@yandex.ru> <54A86135.7080004@yandex.ru> <54A90002.7080009@gmx.at> <54A9C3FB.7000602@yandex.ru> <54AA3881.3080304@gmx.at> <54ABBB47.7010603@yandex.ru> <837fszx7iy.fsf@gnu.org> <83r3r5wqwv.fsf@gnu.org> <83k2wxwexb.fsf@gnu.org> <83fv7kwbow.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1430314592 10305 80.91.229.3 (29 Apr 2015 13:36:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Apr 2015 13:36:32 +0000 (UTC) Cc: emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 29 15:36:24 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YnSA4-0001Ro-Br for ged-emacs-devel@m.gmane.org; Wed, 29 Apr 2015 15:36:24 +0200 Original-Received: from localhost ([::1]:39071 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YnSA3-0006g7-Ir for ged-emacs-devel@m.gmane.org; Wed, 29 Apr 2015 09:36:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35453) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YnRxO-0007gn-He for emacs-devel@gnu.org; Wed, 29 Apr 2015 09:23:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YnRxK-0000XH-Kz for emacs-devel@gnu.org; Wed, 29 Apr 2015 09:23:18 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:39541) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YnRxK-0000W2-EB for emacs-devel@gnu.org; Wed, 29 Apr 2015 09:23:14 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGvvdVS4rw4V/2dsb2JhbAA3gVOhb4EIgXUBAQQBViMFCz8SFBgNJIgTohGLdgIKCxEMOgwDgz4Dg3AEo2OEWA X-IPAS-Result: AgUFAGvvdVS4rw4V/2dsb2JhbAA3gVOhb4EIgXUBAQQBViMFCz8SFBgNJIgTohGLdgIKCxEMOgwDgz4Dg3AEo2OEWA X-IronPort-AV: E=Sophos;i="5.11,557,1422939600"; d="scan'208";a="117769187" Original-Received: from 184-175-14-21.dsl.teksavvy.com (HELO pastel.home) ([184.175.14.21]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2015 09:23:13 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 5993A4AD3; Wed, 29 Apr 2015 09:23:13 -0400 (EDT) In-Reply-To: (Helmut Eller's message of "Wed, 29 Apr 2015 08:10:45 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:186013 Archived-At: > Dmitry took that out because he thinks that it interferes too much with > compilation-mode. Maybe he's right but let me note that M-x rgrep also > uses next-error/prev-error and similarly interferes with > compilation-mode. Indeed, I've occasionally been annoyed by conflicting uses of next-error-last-buffer/next-error-function. And in both directions: sometimes I don't want `grep' to hijack my ongoing traversal of compiler warnings, and sometimes I regret that some other package doesn't let me use C-x ` Maybe we should consider refining this so that all package which can sometimes benefit from C-x ` would feel free to provide support for next-error, without the fear of imposing themselves. For that, the next-error framework needs to make it possible for the user to control which package gets to really use next-error and when. Not sure what that should look like, tho. Maybe some config var could specify which packages's next-error-support is "enabled" by default, then some way for the user to override that default on a case by case basis: e.g. a command to run inside the *xref* buffer would "force-enable" the next-error support for this one time, and maybe a new `next-error-pop-context' command would go back to the previous "next-error-last-buffer/function"? Stefan