From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: conflicting uses of next-error-function Date: Sun, 3 May 2015 02:20:48 +0300 Message-ID: <55455BD0.50508@yandex.ru> References: <83zja6b3tc.fsf@gnu.org> <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> <55411797.2090704@yandex.ru> <554165C5.2090301@yandex.ru> <5541E20F.9000602@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1430608886 29374 80.91.229.3 (2 May 2015 23:21:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 May 2015 23:21:26 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 03 01:21:19 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 1Yogik-00046P-Lr for ged-emacs-devel@m.gmane.org; Sun, 03 May 2015 01:21:18 +0200 Original-Received: from localhost ([::1]:58092 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yogij-0004wt-QG for ged-emacs-devel@m.gmane.org; Sat, 02 May 2015 19:21:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37377) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YogiX-0004wn-Ro for emacs-devel@gnu.org; Sat, 02 May 2015 19:21:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YogiT-0001Uk-S0 for emacs-devel@gnu.org; Sat, 02 May 2015 19:21:05 -0400 Original-Received: from mail-wi0-x22d.google.com ([2a00:1450:400c:c05::22d]:35018) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YogiT-0001UC-L9 for emacs-devel@gnu.org; Sat, 02 May 2015 19:21:01 -0400 Original-Received: by widdi4 with SMTP id di4so85742151wid.0 for ; Sat, 02 May 2015 16:20:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=K9FJ3s5jrjq+Ai/AVZ/xRGLEHeiVurIf6R/PJ2wZofM=; b=O9VzzhBipcCN48XLFbldC6TqcrZVRKLWNhQQ7ZzTOYOuTSPQivVBS5m3yqLp0KG6vX ktgrcPBCByYmjCeyPk0KL+6xXR1wNkhR/IWZmF6hCYvWctW5h0xp9x0d/+OtqC3qFo8D BbvWneU1FbNPghblkbacHGlPGUY+TO1s01Ris+W5cmlOcxtta2RbWSuMauQ4B3RTEghC zSE5m1yZQk2DZQxcefdeprtRwS0b9L049MSfpq7fLzMIO4xmylf4HMfmp/npqx8R+qrZ vD9rsxkFOdfvZtg2DOIeFcHzyyaJLczMIKHT7ANe1HLoALXc55emiAFv0HtVHIUUGz1I kglg== X-Received: by 10.194.104.164 with SMTP id gf4mr30003577wjb.102.1430608852269; Sat, 02 May 2015 16:20:52 -0700 (PDT) Original-Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id z13sm13628094wjr.44.2015.05.02.16.20.51 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 May 2015 16:20:52 -0700 (PDT) user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 in-reply-to: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22d 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:186153 Archived-At: On 04/30/2015 08:46 PM, Helmut Eller wrote: > next-error calls next-error-find-buffer. Maybe we could record every > buffer that was returned by next-error-find-buffer and include them in > the candidate list. That's not terrible, but then we have almost the same two non-ideal choices: - Only record the buffers that have even been noticed as the value of next-error-last-buffer. This way we'll ignore e.g. Compilation buffers that have never had a chance to be used with `next-error'. - Record all buffers that ever were returned from that function. This will also include normal (file-visiting) buffers where next-error-function is set locally (and usually only points to locations within that buffer). Here's a different heuristic: return all buffers where next-error-function is set, but buffer-file-name is nil. Probably not ideal, but it'll clearly delineate between normal and special buffers. I guess that will only leave inability, at certain times, to choose the current buffer's next-error-function over some Compilation buffer's one (http://debbugs.gnu.org/20489).