From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Helmut Eller Newsgroups: gmane.emacs.devel Subject: Re: conflicting uses of next-error-function Date: Wed, 29 Apr 2015 18:58:15 +0200 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 1430326717 6278 80.91.229.3 (29 Apr 2015 16:58:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Apr 2015 16:58:37 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 29 18:58:29 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 1YnVJb-0006jm-LK for ged-emacs-devel@m.gmane.org; Wed, 29 Apr 2015 18:58:27 +0200 Original-Received: from localhost ([::1]:40152 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YnVJb-0002oP-2k for ged-emacs-devel@m.gmane.org; Wed, 29 Apr 2015 12:58:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36432) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YnVJX-0002oD-FE for emacs-devel@gnu.org; Wed, 29 Apr 2015 12:58:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YnVJS-0008Ig-HA for emacs-devel@gnu.org; Wed, 29 Apr 2015 12:58:23 -0400 Original-Received: from mail-wi0-x230.google.com ([2a00:1450:400c:c05::230]:38723) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YnVJS-0008IT-AG for emacs-devel@gnu.org; Wed, 29 Apr 2015 12:58:18 -0400 Original-Received: by wiun10 with SMTP id n10so73266307wiu.1 for ; Wed, 29 Apr 2015 09:58:17 -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=UsPnhjU+9OhnF5Oeb91wzYwQjJl3klYcceJ/5K9+QaI=; b=dKbbAKiw2/7Y3q7l1vYUPMcqREhLTJ7QqoxvqNJYY7t6rhfbJQ+1fAsGLcEUEqXJ7W h8AOH78S5l5a+ULx1L6G1u5RkmlfDq7xnoqT+EjJrcbPwQRzq+RH3EwiMnJWuGdO/qnX ZnpE+AlDTebY8klFtXXdZj1ZUL/DaD7istelJzaw2RscqE0nlFAtDusIOQ66NQKhQJgz izOczszxQDyq2FvXz/mYFDb9bBMoJQ2ji+b+QqWR3rkrxG9CqX8zw/63+OFCg4NpuZJ/ fhL4BcTmvVOVL4zCg2SSO/pjM4mMXcdK3rCkGiWyBWPhIjK6rxdl6dWQIs66M9HSawmt +hdQ== X-Received: by 10.194.79.9 with SMTP id f9mr150573wjx.20.1430326697637; Wed, 29 Apr 2015 09:58:17 -0700 (PDT) Original-Received: from ix (dial-185099.pool.broadband44.net. [212.46.185.99]) by mx.google.com with ESMTPSA id es5sm39796170wjc.30.2015.04.29.09.58.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2015 09:58:16 -0700 (PDT) Original-Received: from helmut by ix with local (Exim 4.84) (envelope-from ) id 1YnVJP-000783-Sm; Wed, 29 Apr 2015 18:58:16 +0200 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:186031 Archived-At: On Wed, Apr 29 2015, Stefan Monnier wrote: > 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"? Maybe we could mark a buffer somehow that it's a reasonable candidate for next-error-last-buffer and have a command ala switch-buffer to select the current next-error-buffer from the list of candidates. Helmut