From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Vitalie Spinu Newsgroups: gmane.emacs.devel Subject: Re: conflicting uses of next-error-function Date: Thu, 30 Apr 2015 01:05:28 +0200 Message-ID: <877fsua62v.fsf@gmail.com> 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 1430348754 31766 80.91.229.3 (29 Apr 2015 23:05:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Apr 2015 23:05:54 +0000 (UTC) Cc: Helmut Eller , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 30 01:05:49 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 1Ynb35-0001BN-TK for ged-emacs-devel@m.gmane.org; Thu, 30 Apr 2015 01:05:48 +0200 Original-Received: from localhost ([::1]:41371 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ynb35-0000QV-9a for ged-emacs-devel@m.gmane.org; Wed, 29 Apr 2015 19:05:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51166) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ynb2s-0000QN-BO for emacs-devel@gnu.org; Wed, 29 Apr 2015 19:05:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ynb2o-0002mm-5h for emacs-devel@gnu.org; Wed, 29 Apr 2015 19:05:34 -0400 Original-Received: from mail-wi0-x230.google.com ([2a00:1450:400c:c05::230]:33369) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ynb2n-0002ki-VE for emacs-devel@gnu.org; Wed, 29 Apr 2015 19:05:30 -0400 Original-Received: by wief7 with SMTP id f7so537329wie.0 for ; Wed, 29 Apr 2015 16:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=vJKBbZ3HH8yMlsMynL4DhUx0pUeRFiu/V89CZU98mXw=; b=S7+pJXefpEkTcvapvt/68YaAw3t1muGwosmw55wl84J0yRoifRQG0VEGxf8oF9BlJ0 u9RwjkLGR4czNY20OTV80TBSlGL1ASaJ2ciUvEVSEbwZhwJyUMUcSR+CVtfMxyDcBBx5 HFYmBgJytFaQi4mZwDD4WbM5SMALqB/f1VUCDiANz/Hb9txQhGCiENYNnuR8lL+Zqkrz uV4A5npxTDpLw0GwwS43oI4FdQxPSJ7OtXJ6GvPEww8GEXhHXruU4d+kXnSx1ckwKADS WKxWDePsdBPCurbXkRiP9JT9dSYNvAlzZPoPZA9ICi23y59PIKp5QfAGY7dKbQjhETsV 8jMQ== X-Received: by 10.180.102.164 with SMTP id fp4mr10315107wib.67.1430348729458; Wed, 29 Apr 2015 16:05:29 -0700 (PDT) Original-Received: from localhost (dhcp-077-251-128-242.chello.nl. [77.251.128.242]) by mx.google.com with ESMTPSA id ju2sm1126389wid.12.2015.04.29.16.05.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2015 16:05:28 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Wed, 29 Apr 2015 09:23:13 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::230 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:186045 Archived-At: >>> Stefan Monnier on Wed, 29 Apr 2015 09:23:13 -0400 wrote: >> 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: Shouldn't then the first invocation of next-error push into xref--marker-ring (for M-.) in case it took you to a wrong place? > 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. How about using the free M-0 prefix in next-error to prompt for the compilation buffer on which to operate? Vitalie