Stefan Kangas <stefankangas@HIDDEN>
to control <at> debbugs.gnu.org
.
Full text available.Received: (at 30674) by debbugs.gnu.org; 13 Mar 2018 23:24:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Mar 13 19:24:42 2018 Received: from localhost ([127.0.0.1]:60137 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1evtHd-0004V2-UG for submit <at> debbugs.gnu.org; Tue, 13 Mar 2018 19:24:42 -0400 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:43766 helo=homiemail-a18.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1evtHc-0004Us-2Q for 30674 <at> debbugs.gnu.org; Tue, 13 Mar 2018 19:24:40 -0400 Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id 060E1258067; Tue, 13 Mar 2018 16:24:39 -0700 (PDT) Received: from localhost.linkov.net (m91-129-107-5.cust.tele2.ee [91.129.107.5]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jurta@HIDDEN) by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPSA id 2F59B258066; Tue, 13 Mar 2018 16:24:37 -0700 (PDT) From: Juri Linkov <juri@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#30674: 27.0.50; flymake-mode should set next-error-function and (probably) next-error-last-buffer Organization: LINKOV.NET References: <15327428-85fd-5b2e-1878-2b5b3b538375@HIDDEN> <87a7vkrelc.fsf@HIDDEN> <618839ea-9fcb-70c2-4152-b0b5d2327083@HIDDEN> Date: Wed, 14 Mar 2018 00:23:45 +0200 In-Reply-To: <618839ea-9fcb-70c2-4152-b0b5d2327083@HIDDEN> (Dmitry Gutov's message of "Tue, 13 Mar 2018 02:43:56 +0200") Message-ID: <8737138sqm.fsf@HIDDEN> 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: 30674 Cc: 30674 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.0 (/) >> I guess to cancel such navigation is possible in at least three ways: >> doing window-quit on the *Occur* buffer, > > For this, next-error-find-buffer-function should be set to > #'next-error-buffer-on-selected-frame. Yes, and in this case you can see the clarity and predictability of this option: when the *Occur* buffer is visible on the selected frame, next-error will navigate the occur results as the user will expect. Hiding the window with the *Occur* buffer will switch navigation to Flymake warnings in the current buffer. This is what can be called WYSIWYG.
bug-gnu-emacs@HIDDEN
:bug#30674
; Package emacs
.
Full text available.Received: (at 30674) by debbugs.gnu.org; 13 Mar 2018 00:44:09 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 12 20:44:09 2018 Received: from localhost ([127.0.0.1]:57845 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1evY2y-0000rf-PP for submit <at> debbugs.gnu.org; Mon, 12 Mar 2018 20:44:09 -0400 Received: from mail-wr0-f175.google.com ([209.85.128.175]:43893) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1evY2x-0000rI-D2 for 30674 <at> debbugs.gnu.org; Mon, 12 Mar 2018 20:44:07 -0400 Received: by mail-wr0-f175.google.com with SMTP id o1so6057203wro.10 for <30674 <at> debbugs.gnu.org>; Mon, 12 Mar 2018 17:44:07 -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=idEAR41g1QLsDQStb3/kHHEeRrdYo9fbUxzUqENkrXM=; b=Pd0d8fw8Hnm/yz6WT4B7W/OtFsZDuK4qLNN+zPZ3m+YjHKYKsiVLS1nFxg7qK0zYXI kDAxIY+/p5jTFbWhJtyJ+6ykPbXPBoXZvSZX7dtjKMh0CqjO6+ufpOS3+jHeAZInG5/P C8pmyd9EKFp2Hd7RdAOjN29qgw+HWAaTsWJdDDyiVbvNyS0HEp0Cm63GrZmU32/J5in0 PSHtRHkJnZr2hdfLc79bhMGcXjFMGpUubxmMsL+NENlTky8Ug2OkusqL/PBmjFoFBqsK ZnjgwIXaX8HW47ySacASNlbdXRdsqkjln5urse5ECNipEhM4NrHLTHc7dG7d7+hKhGrd oqeQ== 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=idEAR41g1QLsDQStb3/kHHEeRrdYo9fbUxzUqENkrXM=; b=BNwmHVj2jGpGapFoIwNqXWzGQjJH8H0uC1rHZSUNil0Lsk1k546tADqAEChtDMLZGm Qsw9c82zGmrIm5jt9ax6MBEkyB//z3FXCo4QhFGn4EqtRQNhXHAQAjdrvMmU612JXReF /NvpvnJbIxqP3iS0qUE/5iWnwxXGgHAjRN/hq/9voJiRt6GWJV25UYDJJ+YxNyn9IRRU 4bRYyKYk9fRltWv/HtkBeg7D6D88NEq6Py+8gKgfxl+k8wU1h+WhJeoqXuUuf+jcExYo loybDeGxsRSoYWw/yMW7C97efyQuiS9bpbrKGN0YLqsqQ/GqC1+uOHIwF3IqLbYWAV6C 8D2w== X-Gm-Message-State: AElRT7H9qZZZVKek8WlFhgfBpsAVlkI1/Ugpiu30+DjgMN9Tb3KDV1kE MRPK3hi2IchRAqowaPGUhIZ0A5cY X-Google-Smtp-Source: AG47ELvxQrO3RnlmWNhe1Kvx7zscHh1BOnn9sXyZCBw92orZDfyzSPUgvE7Ze1wQX5BCeqt8dMpOIQ== X-Received: by 10.223.134.170 with SMTP id 39mr7346894wrx.221.1520901840883; Mon, 12 Mar 2018 17:44:00 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id y1sm7715623wrh.80.2018.03.12.17.43.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Mar 2018 17:43:59 -0700 (PDT) Subject: Re: bug#30674: 27.0.50; flymake-mode should set next-error-function and (probably) next-error-last-buffer To: Juri Linkov <juri@HIDDEN> References: <15327428-85fd-5b2e-1878-2b5b3b538375@HIDDEN> <87a7vkrelc.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <618839ea-9fcb-70c2-4152-b0b5d2327083@HIDDEN> Date: Tue, 13 Mar 2018 02:43:56 +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: <87a7vkrelc.fsf@HIDDEN> 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: 30674 Cc: 30674 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.5 (/) On 3/7/18 12:33 AM, Juri Linkov wrote: > I think it would be a natural fit into the next-error framework. How to > solve conflicts with other sources of next-error is an open question. > For example, after running ‘occur’ on the flymake-mode enabled buffer > next-error should continue navigating ‘occur’ hits. Right. That creates tradeoffs, which in turn push against the flexibility of next-error-find-buffer-function: it's going to more than aesthetic choice now. So I wonder which particular scheme, or schemes, people actually prefer. Or which they'd understand more quickly, just by experimenting (that might be the best default). > I guess to cancel > such navigation is possible in at least three ways: doing window-quit > on the *Occur* buffer, For this, next-error-find-buffer-function should be set to #'next-error-buffer-on-selected-frame. Or will we have a separate predicate function for whether to use the "local" next-error-function? > or using next-error-select-buffer selecting > the current buffer (instead of the *Occur* buffer), That might be too tedious, having to do that for every buffer-with-local-errors you switch to and try to edit (and fix errors/warnings in). However, if we special-case the nil value of next-error-last-buffer, it might not be so tedious: you switch away from the last Occur/Grep/etc buffer with one invocation, and go on editing multiple files. This is where buffer-local (or window-local) values of next-error-last-buffer might bring undesirable behavior: if one of those multiple files was another navigation target from an Occur/Grep/etc navigation, or if we switch to a window that was the target (in the window-local case), the user will need another next-error-select-buffer invocation, and they won't know that until their next-error call brings them somewhere unexpected (and only winner-mode will help undo that). There can be other approaches, such as when there's no visible global-next-error-capable buffers, and the current one is next-error-capable, use it, as long as there are local errors in the given direction, and then switch over to the global navigation. > or re-running flymake > on the buffer. That might be annoying: it runs every time a buffer is saved (and even right after it's visited if flymake-start-on-flymake-mode is non-nil). But hey, it can also be a fine approach, as long as flymake-start-on-flymake-mode is nil. Recalling that the first idea is to only use a global navigation as long as its buffer is visible, let's imagine that it's also so in this case. Grep tries very hard to stay visible. So, we run Grep, jump from it to a source file, start editing. Flymake runs, shows some warnings. If the user fixes them all, maybe switch back to the global navigation automatically; if not, select Grep's window and manually navigate to the next error in the list using one of its "buttons" (which also sets next-error-last-buffer). And if the navigation buffer is not visible, the user can call next-error-select-buffer anyway. This can work well, as long as the user understands what's going on.
bug-gnu-emacs@HIDDEN
:bug#30674
; Package emacs
.
Full text available.Received: (at 30674) by debbugs.gnu.org; 6 Mar 2018 23:07:47 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Mar 06 18:07:47 2018 Received: from localhost ([127.0.0.1]:48197 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1etLgR-0007Zg-KX for submit <at> debbugs.gnu.org; Tue, 06 Mar 2018 18:07:47 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:48854 helo=homiemail-a100.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <juri@HIDDEN>) id 1etLgQ-0007ZZ-JC for 30674 <at> debbugs.gnu.org; Tue, 06 Mar 2018 18:07:46 -0500 Received: from homiemail-a100.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a100.g.dreamhost.com (Postfix) with ESMTP id 2A9E031A078; Tue, 6 Mar 2018 15:07:46 -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@HIDDEN) by homiemail-a100.g.dreamhost.com (Postfix) with ESMTPSA id 4A91B31A075; Tue, 6 Mar 2018 15:07:45 -0800 (PST) From: Juri Linkov <juri@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#30674: 27.0.50; flymake-mode should set next-error-function and (probably) next-error-last-buffer Organization: LINKOV.NET References: <15327428-85fd-5b2e-1878-2b5b3b538375@HIDDEN> Date: Wed, 07 Mar 2018 00:33:59 +0200 In-Reply-To: <15327428-85fd-5b2e-1878-2b5b3b538375@HIDDEN> (Dmitry Gutov's message of "Fri, 2 Mar 2018 03:15:26 +0200") Message-ID: <87a7vkrelc.fsf@HIDDEN> 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: 30674 Cc: 30674 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.0 (/) > Considering the names and docstrings of next-error and previous-error, = I > think it's quite reasonable to expect to be able to navigate the Flymak= e > diagnostics with them. > > Jo=C3=A3o, was there a particular reason you decided against it? Can we > improve next-error somehow, for this to become more appealing? > > Juri, any thoughts? The foremost apparent difficulty is that virtually > any file-editing buffer can become a next-error capable buffer. Would > opening a new file interactively (with flymake-mode being turned on) > automatically change next-error-last-buffer? Would it change after > save-buffer (after which diagnostics are normally refreshed)? I think it would be a natural fit into the next-error framework. How to solve conflicts with other sources of next-error is an open question. For example, after running =E2=80=98occur=E2=80=99 on the flymake-mode en= abled buffer next-error should continue navigating =E2=80=98occur=E2=80=99 hits. I gu= ess to cancel such navigation is possible in at least three ways: doing window-quit on the *Occur* buffer, or using next-error-select-buffer selecting the current buffer (instead of the *Occur* buffer), or re-running flymake on the buffer.
bug-gnu-emacs@HIDDEN
:bug#30674
; Package emacs
.
Full text available.Received: (at submit) by debbugs.gnu.org; 2 Mar 2018 01:15:43 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 01 20:15:43 2018 Received: from localhost ([127.0.0.1]:39888 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1erZIV-00073f-Aa for submit <at> debbugs.gnu.org; Thu, 01 Mar 2018 20:15:43 -0500 Received: from eggs.gnu.org ([208.118.235.92]:58056) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1erZIT-00073T-FO for submit <at> debbugs.gnu.org; Thu, 01 Mar 2018 20:15:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <raaahh@HIDDEN>) id 1erZIN-0003RF-Hl for submit <at> debbugs.gnu.org; Thu, 01 Mar 2018 20:15:36 -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.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, FREEMAIL_REPLY,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:57777) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from <raaahh@HIDDEN>) id 1erZIN-0003R7-Dq for submit <at> debbugs.gnu.org; Thu, 01 Mar 2018 20:15:35 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49010) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <raaahh@HIDDEN>) id 1erZIM-0004oV-9h for bug-gnu-emacs@HIDDEN; Thu, 01 Mar 2018 20:15:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <raaahh@HIDDEN>) id 1erZIJ-0003NW-3p for bug-gnu-emacs@HIDDEN; Thu, 01 Mar 2018 20:15:34 -0500 Received: from mail-wm0-x22d.google.com ([2a00:1450:400c:c09::22d]:52890) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from <raaahh@HIDDEN>) id 1erZII-0003Md-St for bug-gnu-emacs@HIDDEN; Thu, 01 Mar 2018 20:15:31 -0500 Received: by mail-wm0-x22d.google.com with SMTP id t3so274921wmc.2 for <bug-gnu-emacs@HIDDEN>; Thu, 01 Mar 2018 17:15:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=GL5+pyts6qPGXWWos7RAv14jza4eb2fltChuXd/DZZ4=; b=gCHpGufRAGoN7ikQs28b6ZowRVfYCUKNn/kWcPPD3rGBW44mqVkwKq5LmOJOqUO6Tv SPMcA99O9AX6nkEtFzWPBL9APL05mZHuNg2E976rbwTuJzkaaQFFyNeb7NJ/yYY4s4Sl tWqDwIn2rppJ/Q9tHsm7baOOPfSvctd2hoqSF2kk77DI0x/VOBcIQrMlqbEMkngY0ZuM VEAYvmakreJ7RAM7o7oIbro+hSpfaEu2u4fLBt24Qpu1xHmjexk4Mo4pECua13ZcgeQb LUCxbCQgYRl2pwaecSS06MxshFlIMXUw2UdXogYDDaUT1ZSfw/Cl4C4gQzFTGywHuzxq 3MpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:to:from:subject:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=GL5+pyts6qPGXWWos7RAv14jza4eb2fltChuXd/DZZ4=; b=mQGrnfP97mlauFEbpsJZmfrJ+m/yt3gvnBjWaRZsNm2TQ4Rjq/QZoSIVdyGWrjVcX6 gh/gFFzWPF9l2ie+2Zn3Hv1Hg1ir3+46vkSR/kRMnq2kuC239K5LKQXUuwaiGs1dJWdb vblycWnaxlnq5KG51XyytV83792O0WQHw4hma44UNMsI5XFlleHCL1YsqMlrutL0s49L X6HiGYGqreOvgU1KR1XHgBU4UXDBv/0GepOMRb2bliaJYKtuv55TsH4IpjuVZG4fpGZP YG+v7/GnBXyTOSV3q19eOc+5MsyBEEddIz1WV3x6o2rwSKz+4hNGQDDbrvekDnZWECqT CWZw== X-Gm-Message-State: AElRT7F8522SVTb1RTa2KBkDkab6vWZXNw+CMEModzymkRGgWUCp3pNx eC2SP+X2cCQGZw2yGWyvjZQs6hLP X-Google-Smtp-Source: AG47ELutVUtPqH0RBLx1HCAh+ORS3bRvZmLdDzZ13LJXhiDE2uBy/b6YWEH4Up32EQ1r1bkjj8yisg== X-Received: by 10.28.27.194 with SMTP id b185mr155715wmb.102.1519953328966; Thu, 01 Mar 2018 17:15:28 -0800 (PST) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id d5sm273715wma.18.2018.03.01.17.15.27 for <bug-gnu-emacs@HIDDEN> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Mar 2018 17:15:27 -0800 (PST) To: bug-gnu-emacs@HIDDEN From: Dmitry Gutov <dgutov@HIDDEN> Subject: 27.0.50; flymake-mode should set next-error-function and (probably) next-error-last-buffer Message-ID: <15327428-85fd-5b2e-1878-2b5b3b538375@HIDDEN> Date: Fri, 2 Mar 2018 03:15:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Thunderbird/59.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.5 (---) X-Debbugs-CC: joaotavora@HIDDEN X-Debbugs-CC: juri@HIDDEN Considering the names and docstrings of next-error and previous-error, I think it's quite reasonable to expect to be able to navigate the Flymake diagnostics with them. João, was there a particular reason you decided against it? Can we improve next-error somehow, for this to become more appealing? Juri, any thoughts? The foremost apparent difficulty is that virtually any file-editing buffer can become a next-error capable buffer. Would opening a new file interactively (with flymake-mode being turned on) automatically change next-error-last-buffer? Would it change after save-buffer (after which diagnostics are normally refreshed)?
Dmitry Gutov <dgutov@HIDDEN>
:juri@HIDDEN, bug-gnu-emacs@HIDDEN
.
Full text available.juri@HIDDEN, bug-gnu-emacs@HIDDEN
:bug#30674
; Package emacs
.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.