From unknown Fri Jun 20 07:16:00 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#20489 <20489@debbugs.gnu.org> To: bug#20489 <20489@debbugs.gnu.org> Subject: Status: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Reply-To: bug#20489 <20489@debbugs.gnu.org> Date: Fri, 20 Jun 2025 14:16:00 +0000 retitle 20489 25.0.50; next-error-find-buffer chooses non-current buffer wi= thout good reason reassign 20489 emacs submitter 20489 Dmitry Gutov severity 20489 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sat May 02 19:18:10 2015 Received: (at submit) by debbugs.gnu.org; 2 May 2015 23:18:10 +0000 Received: from localhost ([127.0.0.1]:60058 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yogfh-0001mm-Vp for submit@debbugs.gnu.org; Sat, 02 May 2015 19:18:10 -0400 Received: from eggs.gnu.org ([208.118.235.92]:51560) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yogff-0001ma-UZ for submit@debbugs.gnu.org; Sat, 02 May 2015 19:18:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YogfZ-0000UG-ID for submit@debbugs.gnu.org; Sat, 02 May 2015 19:18:02 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:36546) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YogfZ-0000U7-GG for submit@debbugs.gnu.org; Sat, 02 May 2015 19:18:01 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36830) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YogfY-0004bX-Le for bug-gnu-emacs@gnu.org; Sat, 02 May 2015 19:18:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YogfU-0000K5-Kj for bug-gnu-emacs@gnu.org; Sat, 02 May 2015 19:18:00 -0400 Received: from mail-wg0-x22f.google.com ([2a00:1450:400c:c00::22f]:34031) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YogfU-0000Ha-Da for bug-gnu-emacs@gnu.org; Sat, 02 May 2015 19:17:56 -0400 Received: by wgso17 with SMTP id o17so119215947wgs.1 for ; Sat, 02 May 2015 16:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:subject:date:message-id:mime-version:content-type; bh=/pCNAXVAAiyKLJEqmEi1ia41yV2eTze1in9jagebGLQ=; b=pDecvlBa7jFCavBf7ME4aXk0Wvj5SR7A6DMxcgCtNyeEMmz3H1CCV1f7MeHZjI2KQo oGdkxdT5gzslPBqUiMcJSbJScGvLFRFaxBPbUWI+6ucn5d3OLJMTb7jQf3NJvzhQ6n1x 3NSCpVqX6QFMG+XtdbpcizildE6ZNmD+dF3jw2gV6oSpzb0lEvxKYtBzeyH9yFxjIMFp uTG7mXiZpMGl1tYM2fOtSprLcIOF+4YaBS8Ew3Hvla+rE+orZgRfdNKknebUWvZcH4TC BM297R7eHAZR9J7atTfxwUY11hJgjT1mfeBRH+wNoQwCKVK+E+hMFFrkGlFf1t/bLZYT fHjw== X-Received: by 10.180.216.103 with SMTP id op7mr7719042wic.90.1430608666975; Sat, 02 May 2015 16:17:46 -0700 (PDT) Received: from axl ([82.102.93.54]) by mx.google.com with ESMTPSA id df1sm4232206wib.12.2015.05.02.16.17.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 May 2015 16:17:46 -0700 (PDT) From: Dmitry Gutov To: bug-gnu-emacs@gnu.org Subject: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Date: Sun, 03 May 2015 02:17:43 +0300 Message-ID: <86wq0q602w.fsf@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) I've been trying to understand why when the current file-vising buffer has next-error-function set localy, sometimes `next-error' uses it, and sometimes it uses next-error-function from next-error-last-buffer. Looking at the current `next-error-find-buffer', the logic is this: - If a buffer visible in the current frame has next-error-function set, *and* if there's only one such buffer, use it. - If next-error-last-buffer has it set, use that. Othewise, if both of the above fail, - If the current buffer has next-error-function set, use it. That's nonsense. Why should the question of whether the current buffer's next-error-function is used be decided by whether there are any other visible buffers with that variable set. Apparently, this peculiarity has been there for 10.5 years now, introduced in 03e75c7e0 by Juri Linkov. But there's no bug reference, nor a link to a discussion. I'm guessing it was an attempt to solve a problem of next-error-last-buffer never being used if the current buffer has next-error-function. But I think the solution is worse than the problem. It least the previous behavior was consistent. In GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.12.2) of 2015-05-02 on axl Windowing system distributor `The X.Org Foundation', version 11.0.11601901 System Description: Ubuntu 14.10 From debbugs-submit-bounces@debbugs.gnu.org Sun May 03 01:50:09 2015 Received: (at 20489) by debbugs.gnu.org; 3 May 2015 05:50:09 +0000 Received: from localhost ([127.0.0.1]:60158 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yomn1-0003bS-Du for submit@debbugs.gnu.org; Sun, 03 May 2015 01:50:08 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:14544) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yommy-0003aj-Cy for 20489@debbugs.gnu.org; Sun, 03 May 2015 01:50:05 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEFAGvvdVRFpYts/2dsb2JhbAA3gVOfQYIugQiBdQEBBAFWIwULCw4mEhQYDSSIE6IRjCFDCQECAQKDPgODcASjY4RY X-IPAS-Result: AnEFAGvvdVRFpYts/2dsb2JhbAA3gVOfQYIugQiBdQEBBAFWIwULCw4mEhQYDSSIE6IRjCFDCQECAQKDPgODcASjY4RY X-IronPort-AV: E=Sophos;i="5.11,557,1422939600"; d="scan'208";a="118124647" Received: from 69-165-139-108.dsl.teksavvy.com (HELO ceviche.home) ([69.165.139.108]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 May 2015 01:49:59 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 7D0206610A; Sun, 3 May 2015 01:49:58 -0400 (EDT) From: Stefan Monnier To: Dmitry Gutov Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Message-ID: References: <86wq0q602w.fsf@yandex.ru> Date: Sun, 03 May 2015 01:49:58 -0400 In-Reply-To: <86wq0q602w.fsf@yandex.ru> (Dmitry Gutov's message of "Sun, 03 May 2015 02:17:43 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > Apparently, this peculiarity has been there for 10.5 years now, > introduced in 03e75c7e0 by Juri Linkov. But there's no bug reference, nor > a link to a discussion. IIRC this had something to do with hitting C-x ` to jump through the various elements of a *compile* or *grep* buffer, where some of those C-x ` may end up jumping to a buffer that itself has next-error-function set. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun May 03 08:56:26 2015 Received: (at 20489) by debbugs.gnu.org; 3 May 2015 12:56:26 +0000 Received: from localhost ([127.0.0.1]:60253 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YotRZ-0000V8-96 for submit@debbugs.gnu.org; Sun, 03 May 2015 08:56:26 -0400 Received: from mail-wg0-f48.google.com ([74.125.82.48]:33249) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YotRV-0000Ut-Lt for 20489@debbugs.gnu.org; Sun, 03 May 2015 08:56:22 -0400 Received: by wgin8 with SMTP id n8so127145563wgi.0 for <20489@debbugs.gnu.org>; Sun, 03 May 2015 05:56:15 -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=8lPvp7cgTeVQYtzhA8H6ZfnzQ20MHWhwZLgLVWydriI=; b=Rm1YKn5W8Q3ymbd2Ry3VB4PWw2CmQKuaceTPpRxt5D818CIyaA01aUdg61nZdAKLJl u4vKSTNToxzUzbupaoPKh/HdgyAo2MTK5FgIu4uPK4NYnIqQFCaC7IBT56sOXCk7KZMc jDfFCaB9AIhTwwdhXIL6MqAHpRfcDA/OExNwjipibg2COLPfpDqT7gcRToAz79yG/8Ez /Ht0avIuHVGkXR+jxO0bW1m/6oJ7BikzUvAA2Ko2rMBe+RY2k3+lZOeCsOvZKEsd5K0z G9zAKXNWekYiPpuFkpPfzgmDmqYx8Wvni1VgTGJrjJdg+TRbF9/UgirnoROyIztlQkzP pofQ== X-Received: by 10.180.218.137 with SMTP id pg9mr11380267wic.79.1430657775938; Sun, 03 May 2015 05:56:15 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id l3sm6558619wik.16.2015.05.03.05.56.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 May 2015 05:56:15 -0700 (PDT) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason To: Stefan Monnier references: <86wq0q602w.fsf@yandex.ru> From: Dmitry Gutov message-id: <55461AEB.7040402@yandex.ru> Date: Sun, 3 May 2015 15:56:11 +0300 user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/03/2015 08:49 AM, Stefan Monnier wrote: > IIRC this had something to do with hitting C-x ` to jump through the > various elements of a *compile* or *grep* buffer, where some of those > C-x ` may end up jumping to a buffer that itself has > next-error-function set. That's what I guessed, then. It doesn't solve the problem completely anyway. If the *grep* buffer is buried or displayed in a different frame (which is arguably is the best case for using C-x `), C-x ` might open a buffer with next-error-function set, and it will overtake, if it's the only one such in the currently visible frame. There's no easy way to get back to Grep's next-error-function either. Why don't we prioritize, in next-error-find-buffer, next-error-last-buffer over everything else (change the order to 2 3 1 4 5 6)? And then add some way to change next-error-last-buffer programmatically (choosing between the current buffer, if it has next-error-function set, and all other buffers with next-error-function set and buffer-file-name nil; defaulting to the current one). M-0 C-x ` (like suggested by Vitaly) might be OK, to change the used buffer and move to the next error in one step (and similarly in previous-error). But that hijacks the meaning of 0 argument. From debbugs-submit-bounces@debbugs.gnu.org Mon May 04 18:03:46 2015 Received: (at 20489) by debbugs.gnu.org; 4 May 2015 22:03:46 +0000 Received: from localhost ([127.0.0.1]:34101 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YpOSn-0007v4-Cm for submit@debbugs.gnu.org; Mon, 04 May 2015 18:03:45 -0400 Received: from mail-qc0-f176.google.com ([209.85.216.176]:33778) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YpOSl-0007us-Qo for 20489@debbugs.gnu.org; Mon, 04 May 2015 18:03:44 -0400 Received: by qcvz3 with SMTP id z3so30133463qcv.0 for <20489@debbugs.gnu.org>; Mon, 04 May 2015 15:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lifelogs.com; s=google; h=from:to:cc:subject:organization:references:mail-copies-to :gmane-reply-to-list:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=I8UMzPDrPvoAHkLgzatNNyuqY77tt+5U8N4esc6TSEM=; b=trau1ytN921Vt1XFyQFXVk5m0d82oy6O4V+vobWd11CvARPTmNhEXGDy9nOJ/AnH4K haNDzdqjMDp40L0SsSnUXtdpms81ZiCENRUuPpwqR0Dp2101tEcm5GTQC0ggqietqn56 LUsA+Qe77UUMGcwI8w5l3yyS50fBik4ENRDB0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:organization:references :mail-copies-to:gmane-reply-to-list:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=I8UMzPDrPvoAHkLgzatNNyuqY77tt+5U8N4esc6TSEM=; b=ltVAHviFpiiCmjbAkbPnVmvv4B9mStCieBmcT4b8SPFp9Pt/b50S/4blbYtogwoMnr gl2s1kUy4CE08jM+/lxnhz2VfHXArXTMU4ktFKM39GR9IzTa6YLyXHSpLFSlnsfqzs6t /Fw3xIhVhlscHLeJJmTzCPEyIWVNQdZjbe8eYbJpx6qV4/xIPQkI6YEz346yXy4E/jk0 NT53+Ryxhpinx1DO7xSAP6BSG+ZXSQrpK0NkGo3/Y5JtWENP5OR86G9EgjnEGUNyXvi4 IFT0v6kYXq6KmXAD7PNg0lJHlgKuZPiaTXy0QoJ/ToiS/AXL+DMsOk1mzw/QG7WF4gD5 oGUw== X-Gm-Message-State: ALoCoQm9rKz+In5jj6iDs+t9IVvs8WYZl6K6MfDrfrrc4jK7p3F9/7gBafex8F4bIq78UZPYjOEr X-Received: by 10.140.91.18 with SMTP id y18mr29151295qgd.90.1430777018368; Mon, 04 May 2015 15:03:38 -0700 (PDT) Received: from flea (c-98-229-61-72.hsd1.ma.comcast.net. [98.229.61.72]) by mx.google.com with ESMTPSA id 199sm25889236qhu.15.2015.05.04.15.03.37 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 04 May 2015 15:03:37 -0700 (PDT) From: Ted Zlatanov To: Dmitry Gutov Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos References: <86wq0q602w.fsf@yandex.ru> <55461AEB.7040402@yandex.ru> X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never Gmane-Reply-To-List: yes Date: Mon, 04 May 2015 18:03:53 -0400 In-Reply-To: <55461AEB.7040402@yandex.ru> (Dmitry Gutov's message of "Sun, 3 May 2015 15:56:11 +0300") Message-ID: <87sibc6lva.fsf@lifelogs.com> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Sun, 3 May 2015 15:56:11 +0300 Dmitry Gutov wrote: DG> Why don't we prioritize, in next-error-find-buffer, DG> next-error-last-buffer over everything else (change the order to 2 3 1 DG> 4 5 6)? For reference, here are the steps: ;; 1. If one window on the selected frame displays such buffer, return it. ;; 2. If next-error-last-buffer is an acceptable buffer, use that. ;; 3. If the current buffer is acceptable, choose it. ;; 4. Look for any acceptable buffer. ;; 5. Use the current buffer as a last resort if it qualifies, ;; 6. Give up. How about a `next-error-priority' which can be numerically: * local (each position refers to the file itself) = 0 (occur) * finder (each position refers to other files) = 100 (compile, grep) * or can be set by the mode to something else Then (1) can become "if one window on the selected frame has the highest priority, return it." Ted From debbugs-submit-bounces@debbugs.gnu.org Mon May 04 18:22:50 2015 Received: (at 20489) by debbugs.gnu.org; 4 May 2015 22:22:50 +0000 Received: from localhost ([127.0.0.1]:34122 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YpOlG-0008O2-Cq for submit@debbugs.gnu.org; Mon, 04 May 2015 18:22:50 -0400 Received: from mail-wi0-f177.google.com ([209.85.212.177]:36561) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YpOlE-0008Nk-CY for 20489@debbugs.gnu.org; Mon, 04 May 2015 18:22:48 -0400 Received: by wizk4 with SMTP id k4so138115758wiz.1 for <20489@debbugs.gnu.org>; Mon, 04 May 2015 15:22:42 -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=D8X6Bqsl+wP+c0QOVPHMNXHUd7pTfHQPi3BAF/fsuT0=; b=cLex9qB6GMVT9RYikgS1cCn9rqFO3uvd8HgQzi2qEzXhHnNIXkiPNoEzl8pc+xrli/ O/GiolMqL0wEx64rLoUYovO5q24ZfWNwM++lk5+o5Sb1dR7s9KC50opO5zAjGH+6QxNV 5JXNOE93Evvq/9KLIg6MpPueJbkfYbT+yFRhjo3Z7H4NiO9EwWlVodvc0/gyjt/P06NG pOJ84IbKMFoxUwj1rOtWw6Aq6ELTcr4b0EzK2HVR43d68YAja3zhbJadzFK7NFWRSa6E GhvpsDIwE4g9YTcMbluRmvTCTlm2KG6+F9b6VvruHnbfDtNvM4GyYqqDqKW/po43IXO3 jDzA== X-Received: by 10.194.78.49 with SMTP id y17mr46159608wjw.131.1430778162800; Mon, 04 May 2015 15:22:42 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id e2sm13123716wix.15.2015.05.04.15.22.41 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 May 2015 15:22:42 -0700 (PDT) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason To: Ted Zlatanov references: <86wq0q602w.fsf@yandex.ru> <55461AEB.7040402@yandex.ru> <87sibc6lva.fsf@lifelogs.com> From: Dmitry Gutov message-id: <5547F12F.2060809@yandex.ru> Date: Tue, 5 May 2015 01:22:39 +0300 user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <87sibc6lva.fsf@lifelogs.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/05/2015 01:03 AM, Ted Zlatanov wrote: > Then (1) can become "if one window on the selected frame has the highest > priority, return it." How will this help the user to control which error function to use next? And why the windows on the selected frame? If *compile* is buried, does it become useless? I'd say the opposite. Or suppose I have 4 windows open in the frame, and each one's buffer has a next-error-function that refers only to positions in the current file? And there's a *compile* buffer buried somewhere. How do I actually use the current buffer's next-error-function, aside from C-x 1? From debbugs-submit-bounces@debbugs.gnu.org Mon May 04 18:33:49 2015 Received: (at 20489) by debbugs.gnu.org; 4 May 2015 22:33:50 +0000 Received: from localhost ([127.0.0.1]:34134 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YpOvs-0000Et-TP for submit@debbugs.gnu.org; Mon, 04 May 2015 18:33:49 -0400 Received: from mail-qg0-f41.google.com ([209.85.192.41]:34286) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YpOvq-0000Eg-G2 for 20489@debbugs.gnu.org; Mon, 04 May 2015 18:33:47 -0400 Received: by qgfi89 with SMTP id i89so73170588qgf.1 for <20489@debbugs.gnu.org>; Mon, 04 May 2015 15:33:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lifelogs.com; s=google; h=from:to:cc:subject:organization:references:mail-copies-to :gmane-reply-to-list:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=IZvtgVwazqkA7ukaWomLmoyOu20lI2YDKQRlUV4HpBk=; b=e+CwI4Oyql8ragkF//hujIfBcdoWErq2IEgv0K93Ugx3ix8WKxS1CLmm9DlaXuJBI6 NqUguJJiYu6OrRqX2SYEWU7i9MfwzE0b2y3S/4BrEHyZMqKOEKvtEFR9Fh0KeprDFgJ1 e7IEb0qs50O1vp87btzYOY3EnuN0HQFHvt5NI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:organization:references :mail-copies-to:gmane-reply-to-list:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=IZvtgVwazqkA7ukaWomLmoyOu20lI2YDKQRlUV4HpBk=; b=hXgnACGmJI0WdzFNFc6PTzzqGCEUgbf+4OXGH7ooOkHwn8KLzJmxmyD6wDxIK6q1Q8 brZ/HhSiwD2LrcxQYwjOSR5EkxoGGCjaXKmp2hUz4uEOqM01N2DJVgFrH5nFjULqT8Vf acZ9wyHmO8lP/QWUC1XOxOPOPOct7hlmLIBJ5GxcQ/nZu/jvV6hSeq+efGdnvlCCnrc2 jKxq+rAgA4UEqqUnK8UBD7WW5ILcBMBoLOgnJPpXBRYy0Obi3th9v4hG1lT3gNcQ9Mce z/56pn2gyxU78a3oVS9twnX5pGzWRU2diURjNQZie1dBb9v/i++C2B1QPxXPW7uS5nTu lfhg== X-Gm-Message-State: ALoCoQnuLX8nyBnVhmBb+yLzStuozg4iL0rN0MW7RF/QkTp4DYxNhAoBlaYiycyseO3I3sruPRCg X-Received: by 10.55.22.3 with SMTP id g3mr49746929qkh.54.1430778821075; Mon, 04 May 2015 15:33:41 -0700 (PDT) Received: from flea (c-98-229-61-72.hsd1.ma.comcast.net. [98.229.61.72]) by mx.google.com with ESMTPSA id 67sm16719574qhw.43.2015.05.04.15.33.40 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 04 May 2015 15:33:40 -0700 (PDT) From: Ted Zlatanov To: Dmitry Gutov Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos References: <86wq0q602w.fsf@yandex.ru> <55461AEB.7040402@yandex.ru> <87sibc6lva.fsf@lifelogs.com> <5547F12F.2060809@yandex.ru> X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never Gmane-Reply-To-List: yes Date: Mon, 04 May 2015 18:33:56 -0400 In-Reply-To: <5547F12F.2060809@yandex.ru> (Dmitry Gutov's message of "Tue, 5 May 2015 01:22:39 +0300") Message-ID: <87383c6kh7.fsf@lifelogs.com> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Tue, 5 May 2015 01:22:39 +0300 Dmitry Gutov wrote: DG> On 05/05/2015 01:03 AM, Ted Zlatanov wrote: >> Then (1) can become "if one window on the selected frame has the highest >> priority, return it." DG> How will this help the user to control which error function to use next? It doesn't help the user. It helps mode writers give their modes the appropriate priority so the user doesn't have to know. DG> And why the windows on the selected frame? If *compile* is buried, DG> does it become useless? I'd say the opposite. Perhaps? I am giving a suggestion, not a full implementation. The essential thing is that we rank buffers, not just pick "the last one" or the "one visible with 5 hieroglyphs" or whatever other DWIMmery we currently use. DG> Or suppose I have 4 windows open in the frame, and each one's buffer DG> has a next-error-function that refers only to positions in the current DG> file? And there's a *compile* buffer buried somewhere. How do I DG> actually use the current buffer's next-error-function, aside from C-x DG> 1? Some history: I actually, long ago when `next-error' turned into a navigation facility, we[1] had the idea of "meta next-error" which would navigate one level higher than local. That would have made this whole discussion, including rankings by priority, moot by simply saying "to navigate between files (compile, grep) you use `meta-next-error' or whatever it's called. to navigate inside file locations, use `next-error'." I was supposed to write a patch after the release but... the dog ate my TODO list. Perhaps you are interested in adapting that code instead of hacking on the current scheme? Or should I retry implementing it? 9 years late is not too bad, right? :) If there's a time to implement this, I'd say it's now, before the 25.1 release, because it will break how many people expect `next-error' to work. But OTOH I think it will improve the UI. Thanks Ted [1] Lars, me, and others: https://lists.gnu.org/archive/html/emacs-devel/2006-04/msg00488.html From debbugs-submit-bounces@debbugs.gnu.org Tue May 05 11:05:51 2015 Received: (at 20489) by debbugs.gnu.org; 5 May 2015 15:05:51 +0000 Received: from localhost ([127.0.0.1]:35466 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YpePq-0003r9-5u for submit@debbugs.gnu.org; Tue, 05 May 2015 11:05:50 -0400 Received: from mail-wg0-f50.google.com ([74.125.82.50]:35761) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YpePj-0003ql-4H for 20489@debbugs.gnu.org; Tue, 05 May 2015 11:05:44 -0400 Received: by wgyo15 with SMTP id o15so186594937wgy.2 for <20489@debbugs.gnu.org>; Tue, 05 May 2015 08:05:33 -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=wywdyeCa3xB9IhecoOO3h1BGA2PmnSewv+a3NlN3m9M=; b=JoEx+VVhsRbKXjUi7QYnU5r7zaJ+X1syq82E/d+3EPvFV5OFEnINoxYhZYvzvL/JC0 TlZ70arEEcUmmwD+RFzd3Vhqbv+WrWaGMv2LTz0atQWFA9QesS+wSIUjOj3VIIVCH1Tz Fy8GuTpIB5x0jyu6k+T2sPROc1YKbe0aoU0Vo57EZIHZ1xI5w8pDiluFSsdy5RD1Z5/l XCt9iBWGbCVAzhGQFH7R3AukqAasgoetLemmPgdKUZG92msyoiV/0QL+0K4bE6rptE4D d5s6pnvSYTW+GHc9OSQwe+Vtp3tHu5cXpWDDAKZ7vGBPx8Quxx5efEE45+BRPDG+F57X GUhQ== X-Received: by 10.194.200.194 with SMTP id ju2mr51201110wjc.61.1430838333375; Tue, 05 May 2015 08:05:33 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id o6sm16571254wiz.24.2015.05.05.08.05.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 May 2015 08:05:33 -0700 (PDT) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason To: Ted Zlatanov references: <86wq0q602w.fsf@yandex.ru> <55461AEB.7040402@yandex.ru> <87sibc6lva.fsf@lifelogs.com> <5547F12F.2060809@yandex.ru> <87383c6kh7.fsf@lifelogs.com> From: Dmitry Gutov message-id: <5548DC39.2090501@yandex.ru> Date: Tue, 5 May 2015 18:05:29 +0300 user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <87383c6kh7.fsf@lifelogs.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/05/2015 01:33 AM, Ted Zlatanov wrote: > Some history: I actually, long ago when `next-error' turned into a > navigation facility, we[1] had the idea of "meta next-error" which would > navigate one level higher than local. That would have made this whole > discussion, including rankings by priority, moot by simply saying "to > navigate between files (compile, grep) you use `meta-next-error' or > whatever it's called. to navigate inside file locations, use > `next-error'." Thanks for the link. That would've been an improvement, but it wouldn't solve a related problem: when *grep* buffer was created after a *compile* one, how to get back to using *compile*'s list of errors. > Perhaps you are interested in adapting that code instead of hacking on > the current scheme? Or should I retry implementing it? 9 years late is > not too bad, right? :) 9 years is just right, but I'm not sure how much of that implementation we would reuse. It's also not obvious me how to move to the next file, if you only have a next-error-function. M-g M-f/b could switch between next-error-last-buffer values, though. Especially if they're organized in a ring, like Helmut suggested. That will require an update to any Compilation-like mode. From debbugs-submit-bounces@debbugs.gnu.org Tue May 05 11:15:20 2015 Received: (at 20489) by debbugs.gnu.org; 5 May 2015 15:15:20 +0000 Received: from localhost ([127.0.0.1]:35470 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YpeZ5-00045G-Sv for submit@debbugs.gnu.org; Tue, 05 May 2015 11:15:20 -0400 Received: from mail-qk0-f178.google.com ([209.85.220.178]:34280) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YpeZ3-000451-3Y for 20489@debbugs.gnu.org; Tue, 05 May 2015 11:15:17 -0400 Received: by qkgx75 with SMTP id x75so108055416qkg.1 for <20489@debbugs.gnu.org>; Tue, 05 May 2015 08:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lifelogs.com; s=google; h=from:to:cc:subject:organization:references:mail-copies-to :gmane-reply-to-list:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=2DofIXh1ds7q35yhxNcgOiMQLtevzoZ7bMLwp3d0hOU=; b=v5U/IFL4GlE9uuSudDjtsXf38UpujKsva2UOnuo39yDrbQDIKKLXsYaErCFe/UmBh3 FDh4dLFROADXk35uoYc5ZmsL46Q+tf5XZ3JENnQWXWILkZGqS9Pw1/7PSnyVhgJ0O60U PUTlmxZJraTDgyd6DgqSnWd1elPOHyl7xozvs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:organization:references :mail-copies-to:gmane-reply-to-list:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=2DofIXh1ds7q35yhxNcgOiMQLtevzoZ7bMLwp3d0hOU=; b=EVcFow4mijpGjMA51vG1tG2z7JXFRJrbk9/fje4QeeO5BWwXvYqCzANK1uCTZRo2nM w4NXsOxtr3Az7TEIhWx+rcnDoCxzjcOvdecrnkYpj1xVs2x4S4YZ3qGt9ufs0DAEiv6/ I6jd02wtGMkpHCNMfNMSXKgaummq2Q/ljA65XdOoI4ZTbn6bDqzUM+sg44hNj2lNa9so RKs24SQe9uawqZxe49i7hiYO/xHljwNuB4QkazIhXaxExXtRnwA1i5ptD7yN+WZb/8yl f7Y65TkWq3yqW+c+6cy4JaWhtdn57PASuI1Mqe3K2PoJ6f0x0xHVfMNtSqzNttYe9xzx KtZQ== X-Gm-Message-State: ALoCoQksyCZw273yjG+fAisn31xeZEWrRChAnQhBoBB9geZjQ4b3O1EIHSp5F/Xv2koLPVczFnqs X-Received: by 10.140.98.3 with SMTP id n3mr33547678qge.62.1430838911576; Tue, 05 May 2015 08:15:11 -0700 (PDT) Received: from flea (c-98-229-61-72.hsd1.ma.comcast.net. [98.229.61.72]) by mx.google.com with ESMTPSA id n83sm12248392qkh.31.2015.05.05.08.15.10 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 05 May 2015 08:15:10 -0700 (PDT) From: Ted Zlatanov To: Dmitry Gutov Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos References: <86wq0q602w.fsf@yandex.ru> <55461AEB.7040402@yandex.ru> <87sibc6lva.fsf@lifelogs.com> <5547F12F.2060809@yandex.ru> <87383c6kh7.fsf@lifelogs.com> <5548DC39.2090501@yandex.ru> X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never Gmane-Reply-To-List: yes Date: Tue, 05 May 2015 11:15:09 -0400 In-Reply-To: <5548DC39.2090501@yandex.ru> (Dmitry Gutov's message of "Tue, 5 May 2015 18:05:29 +0300") Message-ID: <87y4l3839e.fsf@lifelogs.com> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Tue, 5 May 2015 18:05:29 +0300 Dmitry Gutov wrote: DG> On 05/05/2015 01:33 AM, Ted Zlatanov wrote: >> Some history: I actually, long ago when `next-error' turned into a >> navigation facility, we[1] had the idea of "meta next-error" which would >> navigate one level higher than local. That would have made this whole >> discussion, including rankings by priority, moot by simply saying "to >> navigate between files (compile, grep) you use `meta-next-error' or >> whatever it's called. to navigate inside file locations, use >> `next-error'." DG> Thanks for the link. DG> That would've been an improvement, but it wouldn't solve a related DG> problem: when *grep* buffer was created after a *compile* one, how to DG> get back to using *compile*'s list of errors. I think we have to accept the visible or last used one in that case. >> Perhaps you are interested in adapting that code instead of hacking on >> the current scheme? Or should I retry implementing it? 9 years late is >> not too bad, right? :) DG> 9 years is just right, but I'm not sure how much of that DG> implementation we would reuse. It's also not obvious me how to move to DG> the next file, if you only have a next-error-function. I'm happy to make suggestions but please take this in a direction that makes sense to you. Ted From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 24 16:11:28 2016 Received: (at 20489) by debbugs.gnu.org; 24 Jan 2016 21:11:28 +0000 Received: from localhost ([127.0.0.1]:35189 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aNRwW-0001K1-Bh for submit@debbugs.gnu.org; Sun, 24 Jan 2016 16:11:28 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:39997 helo=homiemail-a17.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aNRwU-0001Js-EL for 20489@debbugs.gnu.org; Sun, 24 Jan 2016 16:11:26 -0500 Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id BDA682B206A; Sun, 24 Jan 2016 13:11:24 -0800 (PST) Received: from localhost.linkov.net (62.65.217.179.cable.starman.ee [62.65.217.179]) (Authenticated sender: jurta@jurta.org) by homiemail-a17.g.dreamhost.com (Postfix) with ESMTPA id EF00C2B2065; Sun, 24 Jan 2016 13:11:23 -0800 (PST) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Organization: LINKOV.NET References: <86wq0q602w.fsf@yandex.ru> Date: Sun, 24 Jan 2016 23:10:30 +0200 In-Reply-To: <86wq0q602w.fsf@yandex.ru> (Dmitry Gutov's message of "Sun, 03 May 2015 02:17:43 +0300") Message-ID: <87oacaiszd.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > - If a buffer visible in the current frame has next-error-function set, > *and* if there's only one such buffer, use it. > > - If next-error-last-buffer has it set, use that. > > Othewise, if both of the above fail, > > - If the current buffer has next-error-function set, use it. > > Apparently, this peculiarity has been there for 10.5 years now, > introduced in 03e75c7e0 by Juri Linkov. But there's no bug reference, nor > a link to a discussion. Sorry, I missed this bug report and regret that it caused you to revert xref's next-error-function integration. The link to the discussion is here: http://lists.gnu.org/archive/html/emacs-devel/2004-05/msg00614.html where you can see the case that we need to support. Now that we have window-local variables, it's possible to support this case in a proper way. Instead of checking if a buffer visible in the current frame, we should check the window-local value of next-error-last-buffer. Thus invoking next-error in the window with the source buffer will continue navigation using the right value of next-error-last-buffer that navigated to its previous occurrence. Thus, the steps will be the following: 1. If window-local next-error-last-buffer is an acceptable buffer, use that. 2. If next-error-last-buffer is an acceptable buffer, use that. 3. If the current buffer is acceptable, choose it. 4. Look for any acceptable buffer. 5. Use the current buffer as a last resort if it qualifies, even despite AVOID-CURRENT. 6. Give up. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 25 01:24:02 2016 Received: (at 20489) by debbugs.gnu.org; 25 Jan 2016 06:24:02 +0000 Received: from localhost ([127.0.0.1]:35400 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aNaZG-0005XO-Jq for submit@debbugs.gnu.org; Mon, 25 Jan 2016 01:24:02 -0500 Received: from mail-lb0-f179.google.com ([209.85.217.179]:35029) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aNaZE-0005Wv-Vq for 20489@debbugs.gnu.org; Mon, 25 Jan 2016 01:24:01 -0500 Received: by mail-lb0-f179.google.com with SMTP id bc4so68308991lbc.2 for <20489@debbugs.gnu.org>; Sun, 24 Jan 2016 22:24:00 -0800 (PST) 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=ClF2EOAeTtYEGJ5c1u4/k9F9k43bgFyXwkX31ZFZcfQ=; b=DTd7AnUJhvf4coTYANIXHZiR2xu5DDdDXI0ygawfzNW0/9my3PSo4R7Zrw0z28aen+ q1sOYNqvWhOe2ecw72rVUpUKnp8b8fXI+eSWaCumcf0iHBnz1NpqaJynDzc0bxULWRQi /XwATC1ILXGOezIj+Dktnwzly00tRcQ/TAFSTHunzxluI94d2FgyNhYrVN399sxeSvxL wqaKnbObjFgti8iKCINqwNhX6dKjfxIyP6iWZYtF8Pesfq9nIT2pnqHG24ApSIkSNjnp MMQBl1YIjcXjr0MDf9XXFA2hHeDHm1CFbdcoM6hCIHf8NSPLXpgN1z+cR6LHCw40K88A FgNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=ClF2EOAeTtYEGJ5c1u4/k9F9k43bgFyXwkX31ZFZcfQ=; b=gTW/eVwyzAyNcf7XFeZJ7I3NAR7rzC4deWL5i5iZbXu0/GK4NRLCpfgu86jI2GEp6A 0em/+8qlheirIewNB+BzIpg3NJRSNG/P6qXwqAjtO10uqonSkaq4QWizEuYKUj1ri3X2 c1gM0+chz8wZO2OrGcSofY4OiClSaa5q+drtDPKsgb9GDjrpqM07hlOcpvL+3OUfyAjB w3q/R4/BfPl0Zh5WFnWxAOu2DUUI9wvabUdKs1nQ+08/c6LRzWemg+EmudWbu2zOhMkj Y/zmp6eHrXAfa8YzJMfsuk2Ycx08R4HdVgmuyQDUAUSadMZYnGsNvTN6UlXDQ+IxE611 JeJg== X-Gm-Message-State: AG10YORmLkU8rywf/2TiF7KSRNOsCT2uUAATpoWwF+grw/6iXBBpEms7Gkv1JHlu1WXt6g== X-Received: by 10.112.64.5 with SMTP id k5mr5582617lbs.133.1453703034873; Sun, 24 Jan 2016 22:23:54 -0800 (PST) Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id b74sm2484541lfb.32.2016.01.24.22.23.53 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Jan 2016 22:23:53 -0800 (PST) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason To: Juri Linkov References: <86wq0q602w.fsf@yandex.ru> <87oacaiszd.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <56A5BF79.909@yandex.ru> Date: Mon, 25 Jan 2016 09:23:53 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: <87oacaiszd.fsf@mail.linkov.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) Hi Juri, Thank you for the reply. But having had time to consider this issue, I think there are benefits to how it currently works. For instance, if I want to switch from a Compilation's buffer next-error-function to the current file buffer's one, I just need to bury Compilation (doing the reverse might be harder, however). If we change this logic, we should make sure not to make anything worse. On 01/25/2016 12:10 AM, Juri Linkov wrote: > The link to the discussion is here: > http://lists.gnu.org/archive/html/emacs-devel/2004-05/msg00614.html > where you can see the case that we need to support. In this scenario, it seems like you could have benefited from next-error-last-buffer value being frame-local instead (maybe implemented as a frame parameter?). > Now that we have window-local variables, it's possible to support > this case in a proper way. Instead of checking if a buffer visible > in the current frame, we should check the window-local value of > next-error-last-buffer. Thus invoking next-error in the window > with the source buffer will continue navigation using the right value > of next-error-last-buffer that navigated to its previous occurrence. How do linting minor modes (like Flycheck or Flymake) fit into this? Suppose I called M-x compile (or, better yet, M-x grep), navigated to some file buffer from it and then see that it has some linter errors highlighed by Flycheck. So I want to use the current buffer's next-error-function now, and jump between linter warnings using next/previous-error. How do I do that? IIU your plan correctly, the current window-local next-error-last-buffer value will continue pointing at the Grep buffer, even if I bury it. Basically, I want to have two at least somewhat guessable sequences of actions that would let the user choose which buffer to use for its next-error-function. As discussed in this issue, the best way to do that seems to require: - Some indicator that a given buffer's next-error-function points to other buffer (then, if you're in a different buffer, that other buffer is still relevant). Like a buffer-local variable called, for example, next-error-function-nonlocal. - A command (or several) to switch between the plausible candidates for next-error-last-buffer. Maybe just have a single command that uses read-buffer with a predicate checking the aforementioned variable and an extra option that means "just use the current buffer". - Ignore next-error-last-buffer's visibility. Or make it frame-local, to account for your scenario as well (but that would bring extra complexity: some people use use frames like almost separate applications, and other can use frames instead of windows, and display them side-by-side). WDYT? From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 25 16:58:58 2016 Received: (at 20489) by debbugs.gnu.org; 25 Jan 2016 21:58:58 +0000 Received: from localhost ([127.0.0.1]:36435 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aNpA2-0004dB-H3 for submit@debbugs.gnu.org; Mon, 25 Jan 2016 16:58:58 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:40355 helo=homiemail-a22.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aNpA0-0004d3-Gc for 20489@debbugs.gnu.org; Mon, 25 Jan 2016 16:58:57 -0500 Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 326B41A8069; Mon, 25 Jan 2016 13:58:53 -0800 (PST) Received: from localhost.linkov.net (82.131.9.206.cable.starman.ee [82.131.9.206]) (Authenticated sender: jurta@jurta.org) by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id 59F2A1A8063; Mon, 25 Jan 2016 13:58:52 -0800 (PST) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Organization: LINKOV.NET References: <86wq0q602w.fsf@yandex.ru> <87oacaiszd.fsf@mail.linkov.net> <56A5BF79.909@yandex.ru> Date: Mon, 25 Jan 2016 23:55:10 +0200 In-Reply-To: <56A5BF79.909@yandex.ru> (Dmitry Gutov's message of "Mon, 25 Jan 2016 09:23:53 +0300") Message-ID: <87zivtqq81.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> The link to the discussion is here: >> http://lists.gnu.org/archive/html/emacs-devel/2004-05/msg00614.html >> where you can see the case that we need to support. > > In this scenario, it seems like you could have benefited from > next-error-last-buffer value being frame-local instead (maybe implemented > as a frame parameter?). A frame might contain more pairs of navigational/target windows, e.g. a window with *grep* output, and a file buffer visited from *grep*; a window with *Occur*, and another place in the same file buffer but visited from *Occur*, etc. So frame-local is not of help here, whereas window-local is, provided a navigational window (like *grep*/*compilation*) always displays target buffers in another dedicated window. As I see this is not what xref currently does: navigating in it jumps between many different windows that is very inconvenient, but this can be easily fixed to work the sane way as *grep* or *compilation* already works. >> Now that we have window-local variables, it's possible to support >> this case in a proper way. Instead of checking if a buffer visible >> in the current frame, we should check the window-local value of >> next-error-last-buffer. Thus invoking next-error in the window >> with the source buffer will continue navigation using the right value >> of next-error-last-buffer that navigated to its previous occurrence. > > How do linting minor modes (like Flycheck or Flymake) fit into this? Does Flycheck or Flymake display a navigation window with a list of results? If not, then this is a new case that we need to support as well. > Suppose I called M-x compile (or, better yet, M-x grep), navigated to some > file buffer from it and then see that it has some linter errors highlighed > by Flycheck. So I want to use the current buffer's next-error-function now, > and jump between linter warnings using next/previous-error. How do I do > that? IIU your plan correctly, the current window-local > next-error-last-buffer value will continue pointing at the Grep buffer, > even if I bury it. What if you have two navigations in the same buffer, and both are without a navigation window that you can't bury? > Basically, I want to have two at least somewhat guessable sequences of > actions that would let the user choose which buffer to use for its > next-error-function. > > As discussed in this issue, the best way to do that seems to require: > > - Some indicator that a given buffer's next-error-function points to other > buffer (then, if you're in a different buffer, that other buffer is still > relevant). Like a buffer-local variable called, for example, > next-error-function-nonlocal. Do you mean to bind a navigation buffer with navigated target buffers/windows? > - A command (or several) to switch between the plausible candidates for > next-error-last-buffer. Maybe just have a single command that uses > read-buffer with a predicate checking the aforementioned variable and an > extra option that means "just use the current buffer". This would be too complicated to use. > - Ignore next-error-last-buffer's visibility. Or make it frame-local, to > account for your scenario as well (but that would bring extra complexity: > some people use use frames like almost separate applications, and other can > use frames instead of windows, and display them side-by-side). Buffers are displayed in windows, so better to bind them to windows. > WDYT? I remember the original idea was to always continue the same navigation that displayed a given target buffer/window, so switching to another navigation in the same window could be achieved by explicitly navigating to another result from another navigation, e.g. when current navigation was from *compilation* then switching to *grep* buffer and typing M-n for the next grep hit in the same file buffer. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 25 18:36:26 2016 Received: (at 20489) by debbugs.gnu.org; 25 Jan 2016 23:36:26 +0000 Received: from localhost ([127.0.0.1]:36470 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aNqgM-0000Bx-B8 for submit@debbugs.gnu.org; Mon, 25 Jan 2016 18:36:26 -0500 Received: from mail-lb0-f172.google.com ([209.85.217.172]:35411) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aNqgK-0000Bk-UX for 20489@debbugs.gnu.org; Mon, 25 Jan 2016 18:36:25 -0500 Received: by mail-lb0-f172.google.com with SMTP id bc4so82920133lbc.2 for <20489@debbugs.gnu.org>; Mon, 25 Jan 2016 15:36:24 -0800 (PST) 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=rXfze5KOA6HVwiHNFdujUNK5fiAauK91bo3e9JP4/Y4=; b=OuPOAkEC0FQbTxaAlIByqpx0qEUKKl53+lQ2iG0ufwByJ2e5k7kB+S5DoTgYL8jxyI myEHM2PrNxdPlM0J8BE0hsoS/4pRnzWbVfC6TmcmV+jBKT+gAAF/52lN+Sy2ZzCvjbkK TwW6tQsChGE2bomMqYTvWO90EMp+/25vs1ofTD3wpsgqhNI/qOb1VoczlVj1VbGsPr5B X9LxpSur9tnz8Pu1RQcUrzaemsqz1SDXUnI8oHss1inYtaRVE9A3Dg6fo3B9RFzrzV2I o0KVWo9dOMdHWgLdQ0QITyTFgswjq3B/w5TRxiNfP13gaqGFwV/Ki/4+DG4ZBI1zfpx4 fC5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=rXfze5KOA6HVwiHNFdujUNK5fiAauK91bo3e9JP4/Y4=; b=gVJ+XgrFmCpWMnh1NuC3poaR7ToQZDqWM8iSMoAxO5/JQ6fHRpf2Bj10linzHGz3A3 eNYepPXDXr62QFHwj8/0gZxkY5XTdduHkjZQF6Reox/HhWguj9/MwXeVdXEiOMDCv2sr mhiCnhAcokNR4i9tVjF8QwYMw5K1fI+OKg2tzoLuJoUvMofdo1/d4t0M00f4pS+oeV1C psjkf9SQyl+b6dloZX6HiNKk/SYNnhAMfKIGp6VZjyULQl85DQ7Bpo9xy/OqDO2eznVA p0n1DMSkp0CZ0P3Z8M8cZQPHww1rRJKujEg/6ZUlOIF5Hy8MoNJ3rqRJG5BYERyH2BH5 D/hA== X-Gm-Message-State: AG10YOTP9Nh6p5FYOeE5MxtIbnG+fnCFEFzJGsU0emWId9qaIwg2+UXAC5+P9+4L+29kKA== X-Received: by 10.112.143.68 with SMTP id sc4mr7225454lbb.122.1453764979102; Mon, 25 Jan 2016 15:36:19 -0800 (PST) Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id r63sm3129865lfe.38.2016.01.25.15.36.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jan 2016 15:36:17 -0800 (PST) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason To: Juri Linkov References: <86wq0q602w.fsf@yandex.ru> <87oacaiszd.fsf@mail.linkov.net> <56A5BF79.909@yandex.ru> <87zivtqq81.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <56A6B171.7080504@yandex.ru> Date: Tue, 26 Jan 2016 02:36:17 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: <87zivtqq81.fsf@mail.linkov.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 01/26/2016 12:55 AM, Juri Linkov wrote: > A frame might contain more pairs of navigational/target windows, > e.g. a window with *grep* output, and a file buffer visited from *grep*; > a window with *Occur*, and another place in the same file buffer > but visited from *Occur*, etc. [...] Content analysis details: (3.1 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [178.252.127.222 listed in zen.spamhaus.org] -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.217.172 listed in wl.mailspike.net] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.217.172 listed in list.dnswl.org] 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 3.1 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 01/26/2016 12:55 AM, Juri Linkov wrote: > A frame might contain more pairs of navigational/target windows, > e.g. a window with *grep* output, and a file buffer visited from *grep*; > a window with *Occur*, and another place in the same file buffer > but visited from *Occur*, etc. [...] Content analysis details: (3.1 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.217.172 listed in list.dnswl.org] 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [178.252.127.222 listed in zen.spamhaus.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.217.172 listed in wl.mailspike.net] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid On 01/26/2016 12:55 AM, Juri Linkov wrote: > A frame might contain more pairs of navigational/target windows, > e.g. a window with *grep* output, and a file buffer visited from *grep*; > a window with *Occur*, and another place in the same file buffer > but visited from *Occur*, etc. Yes, but it wasn't your scenario there. In that scenario, you switched to a different frame, which had only a *compilation* buffer visible, and were surprised to see a next-error-function used from a non-visible buffer you last accessed in a different frame. > So frame-local is not of help here, whereas window-local is, > provided a navigational window (like *grep*/*compilation*) > always displays target buffers in another dedicated window. How does it really help? You've navigated from *grep*, to that buffer A, then did that from *compilation*, and then you can't continue jumping to next *grep* occurrences from that buffer. frame-local could be sufficient if we were sure that different navigation windows show error locations in distinctly different sets of windows, IMHO. We can fix xref, but not every next-error-function uses the same window, and that's not codified in this variable's docstring. change-log-next-error doesn't. > As I see this is not what xref currently does: navigating in it > jumps between many different windows that is very inconvenient, > but this can be easily fixed to work the sane way as *grep* > or *compilation* already works. Yes, this can use an improvement. >> How do linting minor modes (like Flycheck or Flymake) fit into this? > > Does Flycheck or Flymake display a navigation window with a list of results? Flycheck has such a buffer, but it's not displayed by default. And in any case, it sets next-error-function locally in file buffers, but not in its "list of errors" buffer. Hmm. Apparently, Flymake doesn't set next-error-function, so we can disregard it. js2-mode is another example: it's a major mode that sets next-error-function in its buffers. You can ask it for the "list of errors" buffer as well, but it's usually not shown. > If not, then this is a new case that we need to support as well. Apparently so. >> Suppose I called M-x compile (or, better yet, M-x grep), navigated to some >> file buffer from it and then see that it has some linter errors highlighed >> by Flycheck. So I want to use the current buffer's next-error-function now, >> and jump between linter warnings using next/previous-error. How do I do >> that? IIU your plan correctly, the current window-local >> next-error-last-buffer value will continue pointing at the Grep buffer, >> even if I bury it. > > What if you have two navigations in the same buffer, and both are > without a navigation window that you can't bury? I don't follow. The above was an attempt to point out an hole in your plan. I'm not sure you can refute that with a "what if" counter-example. >> - Some indicator that a given buffer's next-error-function points to other >> buffer (then, if you're in a different buffer, that other buffer is still >> relevant). Like a buffer-local variable called, for example, >> next-error-function-nonlocal. > > Do you mean to bind a navigation buffer with navigated target buffers/windows? I mean to ask compilation-mode (as well as other similar modes) to (setq-local next-error-function-nonlocal t), in addition to setting next-error-function and next-error-last-buffer. >> - A command (or several) to switch between the plausible candidates for >> next-error-last-buffer. Maybe just have a single command that uses >> read-buffer with a predicate checking the aforementioned variable and an >> extra option that means "just use the current buffer". > > This would be too complicated to use. Why complicated? It would just be a way to choose the source of errors to follow. You'd also be able to do that by clicking on an error, or pressing RET, in the "nonlocal" navigation buffers. The main point, however, which you might not agree with, is to make next-error-last-buffer global. >> - Ignore next-error-last-buffer's visibility. Or make it frame-local, to >> account for your scenario as well (but that would bring extra complexity: >> some people use use frames like almost separate applications, and other can >> use frames instead of windows, and display them side-by-side). > > Buffers are displayed in windows, so better to bind them to windows. Making next-error-last-buffer window-local feels clunkier to me: there would be no indication that a given window is following *Compilation*, for example. And up until now, next-error worked more or less in a global fashion. > I remember the original idea was to always continue the same navigation > that displayed a given target buffer/window, so switching to another > navigation in the same window could be achieved by explicitly navigating > to another result from another navigation, e.g. when current navigation > was from *compilation* then switching to *grep* buffer and typing M-n > for the next grep hit in the same file buffer. How will you "switch" to the next-error-function set locally by Flycheck in the current file-visiting buffer? How will you switch between Grep and Compilation if they display a location in the same buffer (and window)? Won't the desired navigation buffer have to be visible? So you'd have to select some window, switch to that buffer in it, and then click or press RET on some error? Using a command to switch between next-error-last-buffer candidates seems much quicker. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 26 20:40:44 2016 Received: (at 20489) by debbugs.gnu.org; 27 Jan 2016 01:40:44 +0000 Received: from localhost ([127.0.0.1]:37992 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aOF6C-0007xI-Fu for submit@debbugs.gnu.org; Tue, 26 Jan 2016 20:40:44 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:56158 helo=homiemail-a13.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aOF6A-0007x8-RY for 20489@debbugs.gnu.org; Tue, 26 Jan 2016 20:40:43 -0500 Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id D1ACB334075; Tue, 26 Jan 2016 17:40:41 -0800 (PST) Received: from localhost.linkov.net (82.131.23.111.cable.starman.ee [82.131.23.111]) (Authenticated sender: jurta@jurta.org) by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPA id 10A32334072; Tue, 26 Jan 2016 17:40:40 -0800 (PST) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Organization: LINKOV.NET References: <86wq0q602w.fsf@yandex.ru> <87oacaiszd.fsf@mail.linkov.net> <56A5BF79.909@yandex.ru> <87zivtqq81.fsf@mail.linkov.net> <56A6B171.7080504@yandex.ru> Date: Wed, 27 Jan 2016 02:57:30 +0200 In-Reply-To: <56A6B171.7080504@yandex.ru> (Dmitry Gutov's message of "Tue, 26 Jan 2016 02:36:17 +0300") Message-ID: <87y4bbol9h.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > How does it really help? You've navigated from *grep*, to that buffer A= , > then did that from *compilation*, and then you can't continue jumping t= o > next *grep* occurrences from that buffer. I suppose that navigation from every navigational window displays its tar= gets in own dedicated window that will be associated with its =E2=80=9Cparent=E2= =80=9D window. So e.g. after navigating from *grep* to window A, and from *compilation* to window B, next-error invoked from windows A or B will continue the right navigation. > We can fix xref, but not every next-error-function uses the same window= , > and that's not codified in this variable's docstring. change-log-next-e= rror > doesn't. If some next-error-function doesn't use the same window, still there is no problem because its displayed window will continue the last navigation visited in that window. >>> Suppose I called M-x compile (or, better yet, M-x grep), navigated to= some >>> file buffer from it and then see that it has some linter errors highl= ighed >>> by Flycheck. So I want to use the current buffer's next-error-functio= n now, >>> and jump between linter warnings using next/previous-error. How do I = do >>> that? IIU your plan correctly, the current window-local >>> next-error-last-buffer value will continue pointing at the Grep buffe= r, >>> even if I bury it. >> >> What if you have two navigations in the same buffer, and both are >> without a navigation window that you can't bury? > > I don't follow. The above was an attempt to point out an hole in your > plan. I'm not sure you can refute that with a "what if" counter-example= . This adds another problematic case to consider, but we could avoid it by always requiring creation of a navigation buffer, possibly hidden when necessary. (As for your point about a hole, I already addressed it below - that requires unburing a navigation buffer that you want switch t= o). >>> - Some indicator that a given buffer's next-error-function points to = other >>> buffer (then, if you're in a different buffer, that other buffer is s= till >>> relevant). Like a buffer-local variable called, for example, >>> next-error-function-nonlocal. >> >> Do you mean to bind a navigation buffer with navigated target buffers/= windows? > > I mean to ask compilation-mode (as well as other similar modes) to > (setq-local next-error-function-nonlocal t), in addition to setting > next-error-function and next-error-last-buffer. How this could help to point to other buffer? >>> - A command (or several) to switch between the plausible candidates f= or >>> next-error-last-buffer. Maybe just have a single command that uses >>> read-buffer with a predicate checking the aforementioned variable and= an >>> extra option that means "just use the current buffer". >> >> This would be too complicated to use. > > Why complicated? It would just be a way to choose the source of errors = to > follow. You'd also be able to do that by clicking on an error, or press= ing > RET, in the "nonlocal" navigation buffers. I think it would be more WYSIWYG first to switch to the navigation buffer= , and then to click on an error, or press RET. > The main point, however, which you might not agree with, is to make > next-error-last-buffer global. I prefer this precedence: 1. window-local next-error-last-buffer 2. buffer-local next-error-last-buffer 3. global next-error-last-buffer >>> - Ignore next-error-last-buffer's visibility. Or make it frame-local,= to >>> account for your scenario as well (but that would bring extra complex= ity: >>> some people use use frames like almost separate applications, and oth= er can >>> use frames instead of windows, and display them side-by-side). >> >> Buffers are displayed in windows, so better to bind them to windows. > > Making next-error-last-buffer window-local feels clunkier to me: there > would be no indication that a given window is following *Compilation*, = for > example. And up until now, next-error worked more or less in > a global fashion. Are you hinting that currently there is such indication in the form of navigation buffer's window displayed in the same frame (rule#1 in next-error-find-buffer)? I proposed window-local next-error-last-buffer only because you had some problems with this rule using in xref. >> I remember the original idea was to always continue the same navigatio= n >> that displayed a given target buffer/window, so switching to another >> navigation in the same window could be achieved by explicitly navigati= ng >> to another result from another navigation, e.g. when current navigatio= n >> was from *compilation* then switching to *grep* buffer and typing M-n >> for the next grep hit in the same file buffer. > > How will you "switch" to the next-error-function set locally by Flychec= k in > the current file-visiting buffer? By restarting Flycheck? > How will you switch between Grep and Compilation if they display a loca= tion > in the same buffer (and window)? Won't the desired navigation buffer ha= ve > to be visible? So you'd have to select some window, switch to that buff= er > in it, and then click or press RET on some error? Yes. > Using a command to switch between next-error-last-buffer candidates see= ms > much quicker. In case of Flycheck, there will be no next-error-last-buffer, no? From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 26 21:43:35 2016 Received: (at 20489) by debbugs.gnu.org; 27 Jan 2016 02:43:35 +0000 Received: from localhost ([127.0.0.1]:37998 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aOG51-0000vp-CO for submit@debbugs.gnu.org; Tue, 26 Jan 2016 21:43:35 -0500 Received: from mail-lf0-f41.google.com ([209.85.215.41]:36672) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aOG4z-0000va-NP for 20489@debbugs.gnu.org; Tue, 26 Jan 2016 21:43:34 -0500 Received: by mail-lf0-f41.google.com with SMTP id h129so118847835lfh.3 for <20489@debbugs.gnu.org>; Tue, 26 Jan 2016 18:43:33 -0800 (PST) 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=3DjwlrUm661h8330gSHJlXnlAEBSIGAHv7YhHQ8mmgk=; b=zTSiY8YPQW6BuSbCKbm0fgfgsZMbhDzt3DshiAaPXA95CsIwuWgs0+I97XYZRs1bE+ tHdG13nXg80MaLQpwDvmWsTQ+pjWRrqag1aELI5akvzqzbbAZnmq8zSX3uYy8Fe7zCN9 zYweJu1T4VO0+Dmncn8/VbNCO9i49/OqNDTymyElwfSzIDNLZUJW0lb2yxvICgvD67Bz uqcUQK6e5JtoRHdNUQNBSIZNQMEoAT1ZJyhrBZjDhxJXHJBUm0BcCRJiaOzklhSCEqM1 Hl8mdzYGoLkobkE4sJZ6bsG5RTRj9j3/G03PS0BLU+aM2aqnVN7nxcfXJLed62kwcHMC 1ghg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=3DjwlrUm661h8330gSHJlXnlAEBSIGAHv7YhHQ8mmgk=; b=m+SWC3w6Pz1vTAhPmgxIVNCJIlmdw9lw71xLDymKIJHgTyNKh3al3T3L4Ww0EQ6oTz mxq3ixAsfdDXjG28EoaZuYwcYQFZ9VE1q4rkmAdIwtYEZO7gNV0M1je/x6YoGmhsQpmE qCyewrVdb4jEuscIfkIRtRyR2iaxvFjaR/hS6CgARO9QAxfxAsJ0TnUw80a1I31WZagB vGyEGKm8LGRMqGbt7bMVjpRZJ7fPy6wZ/TMZORYLJsqJiinZ8LX0CVEMoRQo+8DGbmSV icP8GGv2BToKxZA8V6Sm4fxFfoJqQy+Z1lyLNEagygxbX26j4AO58t2vgo6Jmw8T9fwa 22YQ== X-Gm-Message-State: AG10YOQaUiglfaxgwXVic20R7N2NILMiBcUBHeGKlxQPHu4DQJzv/HZ5zkio+M+NbZU+UQ== X-Received: by 10.25.152.199 with SMTP id a190mr10701911lfe.133.1453862607783; Tue, 26 Jan 2016 18:43:27 -0800 (PST) Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id f186sm512310lfd.26.2016.01.26.18.43.26 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jan 2016 18:43:26 -0800 (PST) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason To: Juri Linkov References: <86wq0q602w.fsf@yandex.ru> <87oacaiszd.fsf@mail.linkov.net> <56A5BF79.909@yandex.ru> <87zivtqq81.fsf@mail.linkov.net> <56A6B171.7080504@yandex.ru> <87y4bbol9h.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <56A82ECE.6050609@yandex.ru> Date: Wed, 27 Jan 2016 05:43:26 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: <87y4bbol9h.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 3.1 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 01/27/2016 03:57 AM, Juri Linkov wrote: > I suppose that navigation from every navigational window displays its targets > in own dedicated window that will be associated with its “parent” window. [...] Content analysis details: (3.1 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.215.41 listed in list.dnswl.org] 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [178.252.127.222 listed in zen.spamhaus.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.215.41 listed in wl.mailspike.net] 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 3.1 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 01/27/2016 03:57 AM, Juri Linkov wrote: > I suppose that navigation from every navigational window displays its targets > in own dedicated window that will be associated with its “parent” window. [...] Content analysis details: (3.1 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.215.41 listed in list.dnswl.org] 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [178.252.127.222 listed in zen.spamhaus.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.215.41 listed in wl.mailspike.net] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders On 01/27/2016 03:57 AM, Juri Linkov wrote: > I suppose that navigation from every navigational window displays its targets > in own dedicated window that will be associated with its “parent” window. That's a considerable change. Associated how? The window itself won't have any indication with which navigation buffer it's associated with, will it? And what if you do have the same buffer references in different navigation windows? Will they have to show it in both associated windows? That seems wasteful. > So e.g. after navigating from *grep* to window A, and from *compilation* > to window B, next-error invoked from windows A or B will continue > the right navigation. Suppose you've did that, then turned left to look out of the window for half a minute, then looked back at Emacs. How are you going to predict what M-x next-error will do? Now, in addition to remembering which navigational command you ran last, you have to remember the window associations. >> We can fix xref, but not every next-error-function uses the same window, >> and that's not codified in this variable's docstring. change-log-next-error >> doesn't. > > If some next-error-function doesn't use the same window, still there is > no problem because its displayed window will continue the last navigation > visited in that window. And soon, all windows in the frame will refer to the ChangeLog buffer as its next-error-last-buffer, right? `next-error' always continuing the last navigation does not require window-local values. We can just have next-error-last-buffer to be global. And if you're still thinking of the two-frame scenario, here's a little modification: - Run M-x grep in one frame, with several windows, jump to an error there, in window A. - Switch to another frame, run M-x compile there. - Switch back to the first frame. But select some other window than A. Call M-x next-error, and see it use the location from the *compilation* buffer, even though *grep* is visible right there. That scenario looks just as counter-intuitive to me as the original one. Your proposal would only fix the original one. > This adds another problematic case to consider, but we could avoid it > by always requiring creation of a navigation buffer, possibly hidden > when necessary. (As for your point about a hole, I already addressed it > below - that requires unburing a navigation buffer that you want switch to). One navigational buffer per file buffer? That's too much. >> I mean to ask compilation-mode (as well as other similar modes) to >> (setq-local next-error-function-nonlocal t), in addition to setting >> next-error-function and next-error-last-buffer. > > How this could help to point to other buffer? It will only tag it to be available for completion in the new pick-next-error-last-buffer command. Or we can put those buffers in a ring, which was also suggested here previously. That would also tag them, and allow switching between them in a historical fashion. >> Why complicated? It would just be a way to choose the source of errors to >> follow. You'd also be able to do that by clicking on an error, or pressing >> RET, in the "nonlocal" navigation buffers. > > I think it would be more WYSIWYG first to switch to the navigation buffer, > and then to click on an error, or press RET. That can also be a way to change the global next-error-last-buffer value. And whether it's window-local or not, neither scenario solves the Flycheck problem. >> The main point, however, which you might not agree with, is to make >> next-error-last-buffer global. > > I prefer this precedence: > 1. window-local next-error-last-buffer > 2. buffer-local next-error-last-buffer > 3. global next-error-last-buffer My preference is: 3, 2. Except we never set next-error-last-buffer locally, so we should interpret the global nil value to mean "the current buffer". >> Making next-error-last-buffer window-local feels clunkier to me: there >> would be no indication that a given window is following *Compilation*, for >> example. And up until now, next-error worked more or less in >> a global fashion. > > Are you hinting that currently there is such indication in the form of > navigation buffer's window displayed in the same frame (rule#1 in > next-error-find-buffer)? That an one option - we can indeed keep some logic reliant on whether next-error-last-buffer is visible in the current frame (but drop the "not more than one" limitation, because it leads to non-intuitive behavior). Then the change to the API could be smaller, but the use case of using next-error with non-visible navigational buffers will be more broken than currently. But my first choice is to not rely on buffer visibility at all, and simply follow the current global next-error-last-buffer value, as well as provide an easy way to switch to a different one. > I proposed window-local next-error-last-buffer only because you had > some problems with this rule using in xref. Yes, I did. But IIUC, Eli had more of a problem with the (if (eq (length window-buffers) 1) part of that rule. The commit that disabled next-error integration in xref has a link to that discussion in its message. >> How will you "switch" to the next-error-function set locally by Flycheck in >> the current file-visiting buffer? > > By restarting Flycheck? Restarting how? It's a minor mode that triggers linting checks when the buffer is saved, or you've typed something and wait a bit, or the file buffer has just been opened. The exact set of conditions is customizable. And it doesn't set next-error-last-buffer at all. But suppose it did. Imagine: you M-x compile, jump to an error, that opens the file in a new buffer, Flycheck kicks in, runs its linting check, and sets next-error-function and next-error-last-buffer in that buffer. If you call next-error now, you'll be jumping to the next linting error, not *compilation* error. >> How will you switch between Grep and Compilation if they display a location >> in the same buffer (and window)? Won't the desired navigation buffer have >> to be visible? So you'd have to select some window, switch to that buffer >> in it, and then click or press RET on some error? > > Yes. Lots of clicking. >> Using a command to switch between next-error-last-buffer candidates seems >> much quicker. > > In case of Flycheck, there will be no next-error-last-buffer, no? We should interpret nil as "use the current buffer". From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 27 18:02:21 2016 Received: (at 20489) by debbugs.gnu.org; 27 Jan 2016 23:02:21 +0000 Received: from localhost ([127.0.0.1]:39025 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aOZ6S-0007yG-UV for submit@debbugs.gnu.org; Wed, 27 Jan 2016 18:02:21 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:60778 helo=homiemail-a76.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aOZ6R-0007y8-Qb for 20489@debbugs.gnu.org; Wed, 27 Jan 2016 18:02:20 -0500 Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id BF33645807B; Wed, 27 Jan 2016 15:02:18 -0800 (PST) Received: from localhost.linkov.net (85.253.58.108.cable.starman.ee [85.253.58.108]) (Authenticated sender: jurta@jurta.org) by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id D9C34458079; Wed, 27 Jan 2016 15:02:17 -0800 (PST) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Organization: LINKOV.NET References: <86wq0q602w.fsf@yandex.ru> <87oacaiszd.fsf@mail.linkov.net> <56A5BF79.909@yandex.ru> <87zivtqq81.fsf@mail.linkov.net> <56A6B171.7080504@yandex.ru> <87y4bbol9h.fsf@mail.linkov.net> <56A82ECE.6050609@yandex.ru> Date: Thu, 28 Jan 2016 00:57:31 +0200 In-Reply-To: <56A82ECE.6050609@yandex.ru> (Dmitry Gutov's message of "Wed, 27 Jan 2016 05:43:26 +0300") Message-ID: <87powmd410.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> So e.g. after navigating from *grep* to window A, and from *compilation* >> to window B, next-error invoked from windows A or B will continue >> the right navigation. > > Suppose you've did that, then turned left to look out of the window for > half a minute, then looked back at Emacs. How are you going to predict what > M-x next-error will do? You can see an arrow indication in the left fringe of the navigational window that points to the location of the current file displayed in an adjacent window. > But my first choice is to not rely on buffer visibility at all, and simply > follow the current global next-error-last-buffer value, as well as provide > an easy way to switch to a different one. I just posted an IDE-like layout to emacs-devel, and it demonstrates that the current rule#1 in next-error-find-buffer is the right thing to do in this scenario: after switching from e.g. *grep* to *xref* in the bottom window, next-error will continue navigation from the visible navigation buffer. So no changes are required in this case. >> I proposed window-local next-error-last-buffer only because you had >> some problems with this rule using in xref. > > Yes, I did. But IIUC, Eli had more of a problem with the > > (if (eq (length window-buffers) 1) > > part of that rule. The commit that disabled next-error integration in xref > has a link to that discussion in its message. The rule (if (eq (length window-buffers) 1) itself is not a problem. The problem is in the cases that this rule doesn't support, i.e. (< (length window-buffers) 1) and (> (length window-buffers) 1) We need to find a way to handle these cases as well. >>> How will you switch between Grep and Compilation if they display a location >>> in the same buffer (and window)? Won't the desired navigation buffer have >>> to be visible? So you'd have to select some window, switch to that buffer >>> in it, and then click or press RET on some error? >> >> Yes. > > Lots of clicking. No clicking at all, I don't use the mouse :) From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 27 18:28:10 2016 Received: (at 20489) by debbugs.gnu.org; 27 Jan 2016 23:28:11 +0000 Received: from localhost ([127.0.0.1]:39040 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aOZVS-00008r-N4 for submit@debbugs.gnu.org; Wed, 27 Jan 2016 18:28:10 -0500 Received: from mail-lb0-f173.google.com ([209.85.217.173]:33632) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aOZVR-00008e-6p for 20489@debbugs.gnu.org; Wed, 27 Jan 2016 18:28:09 -0500 Received: by mail-lb0-f173.google.com with SMTP id x4so14494375lbm.0 for <20489@debbugs.gnu.org>; Wed, 27 Jan 2016 15:28:09 -0800 (PST) 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=janw2B1geLU8UW4xbyIWeAfWm6HLCDqijYb6fjDOyKY=; b=W9ndxz8KDF9OHaXc0HLtxGnU1IcCatnMQJNFsj2nM59qhUw8HX5D9AIGPm6JfrZibN 5nbYTm3/lE/8CODVr6QoEuZatkDwBf/+soEhp9jhPkZCE7ZuQxSzaeVEzepDbaoXNf98 BLW7c/ayZXzU4ooQbeAyfmRhXSGvvZGZBpmK9G+JilHCqDSxr+xSd+wqF6q0TLNIcHbr Fs+gcKcOjo5mcQlQPHRGVlv0ZH4B1QT2oO7RWey5GCP0FPFTVL2WJEKfjitVQjR/wfcv rGB0MX+V6EESrbSKch46UPNHPLAToidRThVXTnha5D2QHUzl/MlOGuRzwtZ/8tLYsNe5 EFJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=janw2B1geLU8UW4xbyIWeAfWm6HLCDqijYb6fjDOyKY=; b=DOLB+yVj/8gw5yL06wwyShFlWkCvWJPBof3SzBz/1h06puoaC59LYJGt2w6LGHWvR6 OwRGt+51powdVjbYdFJcxgabr4L5Oz17i2YNM+HFEyk6fGikJQPoYoYKJjMeiusn25jv qSrfzrMueaxErqgbnF7cFE+xXoHAsFsYg3n+pT+kPUwzWPJTJcZxlOtLW7B8bY/kWYcf marCCZr/+tXl/Dy+UxK8vLVxztUQzQsVd55FV1g4nm33ePkpRQdkdxEM5I3R9Pf7Qflu GCIlXyQS0r5LgN2Mck0fEB1LaoiO7I3QNI0je9BRLyxrtbHtKrXMLetxum9nbYh1gk9K lr3A== X-Gm-Message-State: AG10YOQpoYqZ7X5P7LreWTSON9020g09cj5y+3h1sp3uynMwTsQlZ+Dt29fO7+P/BV55GQ== X-Received: by 10.112.134.70 with SMTP id pi6mr9991798lbb.59.1453937283391; Wed, 27 Jan 2016 15:28:03 -0800 (PST) Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id 67sm907796lfq.36.2016.01.27.15.28.02 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jan 2016 15:28:02 -0800 (PST) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason To: Juri Linkov References: <86wq0q602w.fsf@yandex.ru> <87oacaiszd.fsf@mail.linkov.net> <56A5BF79.909@yandex.ru> <87zivtqq81.fsf@mail.linkov.net> <56A6B171.7080504@yandex.ru> <87y4bbol9h.fsf@mail.linkov.net> <56A82ECE.6050609@yandex.ru> <87powmd410.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <56A95281.9080205@yandex.ru> Date: Thu, 28 Jan 2016 02:28:01 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: <87powmd410.fsf@mail.linkov.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 01/28/2016 01:57 AM, Juri Linkov wrote: > You can see an arrow indication in the left fringe of the navigational window > that points to the location of the current file displayed in an adjacent window. [...] Content analysis details: (3.1 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.217.173 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [178.252.127.222 listed in zen.spamhaus.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.217.173 listed in wl.mailspike.net] 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 3.1 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 01/28/2016 01:57 AM, Juri Linkov wrote: > You can see an arrow indication in the left fringe of the navigational window > that points to the location of the current file displayed in an adjacent window. [...] Content analysis details: (3.1 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.217.173 listed in list.dnswl.org] 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [178.252.127.222 listed in zen.spamhaus.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.217.173 listed in wl.mailspike.net] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (raaahh[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders On 01/28/2016 01:57 AM, Juri Linkov wrote: > You can see an arrow indication in the left fringe of the navigational window > that points to the location of the current file displayed in an adjacent window. That's only true of compilation-mode and its derivatives. It's not a part of next-error-function contract (again, change-log-next-error does nothing of the sort; diff-next-error doesn't either). Maybe it's a good idea, but I'm not sure how to enforce something like that, to be able to rely on it. And a small arrow in one window is not a great indicator anyway. > I just posted an IDE-like layout to emacs-devel, and it demonstrates that the > current rule#1 in next-error-find-buffer is the right thing to do in this > scenario: after switching from e.g. *grep* to *xref* in the bottom window, > next-error will continue navigation from the visible navigation buffer. > So no changes are required in this case. What case? We're not going to introduce IDE-like layout as the mandatory, or the default, behavior. The rule#1, as written, also poorly interacts with Flycheck-like use cases. Are you going to comment on that part discussion? Because if you're going to disregard it, we might as well stop talking right now: any acceptable proposal, as far as I'm concerned, handles that case. > The problem is in the cases that this rule doesn't support, i.e. > (< (length window-buffers) 1) and (> (length window-buffers) 1) > We need to find a way to handle these cases as well. Yes: remove that check, for example. We can also realize that the rule #1 is an attempt to do the following: if next-error-last-buffer is no longer visible, try to pick a navigational buffer among the currently visible ones. However, the rule tries to limit the number of visible navigational buffer to one, and aborts otherwise. I think that's because it doesn't know any better way to distinguish between navigational buffers and plain file-visiting buffers that have next-error-function set locally (navigational buffers can also be file-visiting, as in the cases of change-log-mode and diff-mode). The new variable that I proposed would help. > No clicking at all, I don't use the mouse :) Lots of pressing the buttons, then. Which is what I meant. From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 28 19:13:15 2016 Received: (at 20489) by debbugs.gnu.org; 29 Jan 2016 00:13:15 +0000 Received: from localhost ([127.0.0.1]:40118 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aOwgd-0006V9-DB for submit@debbugs.gnu.org; Thu, 28 Jan 2016 19:13:15 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:44101 helo=homiemail-a39.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aOwgc-0006V1-4u for 20489@debbugs.gnu.org; Thu, 28 Jan 2016 19:13:14 -0500 Received: from homiemail-a39.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a39.g.dreamhost.com (Postfix) with ESMTP id EB987150074; Thu, 28 Jan 2016 16:13:12 -0800 (PST) Received: from localhost.linkov.net (85.253.170.103.cable.starman.ee [85.253.170.103]) (Authenticated sender: jurta@jurta.org) by homiemail-a39.g.dreamhost.com (Postfix) with ESMTPA id 1ED11150078; Thu, 28 Jan 2016 16:13:11 -0800 (PST) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Organization: LINKOV.NET References: <86wq0q602w.fsf@yandex.ru> <87oacaiszd.fsf@mail.linkov.net> <56A5BF79.909@yandex.ru> <87zivtqq81.fsf@mail.linkov.net> <56A6B171.7080504@yandex.ru> <87y4bbol9h.fsf@mail.linkov.net> <56A82ECE.6050609@yandex.ru> <87powmd410.fsf@mail.linkov.net> <56A95281.9080205@yandex.ru> Date: Fri, 29 Jan 2016 01:59:45 +0200 In-Reply-To: <56A95281.9080205@yandex.ru> (Dmitry Gutov's message of "Thu, 28 Jan 2016 02:28:01 +0300") Message-ID: <8737th5kt6.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > Maybe it's a good idea, but I'm not sure how to enforce something like > that, to be able to rely on it. And a small arrow in one window is not > a great indicator anyway. A good indication could be provided by a new global minor mode =E2=80=98global-next-error-minor-mode=E2=80=99 showing in the mode line the currently active navigation, and allowing switching to another navigation. > The rule#1, as written, also poorly interacts with Flycheck-like use > cases. Are you going to comment on that part discussion? Flycheck provides its own keybinding =E2=80=98C-c ! n=E2=80=99 for =E2=80= =98flycheck-next-error=E2=80=99, so really there is no problem. A real problem is when a navigational buffer does exist, but it's hidden. IIUC, due to this problem you reverted next-error integration in xref, ri= ght? > We can also realize that the rule #1 is an attempt to do the following:= if > next-error-last-buffer is no longer visible, try to pick a navigational > buffer among the currently visible ones. You mean next-error-last-buffer is no longer visible _on the selected fra= me_? > However, the rule tries to limit the number of visible navigational buf= fer > to one, and aborts otherwise. I think that's because it doesn't know an= y > better way to distinguish between navigational buffers and plain > file-visiting buffers that have next-error-function set locally > (navigational buffers can also be file-visiting, as in the cases of > change-log-mode and diff-mode). The new variable that I proposed > would help. Yes, this is because it's hard to find a better way, and I'm not sure how next-error-function-nonlocal could help, because sometimes a navigati= on might visit another non-file navigational buffer, e.g. multi-occur visiting a *compilation* buffer. From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 28 19:35:28 2016 Received: (at 20489) by debbugs.gnu.org; 29 Jan 2016 00:35:28 +0000 Received: from localhost ([127.0.0.1]:40127 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aOx28-0000D9-DP for submit@debbugs.gnu.org; Thu, 28 Jan 2016 19:35:28 -0500 Received: from mail-lb0-f178.google.com ([209.85.217.178]:33193) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aOx27-0000Cx-0E for 20489@debbugs.gnu.org; Thu, 28 Jan 2016 19:35:27 -0500 Received: by mail-lb0-f178.google.com with SMTP id x4so33229467lbm.0 for <20489@debbugs.gnu.org>; Thu, 28 Jan 2016 16:35:26 -0800 (PST) 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=SBAdPlPSRFXANrB4rRcEM411vzLkWAnoBxPWa96pNf0=; b=FhCTOA8gpZplrGjG/HcdE2QLglKTau0eqH2wUWvLzo4TqOymBh5mw9GeeIVk3b7e69 QA0ARuMzrDgTxIr+EjuZ/nfvi3xBIluCx32MxKyYzNgrWUeAxIiyXhbIBxlyjh6N0nqf rJN0xVV2NdZ9M0om+RwbkqR4nKQPHXc7T3htMw0vNNdOZ2jViZta0SjFdsheRABmQMLs 34Rc7mW5zyzus4hC0WkO5/OzzvK0eIRHSUQLdGX/N2gC5CYN27cY2BSCNO9Y6cBADGkS GJdoUxEKjiVBfgXFrp9SksDbfmcPJtAs7Kgpnv6l964R8oZJdegQj1t/PwgLe4A9qGRN aEFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=SBAdPlPSRFXANrB4rRcEM411vzLkWAnoBxPWa96pNf0=; b=b8ZRM4VMJ4J93/FwC2wn4ha5v3uRj50+NeK7j0AnKpz2QzoyDtv2d1kDG8v5/MwSBS 0584Ctcl/ctYF36lbOMKQz8dlyaB6pzaEyeCBuxHoH16Kxq9EScgX0g+i39uxhpBZtdE aYmyS+i+V/Q5v5xjy8MegXsg8j+gVyVqmpGHVHeAApGJDV0wbjnkcKQSbhlNZLErE0sb tcIrt/bvV+2KJOz2NwWpY5pNIJ+/adPeCLRNEpczKfQp6S0IgGbTWw0unPp/Tey9BvxW FcMShATbtqHnsjTTQ16E+stCLRInvXeViav35HJ3gaOJfzUii6Xg9QuCmlaXmHVdfNvd NxRg== X-Gm-Message-State: AG10YOQ14SNQETRq/PiBc2Q9olzty7EbuSKdeTuYIvAe94xqkR1JP1mc+0fY9Urodq1h6g== X-Received: by 10.112.198.102 with SMTP id jb6mr2206261lbc.44.1454027720953; Thu, 28 Jan 2016 16:35:20 -0800 (PST) Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id o3sm1772556lfb.39.2016.01.28.16.35.19 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jan 2016 16:35:20 -0800 (PST) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason To: Juri Linkov References: <86wq0q602w.fsf@yandex.ru> <87oacaiszd.fsf@mail.linkov.net> <56A5BF79.909@yandex.ru> <87zivtqq81.fsf@mail.linkov.net> <56A6B171.7080504@yandex.ru> <87y4bbol9h.fsf@mail.linkov.net> <56A82ECE.6050609@yandex.ru> <87powmd410.fsf@mail.linkov.net> <56A95281.9080205@yandex.ru> <8737th5kt6.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <56AAB3C7.70902@yandex.ru> Date: Fri, 29 Jan 2016 03:35:19 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: <8737th5kt6.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 01/29/2016 02:59 AM, Juri Linkov wrote: > ...and allowing switching > to another navigation. Are you coming around to my suggestion now? >> The rule#1, as written, also poorly interacts with Flycheck-like use >> cases. Are you going to comment on that part discussion? > > Flycheck provides its own keybinding ‘C-c ! n’ for ‘flycheck-next-error’, > so really there is no problem. That's basically giving up. Do you expect me to repeatedly type `C-c ! n' to move across errors in the current buffer? It's not like it's inconvenient or anything. next-error-function was added exactly so that the user doesn't have to learn a bunch of different key bindings for basically the same thing. There's also e.g. js2-mode, which doesn't have a custom key binding for this. And probably other modes that I just don't know about. > A real problem is when a navigational buffer does exist, but it's hidden. > IIUC, due to this problem you reverted next-error integration in xref, right? No: http://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01286.html See the first sentence there. >> We can also realize that the rule #1 is an attempt to do the following: if >> next-error-last-buffer is no longer visible, try to pick a navigational >> buffer among the currently visible ones. > > You mean next-error-last-buffer is no longer visible _on the selected frame_? I don't really care either way. This question doesn't seem to add any big constraints on the final solution. > Yes, this is because it's hard to find a better way, and I'm not sure > how next-error-function-nonlocal could help, because sometimes a navigation > might visit another non-file navigational buffer, e.g. multi-occur > visiting a *compilation* buffer. What is the exact problem you have in mind there? When *multi-occur* jumps to *compilation*, next-error-last-buffer keeps referring to *multi-occur*. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 29 18:49:40 2016 Received: (at 20489) by debbugs.gnu.org; 29 Jan 2016 23:49:40 +0000 Received: from localhost ([127.0.0.1]:40871 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aPInM-0002v9-Bh for submit@debbugs.gnu.org; Fri, 29 Jan 2016 18:49:40 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:45018 helo=homiemail-a22.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aPInL-0002v2-4k for 20489@debbugs.gnu.org; Fri, 29 Jan 2016 18:49:39 -0500 Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 9289B1A8071; Fri, 29 Jan 2016 15:49:36 -0800 (PST) Received: from localhost.linkov.net (62.65.213.148.cable.starman.ee [62.65.213.148]) (Authenticated sender: jurta@jurta.org) by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id C21E01A8061; Fri, 29 Jan 2016 15:49:35 -0800 (PST) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Organization: LINKOV.NET References: <86wq0q602w.fsf@yandex.ru> <87oacaiszd.fsf@mail.linkov.net> <56A5BF79.909@yandex.ru> <87zivtqq81.fsf@mail.linkov.net> <56A6B171.7080504@yandex.ru> <87y4bbol9h.fsf@mail.linkov.net> <56A82ECE.6050609@yandex.ru> <87powmd410.fsf@mail.linkov.net> <56A95281.9080205@yandex.ru> <8737th5kt6.fsf@mail.linkov.net> <56AAB3C7.70902@yandex.ru> Date: Sat, 30 Jan 2016 01:44:07 +0200 In-Reply-To: <56AAB3C7.70902@yandex.ru> (Dmitry Gutov's message of "Fri, 29 Jan 2016 03:35:19 +0300") Message-ID: <871t90c5o8.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > Do you expect me to repeatedly type `C-c ! n' to move across errors in the > current buffer? It's not like it's inconvenient or > anything. next-error-function was added exactly so that the user doesn't > have to learn a bunch of different key bindings for basically the > same thing. Not repeatedly, it's enough to type is only once, and subsequent invocations of next-error will pick up a new navigation. >> A real problem is when a navigational buffer does exist, but it's hidden. >> IIUC, due to this problem you reverted next-error integration in xref, right? > > No: http://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01286.html > > See the first sentence there. I reread it every time you reference it, but it adds nothing to the discussion. Could you provide more details about this problem. I imagine you meant the case when *xref* is hidden, but *compilation* is visible. Is it so? What are the preconditions for this situation to occur? >> Yes, this is because it's hard to find a better way, and I'm not sure >> how next-error-function-nonlocal could help, because sometimes a navigation >> might visit another non-file navigational buffer, e.g. multi-occur >> visiting a *compilation* buffer. > > What is the exact problem you have in mind there? > > When *multi-occur* jumps to *compilation*, next-error-last-buffer keeps > referring to *multi-occur*. But after you hide *compilation*, *multi-occur* will kick in. This is why I proposed to use window-local values, and your counter-arguments against it (indication/switching) apply to the already used global value of next-error-last-buffer as well: its current state is not discoverable and it's not easy to switch to another navigation. This issue is real, but orthogonal to the subject of bug#20489. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 29 19:58:07 2016 Received: (at 20489) by debbugs.gnu.org; 30 Jan 2016 00:58:08 +0000 Received: from localhost ([127.0.0.1]:40877 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aPJrb-0004WA-L7 for submit@debbugs.gnu.org; Fri, 29 Jan 2016 19:58:07 -0500 Received: from mail-lf0-f52.google.com ([209.85.215.52]:34397) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aPJrZ-0004Vg-Su for 20489@debbugs.gnu.org; Fri, 29 Jan 2016 19:58:06 -0500 Received: by mail-lf0-f52.google.com with SMTP id 17so56934465lfz.1 for <20489@debbugs.gnu.org>; Fri, 29 Jan 2016 16:58:05 -0800 (PST) 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=3PSRBdhgF3E1j1wGneGGhqKpksrkn2LKQrMvFtDgTdc=; b=feUwRRVy53PyzL9aHzDXhG5F4No4y72WNDu7jmFR35y6/jXW4fBDCHc3ItxvKqAvLt CMODuWHHivyG0h89mtjIzoWEOV/aJcpSyUwOhFU/tKjEVoOCLIlflu30los9AXckuFat cdqu6Dqx8AN2T3tqaOTUnYRB6ER5EjvsPE25TC3+6tqlbzI+ae8yfSogcSM0+jDZ9RMu Lc9UdwJOagnGWWaGKsFasGy5MqrXfVAYPJo0g4ACVKLnsqoaExKCBulgu/JuLQzftHCM brtYgKU38/7i330vYagAojNoc8k7+mr6E1+aeqJ7BKwKXxNXjve8zol9lA8Ww9kO01Gg bVoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=3PSRBdhgF3E1j1wGneGGhqKpksrkn2LKQrMvFtDgTdc=; b=biuCIlmeXN6UAsTyVQE59SAxuOwnLbKbyUn3kpG9wVe/SbfXGAxVWmIZcJNQWVqxWS EaeKjNqBOjDI+a68ECpTBrh+nn7ec/rnpvfI3E6si+4jJJ2xmgo+Zri58/U+WhSHGDfi zlhsw3CD6ZJw1dBYjZe4UQa2SVmd6aYnDhySVQgftxorR6vN9WWcQZUCieMxoFXaVlzA KaFe7GZENBa/R1y5D0KUFeQIZJzbUK1CcTzRbMJpGFishUA2d285rbEGB0nL6o952D60 Ph4brFZfhn9h8ZssEO4IDd9PNjmwJ6S5d2bfi/jmdAv9kotC0s02u+GEhkX+8mE6Fquv D9sw== X-Gm-Message-State: AG10YOSA6Bj/10KeBOSdyEmseqT9CFT8JS1xkIRxGfD8wqQYUcMLGKFV6Upx8IQjb8SaEQ== X-Received: by 10.25.90.83 with SMTP id o80mr4426294lfb.23.1454115479828; Fri, 29 Jan 2016 16:57:59 -0800 (PST) Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id c192sm2489030lfb.16.2016.01.29.16.57.58 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jan 2016 16:57:58 -0800 (PST) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason To: Juri Linkov References: <86wq0q602w.fsf@yandex.ru> <87oacaiszd.fsf@mail.linkov.net> <56A5BF79.909@yandex.ru> <87zivtqq81.fsf@mail.linkov.net> <56A6B171.7080504@yandex.ru> <87y4bbol9h.fsf@mail.linkov.net> <56A82ECE.6050609@yandex.ru> <87powmd410.fsf@mail.linkov.net> <56A95281.9080205@yandex.ru> <8737th5kt6.fsf@mail.linkov.net> <56AAB3C7.70902@yandex.ru> <871t90c5o8.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <56AC0A95.2030001@yandex.ru> Date: Sat, 30 Jan 2016 03:57:57 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: <871t90c5o8.fsf@mail.linkov.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 01/30/2016 02:44 AM, Juri Linkov wrote: > Not repeatedly, it's enough to type is only once, and subsequent invocations > of next-error will pick up a new navigation. Fair enough. But the complaint about memorizing different key bindings still stands. >>> A real problem is when a navigational buffer does exist, but it's hidden. >>> IIUC, due to this problem you reverted next-error integration in xref, right? Why is that a problem? Depending on the approach, we either keep using it, or switch to the visible one. >> No: http://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01286.html >> >> See the first sentence there. > > I reread it every time you reference it, but it adds nothing to the discussion. > Could you provide more details about this problem. I imagine you meant the case > when *xref* is hidden, but *compilation* is visible. Is it so? What are the > preconditions for this situation to occur? You really should ask Eli what exactly he meant there, I'm just guessing. I didn't want to keep inquiring at that point. Eli said disable, so I disabled. But IMHO, (eq (length window-buffers) 1) is counter-intuitive: take the configuration with three buffers with next-error-function set visible. Hide the current last-buffer: nothing changes, `next-error' continues working as it did. Hide the next one: and suddenly, `next-error' starts behaving differently. The user is expected to understand too much. >> When *multi-occur* jumps to *compilation*, next-error-last-buffer keeps >> referring to *multi-occur*. > > But after you hide *compilation*, *multi-occur* will kick in. So? It's you who's advocating to stop using the non-visible last-buffer's. My first choice is to only switch next-error-last-buffer when the user requests this explicitly. On the other hand, if we choose the semantics "not visible => bad last-buffer", that would be understandable, too. I don't see why you consider the case "multi-occur references compilation" to be more special than others. It seems no different from "both grep and compilation are visible". > This is why I proposed to use window-local values, and your counter-arguments > against it (indication/switching) apply to the already used global value > of next-error-last-buffer as well: its current state is not discoverable > and it's not easy to switch to another navigation. Your proposal _complicates_ the current state, making it more of a problem. If the global value of next-error-last-buffer is used consistently, at least the current state is easier to remember. I'm also not a big fan of window-local semantics here, personally. > This issue is real, > but orthogonal to the subject of bug#20489. Would you like me to rename the subject to something? The actual problem is that `next-error' exhibits surprising behavior, and doesn't properly support `next-error-function' being set in file-visiting buffers, which is a common situation these days. Since filing this bug, I've somewhat warmed up to using buffer visibility as a condition to choose next-error-last-buffer. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 30 19:16:12 2016 Received: (at 20489) by debbugs.gnu.org; 31 Jan 2016 00:16:12 +0000 Received: from localhost ([127.0.0.1]:42401 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aPfga-0002K0-9T for submit@debbugs.gnu.org; Sat, 30 Jan 2016 19:16:12 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:37942 helo=homiemail-a11.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aPfgY-0002Jq-AM for 20489@debbugs.gnu.org; Sat, 30 Jan 2016 19:16:10 -0500 Received: from homiemail-a11.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a11.g.dreamhost.com (Postfix) with ESMTP id 9CE3F6E070; Sat, 30 Jan 2016 16:16:07 -0800 (PST) Received: from localhost.linkov.net (62.65.226.255.cable.starman.ee [62.65.226.255]) (Authenticated sender: jurta@jurta.org) by homiemail-a11.g.dreamhost.com (Postfix) with ESMTPA id D25DA6E06A; Sat, 30 Jan 2016 16:16:06 -0800 (PST) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Organization: LINKOV.NET References: <86wq0q602w.fsf@yandex.ru> <87oacaiszd.fsf@mail.linkov.net> <56A5BF79.909@yandex.ru> <87zivtqq81.fsf@mail.linkov.net> <56A6B171.7080504@yandex.ru> <87y4bbol9h.fsf@mail.linkov.net> <56A82ECE.6050609@yandex.ru> <87powmd410.fsf@mail.linkov.net> <56A95281.9080205@yandex.ru> <8737th5kt6.fsf@mail.linkov.net> <56AAB3C7.70902@yandex.ru> <871t90c5o8.fsf@mail.linkov.net> <56AC0A95.2030001@yandex.ru> Date: Sun, 31 Jan 2016 01:43:59 +0200 In-Reply-To: <56AC0A95.2030001@yandex.ru> (Dmitry Gutov's message of "Sat, 30 Jan 2016 03:57:57 +0300") Message-ID: <87si1etyyo.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >>> No: http://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01286.html >>> >>> See the first sentence there. >> >> I reread it every time you reference it, but it adds nothing to the discussion. >> Could you provide more details about this problem. I imagine you meant the case >> when *xref* is hidden, but *compilation* is visible. Is it so? What are the >> preconditions for this situation to occur? > > You really should ask Eli what exactly he meant there, I'm just > guessing. I didn't want to keep inquiring at that point. Eli said disable, > so I disabled. I believe Eli meant this case because it's hard to imagine another one. So we have to find a solution for this case. By setting a window-local value of next-error-last-buffer in the selected window, we can continue the xref-navigation even when *compilation* is visible in an adjacent window. > But IMHO, (eq (length window-buffers) 1) is counter-intuitive: take the > configuration with three buffers with next-error-function set visible. Hide > the current last-buffer: nothing changes, `next-error' continues working as > it did. Hide the next one: and suddenly, `next-error' starts > behaving differently. When the number of next-error-function windows is more than one, then there's a dilemma which one to use. >> This is why I proposed to use window-local values, and your counter-arguments >> against it (indication/switching) apply to the already used global value >> of next-error-last-buffer as well: its current state is not discoverable >> and it's not easy to switch to another navigation. > > Your proposal _complicates_ the current state, making it more of > a problem. If the global value of next-error-last-buffer is used > consistently, at least the current state is easier to remember. But it allows the user to continue a paused navigation in another window in another frame, thus having several simultaneously active navigations in different windows. > The actual problem is that `next-error' exhibits surprising behavior, > and doesn't properly support `next-error-function' being set in > file-visiting buffers, which is a common situation these days. What happens when two features set `next-error-function' at the same time? I guess the latest wins, so there is no problem no matter if using visibility of next-error-last-buffer or window-local values. > Since filing this bug, I've somewhat warmed up to using buffer visibility > as a condition to choose next-error-last-buffer. Visibility of next-error-last-buffer is not suitable for navigations without a navigational buffer. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 30 19:39:44 2016 Received: (at 20489) by debbugs.gnu.org; 31 Jan 2016 00:39:45 +0000 Received: from localhost ([127.0.0.1]:42413 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aPg3M-0002so-NR for submit@debbugs.gnu.org; Sat, 30 Jan 2016 19:39:44 -0500 Received: from mail-lf0-f51.google.com ([209.85.215.51]:33846) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aPg3L-0002sZ-3W for 20489@debbugs.gnu.org; Sat, 30 Jan 2016 19:39:43 -0500 Received: by mail-lf0-f51.google.com with SMTP id j78so7345403lfb.1 for <20489@debbugs.gnu.org>; Sat, 30 Jan 2016 16:39:42 -0800 (PST) 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=Zo+/ixLbc+HMlH9uGOgr+hPixdvr+y8wE9eP4inYnyo=; b=NBqDyRLlE1sxC9xg/aLGsmJxLV9lCzzsTL9wG/Jc5vzL3z6zh6jYcPO4NfNsuPcOPY gXy9n209j56DkWoa/FM2Rc8HEkmpUzrxrO5fXN/faxyJ/j5z57tQiBUUmsdGzSzoUUn5 PhrWYZvxfYuHMtr9nUGA7aeyK5DxeOzGogDmP3MXdjqgF00aMok1XK2h3nxWRjukFwxK IbKGc69vWHetSys3lTlsFKLWVnkAii1tFp6Qr9o2J2UCjdjdN2LOzVF9qH6SP3SuMS1q HSmRtXEfX9gz9XbDxgC4I1XHzVV8CNGfDdTDKNsVwjelrptHfa6sohhrfyBWN+iIEwiI qELQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Zo+/ixLbc+HMlH9uGOgr+hPixdvr+y8wE9eP4inYnyo=; b=Wy3xPOmvXziBBTxHyAq1LMplf3n2/uUgvBj9F0abDKRhoctVkfJFFwbjwX+4o77V0+ nRPM1Px8low49hJQRJKXaG+bz8Dc8xpAyebI5tSkMBYj9/pHHkMSPW8DcqL8TcPIVEy1 Q6FXbqZlOlG1o7UzdCBPb8mHOyUo2OpTKnOxIqAs6giLYM3k01TxWvADGgAAKiqt7K91 B4765fEAT6zgJh+nR2Z41NAIiml4iPaVQ9nsSkxu7mfDTl+reUsRyu++2cO2F4SRF5pt lmseSnVa1Af6DCuT5CGh4KBjSzjPxqlDpbndjB657rlND7MhEK1NH0uGRWHCa+YShCfa hd3Q== X-Gm-Message-State: AG10YOSA5jS8NftrgQu1KXeedTi7xRTTIWf9ibQ9oF7Ui1Z1r0VDEJoMNNoUSzeDMPMxiw== X-Received: by 10.25.135.198 with SMTP id j189mr3498639lfd.84.1454200777318; Sat, 30 Jan 2016 16:39:37 -0800 (PST) Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id f4sm2918386lbs.10.2016.01.30.16.39.36 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 30 Jan 2016 16:39:36 -0800 (PST) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason To: Juri Linkov References: <86wq0q602w.fsf@yandex.ru> <87oacaiszd.fsf@mail.linkov.net> <56A5BF79.909@yandex.ru> <87zivtqq81.fsf@mail.linkov.net> <56A6B171.7080504@yandex.ru> <87y4bbol9h.fsf@mail.linkov.net> <56A82ECE.6050609@yandex.ru> <87powmd410.fsf@mail.linkov.net> <56A95281.9080205@yandex.ru> <8737th5kt6.fsf@mail.linkov.net> <56AAB3C7.70902@yandex.ru> <871t90c5o8.fsf@mail.linkov.net> <56AC0A95.2030001@yandex.ru> <87si1etyyo.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <56AD57C7.5050809@yandex.ru> Date: Sun, 31 Jan 2016 03:39:35 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: <87si1etyyo.fsf@mail.linkov.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 01/31/2016 02:43 AM, Juri Linkov wrote: > I believe Eli meant this case because it's hard to imagine another one. > So we have to find a solution for this case. Let's not base the rest of the discussion on a guess, shall we? In the message above, he was replying to my message, where I said: "On the other hand, while *xref* is visible, `next-error' will keep working for its results". I can hardly imagine that in his counter-example, *xref* is hidden. > By setting a window-local value of next-error-last-buffer in the > selected window, we can continue the xref-navigation even when > *compilation* is visible in an adjacent window. Yes. But we _only_ continue it from the same window, which I do not believe to be a good goal. On the other hand, if we just use the global next-error-last-buffer value, we'll just as well "continue the xref-navigation even when *compilation* is visivle in an adjacent window". >> But IMHO, (eq (length window-buffers) 1) is counter-intuitive: take the >> configuration with three buffers with next-error-function set visible. Hide >> the current last-buffer: nothing changes, `next-error' continues working as >> it did. Hide the next one: and suddenly, `next-error' starts >> behaving differently. > > When the number of next-error-function windows is more than one, then > there's a dilemma which one to use. Let's use the last one. That would definitely simplify things. On the other hand, if we assign and read next-error-last-buffer value via two accessor functions, anyone would be able to change the locality of that value. You'd be able to use advice, to store it window-locally. >> Your proposal _complicates_ the current state, making it more of >> a problem. If the global value of next-error-last-buffer is used >> consistently, at least the current state is easier to remember. > > But it allows the user to continue a paused navigation in another window > in another frame, thus having several simultaneously active navigations > in different windows. If the "previous" navigation buffer is visible, you can also continue navigation by going to it, and using one of the links there. If it's not visible, it would make remembering which window belongs to which navigation, even more difficult. > What happens when two features set `next-error-function' at the same time? > I guess the latest wins, so there is no problem no matter if using > visibility of next-error-last-buffer or window-local values. Yes, if next-error-function is set locally in a file buffer, we can only see the last value. But rather than "no problem", I'd say that neither approach to visibility of next-error-last-buffer solves the Flycheck problem. >> Since filing this bug, I've somewhat warmed up to using buffer visibility >> as a condition to choose next-error-last-buffer. > > Visibility of next-error-last-buffer is not suitable for navigations > without a navigational buffer. Hence my proposal to equate the value nil of next-error-last-buffer with "use the current buffer". From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 31 17:11:02 2016 Received: (at 20489) by debbugs.gnu.org; 31 Jan 2016 22:11:03 +0000 Received: from localhost ([127.0.0.1]:43519 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aQ0D0-0007rh-NY for submit@debbugs.gnu.org; Sun, 31 Jan 2016 17:11:02 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:50280 helo=homiemail-a17.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aQ0Cz-0007rI-2G for 20489@debbugs.gnu.org; Sun, 31 Jan 2016 17:11:01 -0500 Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id 847572B206A; Sun, 31 Jan 2016 14:10:59 -0800 (PST) Received: from localhost.linkov.net (82.131.112.255.cable.starman.ee [82.131.112.255]) (Authenticated sender: jurta@jurta.org) by homiemail-a17.g.dreamhost.com (Postfix) with ESMTPA id 9ECCF2B206D; Sun, 31 Jan 2016 14:10:58 -0800 (PST) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Organization: LINKOV.NET References: <86wq0q602w.fsf@yandex.ru> <87oacaiszd.fsf@mail.linkov.net> <56A5BF79.909@yandex.ru> <87zivtqq81.fsf@mail.linkov.net> <56A6B171.7080504@yandex.ru> <87y4bbol9h.fsf@mail.linkov.net> <56A82ECE.6050609@yandex.ru> <87powmd410.fsf@mail.linkov.net> <56A95281.9080205@yandex.ru> <8737th5kt6.fsf@mail.linkov.net> <56AAB3C7.70902@yandex.ru> <871t90c5o8.fsf@mail.linkov.net> <56AC0A95.2030001@yandex.ru> <87si1etyyo.fsf@mail.linkov.net> <56AD57C7.5050809@yandex.ru> Date: Sun, 31 Jan 2016 23:57:33 +0200 In-Reply-To: <56AD57C7.5050809@yandex.ru> (Dmitry Gutov's message of "Sun, 31 Jan 2016 03:39:35 +0300") Message-ID: <87egcxpg36.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > In the message above, he was replying to my message, where I said: "On the > other hand, while *xref* is visible, `next-error' will keep working for its > results". Clearly, this describes a successful case as opposed to the problematic one where *xref* is hidden that evidently needs fixing. >> By setting a window-local value of next-error-last-buffer in the >> selected window, we can continue the xref-navigation even when >> *compilation* is visible in an adjacent window. > > Yes. But we _only_ continue it from the same window, which I do not believe > to be a good goal. > > On the other hand, if we just use the global next-error-last-buffer value, > we'll just as well "continue the xref-navigation even when *compilation* is > visible in an adjacent window". And lose the support for the case of simultaneously active navigations in different windows/frames. >>> But IMHO, (eq (length window-buffers) 1) is counter-intuitive: take the >>> configuration with three buffers with next-error-function set visible. Hide >>> the current last-buffer: nothing changes, `next-error' continues working as >>> it did. Hide the next one: and suddenly, `next-error' starts >>> behaving differently. >> >> When the number of next-error-function windows is more than one, then >> there's a dilemma which one to use. > > Let's use the last one. That would definitely simplify things. Indeed, using (get-mru-window 'visible t t) makes sense. > On the other hand, if we assign and read next-error-last-buffer value via > two accessor functions, anyone would be able to change the locality of that > value. You'd be able to use advice, to store it window-locally. Customizable next-error-find-buffer? Maybe, if we'll fail to find a reasonable default. > If the "previous" navigation buffer is visible, you can also continue > navigation by going to it, and using one of the links there. > > If it's not visible, it would make remembering which window belongs to > which navigation, even more difficult. Isn't it so that the user will remember which navigation displayed a given window? >> What happens when two features set `next-error-function' at the same time? >> I guess the latest wins, so there is no problem no matter if using >> visibility of next-error-last-buffer or window-local values. > > Yes, if next-error-function is set locally in a file buffer, we can only > see the last value. > > But rather than "no problem", I'd say that neither approach to visibility > of next-error-last-buffer solves the Flycheck problem. At least, with window-local values the Flycheck navigation in the given buffer will be confined within the selected window and won't affect other navigations in other windows. So continuing a navigation in other buffers/windows won't continue Flychecking of an unrelated buffer. So Flychecking should not set the global value of next-error-last-buffer. >>> Since filing this bug, I've somewhat warmed up to using buffer visibility >>> as a condition to choose next-error-last-buffer. >> >> Visibility of next-error-last-buffer is not suitable for navigations >> without a navigational buffer. > > Hence my proposal to equate the value nil of next-error-last-buffer with > "use the current buffer". What/who and how would nullify/reset next-error-last-buffer? From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 31 17:38:53 2016 Received: (at 20489) by debbugs.gnu.org; 31 Jan 2016 22:38:53 +0000 Received: from localhost ([127.0.0.1]:43578 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aQ0dw-0008W3-QQ for submit@debbugs.gnu.org; Sun, 31 Jan 2016 17:38:53 -0500 Received: from mail-lb0-f169.google.com ([209.85.217.169]:35066) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aQ0dv-0008Vq-4U for 20489@debbugs.gnu.org; Sun, 31 Jan 2016 17:38:51 -0500 Received: by mail-lb0-f169.google.com with SMTP id bc4so65399169lbc.2 for <20489@debbugs.gnu.org>; Sun, 31 Jan 2016 14:38:51 -0800 (PST) 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=D4KfY8fXyrLnRWKx7kik43771rtdweU0BC7Qklszt0c=; b=crKPF5AhBKUUmaRjfwv9+fl0MSAmSTIxJXsBYNPdTjfhqFvsA2kKjmi2Y9IZkxOxga RrLk4/pB/FKCw0sMf4KHNkOaN0B0mUCkx+IbF15zJe2VpDIOclFUXXw0ZIO+zxS0wA9x H389mFVdNixLurmj8l938wHLMeOuglr4NWczaxJtEkKSzsnsGweoQLd/Ui7RO3G0RXdq X3AjXH6afS+qitiUQWaNgtSQwjE4q59WiF6HbotBwGRdT6jpda9N1NQijn917O3HZna5 BCYMZoIUz8witjTQx8EJjxZkfQQpompglbj3ZEDH38W2yW0GSwWHRJEnGZJOvcnhakva hf/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=D4KfY8fXyrLnRWKx7kik43771rtdweU0BC7Qklszt0c=; b=hig1Z4DPsdEOI90AzdGJJzXe3LtyuvcPHzgJ/Y1qVJiklr9zbzyPhloxkGPNwHXGdo BIlX1SfhSyqbO0ZQmGJ+4KiVMcztD5AzVBplkP4MX13EBG4EvqFHFs79VKfY6kMqubQo uCOZQ3Musri/GLkslZIRvVcHOgzpXtUjyF4xrWcN5u/O0myhEXohFgeKZc+RsX2urw3P XEAKncveRLzmCL/w87aDpqWPx9DWIhRGRMqJDr9t3fjWoJm26j/xspzbDKHlgsIRdDhY gWdQSk4hwRdAa++tAbLCBwcTJqLAwoU+dC39UImyAvZxJOSDDPrlvqoAHBQeadVS/ZO4 FKqQ== X-Gm-Message-State: AG10YOSNl5kUAZuUjGjgG8cNmmEx5EeVTK97sNQd2uPzaVJeCF4hFedf/5FSX/HYPqZY6w== X-Received: by 10.112.161.225 with SMTP id xv1mr7186063lbb.127.1454279925380; Sun, 31 Jan 2016 14:38:45 -0800 (PST) Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id l189sm3521600lfd.30.2016.01.31.14.38.43 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 31 Jan 2016 14:38:44 -0800 (PST) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason To: Juri Linkov References: <86wq0q602w.fsf@yandex.ru> <87oacaiszd.fsf@mail.linkov.net> <56A5BF79.909@yandex.ru> <87zivtqq81.fsf@mail.linkov.net> <56A6B171.7080504@yandex.ru> <87y4bbol9h.fsf@mail.linkov.net> <56A82ECE.6050609@yandex.ru> <87powmd410.fsf@mail.linkov.net> <56A95281.9080205@yandex.ru> <8737th5kt6.fsf@mail.linkov.net> <56AAB3C7.70902@yandex.ru> <871t90c5o8.fsf@mail.linkov.net> <56AC0A95.2030001@yandex.ru> <87si1etyyo.fsf@mail.linkov.net> <56AD57C7.5050809@yandex.ru> <87egcxpg36.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <56AE8CF3.9030108@yandex.ru> Date: Mon, 1 Feb 2016 01:38:43 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: <87egcxpg36.fsf@mail.linkov.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 02/01/2016 12:57 AM, Juri Linkov wrote: >> In the message above, he was replying to my message, where I said: "On the >> other hand, while *xref* is visible, `next-error' will keep working for its >> results". > > Clearly, this describes a successful case as opposed to the problematic one > where *xref* is hidden that evidently needs fixing. Yes. This was my appeal to keep the existing integration of xref with next-error-function. Eli disagreed. What can we gather from that? >> On the other hand, if we just use the global next-error-last-buffer value, >> we'll just as well "continue the xref-navigation even when *compilation* is >> visible in an adjacent window". > > And lose the support for the case of simultaneously active navigations > in different windows/frames. Yup. Did you have many requests, from different users, before introducing this support? >>> When the number of next-error-function windows is more than one, then >>> there's a dilemma which one to use. >> >> Let's use the last one. That would definitely simplify things. > > Indeed, using (get-mru-window 'visible t t) makes sense. I don't follow. The window returned by the above won't necessarily have next-error-function set. And, again, this ignores the Flycheck case. >> If the "previous" navigation buffer is visible, you can also continue >> navigation by going to it, and using one of the links there. >> >> If it's not visible, it would make remembering which window belongs to >> which navigation, even more difficult. > > Isn't it so that the user will remember which navigation displayed > a given window? Sorry, _what_ is so? > At least, with window-local values the Flycheck navigation in the given buffer > will be confined within the selected window and won't affect other navigations > in other windows. With your approach, no window will affect other windows. Even if I ran M-x rgrep, and I see its buffer in the current frame, I'll also have to remember which window it ended at. And if I never clicked on a link in the *grep* buffer, I can't use C-x ` in any window, I'm assuming. > So continuing a navigation in other buffers/windows won't > continue Flychecking of an unrelated buffer. So Flychecking should not set > the global value of next-error-last-buffer. Suppose I use flycheck-next-error in foo.el. And I have a *grep* buffer visible, and I jumped to bar.el from it. And the next error in *grep* is in foo.el. What happens when I, having returned to bar.el's window, call next-error again? Does it jump to foo.el's window? Does it display foo.el in the window where bar.el previously was? Does every navigational window get a second, dedicated window for its locations? Often, we don't have many windows to spare. >> Hence my proposal to equate the value nil of next-error-last-buffer with >> "use the current buffer". > > What/who and how would nullify/reset next-error-last-buffer? A new command. Or maybe a special value of the prefix argument to `next-error'? M-0 C-x `, maybe? But if we have a new command, I could also allow selecting from some of the existing buffers which contain "nonlocal" next-error-function's. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 01 20:13:16 2016 Received: (at 20489) by debbugs.gnu.org; 2 Feb 2016 01:13:16 +0000 Received: from localhost ([127.0.0.1]:55454 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aQPWu-0002sc-8q for submit@debbugs.gnu.org; Mon, 01 Feb 2016 20:13:16 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:41057 helo=homiemail-a15.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aQPWt-0002sV-AC for 20489@debbugs.gnu.org; Mon, 01 Feb 2016 20:13:15 -0500 Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 1B57F76C065; Mon, 1 Feb 2016 17:13:13 -0800 (PST) Received: from localhost.linkov.net (85.253.171.19.cable.starman.ee [85.253.171.19]) (Authenticated sender: jurta@jurta.org) by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 520EC76C058; Mon, 1 Feb 2016 17:13:12 -0800 (PST) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Organization: LINKOV.NET References: <86wq0q602w.fsf@yandex.ru> <87oacaiszd.fsf@mail.linkov.net> <56A5BF79.909@yandex.ru> <87zivtqq81.fsf@mail.linkov.net> <56A6B171.7080504@yandex.ru> <87y4bbol9h.fsf@mail.linkov.net> <56A82ECE.6050609@yandex.ru> <87powmd410.fsf@mail.linkov.net> <56A95281.9080205@yandex.ru> <8737th5kt6.fsf@mail.linkov.net> <56AAB3C7.70902@yandex.ru> <871t90c5o8.fsf@mail.linkov.net> <56AC0A95.2030001@yandex.ru> <87si1etyyo.fsf@mail.linkov.net> <56AD57C7.5050809@yandex.ru> <87egcxpg36.fsf@mail.linkov.net> <56AE8CF3.9030108@yandex.ru> Date: Tue, 02 Feb 2016 02:44:42 +0200 In-Reply-To: <56AE8CF3.9030108@yandex.ru> (Dmitry Gutov's message of "Mon, 1 Feb 2016 01:38:43 +0300") Message-ID: <878u33ncr9.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >>> In the message above, he was replying to my message, where I said: "O= n the >>> other hand, while *xref* is visible, `next-error' will keep working f= or its >>> results". >> >> Clearly, this describes a successful case as opposed to the problemati= c one >> where *xref* is hidden that evidently needs fixing. > > Yes. This was my appeal to keep the existing integration of xref with > next-error-function. Eli disagreed. > > What can we gather from that? I could gather only that we need to support this case in next-error before enabling next-error in xref. >>> On the other hand, if we just use the global next-error-last-buffer v= alue, >>> we'll just as well "continue the xref-navigation even when *compilati= on* is >>> visible in an adjacent window". >> >> And lose the support for the case of simultaneously active navigations >> in different windows/frames. > > Yup. Did you have many requests, from different users, before introduci= ng > this support? The primary question is not how many users asked for it many years ago, but how many users are using it now. >>>> When the number of next-error-function windows is more than one, the= n >>>> there's a dilemma which one to use. >>> >>> Let's use the last one. That would definitely simplify things. >> >> Indeed, using (get-mru-window 'visible t t) makes sense. > > I don't follow. The window returned by the above won't necessarily have > next-error-function set. Obviously, get-mru-=E2=80=9Cnext-error=E2=80=9D-window, i.e. a combinatio= n of both. > And, again, this ignores the Flycheck case. Alas, this means we have to trade visibility of next-error-last-buffer for window-local values. >>> If the "previous" navigation buffer is visible, you can also continue >>> navigation by going to it, and using one of the links there. >>> >>> If it's not visible, it would make remembering which window belongs t= o >>> which navigation, even more difficult. >> >> Isn't it so that the user will remember which navigation displayed >> a given window? > > Sorry, _what_ is so? The users hopefully remember which navigation displayed a given window. >> At least, with window-local values the Flycheck navigation in the give= n buffer >> will be confined within the selected window and won't affect other nav= igations >> in other windows. > > With your approach, no window will affect other windows. Even if I ran = M-x > rgrep, and I see its buffer in the current frame, I'll also have to > remember which window it ended at. And if I never clicked on a link in = the > *grep* buffer, I can't use C-x ` in any window, I'm assuming. C-x ` in any window will use the global value, i.e. the last navigation. >> So continuing a navigation in other buffers/windows won't >> continue Flychecking of an unrelated buffer. So Flychecking should no= t set >> the global value of next-error-last-buffer. > > Suppose I use flycheck-next-error in foo.el. And I have a *grep* buffer > visible, and I jumped to bar.el from it. And the next error in *grep* i= s in > foo.el. What happens when I, having returned to bar.el's window, call > next-error again? Does it jump to foo.el's window? Does it display foo.= el > in the window where bar.el previously was? It will display foo.el in the window where bar.el previously was. AFAIS, this is the point of the current discussion on emacs-devel - to fix xref's window management to work like *compilation* and visit navigated windows predictably. > Does every navigational window get a second, dedicated window for its > locations? Often, we don't have many windows to spare. > >>> Hence my proposal to equate the value nil of next-error-last-buffer w= ith >>> "use the current buffer". >> >> What/who and how would nullify/reset next-error-last-buffer? > > A new command. Or maybe a special value of the prefix argument to > `next-error'? M-0 C-x `, maybe? > > But if we have a new command, I could also allow selecting from some of= the > existing buffers which contain "nonlocal" next-error-function's. Why only =E2=80=9Cnonlocal=E2=80=9D? From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 01 20:40:30 2016 Received: (at 20489) by debbugs.gnu.org; 2 Feb 2016 01:40:30 +0000 Received: from localhost ([127.0.0.1]:55489 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aQPxF-0003an-Sc for submit@debbugs.gnu.org; Mon, 01 Feb 2016 20:40:30 -0500 Received: from mail-lf0-f45.google.com ([209.85.215.45]:33519) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aQPxD-0003aa-Ol for 20489@debbugs.gnu.org; Mon, 01 Feb 2016 20:40:28 -0500 Received: by mail-lf0-f45.google.com with SMTP id m1so33742512lfg.0 for <20489@debbugs.gnu.org>; Mon, 01 Feb 2016 17:40:27 -0800 (PST) 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=BEjwskikvbFHcTlSujsRBaug1vRiLfgL9jOWkehwET0=; b=wjGv4TX/7juHXbK/kio7pr4eY2lYTrjfhrPcXzEB4gsRxEQN4fSa6hCh2dgpjngWzi fpplF5ZRbeSq4d2jRWHmdgEMWHO32JeA+6dc4Hlu/tgbmaxPsL6PJ8iP5xyj2zlsHr7V an55iHZSfSh1J+mvVXjicIdcQE/sQkoUZaFinSHBpgYLGvfLOBn49NFoH4hz564bod6j 8i0Satasp0XIS9j6LS/Rym8lwYNTYk47ExN4HhceoiDVIA5zjcLWcDU04z0O3rHM6u70 ZFaPffr31qoZmoymGZ7bwtS5u1g+KAkeQPcUjwQz8aDG35ebzNsK45+ExejLa6XSXyw8 Qhmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=BEjwskikvbFHcTlSujsRBaug1vRiLfgL9jOWkehwET0=; b=Vy1VTYoCC9vYUlzTY4igVg3RqOfdWFmu/SoisLt6+kclRCF1MUiVLCoBh0XX2JOFI9 TEpNMRxVHE1XSXAKUEZ3cyAqENd6PVzP+pQohoMQMDzHeOvJ+5aNCDe25bMMM4zopeiT edbZkoKhEOQXrKmKRgeFhHH59+JQZdpFZhEusVoQJoOLVwrgR1io4oMkZNlJSNcazhHM eZdGaAbM+adJbIgoJyMZlfFCDPTg3cbkkRSvxRe5kHBw1recFU1kIyR4xBxdwMDU+rGc ebexB1Qwl+2ZjxUub62xgWFgV8pkN+1zu9vbME38ohYku/TkASL2qLivew0/xiDhlj5F uHBQ== X-Gm-Message-State: AG10YOTQW1SNCUXe9GEj7w3gEq7gRNvsV8fss7HykfVHaxOH0x/8mZ2Ht7+2XypC3z17Yw== X-Received: by 10.25.15.24 with SMTP id e24mr7419992lfi.159.1454377221688; Mon, 01 Feb 2016 17:40:21 -0800 (PST) Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id s75sm1385716lfd.38.2016.02.01.17.40.20 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Feb 2016 17:40:20 -0800 (PST) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason To: Juri Linkov References: <86wq0q602w.fsf@yandex.ru> <87oacaiszd.fsf@mail.linkov.net> <56A5BF79.909@yandex.ru> <87zivtqq81.fsf@mail.linkov.net> <56A6B171.7080504@yandex.ru> <87y4bbol9h.fsf@mail.linkov.net> <56A82ECE.6050609@yandex.ru> <87powmd410.fsf@mail.linkov.net> <56A95281.9080205@yandex.ru> <8737th5kt6.fsf@mail.linkov.net> <56AAB3C7.70902@yandex.ru> <871t90c5o8.fsf@mail.linkov.net> <56AC0A95.2030001@yandex.ru> <87si1etyyo.fsf@mail.linkov.net> <56AD57C7.5050809@yandex.ru> <87egcxpg36.fsf@mail.linkov.net> <56AE8CF3.9030108@yandex.ru> <878u33ncr9.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <56B00903.7050706@yandex.ru> Date: Tue, 2 Feb 2016 04:40:19 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: <878u33ncr9.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 02/02/2016 03:44 AM, Juri Linkov wrote: >> Yes. This was my appeal to keep the existing integration of xref with >> next-error-function. Eli disagreed. >> >> What can we gather from that? > > I could gather only that we need to support this case in next-error > before enabling next-error in xref. So I stated the same as you, Eli disagreed, and we're going to conclude that you are right? Good job. > The primary question is not how many users asked for it many years ago, > but how many users are using it now. You're welcome to poll, but so far we only have the data about a single user. > Obviously, get-mru-“next-error”-window, i.e. a combination of both. I have no idea what that means, really. Are we going to store a reference to a window instead of a reference to a buffer? And then take the reference to the buffer from that window? Seem like lots of complexity for nothing. >> And, again, this ignores the Flycheck case. > > Alas, this means we have to trade visibility of next-error-last-buffer > for window-local values. What means? And why? >>> Isn't it so that the user will remember which navigation displayed >>> a given window? >> >> Sorry, _what_ is so? > > The users hopefully remember which navigation displayed a given window. Did your previous sentence make sense? Did you actually mean "Won't users remember..."? And to answer the question, I don't think so. At least, not every time. It seems kind of pointless to answer an observation about added complexity with "won't users remember everything?", don't you think? >> With your approach, no window will affect other windows. Even if I ran M-x >> rgrep, and I see its buffer in the current frame, I'll also have to >> remember which window it ended at. And if I never clicked on a link in the >> *grep* buffer, I can't use C-x ` in any window, I'm assuming. > > C-x ` in any window will use the global value, i.e. the last navigation. So, not only we'll have local values, we'll also have a global one? Upon invoking that command, will focus immediately jump to the one window associated with the navigation buffer? >>> So continuing a navigation in other buffers/windows won't >>> continue Flychecking of an unrelated buffer. So Flychecking should not set >>> the global value of next-error-last-buffer. >> >> Suppose I use flycheck-next-error in foo.el. And I have a *grep* buffer >> visible, and I jumped to bar.el from it. And the next error in *grep* is in >> foo.el. What happens when I, having returned to bar.el's window, call >> next-error again? Does it jump to foo.el's window? Does it display foo.el >> in the window where bar.el previously was? > > It will display foo.el in the window where bar.el previously was. Aren't you at all worried about running out of windows (and not being allowed to split them)? In our last discussion with Martin, he expressed concern that some users use one window per frame. In this scenario, you'll need at least 3. And with two navigational buffers visible, the number of necessary windows will grow to 5. > AFAIS, this is the point of the current discussion on emacs-devel - > to fix xref's window management to work like *compilation* and visit > navigated windows predictably. *compilation* isn't afraid to use different windows when it's convenient. It definitely reuses another window if the buffer it's going to jump to is already displayed. >> But if we have a new command, I could also allow selecting from some of the >> existing buffers which contain "nonlocal" next-error-function's. > > Why only “nonlocal”? Because otherwise there'll be too many options too choose from. To use a different buffer, the user can switch to it first anyway. Nonlocal next-error-functions represent groups of windows that are somehow related (parts of the same problem, matches for the same input, or so on). And with them, we can at least expect that the next error still might be in the current buffer. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 02 20:03:56 2016 Received: (at 20489) by debbugs.gnu.org; 3 Feb 2016 01:03:56 +0000 Received: from localhost ([127.0.0.1]:57275 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aQlrP-0002El-VV for submit@debbugs.gnu.org; Tue, 02 Feb 2016 20:03:56 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:51334 helo=homiemail-a18.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aQlrO-0002Ea-1N for 20489@debbugs.gnu.org; Tue, 02 Feb 2016 20:03:54 -0500 Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id AC51F25006C; Tue, 2 Feb 2016 17:03:52 -0800 (PST) Received: from localhost.linkov.net (85.253.204.130.cable.starman.ee [85.253.204.130]) (Authenticated sender: jurta@jurta.org) by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPA id D7C7C25006B; Tue, 2 Feb 2016 17:03:51 -0800 (PST) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Organization: LINKOV.NET References: <86wq0q602w.fsf@yandex.ru> <87oacaiszd.fsf@mail.linkov.net> <56A5BF79.909@yandex.ru> <87zivtqq81.fsf@mail.linkov.net> <56A6B171.7080504@yandex.ru> <87y4bbol9h.fsf@mail.linkov.net> <56A82ECE.6050609@yandex.ru> <87powmd410.fsf@mail.linkov.net> <56A95281.9080205@yandex.ru> <8737th5kt6.fsf@mail.linkov.net> <56AAB3C7.70902@yandex.ru> <871t90c5o8.fsf@mail.linkov.net> <56AC0A95.2030001@yandex.ru> <87si1etyyo.fsf@mail.linkov.net> <56AD57C7.5050809@yandex.ru> <87egcxpg36.fsf@mail.linkov.net> <56AE8CF3.9030108@yandex.ru> <878u33ncr9.fsf@mail.linkov.net> <56B00903.7050706@yandex.ru> Date: Wed, 03 Feb 2016 02:35:43 +0200 In-Reply-To: <56B00903.7050706@yandex.ru> (Dmitry Gutov's message of "Tue, 2 Feb 2016 04:40:19 +0300") Message-ID: <87d1se62co.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> The primary question is not how many users asked for it many years ago= , >> but how many users are using it now. > > You're welcome to poll, but so far we only have the data about > a single user. Yes, a single user who wants to remove it ;) >> Obviously, get-mru-=E2=80=9Cnext-error=E2=80=9D-window, i.e. a combina= tion of both. > > I have no idea what that means, really. Are we going to store a referen= ce > to a window instead of a reference to a buffer? And then take the refer= ence > to the buffer from that window? Just traverse all windows in the order of recency until finding a window with next-error-function. >>> And, again, this ignores the Flycheck case. >> >> Alas, this means we have to trade visibility of next-error-last-buffer >> for window-local values. > > What means? And why? In case of Flycheck it's next-error-last-buffer is the current buffer and is always visible. >>> With your approach, no window will affect other windows. Even if I ra= n M-x >>> rgrep, and I see its buffer in the current frame, I'll also have to >>> remember which window it ended at. And if I never clicked on a link i= n the >>> *grep* buffer, I can't use C-x ` in any window, I'm assuming. >> >> C-x ` in any window will use the global value, i.e. the last navigatio= n. > > So, not only we'll have local values, we'll also have a global one? When there is no local values, then indeed use a global one. > Upon invoking that command, will focus immediately jump to the one wind= ow > associated with the navigation buffer? Naturally. >>> Suppose I use flycheck-next-error in foo.el. And I have a *grep* buff= er >>> visible, and I jumped to bar.el from it. And the next error in *grep*= is in >>> foo.el. What happens when I, having returned to bar.el's window, call >>> next-error again? Does it jump to foo.el's window? Does it display fo= o.el >>> in the window where bar.el previously was? >> >> It will display foo.el in the window where bar.el previously was. > > Aren't you at all worried about running out of windows (and not being > allowed to split them)? In our last discussion with Martin, he expresse= d > concern that some users use one window per frame. In this scenario, you= 'll > need at least 3. And with two navigational buffers visible, the number = of > necessary windows will grow to 5. I meant reusing an existing window with a file buffer, not creating a new window. I see no reason not to use this behavior by default. >> AFAIS, this is the point of the current discussion on emacs-devel - >> to fix xref's window management to work like *compilation* and visit >> navigated windows predictably. > > *compilation* isn't afraid to use different windows when it's > convenient. It definitely reuses another window if the buffer it's goin= g to > jump to is already displayed. What I see is that *compilation* always reuses another window to not repl= ace the navigational *compilation* buffer with a file buffer. Do you know under what circumstances this behavior might fail. >>> But if we have a new command, I could also allow selecting from some = of the >>> existing buffers which contain "nonlocal" next-error-function's. >> >> Why only =E2=80=9Cnonlocal=E2=80=9D? > > Because otherwise there'll be too many options too choose from. To use > a different buffer, the user can switch to it first anyway. > > Nonlocal next-error-functions represent groups of windows that are some= how > related (parts of the same problem, matches for the same input, or so > on). And with them, we can at least expect that the next error still mi= ght > be in the current buffer. This is why I proposed window-local variables to bind a group of windows to their parent navigational window. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 03 20:00:19 2016 Received: (at 20489) by debbugs.gnu.org; 4 Feb 2016 01:00:19 +0000 Received: from localhost ([127.0.0.1]:58536 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aR8HT-0005Yw-8k for submit@debbugs.gnu.org; Wed, 03 Feb 2016 20:00:19 -0500 Received: from mail-lf0-f46.google.com ([209.85.215.46]:35216) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aR8HR-0005Yf-QB for 20489@debbugs.gnu.org; Wed, 03 Feb 2016 20:00:18 -0500 Received: by mail-lf0-f46.google.com with SMTP id l143so26021516lfe.2 for <20489@debbugs.gnu.org>; Wed, 03 Feb 2016 17:00:17 -0800 (PST) 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=9r5JRvm9anOP64LqDbzwL6A48ePoSP69V0FmM5EjEwU=; b=eN28ag5leasFAMsB3Tvs0w17KmAS55y52YDDcVbcPaSRwoZQw9MRNXmfeltGqpLB11 g84ktv7Qxk4tlZxFODpmzMZkDrGu1NODceiwbtF8PDAHSqM8c+7ySfUeERe6CfnmRBEq vKNwjhjPOKx5gfJlc9Y1CDGKjvFvxJJsjCKRFB2elVHlIhrlFo61i8F2rxReE8o1knxl j7jK4e6ZvxsF8a9yGg8HoJJLG3O9rHvl3C6G1bejFvlJtMAt8CIuFCrr/Q8j12t0Hl1T rPt4+KTvCgv1AgGUBg0K1XFoKas3m7JD+U3e4rij0BdowNzjc0y/zxddditq5aDmyTkp JkPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=9r5JRvm9anOP64LqDbzwL6A48ePoSP69V0FmM5EjEwU=; b=TQBjoVmGK8z6c6AEGMVnTwISmt99JM9bienzvAhfKsW26AMDOuXGgIkml+X3gYPLwq oe2XyfwEE4r77Ura6VrJl7hF+5aJPjmt7p+tw9HDMocbga+FI+x4l0ekXbag6xg7VKSc GGU2JjG7dP0j3YOFHgQltgyP/i2m7j7/A68DfmQV4GLbiW3oA6G6jr3DeztQOYqiEtE5 EaeWSRAwTPT6pkO25kUUhLKNfAf3OsftdLrJ8uu7SR9IOEPjAjUUytRnsDdPIFQ5Xxfe Pj5T3tJhrjqtvju5DUU8718QQKo9MxO7/re1TtJt5Otjelb/2dP+Ng7WH6/RfS5LPGMZ BxAQ== X-Gm-Message-State: AG10YORZ+ZsIwRNXbCVSQIp5jnv0olrPJWSq8wtF74VYc+2ydsMCzcGZMm+Q8xKoJ4kOHA== X-Received: by 10.25.20.165 with SMTP id 37mr2174893lfu.53.1454547611711; Wed, 03 Feb 2016 17:00:11 -0800 (PST) Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id rd3sm1168842lbb.2.2016.02.03.17.00.10 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 03 Feb 2016 17:00:10 -0800 (PST) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason To: Juri Linkov References: <86wq0q602w.fsf@yandex.ru> <87oacaiszd.fsf@mail.linkov.net> <56A5BF79.909@yandex.ru> <87zivtqq81.fsf@mail.linkov.net> <56A6B171.7080504@yandex.ru> <87y4bbol9h.fsf@mail.linkov.net> <56A82ECE.6050609@yandex.ru> <87powmd410.fsf@mail.linkov.net> <56A95281.9080205@yandex.ru> <8737th5kt6.fsf@mail.linkov.net> <56AAB3C7.70902@yandex.ru> <871t90c5o8.fsf@mail.linkov.net> <56AC0A95.2030001@yandex.ru> <87si1etyyo.fsf@mail.linkov.net> <56AD57C7.5050809@yandex.ru> <87egcxpg36.fsf@mail.linkov.net> <56AE8CF3.9030108@yandex.ru> <878u33ncr9.fsf@mail.linkov.net> <56B00903.7050706@yandex.ru> <87d1se62co.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <56B2A29A.3060407@yandex.ru> Date: Thu, 4 Feb 2016 04:00:10 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: <87d1se62co.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 02/03/2016 03:35 AM, Juri Linkov wrote: >> You're welcome to poll, but so far we only have the data about >> a single user. > > Yes, a single user who wants to remove it ;) Apparently, you have no data at all, then. As a user, I don't care about it either way. As a _developer_, I might remove it. Which is what should be done if a feature can't be implemented in a sane way without trampling on user experience in other aspects. > Just traverse all windows in the order of recency until finding a window > with next-error-function. This will almost always default to the current window if you write Elisp, and have global-flycheck-mode enabled. Can't you give a full, constructive proposal, instead of giving pieces that are easy to poke holes in? >>>> And, again, this ignores the Flycheck case. >>> >>> Alas, this means we have to trade visibility of next-error-last-buffer >>> for window-local values. >> >> What means? And why? > > In case of Flycheck it's next-error-last-buffer is the current buffer > and is always visible. You haven't answered the "what" question. But assuming I managed to guess your meaning... How come window-local values are any better? If "next-error-last-buffer is the current buffer" is the current buffer when the variable is stored globally, it will be the window-local value when the variable is stored window-locally. Unless the buffer is not visible, in which case the question is moot. >>>> Suppose I use flycheck-next-error in foo.el. And I have a *grep* buffer >>>> visible, and I jumped to bar.el from it. And the next error in *grep* is in >>>> foo.el. What happens when I, having returned to bar.el's window, call >>>> next-error again? Does it jump to foo.el's window? Does it display foo.el >>>> in the window where bar.el previously was? >>> >>> It will display foo.el in the window where bar.el previously was. >> >> Aren't you at all worried about running out of windows (and not being >> allowed to split them)? In our last discussion with Martin, he expressed >> concern that some users use one window per frame. In this scenario, you'll >> need at least 3. And with two navigational buffers visible, the number of >> necessary windows will grow to 5. > > I meant reusing an existing window with a file buffer, not creating a new > window. Then you are contradicting yourself. > I see no reason not to use this behavior by default. It undermines your proposal: either you have a separate dedicated window for each navigational buffer to show locations in, or the navigational buffers trample on each other's windows when they visit the same files. Which creates the same problem you had, except in certain specific circumstances. But those circumstances are not *that* rare. This will make the behavior less consistent and increase user confusion. > What I see is that *compilation* always reuses another window to not replace > the navigational *compilation* buffer with a file buffer. Do you know > under what circumstances this behavior might fail. *compilation* jumps to foo.el, then *grep* jumps to foo.el. Both use the same window (the default behavior), and both have an arrow in their buffers indicating that foo.el's window is "theirs". However, the last navigational buffer wins. >> Nonlocal next-error-functions represent groups of windows that are somehow >> related (parts of the same problem, matches for the same input, or so >> on). And with them, we can at least expect that the next error still might >> be in the current buffer. > > This is why I proposed window-local variables to bind a group of windows > to their parent navigational window. I don't see how that solves anything. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 21 19:01:31 2016 Received: (at 20489) by debbugs.gnu.org; 22 Feb 2016 00:01:31 +0000 Received: from localhost ([127.0.0.1]:36706 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aXdwR-0001X0-7V for submit@debbugs.gnu.org; Sun, 21 Feb 2016 19:01:31 -0500 Received: from mail-wm0-f52.google.com ([74.125.82.52]:36713) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aXdwP-0001Wo-Td for 20489@debbugs.gnu.org; Sun, 21 Feb 2016 19:01:30 -0500 Received: by mail-wm0-f52.google.com with SMTP id g62so149130818wme.1 for <20489@debbugs.gnu.org>; Sun, 21 Feb 2016 16:01:29 -0800 (PST) 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=0vh3HWEdHO0jKOD7YMAGmk6TlsxXnw+WUYzNoh4W3uk=; b=Tk/QldhBHsd/BxjEwU7wnEbgLTIZaEv1MfiPiyyZihxZubdkw2CXhkpt9VkZy6Qe3l GT85JB3vu7aKUuexmW5/uezYcsuV6Ma8rerlvSXpfzkez6aGiQEo4kaolytaVlXXalDS 048cSGllJlVJZ7T/En2hAcxlese7xe8hxJUJmr2vRHzu7TwxAcWOSHfMMJifhSf3sPGP Sp2gSTueCImJvrtXdtSrSVs3L8Is3ubS4TH7Lf2p9lcIVPm0qrWsrODFSE42wTMsZjsp 1ClHLGMVn3zYn/bFtnjMkhJE0YyBFp5y/6/7ubqqIRGHyO5GB3/h4IzjLJDQXehhcCeq Tjmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=0vh3HWEdHO0jKOD7YMAGmk6TlsxXnw+WUYzNoh4W3uk=; b=hfvPXEwCwUfS6XYdjJyN3A8P0GsERVhunw8oeFkLF8G8jFmMmbnC6k9SVIgrleKuXl Fm4G90I5zf/B6aC1WDD5MM/PU2f120/OhC3l6rHG7noLM1I8saicDsa0P5hkz2kyjjOj fjEZazZ87g2qn8iEj5W9Qb0U5CMVZz1wdXasaE8bHsBu6WrP7ijenJVacL9l0jRk14TU mNgyITepBsDbhAk9VWXBNKmeNdFxK0EPkahExbdo4wVli9faC06JlloVplXv9Pcq7SI3 syjRWhfF4YMGjnzUVuwDODhIC3FA8ajOWjhN28j5tluhGQGsDBrLkehcGNJiY8lmMywn 5Ptw== X-Gm-Message-State: AG10YOQ7UN/FxInRLUBA1MP33KzZIwaB7JUeCtKoxSdWX7r3Zy2XRgjpTO30HV9fImpdfg== X-Received: by 10.28.54.22 with SMTP id d22mr8704351wma.72.1456099284396; Sun, 21 Feb 2016 16:01:24 -0800 (PST) Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id k4sm18573600wmc.12.2016.02.21.16.01.22 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 21 Feb 2016 16:01:23 -0800 (PST) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason To: 20489@debbugs.gnu.org References: <86wq0q602w.fsf@yandex.ru> From: Dmitry Gutov Message-ID: <56CA4FD1.3060609@yandex.ru> Date: Mon, 22 Feb 2016 02:01:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: <86wq0q602w.fsf@yandex.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20489 Cc: Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Hi Eli, Now that the xref window is more "persistent", could you try uncommenting the relevant lines in xref--xref-buffer-mode, and see if the situation has improved here? Or if it hasn't, please describe your main complaint from http://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01286.html in more detail: what happens "when you have both of them"? From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 22 12:22:19 2016 Received: (at 20489) by debbugs.gnu.org; 22 Feb 2016 17:22:19 +0000 Received: from localhost ([127.0.0.1]:38301 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aXuBe-0007sB-VH for submit@debbugs.gnu.org; Mon, 22 Feb 2016 12:22:19 -0500 Received: from eggs.gnu.org ([208.118.235.92]:60813) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aXuBd-0007ry-Pt for 20489@debbugs.gnu.org; Mon, 22 Feb 2016 12:22:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aXuBV-0003Oh-G3 for 20489@debbugs.gnu.org; Mon, 22 Feb 2016 12:22:12 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40651) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXuBV-0003Od-DF; Mon, 22 Feb 2016 12:22:09 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1317 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aXuBU-0006kN-Oz; Mon, 22 Feb 2016 12:22:09 -0500 Date: Mon, 22 Feb 2016 19:22:00 +0200 Message-Id: <83egc4lkxz.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-reply-to: <56CA4FD1.3060609@yandex.ru> (message from Dmitry Gutov on Mon, 22 Feb 2016 02:01:21 +0200) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason References: <86wq0q602w.fsf@yandex.ru> <56CA4FD1.3060609@yandex.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Cc: Eli Zaretskii > From: Dmitry Gutov > Date: Mon, 22 Feb 2016 02:01:21 +0200 > > Now that the xref window is more "persistent", could you try > uncommenting the relevant lines in xref--xref-buffer-mode, and see if > the situation has improved here? Will do. To make this more efficient, can you suggest what situations to try? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 22 12:30:32 2016 Received: (at 20489) by debbugs.gnu.org; 22 Feb 2016 17:30:32 +0000 Received: from localhost ([127.0.0.1]:38310 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aXuJc-000855-0O for submit@debbugs.gnu.org; Mon, 22 Feb 2016 12:30:32 -0500 Received: from mail-wm0-f47.google.com ([74.125.82.47]:35849) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aXuJa-00084r-34 for 20489@debbugs.gnu.org; Mon, 22 Feb 2016 12:30:30 -0500 Received: by mail-wm0-f47.google.com with SMTP id g62so184437474wme.1 for <20489@debbugs.gnu.org>; Mon, 22 Feb 2016 09:30:30 -0800 (PST) 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-transfer-encoding; bh=SqBW81fVp3uTPY+ZPZIgfXhV7xfynSk7pm5mB/vhoH8=; b=BodVa4l0LF3Nzl438MYW4hWm+YOvZyKtJYpdcJ4t71J+0CUgI0hIRv3JEQuD/xMK2a fR4nlzxUp+xx+xSYinO1ZmdcH5X44fuFbFECujciUANQv5YV92er0aFOXpEcx9GF+KWY 4xis6hpFKa8EMA6zh449lOf0Fsb/bGBw8IrPJ5DwZSrdNlka0Q268emuC7WC4VRQa3rU hdqRVCIhG2a2NsW9X6IoYFqnKvfdTin+/unPjkfYJw7lwjqSw7LqGwO3cytorpyzXwqz ir0w7I7b74tGFNTomC6tYBE2CR1MDOdCsjmCETrWPNCZIImOoX9Hf4gETHfa3BVJ2iAW ZwTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=SqBW81fVp3uTPY+ZPZIgfXhV7xfynSk7pm5mB/vhoH8=; b=nBmCYvLHJsiMlmKe+6xpPDmq2nxwyR/aYx5hs8H8xA5ssrcCmMmI+SdRQB/SgFNO+z xhq//PtQlSqLd6KAxqHA2hSOwhEZlMnOr27Y5orcn+5LW7C7OG56ubPFJJRHBIpO0KkZ Eg/qlZ59mWNtigoLT63OO5PYxQSN6X06nZVGyO6VA9f3/2pLWsfRHqBuR5pIbNBnoXl1 3MZttIcMbs97YVp4waWG+b91vECw4ST6/z6rE82hwzZi5zyRv58QqRLTrNL2vgBtaVzJ qIDDk5y7ZXehdK8DIB6gSGG45TDjzYJ9VIzkmHYdixhXYADBwIpo7rtjPsWaGpoXLZRv CACA== X-Gm-Message-State: AG10YORJIoYZQSK00hsNdaGwEIF+9FdENKc50pIbz6qbSR3a80TwEJzGJDSRWPH3KGGe8g== X-Received: by 10.28.175.139 with SMTP id y133mr12825619wme.45.1456162224286; Mon, 22 Feb 2016 09:30:24 -0800 (PST) Received: from [192.168.0.185] ([212.50.99.193]) by smtp.googlemail.com with ESMTPSA id l7sm25726003wjx.14.2016.02.22.09.30.22 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Feb 2016 09:30:22 -0800 (PST) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason To: Eli Zaretskii References: <86wq0q602w.fsf@yandex.ru> <56CA4FD1.3060609@yandex.ru> <83egc4lkxz.fsf@gnu.org> From: Dmitry Gutov Message-ID: <56CB45AD.9010402@yandex.ru> Date: Mon, 22 Feb 2016 19:30:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: <83egc4lkxz.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 02/22/2016 07:22 PM, Eli Zaretskii wrote: > Will do. To make this more efficient, can you suggest what situations > to try? That's what I'm really asking: which scenario did you find most broken before, and does it work better now? From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 22 12:39:34 2016 Received: (at 20489) by debbugs.gnu.org; 22 Feb 2016 17:39:34 +0000 Received: from localhost ([127.0.0.1]:38346 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aXuSM-0008KO-27 for submit@debbugs.gnu.org; Mon, 22 Feb 2016 12:39:34 -0500 Received: from eggs.gnu.org ([208.118.235.92]:38273) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aXuSK-0008K5-BY for 20489@debbugs.gnu.org; Mon, 22 Feb 2016 12:39:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aXuSB-000829-Ao for 20489@debbugs.gnu.org; Mon, 22 Feb 2016 12:39:27 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40982) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXuSB-000820-6Q; Mon, 22 Feb 2016 12:39:23 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1375 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aXuSA-0005rc-9Z; Mon, 22 Feb 2016 12:39:22 -0500 Date: Mon, 22 Feb 2016 19:39:13 +0200 Message-Id: <837fhwlk5a.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-reply-to: <56CB45AD.9010402@yandex.ru> (message from Dmitry Gutov on Mon, 22 Feb 2016 19:30:21 +0200) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason References: <86wq0q602w.fsf@yandex.ru> <56CA4FD1.3060609@yandex.ru> <83egc4lkxz.fsf@gnu.org> <56CB45AD.9010402@yandex.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Cc: 20489@debbugs.gnu.org > From: Dmitry Gutov > Date: Mon, 22 Feb 2016 19:30:21 +0200 > > On 02/22/2016 07:22 PM, Eli Zaretskii wrote: > > > Will do. To make this more efficient, can you suggest what situations > > to try? > > That's what I'm really asking: which scenario did you find most broken > before, and does it work better now? OK, I will dig into my failing memory and try to remember that. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 22 13:09:26 2016 Received: (at 20489) by debbugs.gnu.org; 22 Feb 2016 18:09:26 +0000 Received: from localhost ([127.0.0.1]:38378 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aXuvG-0000fo-7u for submit@debbugs.gnu.org; Mon, 22 Feb 2016 13:09:26 -0500 Received: from mail-wm0-f45.google.com ([74.125.82.45]:37547) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aXuvF-0000fQ-2F for 20489@debbugs.gnu.org; Mon, 22 Feb 2016 13:09:25 -0500 Received: by mail-wm0-f45.google.com with SMTP id g62so175968286wme.0 for <20489@debbugs.gnu.org>; Mon, 22 Feb 2016 10:09:25 -0800 (PST) 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=TipnffhpdDm2GHOj5IlH9aRe0RKos/dV4x3zFrUnVIQ=; b=tkZY+GyRVfjeEv81r3KURa23cnEwD5aO5SqHLCGmrWLo7ozilk31eH0Y9iBGEJj/K2 o6SCg3Jldf+J9otIiUPrC4RYaX3Jkuhgt6/DJi6Mw4PRa4d/8zl5xmioMEdg6oP1WN5k g03Dm1kTJv+Nr+Cq9qRQokkNdCXqAGhdeOfKytYqCuP6dWPekIsT8WgUw3Mgr3Qyrv0H 3dQzc8DjK428jNYnzZk6pfvVRevVfadIlIUBhU2/8dNADD+WJ75lDTBdX62sPHCK2fwC Hwsk2wmzgEjjBBVDFClUSZQaTYREBztG0M+pTFGLhKrmrK+0Q8JhxcJQDBTAhWhfphCd wPdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=TipnffhpdDm2GHOj5IlH9aRe0RKos/dV4x3zFrUnVIQ=; b=d/oE6bSzbQkTbxGByKaT32pDA09W8jF4OTghuEaVqDv5878+tgiaRCDTFM56wPjeDn u837VxSNaSxRJLxIa56QrMbLTFUFn91qYpqZB1npSmD9NzJsDxqZ9JzoDaK0HEk+eS6X g+YAVgGQmdyfeUWMtqzbiB5Zc5gEje5NChe58nbhl2BQoXnOVlfTyxjrDe8rbxbmk2F6 mfTnLzaFBnmFeiJrq9Y63fytnpOg8P1k/MoXFUR++UQEUhDsf4cMBauL2Ufzi5uYmlGc dluMqgpiR+stjhVuJQI7mzjhWmGfrOB7l1ihSrXMsKODPZJbuGCQPgU11HsdchHTpz8W dN+Q== X-Gm-Message-State: AG10YORwumUQWZsP6Xe/tufVndSgjPpd+YVssIhsIc/XrhFDYfcReGVPpLoupRBJu+yqlA== X-Received: by 10.28.21.14 with SMTP id 14mr13338071wmv.39.1456164559575; Mon, 22 Feb 2016 10:09:19 -0800 (PST) Received: from [192.168.0.185] ([212.50.99.193]) by smtp.googlemail.com with ESMTPSA id di1sm25736002wjc.3.2016.02.22.10.09.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Feb 2016 10:09:18 -0800 (PST) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason To: Eli Zaretskii References: <86wq0q602w.fsf@yandex.ru> <56CA4FD1.3060609@yandex.ru> <83egc4lkxz.fsf@gnu.org> <56CB45AD.9010402@yandex.ru> <837fhwlk5a.fsf@gnu.org> From: Dmitry Gutov Message-ID: <56CB4ECC.9040301@yandex.ru> Date: Mon, 22 Feb 2016 20:09:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: <837fhwlk5a.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 02/22/2016 07:39 PM, Eli Zaretskii wrote: > OK, I will dig into my failing memory and try to remember that. (Or you could just try using it and maybe encountering the same problem again.) Thanks. It's not urgent, but it seems to be the best way to process in this issue. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 22 13:12:06 2016 Received: (at 20489) by debbugs.gnu.org; 22 Feb 2016 18:12:06 +0000 Received: from localhost ([127.0.0.1]:38383 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aXuxq-0000k4-Kl for submit@debbugs.gnu.org; Mon, 22 Feb 2016 13:12:06 -0500 Received: from mail-wm0-f52.google.com ([74.125.82.52]:36585) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aXuxp-0000ja-6S for 20489@debbugs.gnu.org; Mon, 22 Feb 2016 13:12:05 -0500 Received: by mail-wm0-f52.google.com with SMTP id g62so186263970wme.1 for <20489@debbugs.gnu.org>; Mon, 22 Feb 2016 10:12:05 -0800 (PST) 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=qiAhQhO/UZ+HWmE7/zcogxbY+uKFysmfRMxVxBZGmbw=; b=mHbvhVKMmgWK2O/Qd/ZUrfSAhmoxUf76fc+BoVL71Tx1uaUO4aa5KnmAeif712eo8j ThEoJlNfXVysoh6/vJONZZcl9t6gUE1tx0z8YjrnjEgdUh9KtiYkFXjYbCRQROqf6Xtt lVhQ5mmV0wHTM/ILaxtRZDB+gbMVUC3Z7dQ+8SAW4GimpCKRRRSstbq4XoJ0o5VjZ5nH H8xQiMDS1kvVNqY0+uZq7+3HRlKGpLT/BIlD3oshvFsWbHyt+S2ppPUeXgX0Jauszu5+ yXvbw6nZVgXhkFuaCUMvff67DuzzJKfvJmFwCltEMjgFFdQcK2W2ywbqkF/L2Q/Q+z8P YCcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=qiAhQhO/UZ+HWmE7/zcogxbY+uKFysmfRMxVxBZGmbw=; b=hmri+0P5QrpQCdBZdB/JhcJ82IV/mbcGlkl9PngCPq0sLGmoShMEfN4yNpSKbDxvS6 ivIPNi9c3hzE6srGvq/ac1qa8XrKTQYjyQtuTFRl6WUkX6xrdyiqUKA6j1eS1jRE7pT3 4extrMY/9u4HkYl15zLuFnKi+tO9Mg1QOMjGX5D03B0sfOSFWJn8qU8a0GYy5BEEJG/u m0I3RyGGKGvKLKADMBGsPJ2V0N7TbkUXIJxRn+m7us75qlrKjXB+sxXsIhSOhNx3xI1T Qne0fvrHcjZZ1I1i1r0SwBYW2D4TOzYyBaOLYel79ankiffRBBNC4W31WVSzNx5piX++ OGEA== X-Gm-Message-State: AG10YOQpFFSrPl34ThWDVIt3O07LRG1CXfNoMt6sR7j8RE/S5uugRSB4b8/ep2tAkvHL1A== X-Received: by 10.28.224.87 with SMTP id x84mr14582271wmg.32.1456164719789; Mon, 22 Feb 2016 10:11:59 -0800 (PST) Received: from [192.168.0.185] ([212.50.99.193]) by smtp.googlemail.com with ESMTPSA id pd1sm25724087wjb.19.2016.02.22.10.11.58 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Feb 2016 10:11:59 -0800 (PST) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason To: Eli Zaretskii References: <86wq0q602w.fsf@yandex.ru> <56CA4FD1.3060609@yandex.ru> <83egc4lkxz.fsf@gnu.org> <56CB45AD.9010402@yandex.ru> <837fhwlk5a.fsf@gnu.org> <56CB4ECC.9040301@yandex.ru> From: Dmitry Gutov Message-ID: <56CB4F6E.9090708@yandex.ru> Date: Mon, 22 Feb 2016 20:11:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: <56CB4ECC.9040301@yandex.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 02/22/2016 08:09 PM, Dmitry Gutov wrote: Sorry, > Thanks. It's not urgent, but it seems to be the best way to process in ^ proceed > this issue. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 22 14:07:40 2016 Received: (at 20489) by debbugs.gnu.org; 22 Feb 2016 19:07:40 +0000 Received: from localhost ([127.0.0.1]:38441 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aXvpc-00029h-38 for submit@debbugs.gnu.org; Mon, 22 Feb 2016 14:07:40 -0500 Received: from eggs.gnu.org ([208.118.235.92]:54891) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aXvpb-00029P-93 for 20489@debbugs.gnu.org; Mon, 22 Feb 2016 14:07:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aXvpT-0005Uh-0X for 20489@debbugs.gnu.org; Mon, 22 Feb 2016 14:07:34 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43365) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXvpS-0005Ub-To; Mon, 22 Feb 2016 14:07:30 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1490 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aXvpS-0000v2-7B; Mon, 22 Feb 2016 14:07:30 -0500 Date: Mon, 22 Feb 2016 21:07:22 +0200 Message-Id: <83si0kk1hx.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-reply-to: <56CB4ECC.9040301@yandex.ru> (message from Dmitry Gutov on Mon, 22 Feb 2016 20:09:16 +0200) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason References: <86wq0q602w.fsf@yandex.ru> <56CA4FD1.3060609@yandex.ru> <83egc4lkxz.fsf@gnu.org> <56CB45AD.9010402@yandex.ru> <837fhwlk5a.fsf@gnu.org> <56CB4ECC.9040301@yandex.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Cc: 20489@debbugs.gnu.org > From: Dmitry Gutov > Date: Mon, 22 Feb 2016 20:09:16 +0200 > > On 02/22/2016 07:39 PM, Eli Zaretskii wrote: > > > OK, I will dig into my failing memory and try to remember that. > > (Or you could just try using it and maybe encountering the same problem > again.) Yes. But I wanted to recollect what made me nervous. Anyway, I found it in the discussion we had back then, so I know what to try. > Thanks. It's not urgent, but it seems to be the best way to process in > this issue. Right. From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 27 05:14:36 2016 Received: (at 20489) by debbugs.gnu.org; 27 Feb 2016 10:14:36 +0000 Received: from localhost ([127.0.0.1]:48175 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aZbtU-0004CT-C2 for submit@debbugs.gnu.org; Sat, 27 Feb 2016 05:14:36 -0500 Received: from eggs.gnu.org ([208.118.235.92]:39857) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aZbtT-0004CH-JI for 20489@debbugs.gnu.org; Sat, 27 Feb 2016 05:14:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aZbtL-0000xI-83 for 20489@debbugs.gnu.org; Sat, 27 Feb 2016 05:14:30 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43132) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZbtL-0000x8-50; Sat, 27 Feb 2016 05:14:27 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4586 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aZbtK-0007bG-Di; Sat, 27 Feb 2016 05:14:26 -0500 Date: Sat, 27 Feb 2016 12:14:07 +0200 Message-Id: <838u26cvf4.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-reply-to: <56CA4FD1.3060609@yandex.ru> (message from Dmitry Gutov on Mon, 22 Feb 2016 02:01:21 +0200) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason References: <86wq0q602w.fsf@yandex.ru> <56CA4FD1.3060609@yandex.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Cc: Eli Zaretskii > From: Dmitry Gutov > Date: Mon, 22 Feb 2016 02:01:21 +0200 > > Now that the xref window is more "persistent", could you try > uncommenting the relevant lines in xref--xref-buffer-mode, and see if > the situation has improved here? It looks much better now, thanks. I think we can uncomment those lines now. A couple of minor nits: . When one uses next-error to step through hits found by Dired's 'A' command, point in the *xref* buffer doesn't move to the hit that is visited in the window displayed above *xref*. Given how next-error works in other cases, I think users will expect point to move accordingly; at least I did. . I see the places I visited marked by a special face in *xref* (good!), but I don't quite understand when they get marked. They certainly don't get marked as I move through hits with next-error or with an explicit RET on a hit in the *xref* buffer. Perhaps we should mark them in real time? That would also help in understanding what that face means, I think. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 28 22:15:20 2016 Received: (at 20489) by debbugs.gnu.org; 29 Feb 2016 03:15:20 +0000 Received: from localhost ([127.0.0.1]:51188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aaEIq-0002ON-5g for submit@debbugs.gnu.org; Sun, 28 Feb 2016 22:15:20 -0500 Received: from mail-wm0-f49.google.com ([74.125.82.49]:35270) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aaEIo-0002O8-B4 for 20489@debbugs.gnu.org; Sun, 28 Feb 2016 22:15:18 -0500 Received: by mail-wm0-f49.google.com with SMTP id l68so43379197wml.0 for <20489@debbugs.gnu.org>; Sun, 28 Feb 2016 19:15:18 -0800 (PST) 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-transfer-encoding; bh=oYpiyGxAzXLdqLnj4X0lf93EE3TlwUScgfhHtRKOFJI=; b=luzNxykz7A5ddb6LLE+gthqRfN/s1RGaFqenO98FbiCqj/YXV+PG3/Y6SgZPIrfBZj fh6qJzYgBugNiDCsZozaMHohP68pvMjrJsICHTTsi2IVodmTZOghPRh4xq3fzls8lteF cptx0zEMtFKQ+HTvnnTGRTbkAxeJNQDq3JXAev6Fkoc28XchVPSqGvsJqH1ZFXHX1VrF U8gX66/M3q2Lqkbgj8so7NFZZgNfHzWmg7qy1qHtsxT7O+VkRUDL7FIOAXLZ3jpkt4JH I8vr1aI5yfaGST8023oRP2DwKgVwtw07aGYv82O1FN1DsZBJcFUYstnSJxNzV43EeWYR EbCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=oYpiyGxAzXLdqLnj4X0lf93EE3TlwUScgfhHtRKOFJI=; b=giG+v6zoawk5FImBDiwFl+N1fJWYrymae4i87R79OhNQz3/kpqXBALL/SKEdjM852V J2zHKKuLeI4ybcB72NSuuPAVUF4ZnEjda20UZQ3blZfS3NKcN+mqrHomdG1tja36ajcp 0vNGbTR5rJ2mumC5ACLaePpgjmsODxNod0hWQkBCVhf0+L+8OYpBcj+J0Xv9hqNi4BSd 1MdtgAWHn9uKWHPppChj+IPO1tNQQ2GkK9WX/52qzCuro/+boDu2PcrN0hev2huWDg5K edip5BfRKnIwcB2NzQKi2XN4m0g1ABYW9fWSTLeVRBW+Hju/6lhW3iJMQi6MfCKRtueW TqEQ== X-Gm-Message-State: AD7BkJKfQp7E+avL9H3hhlnTsp8wo0LY0c+1AAsW3r09EzjUq82OCLT2vzQvnTr/ZnsffA== X-Received: by 10.28.92.13 with SMTP id q13mr8613847wmb.43.1456715712838; Sun, 28 Feb 2016 19:15:12 -0800 (PST) Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id j10sm23687102wjb.46.2016.02.28.19.15.11 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 28 Feb 2016 19:15:11 -0800 (PST) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason To: Eli Zaretskii References: <86wq0q602w.fsf@yandex.ru> <56CA4FD1.3060609@yandex.ru> <838u26cvf4.fsf@gnu.org> From: Dmitry Gutov Message-ID: Date: Mon, 29 Feb 2016 05:15:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <838u26cvf4.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 02/27/2016 12:14 PM, Eli Zaretskii wrote: > . When one uses next-error to step through hits found by Dired's 'A' > command, point in the *xref* buffer doesn't move to the hit that is > visited in the window displayed above *xref*. Given how next-error > works in other cases, I think users will expect point to move > accordingly; at least I did. It would be helpful, but it doesn't seem like `next-error' was designed with this in mind. After all, xref--next-error-function does move point, and that doesn't help (probably because it's called inside with-current-buffer, see next-error-internal). Wrapping xref--next-error-function's definition in (with-selected-window (get-buffer-window xref-buffer-name) ...) does help, but that seems silly. > . I see the places I visited marked by a special face in *xref* > (good!), but I don't quite understand when they get marked. No special face, these are just unadorned buffer-substring values: the ones that have faces applied, are from buffer areas that had been touched by font-lock, the others hadn't. We could remove faces from all lines for consistency, but seeing them on at least some results is nice. > They > certainly don't get marked as I move through hits with next-error > or with an explicit RET on a hit in the *xref* buffer. Perhaps we > should mark them in real time? Not sure how to introduce that feature into the API in a generic fashion. Perhaps if we decided that the "summary" of each xref-match instance is always defined by the buffer contents? Having match-xrefs use a distinct structure from "normal" xrefs seems appropriate, but to fully go this way, I think we'll need the find-buffer-delayed feature first (http://lists.gnu.org/archive/html/emacs-devel/2015-08/msg00060.html). Because then we couldn't afford to have the location buffers closed (or reopen them all) when the xref buffer is rendered. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 29 11:24:05 2016 Received: (at 20489) by debbugs.gnu.org; 29 Feb 2016 16:24:05 +0000 Received: from localhost ([127.0.0.1]:53873 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aaQc9-0006ZW-Lb for submit@debbugs.gnu.org; Mon, 29 Feb 2016 11:24:05 -0500 Received: from eggs.gnu.org ([208.118.235.92]:57962) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aaQc8-0006Z1-Kh for 20489@debbugs.gnu.org; Mon, 29 Feb 2016 11:24:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aaQbz-000465-Gb for 20489@debbugs.gnu.org; Mon, 29 Feb 2016 11:23:59 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33338) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaQbz-000461-D5; Mon, 29 Feb 2016 11:23:55 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4743 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aaQby-0001PF-Nm; Mon, 29 Feb 2016 11:23:55 -0500 Date: Mon, 29 Feb 2016 18:23:42 +0200 Message-Id: <83lh638oz5.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-reply-to: (message from Dmitry Gutov on Mon, 29 Feb 2016 05:15:10 +0200) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason References: <86wq0q602w.fsf@yandex.ru> <56CA4FD1.3060609@yandex.ru> <838u26cvf4.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Cc: 20489@debbugs.gnu.org > From: Dmitry Gutov > Date: Mon, 29 Feb 2016 05:15:10 +0200 > > On 02/27/2016 12:14 PM, Eli Zaretskii wrote: > > > . When one uses next-error to step through hits found by Dired's 'A' > > command, point in the *xref* buffer doesn't move to the hit that is > > visited in the window displayed above *xref*. Given how next-error > > works in other cases, I think users will expect point to move > > accordingly; at least I did. > > It would be helpful, but it doesn't seem like `next-error' was designed > with this in mind. Really? Isn't that strange? Doesn't every user of next-error want that? > Wrapping xref--next-error-function's definition in > > (with-selected-window (get-buffer-window xref-buffer-name) > ...) > > does help, but that seems silly. Right. Too bad if this doesn't have an easy solution, but if so, I guess we will have to live with that. > Not sure how to introduce that feature into the API in a generic > fashion. Perhaps if we decided that the "summary" of each xref-match > instance is always defined by the buffer contents? OK, then let's forget about this until the necessary infrastructure is in place. Please uncomment those lines, if you didn't already. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 29 18:30:47 2016 Received: (at 20489) by debbugs.gnu.org; 29 Feb 2016 23:30:47 +0000 Received: from localhost ([127.0.0.1]:54301 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aaXH5-0003jD-L5 for submit@debbugs.gnu.org; Mon, 29 Feb 2016 18:30:47 -0500 Received: from mail-wm0-f47.google.com ([74.125.82.47]:36155) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aaXH4-0003iy-CC for 20489@debbugs.gnu.org; Mon, 29 Feb 2016 18:30:46 -0500 Received: by mail-wm0-f47.google.com with SMTP id n186so11975128wmn.1 for <20489@debbugs.gnu.org>; Mon, 29 Feb 2016 15:30:46 -0800 (PST) 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-transfer-encoding; bh=P2etbX1UnNXoirt9eDYBKZpnRzX7Nv3pTqmqzcgQoeI=; b=ZpVB+6Z+vZQfkWJ3Py0YRNxZVoyUs5G2z6Xg1ABRrVNtVilHduCYSpaDDNNkyUCEYb 8nvPIhHgGeDccpIndMarFKVFC9670etRQ+JxUCvAcIc2XHv6quAhJuHkSWroIEKc8NHM J8ql9unFb5JO75xs48cVR5J1d9QafTCjHpb0+kI6q8cQnnNyiu3SiWuEmvjYOTwQWHvj W/2V3+1WYpDY3mPXDipo0boVhCSXH7LmpKXcmngnZxtaCgH8IUybq9txO29RTHQgpMNG TQ98d8oduFQTkuk/4TH48dqTpFNJOLGu+TbUqCcBIJ051wi3VasyJzhQbpMioKYaqTIa asQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=P2etbX1UnNXoirt9eDYBKZpnRzX7Nv3pTqmqzcgQoeI=; b=KvGRjBTfLcUX6f6YgG7hVymgCkMMH5SsXAnz91iCAs/n0ySVst7nfvqNYSfhwipP4t /GGnskZVfihOUY2Q9recOGRpychmw9e8EGM949T3l2mtAX4GfXozq+thmo3N6xtIoW/P qXNIA9xsxG/AguuudxKYe6xWh9/iBHoQlIWHxPG7MyhJmfT8MzBFExLiQaGNYRddg9fI +L24n+i1o//eVzsMKbxh14R2fBqram7cs/Cj/32WHCJg8KUCLnhUtiFT2rcQbN/5hZoS FrLjbQEc/G1EELmz6jlWGEauQWFJli1FKVaD+SHeIhMmo9YFHDPL6gcHTxqsWRbf+IkL xImg== X-Gm-Message-State: AD7BkJL7YXnROHMt4Y21LvqJ6h/fGKtBPkriRnQf0CnWB7XD3/PxIANnBcxAPVMacIj4uA== X-Received: by 10.194.59.233 with SMTP id c9mr16327889wjr.88.1456788640714; Mon, 29 Feb 2016 15:30:40 -0800 (PST) Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id u4sm28142378wjz.4.2016.02.29.15.30.38 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Feb 2016 15:30:39 -0800 (PST) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason To: Eli Zaretskii References: <86wq0q602w.fsf@yandex.ru> <56CA4FD1.3060609@yandex.ru> <838u26cvf4.fsf@gnu.org> <83lh638oz5.fsf@gnu.org> From: Dmitry Gutov Message-ID: Date: Tue, 1 Mar 2016 01:30:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <83lh638oz5.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 02/29/2016 06:23 PM, Eli Zaretskii wrote: > Really? Isn't that strange? Doesn't every user of next-error want > that? Just yet another way next-error-function is broken, it seems. > Please uncomment those lines, if you didn't already. Already did, in aae436e2d898a8c8cc243c73d6cec5a8c566a061. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 06 16:56:55 2017 Received: (at 20489) by debbugs.gnu.org; 6 Nov 2017 21:56:55 +0000 Received: from localhost ([127.0.0.1]:54721 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eBpO2-0000F9-TR for submit@debbugs.gnu.org; Mon, 06 Nov 2017 16:56:55 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:52961 helo=homiemail-a39.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eBpO0-0000F1-LL for 20489@debbugs.gnu.org; Mon, 06 Nov 2017 16:56:53 -0500 Received: from homiemail-a39.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a39.g.dreamhost.com (Postfix) with ESMTP id CED04150074; Mon, 6 Nov 2017 13:56:51 -0800 (PST) Received: from localhost.linkov.net (m83-179-179-228.cust.tele2.ee [83.179.179.228]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by homiemail-a39.g.dreamhost.com (Postfix) with ESMTPSA id 9AA0C150069; Mon, 6 Nov 2017 13:56:50 -0800 (PST) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Organization: LINKOV.NET References: <86wq0q602w.fsf@yandex.ru> Date: Mon, 06 Nov 2017 23:53:00 +0200 In-Reply-To: <86wq0q602w.fsf@yandex.ru> (Dmitry Gutov's message of "Sun, 03 May 2015 02:17:43 +0300") Message-ID: <877ev36pmr.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --=-=-= Content-Type: text/plain It seems this discussion that came to a standstill here hopefully is revived and reached a preliminary consensus in bug#28864. Here's the current patch: --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=next-error-5.patch diff --git a/lisp/simple.el b/lisp/simple.el index 375a79e..ceefbc1 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -143,6 +143,7 @@ next-error-last-buffer A buffer becomes most recent when its compilation, grep, or similar mode is started, or when it is used with \\[next-error] or \\[compile-goto-error].") +(make-variable-buffer-local 'next-error-last-buffer) (defvar next-error-function nil "Function to use to find the next error in the current buffer. @@ -191,6 +192,31 @@ next-error-buffer-p (and extra-test-inclusive (funcall extra-test-inclusive)))))) +(defcustom next-error-find-buffer-function nil + "Function called to find a `next-error' capable buffer." + :type '(choice (const :tag "Single next-error capable buffer on selected frame" + next-error-buffer-on-selected-frame) + (const :tag "No default" nil) + (function :tag "Other function")) + :group 'next-error + :version "27.1") + +(defun next-error-buffer-on-selected-frame (&optional avoid-current + extra-test-inclusive + extra-test-exclusive) + "Return a single visible next-error buffer on the selected frame." + (let ((window-buffers + (delete-dups + (delq nil (mapcar (lambda (w) + (if (next-error-buffer-p + (window-buffer w) + avoid-current + extra-test-inclusive extra-test-exclusive) + (window-buffer w))) + (window-list)))))) + (if (eq (length window-buffers) 1) + (car window-buffers)))) + (defun next-error-find-buffer (&optional avoid-current extra-test-inclusive extra-test-exclusive) @@ -207,18 +233,11 @@ next-error-find-buffer that would normally be considered usable. If it returns nil, that buffer is rejected." (or - ;; 1. If one window on the selected frame displays such buffer, return it. - (let ((window-buffers - (delete-dups - (delq nil (mapcar (lambda (w) - (if (next-error-buffer-p - (window-buffer w) - avoid-current - extra-test-inclusive extra-test-exclusive) - (window-buffer w))) - (window-list)))))) - (if (eq (length window-buffers) 1) - (car window-buffers))) + ;; 1. If a customizable function returns a buffer, use it. + (when next-error-find-buffer-function + (funcall next-error-find-buffer-function avoid-current + extra-test-inclusive + extra-test-exclusive)) ;; 2. If next-error-last-buffer is an acceptable buffer, use that. (if (and next-error-last-buffer (next-error-buffer-p next-error-last-buffer avoid-current @@ -283,11 +302,20 @@ next-error (when buffer ;; We know here that next-error-function is a valid symbol we can funcall (with-current-buffer buffer + ;; Allow next-error to be used from the next-error capable buffer. + (setq next-error-last-buffer buffer) (funcall next-error-function (prefix-numeric-value arg) reset) ;; Override possible change of next-error-last-buffer in next-error-function (setq next-error-last-buffer buffer) + (setq-default next-error-last-buffer buffer) (when next-error-recenter (recenter next-error-recenter)) + (message "%s error from %s" + (cond (reset "First") + ((eq (prefix-numeric-value arg) 0) "Current") + ((< (prefix-numeric-value arg) 0) "Previous") + (t "Next")) + next-error-last-buffer) (run-hooks 'next-error-hook))))) (defun next-error-internal () @@ -295,13 +323,26 @@ next-error-internal (let ((buffer (current-buffer))) ;; We know here that next-error-function is a valid symbol we can funcall (with-current-buffer buffer + ;; Allow next-error to be used from the next-error capable buffer. + (setq next-error-last-buffer buffer) (funcall next-error-function 0 nil) ;; Override possible change of next-error-last-buffer in next-error-function (setq next-error-last-buffer buffer) + (setq-default next-error-last-buffer buffer) (when next-error-recenter (recenter next-error-recenter)) + (message "Current error from %s" next-error-last-buffer) (run-hooks 'next-error-hook)))) +(defun next-error-select-buffer (buffer) + "Select a `next-error' capable buffer and set it as the last used." + (interactive + (list (get-buffer + (read-buffer "Select next-error buffer: " nil nil + (lambda (b) (next-error-buffer-p (cdr b))))))) + (setq next-error-last-buffer buffer) + (setq-default next-error-last-buffer buffer)) + (defalias 'goto-next-locus 'next-error) (defalias 'next-match 'next-error) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 15 17:32:57 2018 Received: (at 20489) by debbugs.gnu.org; 15 Feb 2018 22:32:57 +0000 Received: from localhost ([127.0.0.1]:45286 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1emS5J-00033b-KI for submit@debbugs.gnu.org; Thu, 15 Feb 2018 17:32:57 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:40698 helo=homiemail-a101.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1emS5I-00033U-Vh for 20489@debbugs.gnu.org; Thu, 15 Feb 2018 17:32:57 -0500 Received: from homiemail-a101.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a101.g.dreamhost.com (Postfix) with ESMTP id 77991117E06C; Thu, 15 Feb 2018 14:32:56 -0800 (PST) Received: from localhost.linkov.net (m91-129-100-74.cust.tele2.ee [91.129.100.74]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by homiemail-a101.g.dreamhost.com (Postfix) with ESMTPSA id 85CFC117E065; Thu, 15 Feb 2018 14:32:55 -0800 (PST) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Organization: LINKOV.NET References: <86wq0q602w.fsf@yandex.ru> <877ev36pmr.fsf@mail.linkov.net> Date: Fri, 16 Feb 2018 00:16:33 +0200 In-Reply-To: <877ev36pmr.fsf@mail.linkov.net> (Juri Linkov's message of "Mon, 06 Nov 2017 23:53:00 +0200") Message-ID: <87sha1nbjy.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) > It seems this discussion that came to a standstill here > hopefully is revived and reached a preliminary consensus in bug#28864. > Here's the current patch: Dmitry, could you please confirm that this patch works with the current c= ode in xref--next-error-function? If yes, I propose to push it to master. Then we will get more feedback if something is broken :) PS: When I typed the closing paren =E2=80=98)=E2=80=99 in the last senten= ce in =E2=80=98message-mode=E2=80=99, it blinked on the letter =E2=80=98b=E2=80=99. Do you know the reason of = this weird behavior? From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 21 16:30:57 2018 Received: (at 20489-done) by debbugs.gnu.org; 21 Feb 2018 21:30:57 +0000 Received: from localhost ([127.0.0.1]:54965 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eobyb-0004mF-By for submit@debbugs.gnu.org; Wed, 21 Feb 2018 16:30:57 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:45083 helo=homiemail-a100.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eobyZ-0004m7-1N for 20489-done@debbugs.gnu.org; Wed, 21 Feb 2018 16:30:56 -0500 Received: from homiemail-a100.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a100.g.dreamhost.com (Postfix) with ESMTP id 190B531A078 for <20489-done@debbugs.gnu.org>; Wed, 21 Feb 2018 13:30:54 -0800 (PST) Received: from localhost.linkov.net (m91-129-98-215.cust.tele2.ee [91.129.98.215]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by homiemail-a100.g.dreamhost.com (Postfix) with ESMTPSA id 6B0CA31A075 for <20489-done@debbugs.gnu.org>; Wed, 21 Feb 2018 13:30:53 -0800 (PST) From: Juri Linkov To: 20489-done@debbugs.gnu.org Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Organization: LINKOV.NET References: <86wq0q602w.fsf@yandex.ru> <877ev36pmr.fsf@mail.linkov.net> Date: Wed, 21 Feb 2018 23:30:30 +0200 In-Reply-To: <877ev36pmr.fsf@mail.linkov.net> (Juri Linkov's message of "Mon, 06 Nov 2017 23:53:00 +0200") Message-ID: <874lma3ua1.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 20489-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) > It seems this discussion that came to a standstill here > hopefully is revived and reached a preliminary consensus in bug#28864. > Here's the current patch: Finally pushed to master and closed. From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 22 16:46:38 2018 Received: (at 20489) by debbugs.gnu.org; 22 Feb 2018 21:46:38 +0000 Received: from localhost ([127.0.0.1]:56911 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eoyhK-0001oZ-DH for submit@debbugs.gnu.org; Thu, 22 Feb 2018 16:46:38 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:37979 helo=homiemail-a15.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eoyhI-0001oO-Bt for 20489@debbugs.gnu.org; Thu, 22 Feb 2018 16:46:37 -0500 Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 3683976C06B; Thu, 22 Feb 2018 13:46:35 -0800 (PST) Received: from localhost.linkov.net (m91-129-98-215.cust.tele2.ee [91.129.98.215]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPSA id 5D64F76C069; Thu, 22 Feb 2018 13:46:34 -0800 (PST) From: Juri Linkov To: Stefan Monnier Subject: Re: [Emacs-diffs] master d48e07a: * lisp/simple.el (next-error-find-buffer-function): New defcustom. Organization: LINKOV.NET References: <20180221213025.27066.69339@vcs0.savannah.gnu.org> <20180221213027.372932052F@vcs0.savannah.gnu.org> Date: Thu, 22 Feb 2018 23:38:23 +0200 In-Reply-To: (Stefan Monnier's message of "Wed, 21 Feb 2018 17:04:49 -0500") Message-ID: <87r2pc7w60.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) >> +(defcustom next-error-find-buffer-function nil > > Why make it a defcustom rather than a defvar? I changed it to defvar in the following patch. >> + (when next-error-find-buffer-function >> + (funcall next-error-find-buffer-function avoid-current >> + extra-test-inclusive >> + extra-test-exclusive)) > > Could you arrange for the default value of this new *-function var not > to be nil so we can modify it with add-function? Then I guess the default function should return nil. Here is a new patch: diff --git a/lisp/simple.el b/lisp/simple.el index 2101cfe..5413b5a 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -170,14 +170,12 @@ next-error-buffer-p (and extra-test-inclusive (funcall extra-test-inclusive)))))) -(defcustom next-error-find-buffer-function nil - "Function called to find a `next-error' capable buffer." - :type '(choice (const :tag "Single next-error capable buffer on selected frame" - next-error-buffer-on-selected-frame) - (const :tag "No default" nil) - (function :tag "Other function")) - :group 'next-error - :version "27.1") +(defvar next-error-find-buffer-function 'next-error-find-buffer-function-default + "Function to find a `next-error' capable buffer.") + +(defun next-error-find-buffer-function-default (&optional avoid-current + extra-test-inclusive + extra-test-exclusive)) (defun next-error-buffer-on-selected-frame (&optional avoid-current extra-test-inclusive @@ -212,10 +210,9 @@ next-error-find-buffer that buffer is rejected." (or ;; 1. If a customizable function returns a buffer, use it. - (when next-error-find-buffer-function - (funcall next-error-find-buffer-function avoid-current - extra-test-inclusive - extra-test-exclusive)) + (funcall next-error-find-buffer-function avoid-current + extra-test-inclusive + extra-test-exclusive) ;; 2. If next-error-last-buffer is an acceptable buffer, use that. (if (and next-error-last-buffer (next-error-buffer-p next-error-last-buffer avoid-current From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 23 09:36:25 2018 Received: (at 20489) by debbugs.gnu.org; 23 Feb 2018 14:36:25 +0000 Received: from localhost ([127.0.0.1]:57246 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1epESW-0002wO-Sz for submit@debbugs.gnu.org; Fri, 23 Feb 2018 09:36:25 -0500 Received: from chene.dit.umontreal.ca ([132.204.246.20]:50393) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1epEST-0002wE-CK for 20489@debbugs.gnu.org; Fri, 23 Feb 2018 09:36:23 -0500 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w1NEaJ7o007540; Fri, 23 Feb 2018 09:36:20 -0500 Received: by pastel.home (Postfix, from userid 20848) id A0E0F6043C; Fri, 23 Feb 2018 09:36:19 -0500 (EST) From: Stefan Monnier To: Juri Linkov Subject: Re: [Emacs-diffs] master d48e07a: * lisp/simple.el (next-error-find-buffer-function): New defcustom. Message-ID: References: <20180221213025.27066.69339@vcs0.savannah.gnu.org> <20180221213027.372932052F@vcs0.savannah.gnu.org> <87r2pc7w60.fsf@mail.linkov.net> Date: Fri, 23 Feb 2018 09:36:19 -0500 In-Reply-To: <87r2pc7w60.fsf@mail.linkov.net> (Juri Linkov's message of "Thu, 22 Feb 2018 23:38:23 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6229=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6229> : inlines <6431> : streams <1779815> : uri <2598011> X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) >> Could you arrange for the default value of this new *-function var not >> to be nil so we can modify it with add-function? > Then I guess the default function should return nil. Here is a new patch: Fine by me. Tho, see comments below. Stefan > +(defun next-error-find-buffer-function-default (&optional avoid-current > + extra-test-inclusive > + extra-test-exclusive)) This looks like a syntax error to me (function without body). I know it's accepted (because various parts of the byte-compiler need special hacks to deal with it), but please always put a body (i.e. an explicit nil). This said, I don't think you should define this function. Instead: > +(defvar next-error-find-buffer-function 'next-error-find-buffer-function-default should just say (defvar next-error-find-buffer-function #'ignore -- Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 24 16:50:08 2018 Received: (at 20489) by debbugs.gnu.org; 24 Feb 2018 21:50:08 +0000 Received: from localhost ([127.0.0.1]:59104 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ephho-0007KB-65 for submit@debbugs.gnu.org; Sat, 24 Feb 2018 16:50:08 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:47254 helo=homiemail-a15.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ephhl-0007K0-WA for 20489@debbugs.gnu.org; Sat, 24 Feb 2018 16:50:06 -0500 Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 9ED0F76C069; Sat, 24 Feb 2018 13:50:04 -0800 (PST) Received: from localhost.linkov.net (m91-129-98-215.cust.tele2.ee [91.129.98.215]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPSA id B63A376C065; Sat, 24 Feb 2018 13:50:03 -0800 (PST) From: Juri Linkov To: Stefan Monnier Subject: Re: [Emacs-diffs] master d48e07a: * lisp/simple.el (next-error-find-buffer-function): New defcustom. Organization: LINKOV.NET References: <20180221213025.27066.69339@vcs0.savannah.gnu.org> <20180221213027.372932052F@vcs0.savannah.gnu.org> <87r2pc7w60.fsf@mail.linkov.net> Date: Sat, 24 Feb 2018 23:34:35 +0200 In-Reply-To: (Stefan Monnier's message of "Fri, 23 Feb 2018 09:36:19 -0500") Message-ID: <87d10u5axg.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) >> +(defun next-error-find-buffer-function-default (&optional avoid-current >> + extra-test-inclusive >> + extra-test-exclusive)) > > This looks like a syntax error to me (function without body). I know > it's accepted (because various parts of the byte-compiler need special > hacks to deal with it), but please always put a body (i.e. an explicit nil). And without body there is no way to add a docstring. >> +(defvar next-error-find-buffer-function 'next-error-find-buffer-function-default > > should just say > > (defvar next-error-find-buffer-function #'ignore Ah, before arriving to the function without body I mistakenly tried #'identity (that didn't work) whereas I actually intended to try #'ignore. But the question that I really don't understand is what to do with the function next-error-buffer-on-selected-frame that now will have no reference in code, no use by default. How the users are supposed to know that it's possible to put add-function with this function in the init file? Should we document this in the docstring of next-error-buffer-on-selected-frame or the docstring of next-error-find-buffer-function together with examples of using add-function? From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 25 08:19:43 2018 Received: (at 20489) by debbugs.gnu.org; 25 Feb 2018 13:19:43 +0000 Received: from localhost ([127.0.0.1]:59522 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1epwDP-0007ka-4q for submit@debbugs.gnu.org; Sun, 25 Feb 2018 08:19:43 -0500 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:50479) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1epwDN-0007kT-Lz for 20489@debbugs.gnu.org; Sun, 25 Feb 2018 08:19:42 -0500 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w1PDJdMJ006852; Sun, 25 Feb 2018 08:19:40 -0500 Received: by pastel.home (Postfix, from userid 20848) id 76F38605F6; Sun, 25 Feb 2018 08:19:39 -0500 (EST) From: Stefan Monnier To: Juri Linkov Subject: Re: [Emacs-diffs] master d48e07a: * lisp/simple.el (next-error-find-buffer-function): New defcustom. Message-ID: References: <20180221213025.27066.69339@vcs0.savannah.gnu.org> <20180221213027.372932052F@vcs0.savannah.gnu.org> <87r2pc7w60.fsf@mail.linkov.net> <87d10u5axg.fsf@mail.linkov.net> Date: Sun, 25 Feb 2018 08:19:39 -0500 In-Reply-To: <87d10u5axg.fsf@mail.linkov.net> (Juri Linkov's message of "Sat, 24 Feb 2018 23:34:35 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6229=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6229> : inlines <6431> : streams <1779998> : uri <2599100> X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > Ah, before arriving to the function without body I mistakenly tried #'identity > (that didn't work) whereas I actually intended to try #'ignore. Should we provide the K combinator? > But the question that I really don't understand is what to do with the > function next-error-buffer-on-selected-frame that now will have no > reference in code, no use by default. How the users are supposed to > know that it's possible to put add-function with this function in the > init file? Ah, so that's why you had a defcustom? Then maybe having it be a defcustom is a good idea. Stefan "to tell you the truth, I haven't bothered to look at the code to try to understand what these things are doing, so I have no opinion on whether it should be a defcustom or not, or if should be a function defcustom rather than, say, a boolean defcustom" From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 25 16:00:19 2018 Received: (at 20489) by debbugs.gnu.org; 25 Feb 2018 21:00:19 +0000 Received: from localhost ([127.0.0.1]:60689 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eq3P9-0001WH-K0 for submit@debbugs.gnu.org; Sun, 25 Feb 2018 16:00:19 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:50797 helo=homiemail-a23.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eq3P7-0001W8-31 for 20489@debbugs.gnu.org; Sun, 25 Feb 2018 16:00:17 -0500 Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id F41B34B007C; Sun, 25 Feb 2018 13:00:15 -0800 (PST) Received: from localhost.linkov.net (m91-129-98-215.cust.tele2.ee [91.129.98.215]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPSA id 2418D4B006F; Sun, 25 Feb 2018 13:00:14 -0800 (PST) From: Juri Linkov To: Stefan Monnier Subject: Re: [Emacs-diffs] master d48e07a: * lisp/simple.el (next-error-find-buffer-function): New defcustom. Organization: LINKOV.NET References: <20180221213025.27066.69339@vcs0.savannah.gnu.org> <20180221213027.372932052F@vcs0.savannah.gnu.org> <87r2pc7w60.fsf@mail.linkov.net> <87d10u5axg.fsf@mail.linkov.net> Date: Sun, 25 Feb 2018 22:40:53 +0200 In-Reply-To: (Stefan Monnier's message of "Sun, 25 Feb 2018 08:19:39 -0500") Message-ID: <871sh8ol9m.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) >> But the question that I really don't understand is what to do with the >> function next-error-buffer-on-selected-frame that now will have no >> reference in code, no use by default. How the users are supposed to >> know that it's possible to put add-function with this function in the >> init file? > > Ah, so that's why you had a defcustom? Then maybe having it be > a defcustom is a good idea. > > > Stefan "to tell you the truth, I haven't bothered to look at th= e > code to try to understand what these things are doing, > so I have no opinion on whether it should be a defcusto= m > or not, or if should be a function defcustom rather > than, say, a boolean defcustom" I think what we need is to support add-function in defcustom. Probably we already have all building blocks to create a new widget type using a list of functions together with PLACE symbols (e.g. =E2=80=98:around=E2=80=99, =E2=80=98:before=E2=80=99). Then saving= such customization should apply add-function on that list of functions in the customized order. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 26 20:21:34 2018 Received: (at 20489) by debbugs.gnu.org; 27 Feb 2018 01:21:34 +0000 Received: from localhost ([127.0.0.1]:34150 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eqTxW-00063U-Dk for submit@debbugs.gnu.org; Mon, 26 Feb 2018 20:21:34 -0500 Received: from mail-wr0-f171.google.com ([209.85.128.171]:43975) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eqTxU-00063G-Pn for 20489@debbugs.gnu.org; Mon, 26 Feb 2018 20:21:33 -0500 Received: by mail-wr0-f171.google.com with SMTP id u49so23129125wrc.10 for <20489@debbugs.gnu.org>; Mon, 26 Feb 2018 17:21:32 -0800 (PST) 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=UQNFWcRgW8Pp8F0y3L4g+jOo/FJNt5pmUvxEmw18ods=; b=TV8E+RaVeAli2lxnIK6FuK/glPceqTUfEHhyKqZ8TaqrbOIh3yHG5kkRBNsf+D6izO 6EZ58fsT0zY7ZNrTvJehv0pLJ5V+GYd/DvYpD6EPRu8VMK5ALy0G8P00sGjgDtKxeo5W y0Zv7QjVTSCq3Q14P7gYNflCDWuAScWVBvEq+qyd69CrbzKZl0dFTA1r5A6bYvkr8iem 2r0XCPr9J7FywRgFe0JX88e9x70nlTzQ3ItInDszEipVUSTOfukESexv0N9T1Kz1Lrul SA1hlsz/+1lWWIC7Q0LvbwJcgdvVMZwjl3+XdBJnixBd0W9g55WRlepWEyViM7MX22Ac Be4A== 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=UQNFWcRgW8Pp8F0y3L4g+jOo/FJNt5pmUvxEmw18ods=; b=ooXnNOeyARCSJnIqmLo1y9qrAxzeAlCuyfLv9h5C2kuGRKCWC118UjlaZfdl+9rq8Z qjePG3iV7w58K/vyVldHZUiTMJhvA188Ig5DcZ7XJnUqs9VdTi0vtOB3YLpOhGuWg3CS XMPWHfRU1cK/XEMxvO/I4L2ws072T/GAuJsf0VjdFhaAyojDdal8xwVX772NXhrGbXOM e0uOusTIdcCC9HPhmXamzH3LEraTDJnfWa5Efzbg9duXC2ZF2ozFFaGcRZEhF7vC+jVv NEXCPrHJCbsREhklvMhKhdOchgBs1AxlGFMi/7GaaSOBBKnIexXxjcDnCI1UVyoO/T/N kiBg== X-Gm-Message-State: APf1xPBQO3jqV1hjWBB32+b5+bt6adh9fjV3yjx3QGIIbqM+ebFk4AG4 8L+OxLfNklaHk2uoUhVXormslQWg X-Google-Smtp-Source: AH8x227tMRfZvLhnzrw9iPWvoCeNuUAkFhb4ZMiItgA+Yl8J/Z9uiaRSzncNb03ytKLFoPQPItohJw== X-Received: by 10.223.151.204 with SMTP id t12mr11883568wrb.156.1519694486358; Mon, 26 Feb 2018 17:21:26 -0800 (PST) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id v63sm32208937wrc.69.2018.02.26.17.21.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Feb 2018 17:21:23 -0800 (PST) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason To: Juri Linkov References: <86wq0q602w.fsf@yandex.ru> <877ev36pmr.fsf@mail.linkov.net> <87sha1nbjy.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <23fd061a-9b83-742a-6083-6d2f090b8f22@yandex.ru> Date: Tue, 27 Feb 2018 03:21:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Thunderbird/59.0 MIME-Version: 1.0 In-Reply-To: <87sha1nbjy.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) Hi Juri, I'm sorry for the late reply. On 2/16/18 12:16 AM, Juri Linkov wrote: > Dmitry, could you please confirm that this patch works with the current code > in xref--next-error-function? If yes, I propose to push it to master. It doesn't seem to help, unfortunately, in the case of xref buffers. Take this example: - emacs -Q - Navigate to the Emacs source directory, if not already there - M-x project-find-regexp RET Bazaar RET - See the buffer that popped up, and the value of next-error-last-buffer is *xref*. But it's only set locally (the global value is nil). - Type 'M-x next-error'. That pops up the ChangeLog.1 buffer. - next-error-last-buffer is *xref* in the *xref* buffer, and ChangeLog.1 in the ChangeLog.1 buffer. - Type 'M-x next-error' again, and see the error: change-log-goto-source: Cannot find tag or file near ‘point’ Whereas we should still have been using the navigation from *xreF*. Further, I'm not sure I like bug#20489 being closed with this patch only. Even if it worked 100%, it doesn't address everything that came up in that discussion. Bug#28864 being closed is fine, and indeed that scenario has been addressed. > PS: When I typed the closing paren ‘)’ in the last sentence in ‘message-mode’, > it blinked on the letter ‘b’. Do you know the reason of this weird behavior? Sorry, never seen this, and can't reproduce. I haven't been using Emacs for email lately, though. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 26 20:55:07 2018 Received: (at 20489) by debbugs.gnu.org; 27 Feb 2018 01:55:07 +0000 Received: from localhost ([127.0.0.1]:34155 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eqUTz-0006mx-3x for submit@debbugs.gnu.org; Mon, 26 Feb 2018 20:55:07 -0500 Received: from mail-wm0-f45.google.com ([74.125.82.45]:52435) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eqUTx-0006mR-0i for 20489@debbugs.gnu.org; Mon, 26 Feb 2018 20:55:05 -0500 Received: by mail-wm0-f45.google.com with SMTP id t3so21012847wmc.2 for <20489@debbugs.gnu.org>; Mon, 26 Feb 2018 17:55:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=dsCEoBtzTtsRcmNslM8ubKVo7SendrqwdYgfTIepL/k=; b=tMLOhiMbFs/9+5CHxyzDZVDn9967hmrkyuB3E45/TJS9D+b0X53WgVJhLxFDY8rjWl nSr5elS6+u5iDP2qbOCxqKYaPhRkw/xQxmXHY2/umR5712kfero8pFxcjlGW1JNLKoQc vqxdCuQAkUkV1oIkrs9t0a3Tu2FTJg6YR4NsdIEfk51esHGDfw4hvp1ql3EedKpe0NAI Z/eE0uFHaVnqrlXwdkOKYmdsrwg3RUcu4wTgTrnD3pM8AQwzKNjGpDJdyPk/yzg3tc60 hEjAzvcf8ilD+FMTmWvEwTyUBfGIIXmGrgrYeDnyY4vMWfSdyLxzF7K99OjNbfXpl//R K9RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:from:to:cc:references:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=dsCEoBtzTtsRcmNslM8ubKVo7SendrqwdYgfTIepL/k=; b=nk3wre3nn9Di211RmlRQOJYKsgzMC4TS84Meh+y6NMrGIoCkVWleWnQOAlxzBbA5Wk lAliWapSHKehOSUi6mPkiAy7beCFZ5FfqPsyPKjklCGhdMXxklH0CjxdOp6ZMTqnmz5I ZSzt97xaQF/Gbn2arPFMfvbEpz4MQ9o1QDRRPOiCcCUMKyveDrhZoyWnUMIKq+Yg/9qc zRXwMOSwv7Jmp3NCCnFpIwma7yyBHGnDJTSHGKA5GAsHXW/sSysN7k2kQ6vDQst6V+e9 XCFdx4ACewexr8u7DJN8gEbrXH7obxGhBTVv6jSjatjhyEbjOinGgd1B9EI/WhX9aO7J 6NyA== X-Gm-Message-State: APf1xPABA//ih3rnK9HjEClEsC8EvVuetAWh8Eq1EXDSMnE4ZCsMec43 9R3Nm7iBfPExxNnYSNGspZ2M3H+s X-Google-Smtp-Source: AG47ELuWBVOLbFW+ietdfCJlekf66AkwgYYpAcU0TnOeKT/QK7hgPxbT55hB8IHtcMlb0dz83EFKxA== X-Received: by 10.28.167.208 with SMTP id q199mr9740057wme.29.1519696498923; Mon, 26 Feb 2018 17:54:58 -0800 (PST) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id o9sm14887820wrf.43.2018.02.26.17.54.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Feb 2018 17:54:57 -0800 (PST) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason From: Dmitry Gutov To: Juri Linkov References: <86wq0q602w.fsf@yandex.ru> <877ev36pmr.fsf@mail.linkov.net> <87sha1nbjy.fsf@mail.linkov.net> <23fd061a-9b83-742a-6083-6d2f090b8f22@yandex.ru> Message-ID: <81d36dbe-f563-187a-ec16-df4b051ae204@yandex.ru> Date: Tue, 27 Feb 2018 03:54:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Thunderbird/59.0 MIME-Version: 1.0 In-Reply-To: <23fd061a-9b83-742a-6083-6d2f090b8f22@yandex.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) On 2/27/18 3:21 AM, Dmitry Gutov wrote: > Further, I'm not sure I like bug#20489 being closed with this patch > only. Even if it worked 100%, it doesn't address everything that came up > in that discussion. Bug#28864 being closed is fine, and indeed that > scenario has been addressed. Actually, I retract this. next-error-select-buffer should address the other major pain point, as soon as the basics work fine. On that subject: why did we make next-error-last-buffer always buffer-local? From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 27 13:08:09 2018 Received: (at 20489) by debbugs.gnu.org; 27 Feb 2018 18:08:09 +0000 Received: from localhost ([127.0.0.1]:35915 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eqjfb-0002pK-Eg for submit@debbugs.gnu.org; Tue, 27 Feb 2018 13:08:07 -0500 Received: from mail-wm0-f46.google.com ([74.125.82.46]:52525) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eqjfZ-0002of-Km for 20489@debbugs.gnu.org; Tue, 27 Feb 2018 13:08:05 -0500 Received: by mail-wm0-f46.google.com with SMTP id t3so306104wmc.2 for <20489@debbugs.gnu.org>; Tue, 27 Feb 2018 10:08:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=SjnE64TazSKV7glvaZcpCOrCOlHtC1CzWecLso0Yd3I=; b=l8ZiyviCqqe92KlNztTI9CetTHGsD6ybi/pYwi4RXdGQW4TO8fDmQ8yN1Pmy1wLyzy DtIyaf2Z/bgtnVYzsq9M4+5EHMNkNRtZdHhQmuc8QJUEW/gBkkKuMG02fOJ4sknDSeTC bnupx9Ilkt9sFmiz9bvNdGLwQQW8uuQE4BPUfLgCehPC3QKdfdask/MaeMsJq/ujmPUe 9lYMx1PukQ+8aKur08BUI9L5YNWKY6VUDRj2A5wG8DC8e2ZIhyOS4dIReVAq+6u5rw0L RYBxRu0kSi4Lfo8i6X9xlar8zOys7MeibO/kI+PoobOBvDc31/Dp70Olr2DHgFfiredL 5CHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:from:to:cc:references:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=SjnE64TazSKV7glvaZcpCOrCOlHtC1CzWecLso0Yd3I=; b=BL6ui+1KL1++/9INCdHDTdA9FC1gE/se5iLRBkrkXezJAqS1oW/WQbw8MlSmrFYs9Q oL8ZFIyW58U4gqk+QskYedGuokSJvPGfuRetaeZ0Ig9EcoThwZPX2WpQe0wNh8a5uhCN THeunPyzGaTibK8uEy0bAc2UJN5yy5XXKtOBPFZtpSREon8uxgDDqhagzWZbtwNdvlVu 9o5e5tGIRVo0h3x8O/opzhyqFVzQpJVxU+AFSXoS+7ZNDDuJZy5I9qKNA8HCXv5iFW5q VU0fDJDERRL5Kwv3UM6e+oobAGpTfpEQsbXksVI46rvDGugG0sUrW+nz/YKZfHbfl/qv RzCg== X-Gm-Message-State: APf1xPBH85pP4VoFnxZlpbO0iCMg/3Q/DoBC7uAU0XWR5cGQdaxcLHC9 984x+VcoFTD/Z+jFFXLJpA/3WCnp X-Google-Smtp-Source: AG47ELvT8mA3BPx3AFYOW9Kmpauqrz6Ktlswyj5ZG2hpb8RLBdw9obF/giKnS6GVI7REXf7sl7w0NQ== X-Received: by 10.28.231.10 with SMTP id e10mr12490414wmh.125.1519754879246; Tue, 27 Feb 2018 10:07:59 -0800 (PST) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id y145sm100985wmd.43.2018.02.27.10.07.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Feb 2018 10:07:56 -0800 (PST) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason From: Dmitry Gutov To: Juri Linkov References: <86wq0q602w.fsf@yandex.ru> <877ev36pmr.fsf@mail.linkov.net> <87sha1nbjy.fsf@mail.linkov.net> <23fd061a-9b83-742a-6083-6d2f090b8f22@yandex.ru> <81d36dbe-f563-187a-ec16-df4b051ae204@yandex.ru> Message-ID: <2413d917-02c6-a176-8fdc-be0127da87e3@yandex.ru> Date: Tue, 27 Feb 2018 20:07:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Thunderbird/59.0 MIME-Version: 1.0 In-Reply-To: <81d36dbe-f563-187a-ec16-df4b051ae204@yandex.ru> Content-Type: multipart/mixed; boundary="------------67CD4F23759E5BADB7AD8848" Content-Language: en-US X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) This is a multi-part message in MIME format. --------------67CD4F23759E5BADB7AD8848 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 2/27/18 3:54 AM, Dmitry Gutov wrote: > On that subject: why did we make next-error-last-buffer always > buffer-local? So... Any objections to this patch? It does fix the problem I described. --------------67CD4F23759E5BADB7AD8848 Content-Type: text/x-patch; name="next-error-last-buffer-global-again.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="next-error-last-buffer-global-again.diff" diff --git a/lisp/simple.el b/lisp/simple.el index 2101cfe833..b3ec30edba 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -121,7 +121,6 @@ next-error-last-buffer A buffer becomes most recent when its compilation, grep, or similar mode is started, or when it is used with \\[next-error] or \\[compile-goto-error].") -(make-variable-buffer-local 'next-error-last-buffer) (defvar next-error-function nil "Function to use to find the next error in the current buffer. @@ -280,12 +279,10 @@ next-error (when buffer ;; We know here that next-error-function is a valid symbol we can funcall (with-current-buffer buffer - ;; Allow next-error to be used from the next-error capable buffer. - (setq next-error-last-buffer buffer) (funcall next-error-function (prefix-numeric-value arg) reset) - ;; Override possible change of next-error-last-buffer in next-error-function + ;; Allow next-error to be used from the next-error capable buffer. + ;; (If next-error-function changed this var, it will have no effect). (setq next-error-last-buffer buffer) - (setq-default next-error-last-buffer buffer) (when next-error-recenter (recenter next-error-recenter)) (message "%s error from %s" @@ -301,12 +298,10 @@ next-error-internal (let ((buffer (current-buffer))) ;; We know here that next-error-function is a valid symbol we can funcall (with-current-buffer buffer - ;; Allow next-error to be used from the next-error capable buffer. - (setq next-error-last-buffer buffer) (funcall next-error-function 0 nil) - ;; Override possible change of next-error-last-buffer in next-error-function + ;; Allow next-error to be used from the next-error capable buffer. + ;; (If next-error-function changed this var, it will have no effect). (setq next-error-last-buffer buffer) - (setq-default next-error-last-buffer buffer) (when next-error-recenter (recenter next-error-recenter)) (message "Current error from %s" next-error-last-buffer) @@ -318,8 +313,7 @@ next-error-select-buffer (list (get-buffer (read-buffer "Select next-error buffer: " nil nil (lambda (b) (next-error-buffer-p (cdr b))))))) - (setq next-error-last-buffer buffer) - (setq-default next-error-last-buffer buffer)) + (setq next-error-last-buffer buffer)) (defalias 'goto-next-locus 'next-error) (defalias 'next-match 'next-error) --------------67CD4F23759E5BADB7AD8848-- From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 27 16:39:29 2018 Received: (at 20489) by debbugs.gnu.org; 27 Feb 2018 21:39:29 +0000 Received: from localhost ([127.0.0.1]:36045 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eqmy6-0001FX-Lf for submit@debbugs.gnu.org; Tue, 27 Feb 2018 16:39:29 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:36480 helo=homiemail-a20.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eqmy4-0001FP-J6 for 20489@debbugs.gnu.org; Tue, 27 Feb 2018 16:39:24 -0500 Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 7F0367EC07B; Tue, 27 Feb 2018 13:39:23 -0800 (PST) Received: from localhost.linkov.net (m91-129-98-215.cust.tele2.ee [91.129.98.215]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id A6B477EC076; Tue, 27 Feb 2018 13:39:22 -0800 (PST) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Organization: LINKOV.NET References: <86wq0q602w.fsf@yandex.ru> <877ev36pmr.fsf@mail.linkov.net> <87sha1nbjy.fsf@mail.linkov.net> <23fd061a-9b83-742a-6083-6d2f090b8f22@yandex.ru> <81d36dbe-f563-187a-ec16-df4b051ae204@yandex.ru> Date: Tue, 27 Feb 2018 23:16:00 +0200 In-Reply-To: <81d36dbe-f563-187a-ec16-df4b051ae204@yandex.ru> (Dmitry Gutov's message of "Tue, 27 Feb 2018 03:54:55 +0200") Message-ID: <87efl6smxb.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) > On that subject: why did we make next-error-last-buffer always buffer-local? next-error-last-buffer is buffer-local to keep the reference to the parent buffer used to navigate to the current buffer, so the next call of next-buffer will use the same parent buffer to continue navigation from it. This works well in most cases except the case of xref buffers. Below is the explanation for code from next-error with added remarks: (defun next-error (&optional arg reset) (let ((buffer (next-error-find-buffer))) (when buffer (with-current-buffer buffer Here the current buffer is *xref* (funcall next-error-function (prefix-numeric-value arg) reset) next-error-function should navigate from *xref* to another buffer and change the current-buffer to the navigated buffer, e.g. ChangeLog.1. This works fine in most cases, for example when next-error-function is compilation-next-error-function, but fails when next-error-function is xref--next-error-function that switches to ChangeLog.1, but doesn't set the value current-buffer to ChangeLog.1. (setq next-error-last-buffer buffer) In normal cases this sets buffer-local next-error-last-buffer in the navigated buffer, e.g. ChangeLog.1 that should be the current buffer. But since xref--next-error-function doesn't set the right current buffer to ChangeLog.1, this sets buffer-local next-error-last-buffer in the wrong buffer, i.e. in *xref*. IOW, the value returned from (current-buffer) is wrong here after xref--next-error-function call. So the question is: in xref--next-error-function can we use code similar to what is used in compilation-next-error-function that works without problems? From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 27 21:14:05 2018 Received: (at 20489) by debbugs.gnu.org; 28 Feb 2018 02:14:05 +0000 Received: from localhost ([127.0.0.1]:36303 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eqrFt-00052f-7c for submit@debbugs.gnu.org; Tue, 27 Feb 2018 21:14:05 -0500 Received: from mail-wr0-f172.google.com ([209.85.128.172]:38560) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eqrFq-000524-Um for 20489@debbugs.gnu.org; Tue, 27 Feb 2018 21:14:03 -0500 Received: by mail-wr0-f172.google.com with SMTP id n7so762898wrn.5 for <20489@debbugs.gnu.org>; Tue, 27 Feb 2018 18:14:02 -0800 (PST) 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=Vmn+g41tYxJjfq8WYOPsIqK/Ssqx4BCPC8vGdSclok0=; b=d9AdsVLZRHh6ykQ0eowTVSkLxhvd5sRkPWHPA+++eY7p4qusKNCBMJOvBNKLSVhRx2 2xkLbLRSclnxD/ib+unDZh4qmxV7j5saNUG4iPp9MK2ACbn9Km8hiq+7RmVUJbi7LXD/ h8+Pu12Lahhh1JGLnxteDg5RcbGXrA68BOn9cTQq9WLVXRNjfTmI+2EA7tDWEbayXggS g0jzKgWsuzUrieGxkkHo6YI1dne6QlcqeTF/3Z3rL3g3BtSTJi/G7P0J6KD0IUJxvq4h veuHasNrPb8FgU3G7mLN2FuEINr+TzH7+PsEQ08eMzM8Ed1dUvc2jKLaailgRrmhsaSR qP4Q== 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=Vmn+g41tYxJjfq8WYOPsIqK/Ssqx4BCPC8vGdSclok0=; b=dbT+wOLsolJqwO4a1a3GmtCPXnAK9hTUSz53vNGoM2zwBNupu96YcrvQIGJYM2oV0q 9mR92daolHWK3e/zsiGMYKD3fgDBGaMwepWarp9h5IXUvmESTVywoyAGwtuo9uy8v12W R65rT0X9s5mllgGe13urHBzW6PINBb6knH6XDK5gKwI6enp5ZgkGsgjhc1pq0GmcXn8B ddqtfXo9KVVh2nwP9FsrCz37VovkPVgPOCi0bmwvCKn3ic+sErDG0gxhAazzNi+xGPcV snlm9mqf5CJ+drVjTu7DMUqiH/mK8N7Du8Co5gNCFDaWsrXutXRe/rkMK+K+k5v1dP6J 0M8g== X-Gm-Message-State: APf1xPDpYr97YHXJgY9fqNvSCWDtaGKOaqOGGeAZv3tjYloEIwDDWBJg OOcMBLnBqsZHfpPL5UkdaXD41dPJ X-Google-Smtp-Source: AH8x2275M8XQEac8dwwfKHVSrAlMP7ik13lhiArDq56AB4vZZB3dfig6jhL/nlKWljPXSZgxY3r2lQ== X-Received: by 10.223.189.131 with SMTP id l3mr13983713wrh.140.1519784037004; Tue, 27 Feb 2018 18:13:57 -0800 (PST) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id b81sm825472wmb.36.2018.02.27.18.13.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Feb 2018 18:13:55 -0800 (PST) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason To: Juri Linkov References: <86wq0q602w.fsf@yandex.ru> <877ev36pmr.fsf@mail.linkov.net> <87sha1nbjy.fsf@mail.linkov.net> <23fd061a-9b83-742a-6083-6d2f090b8f22@yandex.ru> <81d36dbe-f563-187a-ec16-df4b051ae204@yandex.ru> <87efl6smxb.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: Date: Wed, 28 Feb 2018 04:13:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Thunderbird/59.0 MIME-Version: 1.0 In-Reply-To: <87efl6smxb.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) On 2/27/18 11:16 PM, Juri Linkov wrote: >> On that subject: why did we make next-error-last-buffer always buffer-local? > > next-error-last-buffer is buffer-local to keep the reference to the > parent buffer used to navigate to the current buffer, so the next call of > next-buffer will use the same parent buffer to continue navigation from it. Thank you for the reminder. Looking at the previous discussion, I wasn't fond of this design back then, and still think it's largely unnecessary complexity (it introduces implicit state, and in the situations that it can be useful in, the user will have to remember which windows came from which navigation). Anyway, I've fixed the current problem (see below), so this is a matter of opinion. If you still consider this feature to be important, I think ideally we'd abstract it away behind a new -function variable as well. This way, someone would also be able to implement window-local navigation relationship instead of buffer-local (you've mentioned this option before). > This works well in most cases except the case of xref buffers. > Below is the explanation for code from next-error with added remarks: > > (defun next-error (&optional arg reset) > (let ((buffer (next-error-find-buffer))) > (when buffer > (with-current-buffer buffer > > Here the current buffer is *xref* > > (funcall next-error-function (prefix-numeric-value arg) reset) > > next-error-function should navigate from *xref* to another buffer > and change the current-buffer to the navigated buffer, e.g. ChangeLog.1. If that's something next-error-function must do, let's document it better. Right now it only says "Function to use to find the next error in the current buffer" (how does one "find" an error?) and describes input arguments, but not the return value (which is luckily unused) or which buffer must be current, or which window selected at the end. > This works fine in most cases, for example when next-error-function is > compilation-next-error-function, but fails when next-error-function is > xref--next-error-function that switches to ChangeLog.1, but doesn't set > the value current-buffer to ChangeLog.1. > > (setq next-error-last-buffer buffer) > > In normal cases this sets buffer-local next-error-last-buffer in the > navigated buffer, e.g. ChangeLog.1 that should be the current buffer. > But since xref--next-error-function doesn't set the right current buffer > to ChangeLog.1, this sets buffer-local next-error-last-buffer in the wrong > buffer, i.e. in *xref*. IOW, the value returned from (current-buffer) > is wrong here after xref--next-error-function call. I see. > So the question is: in xref--next-error-function can we use code similar > to what is used in compilation-next-error-function that works without problems? You probably mean compilation-goto-locus (it contains the navigation part), but even so, it's not easy to tell which part you mean (the function does more than one would expect). In short, adapting that code is kind of difficult, but hopefully I found and fixed the problem in xref directly in 11c58c4fc495ea4f7bff52ca077fd3e4382aa900. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 28 12:33:38 2018 Received: (at 20489) by debbugs.gnu.org; 28 Feb 2018 17:33:38 +0000 Received: from localhost ([127.0.0.1]:37760 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1er5bm-0003rg-Ee for submit@debbugs.gnu.org; Wed, 28 Feb 2018 12:33:38 -0500 Received: from eggs.gnu.org ([208.118.235.92]:38826) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1er5bk-0003rU-Lg for 20489@debbugs.gnu.org; Wed, 28 Feb 2018 12:33:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1er5be-0000jq-DR for 20489@debbugs.gnu.org; Wed, 28 Feb 2018 12:33:31 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33590) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1er5bU-0000Zk-E1; Wed, 28 Feb 2018 12:33:20 -0500 Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1er5bS-0004zX-F6; Wed, 28 Feb 2018 12:33:19 -0500 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman To: Juri Linkov In-reply-to: <87efl6smxb.fsf@mail.linkov.net> (message from Juri Linkov on Tue, 27 Feb 2018 23:16:00 +0200) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason References: <86wq0q602w.fsf@yandex.ru> <877ev36pmr.fsf@mail.linkov.net> <87sha1nbjy.fsf@mail.linkov.net> <23fd061a-9b83-742a-6083-6d2f090b8f22@yandex.ru> <81d36dbe-f563-187a-ec16-df4b051ae204@yandex.ru> <87efl6smxb.fsf@mail.linkov.net> Message-Id: Date: Wed, 28 Feb 2018 12:33:18 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rms@gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > On that subject: why did we make next-error-last-buffer always buffer-local? > next-error-last-buffer is buffer-local to keep the reference to the > parent buffer used to navigate to the current buffer, so the next call of > next-buffer will use the same parent buffer to continue navigation from it. How about adding a comment to this effect? -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 28 16:45:36 2018 Received: (at 20489) by debbugs.gnu.org; 28 Feb 2018 21:45:36 +0000 Received: from localhost ([127.0.0.1]:37941 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1er9Xc-0007FY-41 for submit@debbugs.gnu.org; Wed, 28 Feb 2018 16:45:36 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:38331 helo=homiemail-a15.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1er9Xa-0007FQ-7p for 20489@debbugs.gnu.org; Wed, 28 Feb 2018 16:45:34 -0500 Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id AF0CA76C069; Wed, 28 Feb 2018 13:45:33 -0800 (PST) Received: from localhost.linkov.net (m91-129-98-215.cust.tele2.ee [91.129.98.215]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPSA id CA82176C065; Wed, 28 Feb 2018 13:45:32 -0800 (PST) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Organization: LINKOV.NET References: <86wq0q602w.fsf@yandex.ru> <877ev36pmr.fsf@mail.linkov.net> <87sha1nbjy.fsf@mail.linkov.net> <23fd061a-9b83-742a-6083-6d2f090b8f22@yandex.ru> <81d36dbe-f563-187a-ec16-df4b051ae204@yandex.ru> <87efl6smxb.fsf@mail.linkov.net> Date: Wed, 28 Feb 2018 23:17:25 +0200 In-Reply-To: (Dmitry Gutov's message of "Wed, 28 Feb 2018 04:13:54 +0200") Message-ID: <87zi3s7r16.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) > Anyway, I've fixed the current problem (see below), so this is a matter of > opinion. If you still consider this feature to be important, I think > ideally we'd abstract it away behind a new -function variable as well. Please clarify what do you have in mind. In what place in code such function could be called? > This way, someone would also be able to implement window-local navigation > relationship instead of buffer-local (you've mentioned this option before). Window-local navigation could be implemented by something like below. But maybe window-local specific code in next-error and next-error-internal could be abstracted away in a function that you proposed above? diff --git a/lisp/simple.el b/lisp/simple.el index edcb73c..c0da57d 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -174,6 +174,8 @@ next-error-find-buffer-function "Function called to find a `next-error' capable buffer." :type '(choice (const :tag "Single next-error capable buffer on selected frame" next-error-buffer-on-selected-frame) + (const :tag "Previous next-error capable buffer on selected window" + next-error-buffer-on-selected-window) (const :tag "No default" ignore) (function :tag "Other function")) :group 'next-error @@ -195,6 +197,12 @@ next-error-buffer-on-selected-frame (if (eq (length window-buffers) 1) (car window-buffers)))) +(defun next-error-buffer-on-selected-window (&optional _avoid-current + _extra-test-inclusive + _extra-test-exclusive) + "Return the previous next-error buffer used in the selected window." + (window-parameter nil 'next-error-buffer)) + (defun next-error-find-buffer (&optional avoid-current extra-test-inclusive extra-test-exclusive) @@ -285,6 +293,9 @@ next-error ;; Override possible change of next-error-last-buffer in next-error-function (setq next-error-last-buffer buffer) (setq-default next-error-last-buffer buffer) + (when (eq next-error-find-buffer-function + 'next-error-buffer-on-selected-window) + (set-window-parameter nil 'next-error-buffer buffer)) (when next-error-recenter (recenter next-error-recenter)) (message "%s error from %s" @@ -306,6 +317,9 @@ next-error-internal ;; Override possible change of next-error-last-buffer in next-error-function (setq next-error-last-buffer buffer) (setq-default next-error-last-buffer buffer) + (when (eq next-error-find-buffer-function + 'next-error-buffer-on-selected-window) + (set-window-parameter nil 'next-error-buffer buffer)) (when next-error-recenter (recenter next-error-recenter)) (message "Current error from %s" next-error-last-buffer) From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 28 16:45:41 2018 Received: (at 20489) by debbugs.gnu.org; 28 Feb 2018 21:45:42 +0000 Received: from localhost ([127.0.0.1]:37944 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1er9Xh-0007Fr-EF for submit@debbugs.gnu.org; Wed, 28 Feb 2018 16:45:41 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:38336 helo=homiemail-a15.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1er9Xd-0007Fg-QZ for 20489@debbugs.gnu.org; Wed, 28 Feb 2018 16:45:38 -0500 Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 488E076C06B; Wed, 28 Feb 2018 13:45:37 -0800 (PST) Received: from localhost.linkov.net (m91-129-98-215.cust.tele2.ee [91.129.98.215]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPSA id 6B66F76C065; Wed, 28 Feb 2018 13:45:36 -0800 (PST) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Organization: LINKOV.NET References: <86wq0q602w.fsf@yandex.ru> <877ev36pmr.fsf@mail.linkov.net> <87sha1nbjy.fsf@mail.linkov.net> <23fd061a-9b83-742a-6083-6d2f090b8f22@yandex.ru> <81d36dbe-f563-187a-ec16-df4b051ae204@yandex.ru> <87efl6smxb.fsf@mail.linkov.net> Date: Wed, 28 Feb 2018 23:25:02 +0200 In-Reply-To: (Dmitry Gutov's message of "Wed, 28 Feb 2018 04:13:54 +0200") Message-ID: <87efl46c41.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) > This way, someone would also be able to implement window-local navigati= on > relationship instead of buffer-local (you've mentioned this option befo= re). In addition to code sent in the previous message that should select the r= ight next-error capable buffer from the navigated buffer (e.g. on typing =E2=80= =98next-error=E2=80=99), for window-local navigation we also need to select the last used window (= e.g. typing RET on the list of matches), so all navigation will be in the same= window. (defun display-buffer-in-next-error-last-window (buffer alist) "Return a window used to display the last next-error buffer." (let* ((window (car (delq nil (mapcar (lambda (w) (when (and (local-variable-p 'next-error-la= st-buffer (window-buffer= w)) (eq (current-buffer) (buffer-local-value 'next-error-last-buffer (window-buffer w)))) w)) (window-list-1 nil 'nomini)))))) (when (window-live-p window) window (prog1 (window--display-buffer buffer window 'reuse alist) (unless (cdr (assq 'inhibit-switch-frame alist)) (window--maybe-raise-frame (window-frame window))))))) (push '("\\`\\*\\(compilation\\|grep\\|Occur\\)\\*\\'" display-buffer-in-next-error-last-window (inhibit-same-window . t)) display-buffer-from-alist) But this requires a feature that is not yet implemented, namely a customization like =E2=80=98display-buffer-from-alist=E2=80=99 to match= the source buffer name (that was the current buffer before navigation) instead of the target buffer (the buffer to display) like =E2=80=98display-buffer= -alist=E2=80=99 currently specifies. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 28 16:45:46 2018 Received: (at 20489) by debbugs.gnu.org; 28 Feb 2018 21:45:46 +0000 Received: from localhost ([127.0.0.1]:37947 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1er9Xl-0007G8-SL for submit@debbugs.gnu.org; Wed, 28 Feb 2018 16:45:46 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:38339 helo=homiemail-a15.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1er9Xh-0007Fq-Ci for 20489@debbugs.gnu.org; Wed, 28 Feb 2018 16:45:41 -0500 Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id D445376C06B; Wed, 28 Feb 2018 13:45:40 -0800 (PST) Received: from localhost.linkov.net (m91-129-98-215.cust.tele2.ee [91.129.98.215]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPSA id 0796F76C065; Wed, 28 Feb 2018 13:45:39 -0800 (PST) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Organization: LINKOV.NET References: <86wq0q602w.fsf@yandex.ru> <877ev36pmr.fsf@mail.linkov.net> <87sha1nbjy.fsf@mail.linkov.net> <23fd061a-9b83-742a-6083-6d2f090b8f22@yandex.ru> <81d36dbe-f563-187a-ec16-df4b051ae204@yandex.ru> <87efl6smxb.fsf@mail.linkov.net> Date: Wed, 28 Feb 2018 23:32:52 +0200 In-Reply-To: (Dmitry Gutov's message of "Wed, 28 Feb 2018 04:13:54 +0200") Message-ID: <87woyw4x6j.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) >> This works well in most cases except the case of xref buffers. >> Below is the explanation for code from next-error with added remarks: >> >> (defun next-error (&optional arg reset) >> (let ((buffer (next-error-find-buffer))) >> (when buffer >> (with-current-buffer buffer >> >> Here the current buffer is *xref* >> >> (funcall next-error-function (prefix-numeric-value arg) reset) >> >> next-error-function should navigate from *xref* to another buffer >> and change the current-buffer to the navigated buffer, e.g. ChangeLog.1. > > If that's something next-error-function must do, let's document it > better. Right now it only says "Function to use to find the next error in > the current buffer" (how does one "find" an error?) and describes input > arguments, but not the return value (which is luckily unused) or which > buffer must be current, or which window selected at the end. It's not yet clear which window should be selected at the end, please see the recent bug#30646. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 01 18:07:38 2018 Received: (at 20489) by debbugs.gnu.org; 1 Mar 2018 23:07:38 +0000 Received: from localhost ([127.0.0.1]:39840 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1erXIY-0004E9-72 for submit@debbugs.gnu.org; Thu, 01 Mar 2018 18:07:38 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:48326 helo=homiemail-a18.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1erXIW-0004E2-Gg for 20489@debbugs.gnu.org; Thu, 01 Mar 2018 18:07:36 -0500 Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id A4814258067; Thu, 1 Mar 2018 15:07:35 -0800 (PST) Received: from localhost.linkov.net (m91-129-98-215.cust.tele2.ee [91.129.98.215]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPSA id BEDDD258066; Thu, 1 Mar 2018 15:07:34 -0800 (PST) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Organization: LINKOV.NET References: <86wq0q602w.fsf@yandex.ru> <877ev36pmr.fsf@mail.linkov.net> <87sha1nbjy.fsf@mail.linkov.net> <23fd061a-9b83-742a-6083-6d2f090b8f22@yandex.ru> <81d36dbe-f563-187a-ec16-df4b051ae204@yandex.ru> <87efl6smxb.fsf@mail.linkov.net> <87efl46c41.fsf@mail.linkov.net> Date: Fri, 02 Mar 2018 00:58:10 +0200 In-Reply-To: <87efl46c41.fsf@mail.linkov.net> (Juri Linkov's message of "Wed, 28 Feb 2018 23:25:02 +0200") Message-ID: <87po4ne72v.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) > But this requires a feature that is not yet implemented, namely > a customization like =E2=80=98display-buffer-from-alist=E2=80=99 to mat= ch the source > buffer name (that was the current buffer before navigation) instead > of the target buffer (the buffer to display) like =E2=80=98display-buff= er-alist=E2=80=99 > currently specifies. Actually no new feature is needed, =E2=80=98display-buffer-alist=E2=80=99= is powerful enough, and this can be easily implemented with a few lines of code: 1. next-error for *xref* to reuse the same window: (push '(display-buffer-condition-next-error display-buffer-same-window) display-buffer-alist) (defun display-buffer-condition-next-error (_buffer-name _action) (memq this-command '(next-error previous-error))) 2. with e.g. two *grep* windows, typing RET to select the right locus win= dow: (push '(display-buffer-condition-from-next-error-buffer display-buffer-in-next-error-last-window (inhibit-same-window . t)) display-buffer-alist) (defun display-buffer-condition-from-next-error-buffer (_buffer-name _act= ion) (string-match-p "\\`\\*\\(compilation\\|grep\\|Occur\\)\\*\\(\\|<[0-9]+= >\\)\\'" (buffer-name (current-buffer)))) (defun display-buffer-in-next-error-last-window (buffer alist) "Return a window used to display the last next-error buffer." (let* ((window (car (delq nil (mapcar (lambda (w) (when (and (local-variable-p 'next-error-la= st-buffer (window-buffer= w)) (eq (current-buffer) (buffer-local-value 'next-error-last-buffer (window-buffer w)))) w)) (window-list-1 nil 'nomini)))))) (when (window-live-p window) window (prog1 (window--display-buffer buffer window 'reuse alist) (unless (cdr (assq 'inhibit-switch-frame alist)) (window--maybe-raise-frame (window-frame window))))))) From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 01 18:07:41 2018 Received: (at 20489) by debbugs.gnu.org; 1 Mar 2018 23:07:41 +0000 Received: from localhost ([127.0.0.1]:39843 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1erXIb-0004EP-EQ for submit@debbugs.gnu.org; Thu, 01 Mar 2018 18:07:41 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:48330 helo=homiemail-a18.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1erXIZ-0004EI-Oc for 20489@debbugs.gnu.org; Thu, 01 Mar 2018 18:07:40 -0500 Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id 5D0F5258068; Thu, 1 Mar 2018 15:07:39 -0800 (PST) Received: from localhost.linkov.net (m91-129-98-215.cust.tele2.ee [91.129.98.215]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPSA id 4D37E258066; Thu, 1 Mar 2018 15:07:38 -0800 (PST) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Organization: LINKOV.NET References: <86wq0q602w.fsf@yandex.ru> <877ev36pmr.fsf@mail.linkov.net> <87sha1nbjy.fsf@mail.linkov.net> <23fd061a-9b83-742a-6083-6d2f090b8f22@yandex.ru> <81d36dbe-f563-187a-ec16-df4b051ae204@yandex.ru> <87efl6smxb.fsf@mail.linkov.net> Date: Fri, 02 Mar 2018 01:04:10 +0200 In-Reply-To: (Dmitry Gutov's message of "Wed, 28 Feb 2018 04:13:54 +0200") Message-ID: <87efl3cs9g.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) >> So the question is: in xref--next-error-function can we use code similar >> to what is used in compilation-next-error-function that works without problems? > > You probably mean compilation-goto-locus (it contains the navigation part), > but even so, it's not easy to tell which part you mean (the function does > more than one would expect). > > In short, adapting that code is kind of difficult, but hopefully I found > and fixed the problem in xref directly > in 11c58c4fc495ea4f7bff52ca077fd3e4382aa900. While looking at this, I discovered more problems: 1. the same problem that you fixed for xref, also exists in occur: it doesn't set the right current-buffer for next-error. 2. also typing RET in *Occur* doesn't set next-error-last-buffer. Maybe we need to set it in occur-mode-goto-occurrence (but not in occur-next-error) 3. typing RET in *xref* should set next-error-last-buffer as well 4. Maybe these 2 lines needed to be added also to xref--xref-buffer-mode: (setq next-error-last-buffer buffer) (setq-default next-error-last-buffer buffer) like in next-error to set both buffer-local and global values. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 01 19:54:17 2018 Received: (at 20489) by debbugs.gnu.org; 2 Mar 2018 00:54:17 +0000 Received: from localhost ([127.0.0.1]:39883 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1erYxl-0006aS-FV for submit@debbugs.gnu.org; Thu, 01 Mar 2018 19:54:17 -0500 Received: from mail-wm0-f53.google.com ([74.125.82.53]:51418) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1erYxj-0006aE-FA for 20489@debbugs.gnu.org; Thu, 01 Mar 2018 19:54:15 -0500 Received: by mail-wm0-f53.google.com with SMTP id h21so222582wmd.1 for <20489@debbugs.gnu.org>; Thu, 01 Mar 2018 16:54:15 -0800 (PST) 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=j/rKOTNFKZswk0RvcP3NUcdSrj+5G6ILv1szSodo4oE=; b=IYougZ2MXaSFwyo+M3ihwn4RCRq0POYRO2wKnOVLxjUGfn4Fjcht5qTjvHeqCzJ4cl bbU8znyhUM29eOfFvUh96PPtocXKqoTrYQnBcYR+AN3KoK0I45y+SyAVBoDrX32oDs9E Z1BFU4MXaojygijpfUJu3YpMw+vAiAO8v2j0hL8G2zfVJYNjK1xEdN2QK4AYuu6RiAY0 vyKoFsB1KS9Hhuc9yzGDKNH77UWIZAgc6hmWmku7tKei9xOMo3Dw5iSKwVS1Ic5fYz6a jpKO3tRsvJPqux7satQ4/HFEk0fMK8LhmKBHcaDpCZW7IsQVgOljbHv4cuqk2SId5GZl 0//g== 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=j/rKOTNFKZswk0RvcP3NUcdSrj+5G6ILv1szSodo4oE=; b=KvWKAqsbUdJZLsbqmPIl2TgZjuECqAvz4eJzjkZJAK0K6hEoAdMZXUcrJM1fIEcmtE 8Kv4Cc7YeCkrfvYNeroZXc+Qxw3uoS6J/pgxonMT6kjXn5u9pgGtpaZJj1Ld5DGln6pQ yVxLUuzKuhB/ItUs0rUTgDDtXgMr+aK5eKqtI+twQ34/915Y81YS1HD9Cl02jtaE9d8y O3+XEGflby5vw36h1Of6vXEzyF8s2TjYMT2kHF0wIxQvN15HAaCAKzg6Iumf3d7eUrak 8GzguKh+mmUGuABeu6P8MkKxXxE9hp92XTKs2vMLAKaFQDu5VmbM4IwF0hqLKfmEJAfM Auow== X-Gm-Message-State: AElRT7EnXLJZfVuAXBxTo4CSg6A4+07JRaGc+W+6yLqKQxZld8qEpygR +w/tJHpXQKDend7QuiSLJNzM2V1e X-Google-Smtp-Source: AG47ELtRF4paabOrkpaDBOQ96nJvUGswy050I3mMbgG5U5Z/ZdUCxreidNcAGtJaXenr2GP0Obuwfg== X-Received: by 10.28.12.79 with SMTP id 76mr120478wmm.116.1519952049252; Thu, 01 Mar 2018 16:54:09 -0800 (PST) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id q9sm5630046wrf.11.2018.03.01.16.54.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Mar 2018 16:54:08 -0800 (PST) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason To: Juri Linkov References: <86wq0q602w.fsf@yandex.ru> <877ev36pmr.fsf@mail.linkov.net> <87sha1nbjy.fsf@mail.linkov.net> <23fd061a-9b83-742a-6083-6d2f090b8f22@yandex.ru> <81d36dbe-f563-187a-ec16-df4b051ae204@yandex.ru> <87efl6smxb.fsf@mail.linkov.net> <87woyw4x6j.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <1b7240c6-4d67-726b-9412-654672fbb7ff@yandex.ru> Date: Fri, 2 Mar 2018 02:54:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Thunderbird/59.0 MIME-Version: 1.0 In-Reply-To: <87woyw4x6j.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) On 2/28/18 11:32 PM, Juri Linkov wrote: >> If that's something next-error-function must do, let's document it >> better. Right now it only says "Function to use to find the next error in >> the current buffer" (how does one "find" an error?) and describes input >> arguments, but not the return value (which is luckily unused) or which >> buffer must be current, or which window selected at the end. > > It's not yet clear which window should be selected at the end, > please see the recent bug#30646. I'm not seeing that problem with xref, or Grep. Guessing it's a bug in occur-next-error, which as you noted in a more recent message, doesn't set the current buffer to the right value at the end. No need to change next-error for this. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 01 20:19:12 2018 Received: (at 20489) by debbugs.gnu.org; 2 Mar 2018 01:19:12 +0000 Received: from localhost ([127.0.0.1]:39894 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1erZLr-000798-RA for submit@debbugs.gnu.org; Thu, 01 Mar 2018 20:19:12 -0500 Received: from mail-wr0-f177.google.com ([209.85.128.177]:36000) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1erZLp-00078t-GW for 20489@debbugs.gnu.org; Thu, 01 Mar 2018 20:19:10 -0500 Received: by mail-wr0-f177.google.com with SMTP id v111so8493068wrb.3 for <20489@debbugs.gnu.org>; Thu, 01 Mar 2018 17:19:09 -0800 (PST) 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=5NWB793XoC5pj57+NjFEVfO3ok8+p8VSry2xwGNJ6fg=; b=hCNRi1WP/5RwMNN9fJGwj0l9Ybn+BgXswRl79wIbE8223GwEejz0LIOWdygm2vmyzX 3RI/Lr+v/J1fOdxxAq2Vu+YxoNB5ud+ZzGb1CyiIoYEGjoMSCRAY6dT9Jn5Bgdfet2DA uTby/OYyGpBRK+VL6S8gfCbQIlZPiUr7j7IUSSbp0pesdUismT1lYouOs0v7kFv5nqmn GnXR/RWH71eiJ+xgjGEw3msUjipicciX+5GjbzQ5Xj4ds+dIFoADyyyprMQVDqxTqEiO 0VyXoc9TQRVKn0oZFfhe0t3hvt0bXxnb+q7lMVKOLz8m98ij+GlSGlFoAfcmKiM+YGzS rrcw== 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=5NWB793XoC5pj57+NjFEVfO3ok8+p8VSry2xwGNJ6fg=; b=dJ/fvhtMB5QhLtWIaoDrYOCZdcsruMjMF8SiWC652iGX3uFLrjOlWFVx1My42EdxJ8 +Y0vTov+opMtLXEdJM36Wcgxopg7T+hMagYrXMI0z2niQt6TTNU72oZT8F5AYC85KreP ncOPZGztyM61jLUNVs3pprj/bPjSR5G3sYpXUnfUjV3AtEOAp0cDE2DTC5eZj7aB43Qp CqlqZVEvdyC0luyhyW2Fj/15l3sqXcrCtVa49tfLFS5PYk0vV/IotatZ7OLMuvqJO63l I0w61GIAE7CdhN/w7+BJaA2b1vl5jpWIE+VF7jkAnut9nL+DZQc/CdXc371N6+wzEHMn 8ddw== X-Gm-Message-State: APf1xPDthexyXMZ+YGaO/1MCaN/L5klP7YMgavhJr4Vpjs/PP8NswnmF 6LN3Nl4i4kMZv6JBPVUgrDLMZ8Ic X-Google-Smtp-Source: AG47ELug/PFY82u6XId3EUwI/ImFJLDn2/OyRaEGPSmwZa0U71NdyLJnAuC1wRXiwqZtjnOozZN+CQ== X-Received: by 10.223.157.205 with SMTP id q13mr3383485wre.266.1519953543465; Thu, 01 Mar 2018 17:19:03 -0800 (PST) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id q9sm5675717wrf.11.2018.03.01.17.19.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Mar 2018 17:19:02 -0800 (PST) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason To: Juri Linkov References: <86wq0q602w.fsf@yandex.ru> <877ev36pmr.fsf@mail.linkov.net> <87sha1nbjy.fsf@mail.linkov.net> <23fd061a-9b83-742a-6083-6d2f090b8f22@yandex.ru> <81d36dbe-f563-187a-ec16-df4b051ae204@yandex.ru> <87efl6smxb.fsf@mail.linkov.net> <87zi3s7r16.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: Date: Fri, 2 Mar 2018 03:19:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Thunderbird/59.0 MIME-Version: 1.0 In-Reply-To: <87zi3s7r16.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) On 2/28/18 11:17 PM, Juri Linkov wrote: >> Anyway, I've fixed the current problem (see below), so this is a matter of >> opinion. If you still consider this feature to be important, I think >> ideally we'd abstract it away behind a new -function variable as well. > > Please clarify what do you have in mind. In what place in code such > function could be called? Any place that contains (setq next-error-last-buffer buffer) (setq-default next-error-last-buffer buffer) now, would instead call (funcall next-error-save-last-buffer-function target-buf target-win) >> This way, someone would also be able to implement window-local navigation >> relationship instead of buffer-local (you've mentioned this option before). > > Window-local navigation could be implemented by something like below. > But maybe window-local specific code in next-error and next-error-internal > could be abstracted away in a function that you proposed above? Yes. next-error-save-last-buffer-function and next-error-find-buffer-function would have to be in sync (we'd have to somehow make sure the user will have to try hard to set them to incompatible values, at least if they do that via the Customize interface). Further, I think next-error-find-buffer-function will also have to encompass the item 2 in next-error-find-buffer, so that the alternative could supply the window-local value instead. Anyway, I'd really like to put a pin in both buffer-local and window-local values for now, because they both complicate the picture. Instead, could we address bug#30674 first? Personally, moving between errors and warnings in the current file using next/previous-error feels a lot more useful. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 01 20:26:27 2018 Received: (at 20489) by debbugs.gnu.org; 2 Mar 2018 01:26:27 +0000 Received: from localhost ([127.0.0.1]:39899 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1erZSt-0007JU-JV for submit@debbugs.gnu.org; Thu, 01 Mar 2018 20:26:27 -0500 Received: from mail-wm0-f51.google.com ([74.125.82.51]:51104) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1erZSs-0007JH-Bx for 20489@debbugs.gnu.org; Thu, 01 Mar 2018 20:26:26 -0500 Received: by mail-wm0-f51.google.com with SMTP id w128so315395wmw.0 for <20489@debbugs.gnu.org>; Thu, 01 Mar 2018 17:26:26 -0800 (PST) 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=aV5mkOZz1MAyXpX8/NMH9u3yOHYOHlWYxPhNcyeJT9M=; b=fUSRUTc9KzkAhVY7BT+mYX0KHfahMWvo0env8Q/8UozfQUum7f/horjXS+eE1hIjq+ Kwr6n2RPVjSDBQe/Z4F8tbG1WwjIlfzCIy0uaViQT86S6aYlLLVI2tS3BhT08uaGOe1M jo8Jo7mxGWzFEOqOsj1LTUFYwXiSTp305jCOAyQZKcRRpmUFgS0/T6a38z8jNkjrIlE0 fBsZcMH62bqCPol7c+0X9DcaOEMczv7u2NOr8KSRJo5KeLvX9dHLkC/TZztnVXJefhDx NdfDEZNIHu3raUVAo7wtkd2adw0oZZVDJPMcUdGjXXO8DXH0acJPATys+SUbrmyPVee3 Opiw== 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=aV5mkOZz1MAyXpX8/NMH9u3yOHYOHlWYxPhNcyeJT9M=; b=IiPzyCFGf/asQDBepxZgIKKFa+pOQlwNEwwqwIa8v6ssGCtDxchrCKIie5V9wOGIfB 8dL/cSdhx0M3XItgNRuUd5Itkn5WCqmyzONy0dwKlPEKpcys9ki/Kfh4cRz3FjHogw4/ BSDvM7JFhAmI87mUvFI29m/KflbDfL3g1YZuaw/Q0ZskEGgS8WgtIYdiH2j0edOn4Hlo 2hq1C9cQoWo1DQBSHVOnESu5ue1+kEo6ZoWx8KWg3BS/BdgMFSO+ds2sy2GZjUaDWaj7 1agBNkmIc+KA5Judxq+EVNIiLp1DeVHYIijcqr43iXVkGKNuzcYPguT/pcpLlaCqRZ4J l9Qg== X-Gm-Message-State: AElRT7E7f+Xj3NFq0g3nE1Da2+gpHf8Obda/ZtxtU2Y4ilBHOpu75hPL Vx/zO4+5oGcPDBg6muG2Oxx8cgBC X-Google-Smtp-Source: AG47ELsfXNPaK88Gq/clMeFe1jXiNR6bHti2VYgDQHJWJacI71mFy4iOev1LGNtQQZzTxcuK1rm0UA== X-Received: by 10.28.194.2 with SMTP id s2mr161627wmf.55.1519953980477; Thu, 01 Mar 2018 17:26:20 -0800 (PST) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id 35sm5375509wra.4.2018.03.01.17.26.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Mar 2018 17:26:19 -0800 (PST) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason To: Juri Linkov References: <86wq0q602w.fsf@yandex.ru> <877ev36pmr.fsf@mail.linkov.net> <87sha1nbjy.fsf@mail.linkov.net> <23fd061a-9b83-742a-6083-6d2f090b8f22@yandex.ru> <81d36dbe-f563-187a-ec16-df4b051ae204@yandex.ru> <87efl6smxb.fsf@mail.linkov.net> <87efl46c41.fsf@mail.linkov.net> <87po4ne72v.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: Date: Fri, 2 Mar 2018 03:26:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Thunderbird/59.0 MIME-Version: 1.0 In-Reply-To: <87po4ne72v.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) On 3/2/18 12:58 AM, Juri Linkov wrote: > Actually no new feature is needed, ‘display-buffer-alist’ is powerful enough, > and this can be easily implemented with a few lines of code: > > 1. next-error for *xref* to reuse the same window: > > ... > > 2. with e.g. two *grep* windows, typing RET to select the right locus window: > > ... Both of these sound pretty cool (and a fair distance over my head). I'm not sure they'd make a radical change to any of my workflows. In many ways, I feel window management is a bit of a lost cause in Emacs, and if anyone's going to fix that, next-error is probably not the place to start. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 01 20:30:32 2018 Received: (at 20489) by debbugs.gnu.org; 2 Mar 2018 01:30:32 +0000 Received: from localhost ([127.0.0.1]:39903 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1erZWq-0007Q9-5D for submit@debbugs.gnu.org; Thu, 01 Mar 2018 20:30:32 -0500 Received: from mail-wr0-f170.google.com ([209.85.128.170]:33309) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1erZWo-0007Pv-NR for 20489@debbugs.gnu.org; Thu, 01 Mar 2018 20:30:31 -0500 Received: by mail-wr0-f170.google.com with SMTP id v18so7860983wrv.0 for <20489@debbugs.gnu.org>; Thu, 01 Mar 2018 17:30:30 -0800 (PST) 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=Zy7B2rotG8aNHeZkfFfja8ngTu1EppLp75DzMvQOMxY=; b=Iv+eacFHX3JNStjG3Y8N83cOshsLRZ1Vpom6S6olZa6xSrFXNnJThXrKXlxiMy9Pbh zu/WxlA1k0c39/epo39eD/ZXeM76gqECHdhkiZPGNN+L+3UD4//0vv85dbkBMb8Ncv1/ lOeWG7d2ZOQJlTulYclJF2DUKsfukoawg1Vmso47c0Q5HlW4fRwO9+JggI/J16/rK7QL w6e1+Y0fVxjQWtlTAZFMGEAdlMd82pBVXWPkJ1wVo3CM7unZu8IjcsaU176cELpzR8R1 UsMUYYovL1npkjde1a1ER4CKSMZMfnFg1Pzvl5kkmwOZqfclCsWIot+zmFboJPWDHz/i HMUw== 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=Zy7B2rotG8aNHeZkfFfja8ngTu1EppLp75DzMvQOMxY=; b=Z137O2MGSn3qpmZbAYFgfHxmUVWkR3lSPs+rjU8FSFFaBXZsfaokyAERY2gseGHH5y IzNzwS5jxUDzVF+I4/HxUgv99a0ebrtOko479/saY3dQHjJ7hK9zWzVDH/7SC7vD3nH6 eLC61/ePJXeb2/RehMcBNxOCOP3lBXZsmGSjdv/fRK8rNTlN6TF+dooa4mLrQpbA02pH yr+S5mKNI2GcG3WY05CAC+O7Yg0B784EXuH1j1/DxZyaMiyoEH2xJ8zctDglfbwh4l4G g/RAZbisGRHvC4ZGbC7tPS9lOwomDJzuws8AwjtDYMMZTOq0VTK5KiFrfQzAXSauEPoy Bf3Q== X-Gm-Message-State: APf1xPCMbdFlS04eNmP5K5tPcB274ZSo/EEiYXCHsDUGBCNfwdy+bWFR HDtvR7MLwl6ektIGvGXzc2ahog7u X-Google-Smtp-Source: AG47ELuuSsy89u1wnqt63RoHIXkP8+mbo8nLvmKLgPGGQvbiSM0VwCbiMDDrFQ8b5CRvvUWpcISTxw== X-Received: by 10.223.161.77 with SMTP id r13mr3565968wrr.1.1519954224891; Thu, 01 Mar 2018 17:30:24 -0800 (PST) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id 43sm5667202wru.40.2018.03.01.17.30.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Mar 2018 17:30:24 -0800 (PST) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason To: Juri Linkov References: <86wq0q602w.fsf@yandex.ru> <877ev36pmr.fsf@mail.linkov.net> <87sha1nbjy.fsf@mail.linkov.net> <23fd061a-9b83-742a-6083-6d2f090b8f22@yandex.ru> <81d36dbe-f563-187a-ec16-df4b051ae204@yandex.ru> <87efl6smxb.fsf@mail.linkov.net> <87efl3cs9g.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <22ae650d-7a6f-d4b1-ef2e-71dcf5456f85@yandex.ru> Date: Fri, 2 Mar 2018 03:30:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Thunderbird/59.0 MIME-Version: 1.0 In-Reply-To: <87efl3cs9g.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) On 3/2/18 1:04 AM, Juri Linkov wrote: >> In short, adapting that code is kind of difficult, but hopefully I found >> and fixed the problem in xref directly >> in 11c58c4fc495ea4f7bff52ca077fd3e4382aa900. > > While looking at this, I discovered more problems: > > 1. the same problem that you fixed for xref, also exists in occur: > it doesn't set the right current-buffer for next-error. Sounds indeed like a bug. > 2. also typing RET in *Occur* doesn't set next-error-last-buffer. > Maybe we need to set it in occur-mode-goto-occurrence (but not in occur-next-error) Should it? Why? Hopefully, not just because Compilation does it (if we just want consistency, we can fix it in the other way, too). > 3. typing RET in *xref* should set next-error-last-buffer as well Same question. > 4. Maybe these 2 lines needed to be added also to xref--xref-buffer-mode: > > (setq next-error-last-buffer buffer) > (setq-default next-error-last-buffer buffer) > > like in next-error to set both buffer-local and global values. I guess so (but one of them is already there). TBH, seeing these two lines together still makes me cringe a little. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 06 18:07:41 2018 Received: (at 20489) by debbugs.gnu.org; 6 Mar 2018 23:07:41 +0000 Received: from localhost ([127.0.0.1]:48191 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1etLgL-0007Z9-6T for submit@debbugs.gnu.org; Tue, 06 Mar 2018 18:07:41 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:48828 helo=homiemail-a100.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1etLgJ-0007Z2-Or for 20489@debbugs.gnu.org; Tue, 06 Mar 2018 18:07:40 -0500 Received: from homiemail-a100.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a100.g.dreamhost.com (Postfix) with ESMTP id D4D3A31A078; Tue, 6 Mar 2018 15:07:38 -0800 (PST) Received: from localhost.linkov.net (m91-129-110-147.cust.tele2.ee [91.129.110.147]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by homiemail-a100.g.dreamhost.com (Postfix) with ESMTPSA id E696F31A07A; Tue, 6 Mar 2018 15:07:37 -0800 (PST) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Organization: LINKOV.NET References: <86wq0q602w.fsf@yandex.ru> <877ev36pmr.fsf@mail.linkov.net> <87sha1nbjy.fsf@mail.linkov.net> <23fd061a-9b83-742a-6083-6d2f090b8f22@yandex.ru> <81d36dbe-f563-187a-ec16-df4b051ae204@yandex.ru> <87efl6smxb.fsf@mail.linkov.net> <87zi3s7r16.fsf@mail.linkov.net> Date: Wed, 07 Mar 2018 00:17:53 +0200 In-Reply-To: (Dmitry Gutov's message of "Fri, 2 Mar 2018 03:19:01 +0200") Message-ID: <87vae8u8h2.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) >>> Anyway, I've fixed the current problem (see below), so this is a matter of >>> opinion. If you still consider this feature to be important, I think >>> ideally we'd abstract it away behind a new -function variable as well. >> >> Please clarify what do you have in mind. In what place in code such >> function could be called? > > Any place that contains > > (setq next-error-last-buffer buffer) > (setq-default next-error-last-buffer buffer) > > now, would instead call > > (funcall next-error-save-last-buffer-function target-buf target-win) But isn't it possible to do this in next-error-hook? It's called by run-hooks in the same place in next-error. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 06 18:07:44 2018 Received: (at 20489) by debbugs.gnu.org; 6 Mar 2018 23:07:44 +0000 Received: from localhost ([127.0.0.1]:48194 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1etLgO-0007ZQ-CU for submit@debbugs.gnu.org; Tue, 06 Mar 2018 18:07:44 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:48840 helo=homiemail-a100.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1etLgN-0007ZJ-0d for 20489@debbugs.gnu.org; Tue, 06 Mar 2018 18:07:43 -0500 Received: from homiemail-a100.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a100.g.dreamhost.com (Postfix) with ESMTP id 8C91131A078; Tue, 6 Mar 2018 15:07:42 -0800 (PST) Received: from localhost.linkov.net (m91-129-110-147.cust.tele2.ee [91.129.110.147]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by homiemail-a100.g.dreamhost.com (Postfix) with ESMTPSA id 9B4F831A073; Tue, 6 Mar 2018 15:07:41 -0800 (PST) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Organization: LINKOV.NET References: <86wq0q602w.fsf@yandex.ru> <877ev36pmr.fsf@mail.linkov.net> <87sha1nbjy.fsf@mail.linkov.net> <23fd061a-9b83-742a-6083-6d2f090b8f22@yandex.ru> <81d36dbe-f563-187a-ec16-df4b051ae204@yandex.ru> <87efl6smxb.fsf@mail.linkov.net> <87efl46c41.fsf@mail.linkov.net> <87po4ne72v.fsf@mail.linkov.net> Date: Wed, 07 Mar 2018 00:25:30 +0200 In-Reply-To: (Dmitry Gutov's message of "Fri, 2 Mar 2018 03:26:17 +0200") Message-ID: <87fu5cstjx.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) >> Actually no new feature is needed, =E2=80=98display-buffer-alist=E2=80= =99 is powerful enough, >> and this can be easily implemented with a few lines of code: >> >> 1. next-error for *xref* to reuse the same window: >> >> ... >> >> 2. with e.g. two *grep* windows, typing RET to select the right locus = window: >> >> ... > Both of these sound pretty cool (and a fair distance over my head). I'm= not > sure they'd make a radical change to any of my workflows. I created such complex solution to work around the peculiarities of xref: navigating with next-error displays every new opened buffer in another wi= ndow, thus eventually obscuring the *xref* buffer itself. Could you change xre= f to use the same logic as is used in compilation/grep that shows all next-= error places in the same window adjacent to the initial window with the list of compilation errors or grep hits that are always visible on the screen. > In many ways, I feel window management is a bit of a lost cause in > Emacs, and if anyone's going to fix that, next-error is probably not > the place to start. For better window management we need a higher declarative layer of configuration based on display-buffer-alist. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 07 09:09:12 2018 Received: (at 20489) by debbugs.gnu.org; 7 Mar 2018 14:09:12 +0000 Received: from localhost ([127.0.0.1]:48618 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1etZkl-0004tA-Pp for submit@debbugs.gnu.org; Wed, 07 Mar 2018 09:09:11 -0500 Received: from mail-wm0-f46.google.com ([74.125.82.46]:36808) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1etZkj-0004su-S5 for 20489@debbugs.gnu.org; Wed, 07 Mar 2018 09:09:10 -0500 Received: by mail-wm0-f46.google.com with SMTP id 188so4959877wme.1 for <20489@debbugs.gnu.org>; Wed, 07 Mar 2018 06:09:09 -0800 (PST) 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=MMCz85S0u9CGT6n9QVCk/H7apKGIOPatC2FwhmvDsJs=; b=ay0oAOBsRyCUEAyGrSw6CfiUoVOkP0R9k47cKpf1zGByxKeZWgHy8jOzCQXlgXIcXc ZKQWxaEZULPfcxYcsBe8GJycnmkHzg6qZpaf9+SSqQ8JN5VeWnBVHkdwki1BdB8DYoXC oE2tZoRFC4MaHmKukqzQ4RxMDmCjPM0cB8HVmwIFDU6dkoxdzMUCbbMlujZ0LNCjCXfQ wValGYoqe/yj5viDAeViYyFrbUZ9xd0p8GGnILckOPYCxbCp9zIzxyt14pwsbvNx8jm4 OQVixCzT5mIXjmr0SqzdT49bXvlx27X37dayk11FkIxZZVnwZovvd/z7RPkOfkPqfg18 31Zg== 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=MMCz85S0u9CGT6n9QVCk/H7apKGIOPatC2FwhmvDsJs=; b=iRB4YPyCODUJqrzk/iRebXCOZvBWBeTfJLEJqtqeLzfX/btInz6EDGfxp92hY7adoJ KGNmuOppddkwfspzxGw8+4e1O4VeD5M3Xsh3DVx7EwEHJDSuasOGRYzKIQBgL5GCgJz+ NUU6z/ncarFNh+ED8WaMFW/VgPC9ZX+boudEybbsc+sSO75/xhlocIzPxbDoVTPPXgNZ sJds+go+4c+FUHAmIDywde6BSmlkE0AtpRmjHtu8O8O9TYUsWcdfNl+eP3oxLX4bL0ex Dlj9YP75PmNVtek4G0nWKeIAceYirLsd2OikWxpwMW/FZ4iVS9uIkRmP/3NnZNyeWPvv 6dGg== X-Gm-Message-State: APf1xPDw9JRJuX3K/Qaa6X5WwDanLOU5ijeKZVcKzlgDHj362xR702Jj fpoE80d0CQNzTI6FEcKQp/Tm4o1b X-Google-Smtp-Source: AG47ELu9IP3Na2cESfg0ZdW/Xy32zc7LvU/r1HmQs3m8tjqdNPbvCd85qqqlJkdcdXVL6qTrR3Nk0w== X-Received: by 10.80.195.137 with SMTP id h9mr28591119edf.232.1520431743614; Wed, 07 Mar 2018 06:09:03 -0800 (PST) Received: from [192.168.0.174] ([212.50.99.193]) by smtp.googlemail.com with ESMTPSA id p20sm13187803eda.11.2018.03.07.06.09.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Mar 2018 06:09:02 -0800 (PST) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason To: Juri Linkov References: <86wq0q602w.fsf@yandex.ru> <877ev36pmr.fsf@mail.linkov.net> <87sha1nbjy.fsf@mail.linkov.net> <23fd061a-9b83-742a-6083-6d2f090b8f22@yandex.ru> <81d36dbe-f563-187a-ec16-df4b051ae204@yandex.ru> <87efl6smxb.fsf@mail.linkov.net> <87efl46c41.fsf@mail.linkov.net> <87po4ne72v.fsf@mail.linkov.net> <87fu5cstjx.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <083b9294-67e3-49a6-bb3b-3ab1ee4bfb83@yandex.ru> Date: Wed, 7 Mar 2018 16:08:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Thunderbird/59.0 MIME-Version: 1.0 In-Reply-To: <87fu5cstjx.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) On 3/7/18 12:25 AM, Juri Linkov wrote: > I created such complex solution to work around the peculiarities of xref: > navigating with next-error displays every new opened buffer in another window, > thus eventually obscuring the *xref* buffer itself. That's odd. I remember having such problems before, but not since Joao's efforts landed in 2a973edeacefcabb9fd8024188b7e167f0f9a9b6. > Could you change xref > to use the same logic as is used in compilation/grep that shows all next-error > places in the same window adjacent to the initial window with the list of > compilation errors or grep hits that are always visible on the screen. More generally, if such behavior is desirable by all next-error-function setups, shouldn't next-error somehow enforce it? Or provide helpers, at least. Anyway, it works fine for me in xref already. Do you have a repro scenario in Emacs master? From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 07 09:11:37 2018 Received: (at 20489) by debbugs.gnu.org; 7 Mar 2018 14:11:37 +0000 Received: from localhost ([127.0.0.1]:48623 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1etZn7-0004x2-5j for submit@debbugs.gnu.org; Wed, 07 Mar 2018 09:11:37 -0500 Received: from mail-wm0-f45.google.com ([74.125.82.45]:39083) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1etZn5-0004wp-1T for 20489@debbugs.gnu.org; Wed, 07 Mar 2018 09:11:35 -0500 Received: by mail-wm0-f45.google.com with SMTP id i3so4931641wmi.4 for <20489@debbugs.gnu.org>; Wed, 07 Mar 2018 06:11:35 -0800 (PST) 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=ZxNY5pCFgA1jxP31qKiDDBIVZSXThgPvmRCSiqHowdo=; b=foz4i75SzB5xAPgAvfAqTkSbP/ZWThXS8Oxlk2a6vGpQDp2YZATdB112vY5fN7XTbG 1HyJ6UPbBMd9hS9mPJLhlW+fdKSBV1a9ycVs6dBFzW+e/pvp3r0QoJWCK2ByjjjsgyFL tlNOGy3kWUKh2oE5eNnva2MAY6MH4YXR3woztpznLDKyXxKyOneQO/yq0XxpVfHeRiwW 4zMS42z9WyfwRatzMUOk4UVh9Jy4HzC6bqgAqMCqgx0tBsOKZNuNcz6E59CC3JbQ0N00 KvFaDkvKTL1BK4ePvtsxz1nEiMCE/DurLXkiIoUzeAaadkvQbnxJQ8GQB7NHqrKuTOXf IhOA== 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=ZxNY5pCFgA1jxP31qKiDDBIVZSXThgPvmRCSiqHowdo=; b=Xxy2QdximksLnCTT3k3R+ObUH7U1ZVSRZUq8ypn9Tnii1X8U4B6VYnQwiV8QC6J1SF UxTboV69jIIC+STiohHERcRAODUAXh3SfvwbgQzUC7+FlM+6vIdGyf7eLbBfO88wYLI5 t1Js6vzGsKlJov6MZr4nZq3bS7EFzql3DdwvnYGn7BSZZw1wo3GWK0IftU4heRRBaImB X3b3XzLhVtRysQjcS+IqJ/NuMFDLKDkO0RHQ6m2xMy/d33UUqeXoj9T2x4kSHoVek1pc SfjEV/vukXQgROw33h+ofR3cpMY9rtEeVOYy67J+95XEbQFxEzZjRbGvru59DJTaFt82 aO/g== X-Gm-Message-State: APf1xPA1yi0IKEDFTqFaNuLt3rJhP6bCX6b49TRNCiWaRd5oM4RFuk1B f4NWpNA43saxubVkwZ/jxBfMTYeF X-Google-Smtp-Source: AG47ELuQzjqdRiJ5vSzJOkkSqzMezKHUpZ2ucHlgACXd9Af+JiKsqv/j5w0dGnUjt+M0wdR0fgHSOA== X-Received: by 10.80.137.135 with SMTP id g7mr28199459edg.100.1520431889257; Wed, 07 Mar 2018 06:11:29 -0800 (PST) Received: from [192.168.0.174] ([212.50.99.193]) by smtp.googlemail.com with ESMTPSA id v15sm15712262eda.38.2018.03.07.06.11.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Mar 2018 06:11:27 -0800 (PST) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason To: Juri Linkov References: <86wq0q602w.fsf@yandex.ru> <877ev36pmr.fsf@mail.linkov.net> <87sha1nbjy.fsf@mail.linkov.net> <23fd061a-9b83-742a-6083-6d2f090b8f22@yandex.ru> <81d36dbe-f563-187a-ec16-df4b051ae204@yandex.ru> <87efl6smxb.fsf@mail.linkov.net> <87zi3s7r16.fsf@mail.linkov.net> <87vae8u8h2.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <2098d801-3877-d404-f66e-debefc0916b6@yandex.ru> Date: Wed, 7 Mar 2018 16:11:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Thunderbird/59.0 MIME-Version: 1.0 In-Reply-To: <87vae8u8h2.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) On 3/7/18 12:17 AM, Juri Linkov wrote: >>> Please clarify what do you have in mind. In what place in code such >>> function could be called? >> >> Any place that contains >> >> (setq next-error-last-buffer buffer) >> (setq-default next-error-last-buffer buffer) >> >> now, would instead call >> >> (funcall next-error-save-last-buffer-function target-buf target-win) > > But isn't it possible to do this in next-error-hook? > It's called by run-hooks in the same place in next-error. For one thing, next-error-select-buffer doesn't call next-error-hook. And there are other such places (e.g. like you were saying xref--xref-buffer-mode should set next-error-last-buffer similarly). Aside from that, why would we want to obscure this piece of logic behind a hook? From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 07 16:36:16 2018 Received: (at 20489) by debbugs.gnu.org; 7 Mar 2018 21:36:16 +0000 Received: from localhost ([127.0.0.1]:49939 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1etgjP-00047z-TZ for submit@debbugs.gnu.org; Wed, 07 Mar 2018 16:36:16 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:44426 helo=homiemail-a18.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1etgjM-00047j-UP for 20489@debbugs.gnu.org; Wed, 07 Mar 2018 16:36:13 -0500 Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id A8360258067; Wed, 7 Mar 2018 13:36:10 -0800 (PST) Received: from localhost.linkov.net (m91-129-110-147.cust.tele2.ee [91.129.110.147]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPSA id D0C01258066; Wed, 7 Mar 2018 13:36:09 -0800 (PST) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Organization: LINKOV.NET References: <86wq0q602w.fsf@yandex.ru> <877ev36pmr.fsf@mail.linkov.net> <87sha1nbjy.fsf@mail.linkov.net> <23fd061a-9b83-742a-6083-6d2f090b8f22@yandex.ru> <81d36dbe-f563-187a-ec16-df4b051ae204@yandex.ru> <87efl6smxb.fsf@mail.linkov.net> <87efl46c41.fsf@mail.linkov.net> <87po4ne72v.fsf@mail.linkov.net> <87fu5cstjx.fsf@mail.linkov.net> <083b9294-67e3-49a6-bb3b-3ab1ee4bfb83@yandex.ru> Date: Wed, 07 Mar 2018 23:03:07 +0200 In-Reply-To: <083b9294-67e3-49a6-bb3b-3ab1ee4bfb83@yandex.ru> (Dmitry Gutov's message of "Wed, 7 Mar 2018 16:08:59 +0200") Message-ID: <87fu5bzjhw.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) >> I created such complex solution to work around the peculiarities of xr= ef: >> navigating with next-error displays every new opened buffer in another= window, >> thus eventually obscuring the *xref* buffer itself. > > That's odd. I remember having such problems before, but not since Joao'= s > efforts landed in 2a973edeacefcabb9fd8024188b7e167f0f9a9b6. > [...] > Anyway, it works fine for me in xref already. Do you have a repro scena= rio > in Emacs master? Sorry, can't reproduce anymore, looks like already fixed by Jo=E3o. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 07 16:36:16 2018 Received: (at 20489) by debbugs.gnu.org; 7 Mar 2018 21:36:16 +0000 Received: from localhost ([127.0.0.1]:49941 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1etgjQ-000481-5j for submit@debbugs.gnu.org; Wed, 07 Mar 2018 16:36:16 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:44430 helo=homiemail-a18.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1etgjO-00047n-PF for 20489@debbugs.gnu.org; Wed, 07 Mar 2018 16:36:15 -0500 Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id 4242A258068; Wed, 7 Mar 2018 13:36:14 -0800 (PST) Received: from localhost.linkov.net (m91-129-110-147.cust.tele2.ee [91.129.110.147]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPSA id 6AAC1258066; Wed, 7 Mar 2018 13:36:13 -0800 (PST) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Organization: LINKOV.NET References: <86wq0q602w.fsf@yandex.ru> <877ev36pmr.fsf@mail.linkov.net> <87sha1nbjy.fsf@mail.linkov.net> <23fd061a-9b83-742a-6083-6d2f090b8f22@yandex.ru> <81d36dbe-f563-187a-ec16-df4b051ae204@yandex.ru> <87efl6smxb.fsf@mail.linkov.net> <87zi3s7r16.fsf@mail.linkov.net> <87vae8u8h2.fsf@mail.linkov.net> <2098d801-3877-d404-f66e-debefc0916b6@yandex.ru> Date: Wed, 07 Mar 2018 23:11:49 +0200 In-Reply-To: <2098d801-3877-d404-f66e-debefc0916b6@yandex.ru> (Dmitry Gutov's message of "Wed, 7 Mar 2018 16:11:25 +0200") Message-ID: <87po4fy4iy.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) >>>> Please clarify what do you have in mind. In what place in code such >>>> function could be called? >>> >>> Any place that contains >>> >>> (setq next-error-last-buffer buffer) >>> (setq-default next-error-last-buffer buffer) >>> >>> now, would instead call >>> >>> (funcall next-error-save-last-buffer-function target-buf target-wi= n) >> >> But isn't it possible to do this in next-error-hook? >> It's called by run-hooks in the same place in next-error. > > For one thing, next-error-select-buffer doesn't call next-error-hook. > > And there are other such places (e.g. like you were saying > xref--xref-buffer-mode should set next-error-last-buffer similarly). 3. And hooks are intended only for user customization. > Aside from that, why would we want to obscure this piece of logic behin= d > a hook? Instead of a hook I think it would be fine to define an =E2=80=9Cadvisabl= e=E2=80=9D function like Stefan asked to do for next-error-find-buffer-function to be able to put advices on it. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 12 18:08:32 2018 Received: (at 20489) by debbugs.gnu.org; 12 Mar 2018 22:08:32 +0000 Received: from localhost ([127.0.0.1]:57749 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1evVcO-0005Fl-2P for submit@debbugs.gnu.org; Mon, 12 Mar 2018 18:08:32 -0400 Received: from mail-wr0-f169.google.com ([209.85.128.169]:35562) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1evVcL-0005FW-01 for 20489@debbugs.gnu.org; Mon, 12 Mar 2018 18:08:29 -0400 Received: by mail-wr0-f169.google.com with SMTP id n12so6125770wra.2 for <20489@debbugs.gnu.org>; Mon, 12 Mar 2018 15:08:28 -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=TQ8Isxf5qoDvQa1ko/0q9/WvQp9JPdR8epV1nEgdp5w=; b=rXaFs+8RXhtslBbACV226dStGAmoss2iZUYxpwbW0OAPS4zF209NPiR5+ZUbrVJn6Y RY2WYordHie8EyJV5/3tSjwq7J20B5FXIQUEP0E4SnNqxXE4HbpgqEhk7Dn0IoiQlH15 yOCBl+Nk8qM4zhxnJ6GYWPzH5+keBEaeUg6QuZKDUwrRtjZw/ipqcMgr90qQNebO76O6 ubhWeXicpCgNQ+8/QIMh6px5Mpc0+X96GIHnK9KPXV9iJCfo05cMMCtbrmOfdjo1fQyJ EVRzac0XTCJRWKow3Cr/0KdUdjbqTX+bO+Z+rU36Z6cafmtEKFtInc+lFWHkioqVhkJf kWCw== 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=TQ8Isxf5qoDvQa1ko/0q9/WvQp9JPdR8epV1nEgdp5w=; b=jLuqdoBnlB1nfwk5afx6a9Ylrigcyg1x1Dm6Mjrvsg3FiSlfewWhgPpoE3mw3zpQeS 9bzHsbcPAGVQg85ue8WfHmDO+MyI2jYMWvx8JoDeqaqrgjOH9P30Byw2hEFuw72KTAoF wTRHlLYiE8addFnHNqd2zyrl2hGKuamqd3Po7yum927pTnGwOFC/0YLNDCJ9EVnkEUQa 0eWxVWIAW7Es+56EWaFuramrivaF7vHLM0C8sG3HtJNfTcN5PMtmRnhHvTs1oBe2YbkC vspxaaFBN9USAH/RN33H65pVQMbdhwWxkK4+43gM/lrOn5T6y9I9lqT/zuW2KCNiS9dM 97PQ== X-Gm-Message-State: AElRT7Hlt8KLma3J7WvR6jU/XAfvIY5ABqR3N+KyQYjbzdYV+3I8pikj g2LIFctaUpZEZGuUlwy3afYrgghS X-Google-Smtp-Source: AG47ELuBpm1wxylVvvd3qr5HEESho9HtlxuVduY3CMXSsolBoYQUzmruu1FsIbaXJ51T2AtdEd0J8g== X-Received: by 10.223.139.199 with SMTP id w7mr7036352wra.219.1520892503018; Mon, 12 Mar 2018 15:08:23 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id b8sm8290217wrf.29.2018.03.12.15.08.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Mar 2018 15:08:22 -0700 (PDT) Subject: Re: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason To: Juri Linkov References: <86wq0q602w.fsf@yandex.ru> <877ev36pmr.fsf@mail.linkov.net> <87sha1nbjy.fsf@mail.linkov.net> <23fd061a-9b83-742a-6083-6d2f090b8f22@yandex.ru> <81d36dbe-f563-187a-ec16-df4b051ae204@yandex.ru> <87efl6smxb.fsf@mail.linkov.net> <87zi3s7r16.fsf@mail.linkov.net> <87vae8u8h2.fsf@mail.linkov.net> <2098d801-3877-d404-f66e-debefc0916b6@yandex.ru> <87po4fy4iy.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: Date: Tue, 13 Mar 2018 00:08:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Thunderbird/59.0 MIME-Version: 1.0 In-Reply-To: <87po4fy4iy.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 20489 Cc: 20489@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) On 3/7/18 11:11 PM, Juri Linkov wrote: >> For one thing, next-error-select-buffer doesn't call next-error-hook. >> >> And there are other such places (e.g. like you were saying >> xref--xref-buffer-mode should set next-error-last-buffer similarly). > > 3. And hooks are intended only for user customization. Well, we do use them in the core as well. E.g. in define-globalized-minor-mode. >> Aside from that, why would we want to obscure this piece of logic behind >> a hook? > > Instead of a hook I think it would be fine to define an “advisable” function > like Stefan asked to do for next-error-find-buffer-function to be able > to put advices on it. next-error-find-buffer-function would advise it? How? I don't quite see the design. Also, next-error-save-last-buffer-function might be invoked before next-error-find-buffer-function is ever called. E.g. by compilation-start. From unknown Fri Jun 20 07:16:00 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 10 Apr 2018 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator