From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 27 21:51:22 2020 Received: (at submit) by debbugs.gnu.org; 28 Apr 2020 01:51:23 +0000 Received: from localhost ([127.0.0.1]:38456 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTFP8-0003kM-Kk for submit@debbugs.gnu.org; Mon, 27 Apr 2020 21:51:22 -0400 Received: from lists.gnu.org ([209.51.188.17]:45472) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTFP6-0003kC-IV for submit@debbugs.gnu.org; Mon, 27 Apr 2020 21:51:20 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36620) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jTFP5-0000Gp-0D for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2020 21:51:20 -0400 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jTFP3-00051c-BZ for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2020 21:51:18 -0400 Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]:39918) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jTFP2-00050i-GQ for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2020 21:51:17 -0400 Received: by mail-wm1-x32c.google.com with SMTP id y24so1018907wma.4 for ; Mon, 27 Apr 2020 18:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=to:subject:from:autocrypt:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=5ZNjtThBuquH7YEhalrFFqdcipVcK/MKDCEPgaStrtg=; b=FQmPKg5gvaPd+PftSrIlvI73intBNNqPb67wszPmgrUX+phT3ixbvjs7Dagi5MDoZw Pb22t1FscXNAklkKGgmfXfJWz17CdeqLN6LwKtoZ+habU3iqrUnz3yEp0wj1zLHHH9l4 HTkfgN6oojNXAoyvYR7rc0tA20tVuqb0JCxRk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:subject:from:autocrypt:message-id:date :user-agent:mime-version:content-transfer-encoding:content-language; bh=5ZNjtThBuquH7YEhalrFFqdcipVcK/MKDCEPgaStrtg=; b=WSYyPiOLibBkSKcl12Utc/2Xz1AZ1ZJf/eODWwnEhcLC03+GxDw9DlUY0Dc45UGHGY 0UOXecBycUNnWdqsRIW23dg+6U8WuUiRkHFNzE1tFmEv8VR4VyQmICO96iHfF9Zl/j2V Zo8PO21IkzkuZ7mTzbRTCoZ4ZlHxPR5wIDOM051Io+2hOC7yN0U3nl9OXu9NkloWJ4MY 0NUAYYgMtwE7KuG1LNn1wUfw7DJb1AFoVUw5vq8cKZ240eU71iO01cykVU4pm8GDkSES irvTcDLMxmNOjH/2xJhbRTqWsSa1rMQDFVPLd7V7uzsNFyjG76Ze6xP5gwiR6AdQ4s4E 0JXA== X-Gm-Message-State: AGi0PuZLprlsGSkkRTlZjKvFMgujuDbaaXVHVD+vOg1M22JVvNY1JdwZ nL01H5tpZfY5dFBU/ehhsvOOY9Zciskgjw== X-Google-Smtp-Source: APiQypInSda6yIMzmrGtKQp3h0Sj83PnNa4OTqj111bDGkBoI4Z2b+Rg0CX96BSihA29F/e419Sq9g== X-Received: by 2002:a05:600c:2a52:: with SMTP id x18mr1646378wme.37.1588038672373; Mon, 27 Apr 2020 18:51:12 -0700 (PDT) Received: from [192.168.1.104] ([85.232.212.161]) by smtp.gmail.com with ESMTPSA id v16sm1246197wml.30.2020.04.27.18.51.10 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Apr 2020 18:51:11 -0700 (PDT) To: bug-gnu-emacs@gnu.org Subject: 27.0.91; next-error-select-buffer does not always behave as documented From: Trevor Spiteri Autocrypt: addr=tspiteri@ieee.org; prefer-encrypt=mutual; keydata= mQINBFcxvj8BEADgjJ0VPjUDQHNOO8+zw4txojpVRUbw3q4o3EaxHBSn3Nzl8qtp+OOzDe6n M4YQK6/ocBSJc+w3rFQzjmHxcCaJW8XJTaV27ot9r/wS6ucz34xFM6PJp2iIVT5SI5h1htIv ywJ9JlC+BiVN8X3QAvBJeQEGx48HNv+oYR/6mLvh/3cuyABBcmmsMBmG6ACpLJ6COhOXkl4r XB+gmVvt72HWy+zYyF/m1aMxQFakrAVWP3uslReCPR66bKiS9Hm77IyGGE5LOhccda0nFy5I kHqibst646jTQAu1EcpQZrnRXq7JOEOToM3Aj8GRI+T9+rKr1rf2RA7zdm0D9reUV+iPOEaI jFa4XT43BddM8mlV5pSQft2qoB3cTNHo1uJz8cQWTlmwcJiUEPVi5+5EtuDz/ovxSRIepNl4 zEHO5NNIqt2AZNLr+49UwWSmNi5NVfDxjXswCmFfUBFev14nxVz7jaPWUtD+htzkIUAoidlM a7tkeboP6j1UonX/ELwRTnWctpich8GCVaV+AaTViNpiJFw/wR3jN3rjE2AN5dgSgLEroInS M+U3a21c0pGarETx/JlpteZjWxvMMtdDr0MeLqVvSMxErvBB+0JhqkK9uAoAj8hCe6mweDao qIyUwPewbDD9Gcgxzd2ljbPcw1kOP8hFEjn+WWOcYY+rVu6+jQARAQABtCJUcmV2b3IgU3Bp dGVyaSA8dHNwaXRlcmlAaWVlZS5vcmc+iQJXBBMBCABBAhsjBQsJCAcCBhUICQoLAgQWAgMB Ah4BAheAAhkBFiEEG4iXMFy2k8rbrA4H9yiscA+IZu4FAlzwZ/UFCQ8kqzYACgkQ9yiscA+I Zu4u8w/+O5XMgDJwAKcpeO/ny93NR00YB5kMQlehvIgobuFnmt+bEQwZUuvVt+S5477ArJI2 XJiDOXh73qn0Yp/kqSdOf0lvteP3bNtRdJkl8X6oqBcI/hg8cdIzffSKR+yUduzo2TEkxhFQ n2cgEKYxzVmHgiEjVaPCt/NEqYNjRkPCmpaIlmQjzbsP6gCgM3B19GDz7Pp4aM+h/9K6FbT1 2LOpVfyJxn9DfTV0zHfNMJ1Rz6fJQmQ3pGm7s614f+I1HEoO5CQQTtJ8VSdUBD33P5QotaNF AdPZKpfIb/2w4VP/k2Sd6dJFJY2lWMKs0cxeyfDbaUyPVgjEZjW0msZXYLGS2BLgKWAMLBE2 MXRY+7Qria1+Jn+pCrlTbHAOhL/f30H0iunBm2Okkc39lZbrTjHwSqofag9xTGvqPlCa6sIB 0Lp7uqUvxezL+p0mz8XmZabKWxstKh9qOHcPXkeDtsfkfiv/Q7QHIUmPOdIcouMgs4atQPbC 47ko95wXZcamvSavuAVsZeAVfBI54R7U14gbSVaxHOr3a7qKFbDjoK+pm5+Sio2GuTzlls4Y YQ32GY/j7R94xiKMCnb4GSOnj8W995d5BVYU/DAV3xhJ4LrTTH2rF1c3jNV4MQBVI0u/wICN XM8uAXjHd2kHoHZKAJQhtk3Ns+aRZzKjmCX0/GJhIFy5Ag0EVzG+PwEQAOBQdUpKN9sAaIt9 x1qsF5/tetgh7LYkj1A5nBGl054x62kFcD8bj98nZG53I0UzFxD0ZLyhN08vg3cpg80d+24v hUJJk3O0MIRy3cDqPolxYpKjzf3fgt4Sl1+lZuXGFnBfh3UQgPmwC04zN8orqDdgwoJvyGtK wqxMxE5d3HCNIYZszOOc+jLE50wXqfkqd47AmaSRZVJWgfrinFkPEoU2496uLakXZzUJDBgY LTL8VIQ5qR/KwE8QMIsdWxUBIUC7paUS0qTy/Nyx2UlrfeunLy8pY8XtL6X2/IukpiMrVE4D Ay+3dIrlX0/uquRTX+4zEMptOkqDS3hSmpsxqVQAs0wAiQrbrurPq8FfNMjSWDYNXfVW33wc 5ROQolC+pCnwYvWSUUsXzXEAjYUa9k65S8KsYLFquDW8KS6f4LEbdUrhmj8cLow0jOvKEgpX VqEsTOGKJ7HxArW+gVNPSr2i5rIuM8wa6PtbAY8izebYPJYGzAv17sybTyBw6a8yUF1Gwfar Wsm0QnmZKXqy6AzNToV52kVuII6yMG9DBLq6SRgzQmFpXzxaaEdPZqzvJlZ/AX9GFNx2illA bCmwhLcAenVmMpO5KYRdD1aC80VyMPYLxFO896gUaYuphZkqjCkTReexFQPTxXZFoNL8rrMp /WUFh6XR/QJPuAD1OZWbABEBAAGJAjwEGAEIACYCGwwWIQQbiJcwXLaTytusDgf3KKxwD4hm 7gUCXPBn9gUJDySrNwAKCRD3KKxwD4hm7k4iD/9VGy6RHYN7HcxsF2fW9xbO91F9M57Kz9um C50LPItJPBCDq9vX7cCrk7Bg6ZIP0EqL/qRsfSabFemz8XV22skaPB/O6E9WGh+6geo5krNb eUvzeqIh6A6RMStiJYjEKwePAx+1xUgzi5PiK7y8MYRaQQly7cJEveLYsCh4GFf7hXDCGdxP Nt1hV3KeEipS2p2VdwTBHydmiUYdb1jURv5zeorUo8313R0zh4GJGPp+Gync1C2Y0vWTeCOY lpgcWfM8wXA6DVWC/49yQZCL+ryNOEbHqdTGzXc/F2EdcOVOvFG6jhg8aM8tYY9Iqj9D0P8i IAII64/OG+PQRwCZez6Z+riJzfJIfeXHw06BHI9COdSu7EyzKLZdacXsPLjZ+X/+IciGyFLq EmcZxoWWcDWr0kZ4JharhOLyewVbGcb/sqH8rWx666KSfNSEKRgcRxOGHYeVVspWl2EDDBBE vyy8W1tCsT5wxDb3yY72i5ESvLHmU4kgKZntizEPUvLqY7qESALO5+iZneXIwgRriAP1vNe5 dlV5KfR0BVdH60RxWCIZ8RIgrrrfPkn8ne122dkgfYdjqB516hG8EiNl48MlsgcV/r9VTqNR ocbCobKMDCU4ge53B1FfvB1fgKcquR6g73NNiFXc1rQAzTR0asNhUpWMpUJ+s2YkIGz+Qqdn xQ== Message-ID: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> Date: Tue, 28 Apr 2020 03:51:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::32c; envelope-from=tspiteri@ieee.org; helo=mail-wm1-x32c.google.com X-detected-operating-system: by eggs.gnu.org: Error: [-] PROGRAM ABORT : Malformed IPv6 address (bad octet value). Location : parse_addr6(), p0f-client.c:67 X-Received-From: 2a00:1450:4864:20::32c X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit 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: -2.3 (--) The next-error-select-buffer documentation states that “the selected buffer becomes the source of locations for the subsequent invocation of ‘next-error’ or ‘previous-error’.” However, it is not the case for the following: 1. Go in a fresh next-error capable buffer (not *grep*). 2. Grep for something. 3. M-x next-error-select-buffer *grep* 4. M-x next-error The buffer of 1 (not *grep*) is the source of locations instead of the expected *grep*. This is because although next-error-select-buffer sets the variable next-error-last-buffer, it is not used in this case: When next-error calls next-error-find-buffer, next-error-buffer has no buffer-local value yet, so condition 2. in next-error-find-buffer (that next-error-buffer has no buffer-local value and the current buffer is a next-error capable buffer) is true, and the function never even checks next-error-last-buffer. In GNU Emacs 27.0.91 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.13, cairo version 1.16.0) of 2020-04-23 built on desktop Repository revision: ba6104d1e8db4e8db2f12acaebf092ef579c6632 Repository branch: emacs-27 From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 28 07:42:07 2020 Received: (at submit) by debbugs.gnu.org; 28 Apr 2020 11:42:07 +0000 Received: from localhost ([127.0.0.1]:39177 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTOcp-0006TO-8H for submit@debbugs.gnu.org; Tue, 28 Apr 2020 07:42:07 -0400 Received: from lists.gnu.org ([209.51.188.17]:34569) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTOcn-0006TH-Vw for submit@debbugs.gnu.org; Tue, 28 Apr 2020 07:42:06 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51158) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jTOZO-0004rg-H4 for bug-gnu-emacs@gnu.org; Tue, 28 Apr 2020 07:42:05 -0400 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jTOYK-0002QA-DU for bug-gnu-emacs@gnu.org; Tue, 28 Apr 2020 07:38:34 -0400 Received: from mail-wr1-x432.google.com ([2a00:1450:4864:20::432]:46590) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jTOYJ-0002Q2-UK for bug-gnu-emacs@gnu.org; Tue, 28 Apr 2020 07:37:28 -0400 Received: by mail-wr1-x432.google.com with SMTP id f13so24189020wrm.13 for ; Tue, 28 Apr 2020 04:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=5ZIN8txhaGNsU7azsekz2v+nMlyHoK0RnhcTu/Q5jig=; b=SYjLt3N5CQE+NJQvpIsDLloUMKaPKjm2yQq2K/wnFbJAkZh+ecRGBQkMA99H/3yy7Q M8w2D2A5gAfBvW+uBfPw1vkuW/9PSuLdccyCaFGEtkcr/Ira7v6xn9iLP8Wd1+lyANOO vd/K3AEGdkPEhdEcpHaNaL7KbGoYcFMwYcTc0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=5ZIN8txhaGNsU7azsekz2v+nMlyHoK0RnhcTu/Q5jig=; b=PGq/YGoxiSmBdA5jojQeNsCdCV6OrWCjyfsIyGFgDyaQpHtLSUO1XW0+pAaFRBHUVi I+LWReGeqWZm/uSjvYXwY5tBY8w6I+eJapFbCgDKWngoacfy25oXUOnrJairrJjsVlWA zuAsO95d4eGv+QWSCDk28ACh3ESAec6hWdHpOk1R80q4rtlSp0MuEfgGKAJQDXYn0lBW QQeHsxRBJHatfqrVh5lPXWQcO6QvY38zMh9Kl9GLmt96bQOxDtIPd0EpRWkCxoRP5CVT uFn9cQSouy6S2FvHwiwudCMOVQYsYAqyvSCU0MlKAJlvsgwSDgpDiL3/y2MKP7knYPwQ iI5w== X-Gm-Message-State: AGi0PuYyu5PB7rSMiwEFtaGkPIIEemXCOFwkcYqjZX3ioYsKSo8YkguI LmUzIIqTU1e7Kfz8rgtDA72cg25QCOv3Yw== X-Google-Smtp-Source: APiQypLxQeD7oqrq1l1Zc14sVQXaD4j1jvNXhDBS7a9FPwz2ZuF7MY1qZcH3u7oaFvYxvoZRnGwqJQ== X-Received: by 2002:a5d:4e02:: with SMTP id p2mr35163817wrt.302.1588073844657; Tue, 28 Apr 2020 04:37:24 -0700 (PDT) Received: from [192.168.1.104] ([85.232.212.161]) by smtp.gmail.com with ESMTPSA id a67sm3071672wmc.30.2020.04.28.04.37.23 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Apr 2020 04:37:24 -0700 (PDT) Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented To: bug-gnu-emacs@gnu.org References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> From: Trevor Spiteri Autocrypt: addr=tspiteri@ieee.org; prefer-encrypt=mutual; keydata= mQINBFcxvj8BEADgjJ0VPjUDQHNOO8+zw4txojpVRUbw3q4o3EaxHBSn3Nzl8qtp+OOzDe6n M4YQK6/ocBSJc+w3rFQzjmHxcCaJW8XJTaV27ot9r/wS6ucz34xFM6PJp2iIVT5SI5h1htIv ywJ9JlC+BiVN8X3QAvBJeQEGx48HNv+oYR/6mLvh/3cuyABBcmmsMBmG6ACpLJ6COhOXkl4r XB+gmVvt72HWy+zYyF/m1aMxQFakrAVWP3uslReCPR66bKiS9Hm77IyGGE5LOhccda0nFy5I kHqibst646jTQAu1EcpQZrnRXq7JOEOToM3Aj8GRI+T9+rKr1rf2RA7zdm0D9reUV+iPOEaI jFa4XT43BddM8mlV5pSQft2qoB3cTNHo1uJz8cQWTlmwcJiUEPVi5+5EtuDz/ovxSRIepNl4 zEHO5NNIqt2AZNLr+49UwWSmNi5NVfDxjXswCmFfUBFev14nxVz7jaPWUtD+htzkIUAoidlM a7tkeboP6j1UonX/ELwRTnWctpich8GCVaV+AaTViNpiJFw/wR3jN3rjE2AN5dgSgLEroInS M+U3a21c0pGarETx/JlpteZjWxvMMtdDr0MeLqVvSMxErvBB+0JhqkK9uAoAj8hCe6mweDao qIyUwPewbDD9Gcgxzd2ljbPcw1kOP8hFEjn+WWOcYY+rVu6+jQARAQABtCJUcmV2b3IgU3Bp dGVyaSA8dHNwaXRlcmlAaWVlZS5vcmc+iQJXBBMBCABBAhsjBQsJCAcCBhUICQoLAgQWAgMB Ah4BAheAAhkBFiEEG4iXMFy2k8rbrA4H9yiscA+IZu4FAlzwZ/UFCQ8kqzYACgkQ9yiscA+I Zu4u8w/+O5XMgDJwAKcpeO/ny93NR00YB5kMQlehvIgobuFnmt+bEQwZUuvVt+S5477ArJI2 XJiDOXh73qn0Yp/kqSdOf0lvteP3bNtRdJkl8X6oqBcI/hg8cdIzffSKR+yUduzo2TEkxhFQ n2cgEKYxzVmHgiEjVaPCt/NEqYNjRkPCmpaIlmQjzbsP6gCgM3B19GDz7Pp4aM+h/9K6FbT1 2LOpVfyJxn9DfTV0zHfNMJ1Rz6fJQmQ3pGm7s614f+I1HEoO5CQQTtJ8VSdUBD33P5QotaNF AdPZKpfIb/2w4VP/k2Sd6dJFJY2lWMKs0cxeyfDbaUyPVgjEZjW0msZXYLGS2BLgKWAMLBE2 MXRY+7Qria1+Jn+pCrlTbHAOhL/f30H0iunBm2Okkc39lZbrTjHwSqofag9xTGvqPlCa6sIB 0Lp7uqUvxezL+p0mz8XmZabKWxstKh9qOHcPXkeDtsfkfiv/Q7QHIUmPOdIcouMgs4atQPbC 47ko95wXZcamvSavuAVsZeAVfBI54R7U14gbSVaxHOr3a7qKFbDjoK+pm5+Sio2GuTzlls4Y YQ32GY/j7R94xiKMCnb4GSOnj8W995d5BVYU/DAV3xhJ4LrTTH2rF1c3jNV4MQBVI0u/wICN XM8uAXjHd2kHoHZKAJQhtk3Ns+aRZzKjmCX0/GJhIFy5Ag0EVzG+PwEQAOBQdUpKN9sAaIt9 x1qsF5/tetgh7LYkj1A5nBGl054x62kFcD8bj98nZG53I0UzFxD0ZLyhN08vg3cpg80d+24v hUJJk3O0MIRy3cDqPolxYpKjzf3fgt4Sl1+lZuXGFnBfh3UQgPmwC04zN8orqDdgwoJvyGtK wqxMxE5d3HCNIYZszOOc+jLE50wXqfkqd47AmaSRZVJWgfrinFkPEoU2496uLakXZzUJDBgY LTL8VIQ5qR/KwE8QMIsdWxUBIUC7paUS0qTy/Nyx2UlrfeunLy8pY8XtL6X2/IukpiMrVE4D Ay+3dIrlX0/uquRTX+4zEMptOkqDS3hSmpsxqVQAs0wAiQrbrurPq8FfNMjSWDYNXfVW33wc 5ROQolC+pCnwYvWSUUsXzXEAjYUa9k65S8KsYLFquDW8KS6f4LEbdUrhmj8cLow0jOvKEgpX VqEsTOGKJ7HxArW+gVNPSr2i5rIuM8wa6PtbAY8izebYPJYGzAv17sybTyBw6a8yUF1Gwfar Wsm0QnmZKXqy6AzNToV52kVuII6yMG9DBLq6SRgzQmFpXzxaaEdPZqzvJlZ/AX9GFNx2illA bCmwhLcAenVmMpO5KYRdD1aC80VyMPYLxFO896gUaYuphZkqjCkTReexFQPTxXZFoNL8rrMp /WUFh6XR/QJPuAD1OZWbABEBAAGJAjwEGAEIACYCGwwWIQQbiJcwXLaTytusDgf3KKxwD4hm 7gUCXPBn9gUJDySrNwAKCRD3KKxwD4hm7k4iD/9VGy6RHYN7HcxsF2fW9xbO91F9M57Kz9um C50LPItJPBCDq9vX7cCrk7Bg6ZIP0EqL/qRsfSabFemz8XV22skaPB/O6E9WGh+6geo5krNb eUvzeqIh6A6RMStiJYjEKwePAx+1xUgzi5PiK7y8MYRaQQly7cJEveLYsCh4GFf7hXDCGdxP Nt1hV3KeEipS2p2VdwTBHydmiUYdb1jURv5zeorUo8313R0zh4GJGPp+Gync1C2Y0vWTeCOY lpgcWfM8wXA6DVWC/49yQZCL+ryNOEbHqdTGzXc/F2EdcOVOvFG6jhg8aM8tYY9Iqj9D0P8i IAII64/OG+PQRwCZez6Z+riJzfJIfeXHw06BHI9COdSu7EyzKLZdacXsPLjZ+X/+IciGyFLq EmcZxoWWcDWr0kZ4JharhOLyewVbGcb/sqH8rWx666KSfNSEKRgcRxOGHYeVVspWl2EDDBBE vyy8W1tCsT5wxDb3yY72i5ESvLHmU4kgKZntizEPUvLqY7qESALO5+iZneXIwgRriAP1vNe5 dlV5KfR0BVdH60RxWCIZ8RIgrrrfPkn8ne122dkgfYdjqB516hG8EiNl48MlsgcV/r9VTqNR ocbCobKMDCU4ge53B1FfvB1fgKcquR6g73NNiFXc1rQAzTR0asNhUpWMpUJ+s2YkIGz+Qqdn xQ== Message-ID: Date: Tue, 28 Apr 2020 13:37:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::432; envelope-from=tspiteri@ieee.org; helo=mail-wr1-x432.google.com X-detected-operating-system: by eggs.gnu.org: Error: [-] PROGRAM ABORT : Malformed IPv6 address (bad octet value). Location : parse_addr6(), p0f-client.c:67 X-Received-From: 2a00:1450:4864:20::432 X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit 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: -2.3 (--) On 28/04/2020 03:51, Trevor Spiteri wrote: > 1. Go in a fresh next-error capable buffer (not *grep*). > 2. Grep for something. > 3. M-x next-error-select-buffer *grep* > 4. M-x next-error And I just realized, this is also a regression from Emacs 26 if step 3 is skipped, as step 2 itself also sets next-error-last-buffer . From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 28 19:58:08 2020 Received: (at 40919) by debbugs.gnu.org; 28 Apr 2020 23:58:08 +0000 Received: from localhost ([127.0.0.1]:41902 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTa76-0000b1-DC for submit@debbugs.gnu.org; Tue, 28 Apr 2020 19:58:08 -0400 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:50513) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTa74-0000aL-Ec for 40919@debbugs.gnu.org; Tue, 28 Apr 2020 19:58:07 -0400 X-Originating-IP: 91.129.106.11 Received: from mail.gandi.net (m91-129-106-11.cust.tele2.ee [91.129.106.11]) (Authenticated sender: juri@linkov.net) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 2BDAB6000B; Tue, 28 Apr 2020 23:57:58 +0000 (UTC) From: Juri Linkov To: Trevor Spiteri Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented Organization: LINKOV.NET References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> Date: Wed, 29 Apr 2020 02:40:20 +0300 In-Reply-To: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> (Trevor Spiteri's message of "Tue, 28 Apr 2020 03:51:09 +0200") Message-ID: <87d07rmb6j.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40919 Cc: 40919@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.7 (-) > The next-error-select-buffer documentation states that “the selected > buffer becomes the source of locations for the subsequent invocation of > ‘next-error’ or ‘previous-error’.” However, it is not the case for the > following: > > 1. Go in a fresh next-error capable buffer (not *grep*). > 2. Grep for something. > 3. M-x next-error-select-buffer *grep* > 4. M-x next-error > > The buffer of 1 (not *grep*) is the source of locations instead of > the expected *grep*. > > This is because although next-error-select-buffer sets the variable > next-error-last-buffer, it is not used in this case: When next-error > calls next-error-find-buffer, next-error-buffer has no buffer-local > value yet, so condition 2. in next-error-find-buffer (that > next-error-buffer has no buffer-local value and the current buffer is a > next-error capable buffer) is true, and the function never even checks > next-error-last-buffer. Thanks for the report. Do you think the problem is in implementation, or only in documentation? IOW, do you think its behavior is correct, but the documentation should be fixed to describe more clearly what next-error was intended to do in this situation? From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 28 20:13:33 2020 Received: (at 40919) by debbugs.gnu.org; 29 Apr 2020 00:13:33 +0000 Received: from localhost ([127.0.0.1]:41947 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTaM0-00010r-O6 for submit@debbugs.gnu.org; Tue, 28 Apr 2020 20:13:33 -0400 Received: from mail-wr1-f52.google.com ([209.85.221.52]:34606) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTaLy-00010f-MO for 40919@debbugs.gnu.org; Tue, 28 Apr 2020 20:13:31 -0400 Received: by mail-wr1-f52.google.com with SMTP id j1so439273wrt.1 for <40919@debbugs.gnu.org>; Tue, 28 Apr 2020 17:13:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=to:cc:references:from:autocrypt:subject:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=2fxCjzE2urFjMNNh8giXqJF3eUpKSTeoaUvcUTtuL6E=; b=biQ+ZOB3+51uD23aRQlghHV4w3QuAl82ZKLwubT84kGapOVcO6GZQwmLkE6B5l4Krk Ok+fN8UciVrebJrT9vhaJZhfOis7mczUzDup/0o8d/1MZ8clmE5OC1pVd9CDyiOEBVRq ExAaumJVOyfbV1DCGtgMTZsDhHt8axKpTEJhc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:autocrypt:subject :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=2fxCjzE2urFjMNNh8giXqJF3eUpKSTeoaUvcUTtuL6E=; b=TCwCLZNCubvYldDwquXgXzM41EkIy1mCaW0XDddsIJsJatt6aeJXQIbw1wXI7kQgAE ykA4fJZrMjIUg/YM7tEEaTxTq8CFXpq3My+1lfbntshms2EDwUq1cZHVjAJDODa5Kgl9 CUeW2Dim8DyDQ7u/yW3msrqk5mYEqJpjJ1ATVhPc3gfsgoVbB/7qb28GOb6rEAK+xb/2 Au9EuweCmJ7BW0XFHlltU8tfAeqZWSD/BAI/dQLQYxbWTx1C9U5ipl2bwVVoIIHPEHWj 9635ZbGxT+i7iIPwXBv9q0Tw3L7xoPpOqAfPrL747YfFd9x1nFgS+FaIPTdilXsSJxlr AKhQ== X-Gm-Message-State: AGi0PuYDwVB6Uoj1eEHY5m86CFMxcVZXvaBenFRWwpWk5OHDfqxpc5rc LpnN/6JdoXvUlv9hTlZlfzYB9Z/sHQc7ww== X-Google-Smtp-Source: APiQypIpwTQ94xyCdqTxDCOYy+/jltahGjB67SL9FehB7wd9twO0qhxp9hNgq8XHZUTYOq3q0RLhUQ== X-Received: by 2002:a5d:6887:: with SMTP id h7mr35877329wru.365.1588119204312; Tue, 28 Apr 2020 17:13:24 -0700 (PDT) Received: from [192.168.1.104] ([85.232.212.161]) by smtp.gmail.com with ESMTPSA id p190sm5444143wmp.38.2020.04.28.17.13.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Apr 2020 17:13:23 -0700 (PDT) To: Juri Linkov References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> From: Trevor Spiteri Autocrypt: addr=tspiteri@ieee.org; prefer-encrypt=mutual; keydata= mQINBFcxvj8BEADgjJ0VPjUDQHNOO8+zw4txojpVRUbw3q4o3EaxHBSn3Nzl8qtp+OOzDe6n M4YQK6/ocBSJc+w3rFQzjmHxcCaJW8XJTaV27ot9r/wS6ucz34xFM6PJp2iIVT5SI5h1htIv ywJ9JlC+BiVN8X3QAvBJeQEGx48HNv+oYR/6mLvh/3cuyABBcmmsMBmG6ACpLJ6COhOXkl4r XB+gmVvt72HWy+zYyF/m1aMxQFakrAVWP3uslReCPR66bKiS9Hm77IyGGE5LOhccda0nFy5I kHqibst646jTQAu1EcpQZrnRXq7JOEOToM3Aj8GRI+T9+rKr1rf2RA7zdm0D9reUV+iPOEaI jFa4XT43BddM8mlV5pSQft2qoB3cTNHo1uJz8cQWTlmwcJiUEPVi5+5EtuDz/ovxSRIepNl4 zEHO5NNIqt2AZNLr+49UwWSmNi5NVfDxjXswCmFfUBFev14nxVz7jaPWUtD+htzkIUAoidlM a7tkeboP6j1UonX/ELwRTnWctpich8GCVaV+AaTViNpiJFw/wR3jN3rjE2AN5dgSgLEroInS M+U3a21c0pGarETx/JlpteZjWxvMMtdDr0MeLqVvSMxErvBB+0JhqkK9uAoAj8hCe6mweDao qIyUwPewbDD9Gcgxzd2ljbPcw1kOP8hFEjn+WWOcYY+rVu6+jQARAQABtCJUcmV2b3IgU3Bp dGVyaSA8dHNwaXRlcmlAaWVlZS5vcmc+iQJXBBMBCABBAhsjBQsJCAcCBhUICQoLAgQWAgMB Ah4BAheAAhkBFiEEG4iXMFy2k8rbrA4H9yiscA+IZu4FAlzwZ/UFCQ8kqzYACgkQ9yiscA+I Zu4u8w/+O5XMgDJwAKcpeO/ny93NR00YB5kMQlehvIgobuFnmt+bEQwZUuvVt+S5477ArJI2 XJiDOXh73qn0Yp/kqSdOf0lvteP3bNtRdJkl8X6oqBcI/hg8cdIzffSKR+yUduzo2TEkxhFQ n2cgEKYxzVmHgiEjVaPCt/NEqYNjRkPCmpaIlmQjzbsP6gCgM3B19GDz7Pp4aM+h/9K6FbT1 2LOpVfyJxn9DfTV0zHfNMJ1Rz6fJQmQ3pGm7s614f+I1HEoO5CQQTtJ8VSdUBD33P5QotaNF AdPZKpfIb/2w4VP/k2Sd6dJFJY2lWMKs0cxeyfDbaUyPVgjEZjW0msZXYLGS2BLgKWAMLBE2 MXRY+7Qria1+Jn+pCrlTbHAOhL/f30H0iunBm2Okkc39lZbrTjHwSqofag9xTGvqPlCa6sIB 0Lp7uqUvxezL+p0mz8XmZabKWxstKh9qOHcPXkeDtsfkfiv/Q7QHIUmPOdIcouMgs4atQPbC 47ko95wXZcamvSavuAVsZeAVfBI54R7U14gbSVaxHOr3a7qKFbDjoK+pm5+Sio2GuTzlls4Y YQ32GY/j7R94xiKMCnb4GSOnj8W995d5BVYU/DAV3xhJ4LrTTH2rF1c3jNV4MQBVI0u/wICN XM8uAXjHd2kHoHZKAJQhtk3Ns+aRZzKjmCX0/GJhIFy5Ag0EVzG+PwEQAOBQdUpKN9sAaIt9 x1qsF5/tetgh7LYkj1A5nBGl054x62kFcD8bj98nZG53I0UzFxD0ZLyhN08vg3cpg80d+24v hUJJk3O0MIRy3cDqPolxYpKjzf3fgt4Sl1+lZuXGFnBfh3UQgPmwC04zN8orqDdgwoJvyGtK wqxMxE5d3HCNIYZszOOc+jLE50wXqfkqd47AmaSRZVJWgfrinFkPEoU2496uLakXZzUJDBgY LTL8VIQ5qR/KwE8QMIsdWxUBIUC7paUS0qTy/Nyx2UlrfeunLy8pY8XtL6X2/IukpiMrVE4D Ay+3dIrlX0/uquRTX+4zEMptOkqDS3hSmpsxqVQAs0wAiQrbrurPq8FfNMjSWDYNXfVW33wc 5ROQolC+pCnwYvWSUUsXzXEAjYUa9k65S8KsYLFquDW8KS6f4LEbdUrhmj8cLow0jOvKEgpX VqEsTOGKJ7HxArW+gVNPSr2i5rIuM8wa6PtbAY8izebYPJYGzAv17sybTyBw6a8yUF1Gwfar Wsm0QnmZKXqy6AzNToV52kVuII6yMG9DBLq6SRgzQmFpXzxaaEdPZqzvJlZ/AX9GFNx2illA bCmwhLcAenVmMpO5KYRdD1aC80VyMPYLxFO896gUaYuphZkqjCkTReexFQPTxXZFoNL8rrMp /WUFh6XR/QJPuAD1OZWbABEBAAGJAjwEGAEIACYCGwwWIQQbiJcwXLaTytusDgf3KKxwD4hm 7gUCXPBn9gUJDySrNwAKCRD3KKxwD4hm7k4iD/9VGy6RHYN7HcxsF2fW9xbO91F9M57Kz9um C50LPItJPBCDq9vX7cCrk7Bg6ZIP0EqL/qRsfSabFemz8XV22skaPB/O6E9WGh+6geo5krNb eUvzeqIh6A6RMStiJYjEKwePAx+1xUgzi5PiK7y8MYRaQQly7cJEveLYsCh4GFf7hXDCGdxP Nt1hV3KeEipS2p2VdwTBHydmiUYdb1jURv5zeorUo8313R0zh4GJGPp+Gync1C2Y0vWTeCOY lpgcWfM8wXA6DVWC/49yQZCL+ryNOEbHqdTGzXc/F2EdcOVOvFG6jhg8aM8tYY9Iqj9D0P8i IAII64/OG+PQRwCZez6Z+riJzfJIfeXHw06BHI9COdSu7EyzKLZdacXsPLjZ+X/+IciGyFLq EmcZxoWWcDWr0kZ4JharhOLyewVbGcb/sqH8rWx666KSfNSEKRgcRxOGHYeVVspWl2EDDBBE vyy8W1tCsT5wxDb3yY72i5ESvLHmU4kgKZntizEPUvLqY7qESALO5+iZneXIwgRriAP1vNe5 dlV5KfR0BVdH60RxWCIZ8RIgrrrfPkn8ne122dkgfYdjqB516hG8EiNl48MlsgcV/r9VTqNR ocbCobKMDCU4ge53B1FfvB1fgKcquR6g73NNiFXc1rQAzTR0asNhUpWMpUJ+s2YkIGz+Qqdn xQ== Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented Message-ID: Date: Wed, 29 Apr 2020 02:13:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <87d07rmb6j.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 40919 Cc: 40919@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.0 (-) >> The next-error-select-buffer documentation states that =E2=80=9Cthe se= lected >> buffer becomes the source of locations for the subsequent invocation o= f >> =E2=80=98next-error=E2=80=99 or =E2=80=98previous-error=E2=80=99.=E2=80= =9D However, it is not the case for the >> following: >> >> 1. Go in a fresh next-error capable buffer (not *grep*). >> 2. Grep for something. >> 3. M-x next-error-select-buffer *grep* >> 4. M-x next-error >> >> The buffer of 1 (not *grep*) is the source of locations instead of >> the expected *grep*. >> >> This is because although next-error-select-buffer sets the variable >> next-error-last-buffer, it is not used in this case: When next-error >> calls next-error-find-buffer, next-error-buffer has no buffer-local >> value yet, so condition 2. in next-error-find-buffer (that >> next-error-buffer has no buffer-local value and the current buffer is = a >> next-error capable buffer) is true, and the function never even checks= >> next-error-last-buffer. > Thanks for the report. Do you think the problem is in implementation, > or only in documentation? IOW, do you think its behavior is correct, > but the documentation should be fixed to describe more clearly what > next-error was intended to do in this situation? I think the error is in the implementation. In fact I added a later comment to the bug report. > And I just realized, this is also a regression from Emacs 26 if step 3 > is skipped, as step 2 itself also sets next-error-last-buffer . As a use case, let's say I'm in a buffer that has next-error capabilities because of say flycheck, and I grep or compile; I want to start going through the new errors immediately. That is why compilation-start finishes=C2=A0 with (setq next-error-last-buffer outbuf= ) and that's how Emacs 26 works (without step 3 as next-error-select-buffer is new). In Emacs 27 not only does that break, but even using the new function has no effect. From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 29 16:59:21 2020 Received: (at 40919) by debbugs.gnu.org; 29 Apr 2020 20:59:21 +0000 Received: from localhost ([127.0.0.1]:44792 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTtnc-00073F-W2 for submit@debbugs.gnu.org; Wed, 29 Apr 2020 16:59:21 -0400 Received: from relay11.mail.gandi.net ([217.70.178.231]:57941) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTtnb-000730-Gc for 40919@debbugs.gnu.org; Wed, 29 Apr 2020 16:59:20 -0400 Received: from mail.gandi.net (m91-129-106-11.cust.tele2.ee [91.129.106.11]) (Authenticated sender: juri@linkov.net) by relay11.mail.gandi.net (Postfix) with ESMTPSA id 08B28100004; Wed, 29 Apr 2020 20:59:11 +0000 (UTC) From: Juri Linkov To: Trevor Spiteri Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented Organization: LINKOV.NET References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> Date: Wed, 29 Apr 2020 23:38:59 +0300 In-Reply-To: (Trevor Spiteri's message of "Wed, 29 Apr 2020 02:13:22 +0200") Message-ID: <87zhau5bfw.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40919 Cc: 40919@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.7 (-) > I think the error is in the implementation. Then I see no way other than for next-error-select-buffer to say: "the current buffer was visited from next-error-last-buffer". Yes, this is a lie, but a white lie with good intentions, so next-error-find-buffer will trust this misinformation and leave the buffer alone. Is this patch morally acceptable? diff --git a/lisp/simple.el b/lisp/simple.el index b5ba05426f..b5f148b7d5 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -379,7 +379,8 @@ 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 next-error-last-buffer buffer) + (setq next-error-buffer buffer)) (defalias 'goto-next-locus 'next-error) (defalias 'next-match 'next-error) From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 29 18:40:46 2020 Received: (at 40919) by debbugs.gnu.org; 29 Apr 2020 22:40:46 +0000 Received: from localhost ([127.0.0.1]:44848 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTvNl-00017D-Nl for submit@debbugs.gnu.org; Wed, 29 Apr 2020 18:40:46 -0400 Received: from mail-wr1-f41.google.com ([209.85.221.41]:33422) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jTvNj-00016z-MB for 40919@debbugs.gnu.org; Wed, 29 Apr 2020 18:40:44 -0400 Received: by mail-wr1-f41.google.com with SMTP id s10so4546519wrr.0 for <40919@debbugs.gnu.org>; Wed, 29 Apr 2020 15:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=subject:to:cc:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=Eq5vBIhLhYFFeV3qdCgqe8ne2Wmh9uEX9UqiSdAh/9c=; b=Q35ATVAJq5qGke+rk799L1Qr4nJPwkfjZ60kuUn4TQ4dLTpHDvLP4bKGRV4QloTb56 iviR6BtSRG3vQn9ah5hedp4I0L9mBc933b11fWeYqB/wavpzoPSdeAPBF7VGQw3yVLOT L6V/MqXRY2N00pHlpmVO66KxsBV4q6tX/1hv0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=Eq5vBIhLhYFFeV3qdCgqe8ne2Wmh9uEX9UqiSdAh/9c=; b=U3cCCQ/ynhOR8UhSlYf7+WU4sMvQyClnk2iEjz54VXNyQn/p7Bx1hCdr881PYLxo2/ Nv2Q/G18eeaziRGoO1zOFRRmzx/KqM7K5RJlUy3WQqUY+1bH6Z6DwH/oB0ZD59YLLiBk 695jquRS5v36HUYgoBi2IL1wYMA5P4G6MRTcyPU8DvCTubT94xOgo9OgdgQlODwaPnn1 ubZe7J5dlLL+VsMaHsIUfQ4P1OFCPzdzzzeDfA8eeiHdxWB8Qozjfhxv3BtkHtZD9dcm EVZVOfGuq2W8nnmSvOQpx07LCXLjqlQ8PnoDwYKK8SC1MpeiACGJr7usZ2V1ivaJZL/K NjEw== X-Gm-Message-State: AGi0PuZlA7vnamZcqKRLe3utHGJe4jGD1gyFz7UIC17v4/F6lUq03njE nln40oOdagVnJ0n5hYPytd6nUhanDAA= X-Google-Smtp-Source: APiQypLWWcoWfDaq9riMKjX4oKP5z/XPQB9rONgj9jFDHWmlDVDoiMD60VHnFXUlguo4kUx2sGnhPw== X-Received: by 2002:adf:e711:: with SMTP id c17mr216908wrm.334.1588200037383; Wed, 29 Apr 2020 15:40:37 -0700 (PDT) Received: from [192.168.1.104] ([85.232.212.161]) by smtp.gmail.com with ESMTPSA id g25sm9548194wmh.24.2020.04.29.15.40.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Apr 2020 15:40:36 -0700 (PDT) Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented To: Juri Linkov References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> From: Trevor Spiteri Autocrypt: addr=tspiteri@ieee.org; prefer-encrypt=mutual; keydata= mQINBFcxvj8BEADgjJ0VPjUDQHNOO8+zw4txojpVRUbw3q4o3EaxHBSn3Nzl8qtp+OOzDe6n M4YQK6/ocBSJc+w3rFQzjmHxcCaJW8XJTaV27ot9r/wS6ucz34xFM6PJp2iIVT5SI5h1htIv ywJ9JlC+BiVN8X3QAvBJeQEGx48HNv+oYR/6mLvh/3cuyABBcmmsMBmG6ACpLJ6COhOXkl4r XB+gmVvt72HWy+zYyF/m1aMxQFakrAVWP3uslReCPR66bKiS9Hm77IyGGE5LOhccda0nFy5I kHqibst646jTQAu1EcpQZrnRXq7JOEOToM3Aj8GRI+T9+rKr1rf2RA7zdm0D9reUV+iPOEaI jFa4XT43BddM8mlV5pSQft2qoB3cTNHo1uJz8cQWTlmwcJiUEPVi5+5EtuDz/ovxSRIepNl4 zEHO5NNIqt2AZNLr+49UwWSmNi5NVfDxjXswCmFfUBFev14nxVz7jaPWUtD+htzkIUAoidlM a7tkeboP6j1UonX/ELwRTnWctpich8GCVaV+AaTViNpiJFw/wR3jN3rjE2AN5dgSgLEroInS M+U3a21c0pGarETx/JlpteZjWxvMMtdDr0MeLqVvSMxErvBB+0JhqkK9uAoAj8hCe6mweDao qIyUwPewbDD9Gcgxzd2ljbPcw1kOP8hFEjn+WWOcYY+rVu6+jQARAQABtCJUcmV2b3IgU3Bp dGVyaSA8dHNwaXRlcmlAaWVlZS5vcmc+iQJXBBMBCABBAhsjBQsJCAcCBhUICQoLAgQWAgMB Ah4BAheAAhkBFiEEG4iXMFy2k8rbrA4H9yiscA+IZu4FAlzwZ/UFCQ8kqzYACgkQ9yiscA+I Zu4u8w/+O5XMgDJwAKcpeO/ny93NR00YB5kMQlehvIgobuFnmt+bEQwZUuvVt+S5477ArJI2 XJiDOXh73qn0Yp/kqSdOf0lvteP3bNtRdJkl8X6oqBcI/hg8cdIzffSKR+yUduzo2TEkxhFQ n2cgEKYxzVmHgiEjVaPCt/NEqYNjRkPCmpaIlmQjzbsP6gCgM3B19GDz7Pp4aM+h/9K6FbT1 2LOpVfyJxn9DfTV0zHfNMJ1Rz6fJQmQ3pGm7s614f+I1HEoO5CQQTtJ8VSdUBD33P5QotaNF AdPZKpfIb/2w4VP/k2Sd6dJFJY2lWMKs0cxeyfDbaUyPVgjEZjW0msZXYLGS2BLgKWAMLBE2 MXRY+7Qria1+Jn+pCrlTbHAOhL/f30H0iunBm2Okkc39lZbrTjHwSqofag9xTGvqPlCa6sIB 0Lp7uqUvxezL+p0mz8XmZabKWxstKh9qOHcPXkeDtsfkfiv/Q7QHIUmPOdIcouMgs4atQPbC 47ko95wXZcamvSavuAVsZeAVfBI54R7U14gbSVaxHOr3a7qKFbDjoK+pm5+Sio2GuTzlls4Y YQ32GY/j7R94xiKMCnb4GSOnj8W995d5BVYU/DAV3xhJ4LrTTH2rF1c3jNV4MQBVI0u/wICN XM8uAXjHd2kHoHZKAJQhtk3Ns+aRZzKjmCX0/GJhIFy5Ag0EVzG+PwEQAOBQdUpKN9sAaIt9 x1qsF5/tetgh7LYkj1A5nBGl054x62kFcD8bj98nZG53I0UzFxD0ZLyhN08vg3cpg80d+24v hUJJk3O0MIRy3cDqPolxYpKjzf3fgt4Sl1+lZuXGFnBfh3UQgPmwC04zN8orqDdgwoJvyGtK wqxMxE5d3HCNIYZszOOc+jLE50wXqfkqd47AmaSRZVJWgfrinFkPEoU2496uLakXZzUJDBgY LTL8VIQ5qR/KwE8QMIsdWxUBIUC7paUS0qTy/Nyx2UlrfeunLy8pY8XtL6X2/IukpiMrVE4D Ay+3dIrlX0/uquRTX+4zEMptOkqDS3hSmpsxqVQAs0wAiQrbrurPq8FfNMjSWDYNXfVW33wc 5ROQolC+pCnwYvWSUUsXzXEAjYUa9k65S8KsYLFquDW8KS6f4LEbdUrhmj8cLow0jOvKEgpX VqEsTOGKJ7HxArW+gVNPSr2i5rIuM8wa6PtbAY8izebYPJYGzAv17sybTyBw6a8yUF1Gwfar Wsm0QnmZKXqy6AzNToV52kVuII6yMG9DBLq6SRgzQmFpXzxaaEdPZqzvJlZ/AX9GFNx2illA bCmwhLcAenVmMpO5KYRdD1aC80VyMPYLxFO896gUaYuphZkqjCkTReexFQPTxXZFoNL8rrMp /WUFh6XR/QJPuAD1OZWbABEBAAGJAjwEGAEIACYCGwwWIQQbiJcwXLaTytusDgf3KKxwD4hm 7gUCXPBn9gUJDySrNwAKCRD3KKxwD4hm7k4iD/9VGy6RHYN7HcxsF2fW9xbO91F9M57Kz9um C50LPItJPBCDq9vX7cCrk7Bg6ZIP0EqL/qRsfSabFemz8XV22skaPB/O6E9WGh+6geo5krNb eUvzeqIh6A6RMStiJYjEKwePAx+1xUgzi5PiK7y8MYRaQQly7cJEveLYsCh4GFf7hXDCGdxP Nt1hV3KeEipS2p2VdwTBHydmiUYdb1jURv5zeorUo8313R0zh4GJGPp+Gync1C2Y0vWTeCOY lpgcWfM8wXA6DVWC/49yQZCL+ryNOEbHqdTGzXc/F2EdcOVOvFG6jhg8aM8tYY9Iqj9D0P8i IAII64/OG+PQRwCZez6Z+riJzfJIfeXHw06BHI9COdSu7EyzKLZdacXsPLjZ+X/+IciGyFLq EmcZxoWWcDWr0kZ4JharhOLyewVbGcb/sqH8rWx666KSfNSEKRgcRxOGHYeVVspWl2EDDBBE vyy8W1tCsT5wxDb3yY72i5ESvLHmU4kgKZntizEPUvLqY7qESALO5+iZneXIwgRriAP1vNe5 dlV5KfR0BVdH60RxWCIZ8RIgrrrfPkn8ne122dkgfYdjqB516hG8EiNl48MlsgcV/r9VTqNR ocbCobKMDCU4ge53B1FfvB1fgKcquR6g73NNiFXc1rQAzTR0asNhUpWMpUJ+s2YkIGz+Qqdn xQ== Message-ID: <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> Date: Thu, 30 Apr 2020 00:40:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <87zhau5bfw.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 40919 Cc: 40919@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.0 (-) On 29/04/2020 22:38, Juri Linkov wrote: >> I think the error is in the implementation. > Then I see no way other than for next-error-select-buffer to say: > "the current buffer was visited from next-error-last-buffer". > Yes, this is a lie, but a white lie with good intentions, so > next-error-find-buffer will trust this misinformation and leave > the buffer alone. Is this patch morally acceptable? > > diff --git a/lisp/simple.el b/lisp/simple.el > index b5ba05426f..b5f148b7d5 100644 > --- a/lisp/simple.el > +++ b/lisp/simple.el > @@ -379,7 +379,8 @@ 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 next-error-last-buffer buffer) > + (setq next-error-buffer buffer)) > > (defalias 'goto-next-locus 'next-error) > (defalias 'next-match 'next-error) > I think this would work for next-error-select-buffer. Then to fix the other issue about new compilations, compilation-start can be modified to use next-error-select-buffer. That way the change in compilation-start is morally unambiguous :) diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el index 455f181f50..41e77007c6 100644 --- a/lisp/progmodes/compile.el +++ b/lisp/progmodes/compile.el @@ -1910,7 +1910,7 @@ compilation-start      (goto-char (point-max))))        ;; Make it so the next C-x ` will use this buffer. -    (setq next-error-last-buffer outbuf))) +    (next-error-select-buffer outbuf)))    (defun compilation-set-window-height (window)    "Set the height of WINDOW according to `compilation-window-height'." From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 30 16:24:45 2020 Received: (at 40919) by debbugs.gnu.org; 30 Apr 2020 20:24:45 +0000 Received: from localhost ([127.0.0.1]:47777 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUFjh-0003rC-1B for submit@debbugs.gnu.org; Thu, 30 Apr 2020 16:24:45 -0400 Received: from relay12.mail.gandi.net ([217.70.178.232]:35781) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUFje-0003qv-HA for 40919@debbugs.gnu.org; Thu, 30 Apr 2020 16:24:43 -0400 Received: from mail.gandi.net (m91-129-106-11.cust.tele2.ee [91.129.106.11]) (Authenticated sender: juri@linkov.net) by relay12.mail.gandi.net (Postfix) with ESMTPSA id DB2F1200007; Thu, 30 Apr 2020 20:24:34 +0000 (UTC) From: Juri Linkov To: Trevor Spiteri Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented Organization: LINKOV.NET References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> Date: Thu, 30 Apr 2020 23:14:09 +0300 In-Reply-To: <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> (Trevor Spiteri's message of "Thu, 30 Apr 2020 00:40:35 +0200") Message-ID: <87bln8u3xq.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40919 Cc: 40919@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.7 (-) >> @@ -379,7 +379,8 @@ 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 next-error-last-buffer buffer) >> + (setq next-error-buffer buffer)) >> >> (defalias 'goto-next-locus 'next-error) >> (defalias 'next-match 'next-error) >> > I think this would work for next-error-select-buffer. Then to fix the > other issue about new compilations, compilation-start can be modified to > use next-error-select-buffer. That way the change in compilation-start > is morally unambiguous :) I'm not sure if this is morally right, because users might want to continue to navigate an old next-error buffer, even after creating a new next-error buffer. OTOH, by using next-error-select-buffer they explicitly say that they want to switch to the new navigation. Do you think it's right to implicitly assume the user's intention? We should base the decision not on precedence set by older versions, but on expectations of most users. > diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el > index 455f181f50..41e77007c6 100644 > --- a/lisp/progmodes/compile.el > +++ b/lisp/progmodes/compile.el > @@ -1910,7 +1910,7 @@ compilation-start > (goto-char (point-max)))) > > ;; Make it so the next C-x ` will use this buffer. > - (setq next-error-last-buffer outbuf))) > + (next-error-select-buffer outbuf))) > > (defun compilation-set-window-height (window) > "Set the height of WINDOW according to `compilation-window-height'." There are more places that set next-error-last-buffer: vc-git-grep, occur-1, xref.el... But I'm still not sure if this is a preferable behavior for most users. Maybe this needs a user option? From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 30 19:18:59 2020 Received: (at 40919) by debbugs.gnu.org; 30 Apr 2020 23:19:00 +0000 Received: from localhost ([127.0.0.1]:47909 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUISJ-0008F0-N0 for submit@debbugs.gnu.org; Thu, 30 Apr 2020 19:18:59 -0400 Received: from mail-wm1-f49.google.com ([209.85.128.49]:55312) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUISH-0008Ej-JL for 40919@debbugs.gnu.org; Thu, 30 Apr 2020 19:18:58 -0400 Received: by mail-wm1-f49.google.com with SMTP id e26so4093539wmk.5 for <40919@debbugs.gnu.org>; Thu, 30 Apr 2020 16:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=to:cc:references:from:autocrypt:subject:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=kcMgoRjd5H/smHp8gs4dSYGiPxAyAZHRh3jadAbwh2A=; b=VeP1isBQHk692wapsIqzoSobej7qV3jxqAcsrgSGvvypv5mgaEEOOfoZ5XoCG7HQjA 0v+nL4acyiltsJQpAtvp1pTRYl2BBu8N2V549dHiiRkSiGCqg65SRwBnA74GMu3Zh/AB 8vdk8pu7s70MfAyM4TylWw1SUndA99PeJiYno= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:autocrypt:subject :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=kcMgoRjd5H/smHp8gs4dSYGiPxAyAZHRh3jadAbwh2A=; b=MXUhkm14FK3ey1gT8DfuaPOqh/cmZfJ3MwITmQgbAxkJ7mVHLG0+aqkR104Pe2cp0q ZZ1xuWD87pOPByd6zXSB7US8Qoec3MDh2gSATovsu9eel/Jft3Od45L3EpTjeI3rNiTc QV6vY9JfesgrdY0jrRIUU6MDG4zoI5+qaSYsdb/LAkeLa8E2tootYUkqL6cEWx+5AOis IAUehyFdLNcxODedUV/Y9ZiROS/Re9a/CjkAEiX4lU4NirU2a7FOAv+Y4jdPOAikEzOj x0hivwMM4oNuxwLysmpRFI2K6LcDT/v5U0gvo5M11OuKbmHz7WKzU5GGPp4765TuEw7a oHIA== X-Gm-Message-State: AGi0PuaqYzw2IRhz9sS8T5ZNJlXqJfzHt+RO/Tc+9+tWJ0YkBkRzf8ac rmN/tZJHtO/xQQCYkOskWh5F6RQixdY= X-Google-Smtp-Source: APiQypJzQAdaF/7qPDmWNkR15oDnuR0f89MYbImes37sXaNZnqsGQmr9MIviLJekXrsHwLPU9+Q71A== X-Received: by 2002:a05:600c:24cf:: with SMTP id 15mr954913wmu.94.1588288731210; Thu, 30 Apr 2020 16:18:51 -0700 (PDT) Received: from [192.168.1.104] ([85.232.212.161]) by smtp.gmail.com with ESMTPSA id a9sm1459789wmm.38.2020.04.30.16.18.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Apr 2020 16:18:50 -0700 (PDT) To: Juri Linkov References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> From: Trevor Spiteri Autocrypt: addr=tspiteri@ieee.org; prefer-encrypt=mutual; keydata= mQINBFcxvj8BEADgjJ0VPjUDQHNOO8+zw4txojpVRUbw3q4o3EaxHBSn3Nzl8qtp+OOzDe6n M4YQK6/ocBSJc+w3rFQzjmHxcCaJW8XJTaV27ot9r/wS6ucz34xFM6PJp2iIVT5SI5h1htIv ywJ9JlC+BiVN8X3QAvBJeQEGx48HNv+oYR/6mLvh/3cuyABBcmmsMBmG6ACpLJ6COhOXkl4r XB+gmVvt72HWy+zYyF/m1aMxQFakrAVWP3uslReCPR66bKiS9Hm77IyGGE5LOhccda0nFy5I kHqibst646jTQAu1EcpQZrnRXq7JOEOToM3Aj8GRI+T9+rKr1rf2RA7zdm0D9reUV+iPOEaI jFa4XT43BddM8mlV5pSQft2qoB3cTNHo1uJz8cQWTlmwcJiUEPVi5+5EtuDz/ovxSRIepNl4 zEHO5NNIqt2AZNLr+49UwWSmNi5NVfDxjXswCmFfUBFev14nxVz7jaPWUtD+htzkIUAoidlM a7tkeboP6j1UonX/ELwRTnWctpich8GCVaV+AaTViNpiJFw/wR3jN3rjE2AN5dgSgLEroInS M+U3a21c0pGarETx/JlpteZjWxvMMtdDr0MeLqVvSMxErvBB+0JhqkK9uAoAj8hCe6mweDao qIyUwPewbDD9Gcgxzd2ljbPcw1kOP8hFEjn+WWOcYY+rVu6+jQARAQABtCJUcmV2b3IgU3Bp dGVyaSA8dHNwaXRlcmlAaWVlZS5vcmc+iQJXBBMBCABBAhsjBQsJCAcCBhUICQoLAgQWAgMB Ah4BAheAAhkBFiEEG4iXMFy2k8rbrA4H9yiscA+IZu4FAlzwZ/UFCQ8kqzYACgkQ9yiscA+I Zu4u8w/+O5XMgDJwAKcpeO/ny93NR00YB5kMQlehvIgobuFnmt+bEQwZUuvVt+S5477ArJI2 XJiDOXh73qn0Yp/kqSdOf0lvteP3bNtRdJkl8X6oqBcI/hg8cdIzffSKR+yUduzo2TEkxhFQ n2cgEKYxzVmHgiEjVaPCt/NEqYNjRkPCmpaIlmQjzbsP6gCgM3B19GDz7Pp4aM+h/9K6FbT1 2LOpVfyJxn9DfTV0zHfNMJ1Rz6fJQmQ3pGm7s614f+I1HEoO5CQQTtJ8VSdUBD33P5QotaNF AdPZKpfIb/2w4VP/k2Sd6dJFJY2lWMKs0cxeyfDbaUyPVgjEZjW0msZXYLGS2BLgKWAMLBE2 MXRY+7Qria1+Jn+pCrlTbHAOhL/f30H0iunBm2Okkc39lZbrTjHwSqofag9xTGvqPlCa6sIB 0Lp7uqUvxezL+p0mz8XmZabKWxstKh9qOHcPXkeDtsfkfiv/Q7QHIUmPOdIcouMgs4atQPbC 47ko95wXZcamvSavuAVsZeAVfBI54R7U14gbSVaxHOr3a7qKFbDjoK+pm5+Sio2GuTzlls4Y YQ32GY/j7R94xiKMCnb4GSOnj8W995d5BVYU/DAV3xhJ4LrTTH2rF1c3jNV4MQBVI0u/wICN XM8uAXjHd2kHoHZKAJQhtk3Ns+aRZzKjmCX0/GJhIFy5Ag0EVzG+PwEQAOBQdUpKN9sAaIt9 x1qsF5/tetgh7LYkj1A5nBGl054x62kFcD8bj98nZG53I0UzFxD0ZLyhN08vg3cpg80d+24v hUJJk3O0MIRy3cDqPolxYpKjzf3fgt4Sl1+lZuXGFnBfh3UQgPmwC04zN8orqDdgwoJvyGtK wqxMxE5d3HCNIYZszOOc+jLE50wXqfkqd47AmaSRZVJWgfrinFkPEoU2496uLakXZzUJDBgY LTL8VIQ5qR/KwE8QMIsdWxUBIUC7paUS0qTy/Nyx2UlrfeunLy8pY8XtL6X2/IukpiMrVE4D Ay+3dIrlX0/uquRTX+4zEMptOkqDS3hSmpsxqVQAs0wAiQrbrurPq8FfNMjSWDYNXfVW33wc 5ROQolC+pCnwYvWSUUsXzXEAjYUa9k65S8KsYLFquDW8KS6f4LEbdUrhmj8cLow0jOvKEgpX VqEsTOGKJ7HxArW+gVNPSr2i5rIuM8wa6PtbAY8izebYPJYGzAv17sybTyBw6a8yUF1Gwfar Wsm0QnmZKXqy6AzNToV52kVuII6yMG9DBLq6SRgzQmFpXzxaaEdPZqzvJlZ/AX9GFNx2illA bCmwhLcAenVmMpO5KYRdD1aC80VyMPYLxFO896gUaYuphZkqjCkTReexFQPTxXZFoNL8rrMp /WUFh6XR/QJPuAD1OZWbABEBAAGJAjwEGAEIACYCGwwWIQQbiJcwXLaTytusDgf3KKxwD4hm 7gUCXPBn9gUJDySrNwAKCRD3KKxwD4hm7k4iD/9VGy6RHYN7HcxsF2fW9xbO91F9M57Kz9um C50LPItJPBCDq9vX7cCrk7Bg6ZIP0EqL/qRsfSabFemz8XV22skaPB/O6E9WGh+6geo5krNb eUvzeqIh6A6RMStiJYjEKwePAx+1xUgzi5PiK7y8MYRaQQly7cJEveLYsCh4GFf7hXDCGdxP Nt1hV3KeEipS2p2VdwTBHydmiUYdb1jURv5zeorUo8313R0zh4GJGPp+Gync1C2Y0vWTeCOY lpgcWfM8wXA6DVWC/49yQZCL+ryNOEbHqdTGzXc/F2EdcOVOvFG6jhg8aM8tYY9Iqj9D0P8i IAII64/OG+PQRwCZez6Z+riJzfJIfeXHw06BHI9COdSu7EyzKLZdacXsPLjZ+X/+IciGyFLq EmcZxoWWcDWr0kZ4JharhOLyewVbGcb/sqH8rWx666KSfNSEKRgcRxOGHYeVVspWl2EDDBBE vyy8W1tCsT5wxDb3yY72i5ESvLHmU4kgKZntizEPUvLqY7qESALO5+iZneXIwgRriAP1vNe5 dlV5KfR0BVdH60RxWCIZ8RIgrrrfPkn8ne122dkgfYdjqB516hG8EiNl48MlsgcV/r9VTqNR ocbCobKMDCU4ge53B1FfvB1fgKcquR6g73NNiFXc1rQAzTR0asNhUpWMpUJ+s2YkIGz+Qqdn xQ== Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented Message-ID: <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> Date: Fri, 1 May 2020 01:18:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <87bln8u3xq.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 40919 Cc: 40919@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.0 (-) >> I think this would work for next-error-select-buffer. Then to fix the >> other issue about new compilations, compilation-start can be modified = to >> use next-error-select-buffer. That way the change in compilation-start= >> is morally unambiguous :) > I'm not sure if this is morally right, because users might want to > continue to navigate an old next-error buffer, even after creating > a new next-error buffer. > > OTOH, by using next-error-select-buffer they explicitly say that > they want to switch to the new navigation. Do you think it's right > to implicitly assume the user's intention? > > We should base the decision not on precedence set by older versions, > but on expectations of most users. > >> diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el >> index 455f181f50..41e77007c6 100644 >> --- a/lisp/progmodes/compile.el >> +++ b/lisp/progmodes/compile.el >> @@ -1910,7 +1910,7 @@ compilation-start >> (goto-char (point-max)))) >> =20 >> ;; Make it so the next C-x ` will use this buffer. >> - (setq next-error-last-buffer outbuf))) >> + (next-error-select-buffer outbuf))) >> =20 >> (defun compilation-set-window-height (window) >> "Set the height of WINDOW according to `compilation-window-height'.= " > There are more places that set next-error-last-buffer: vc-git-grep, occ= ur-1, > xref.el... > > But I'm still not sure if this is a preferable behavior for most users.= > Maybe this needs a user option? I thought that the change was unintentional. If it's intentional that's another thing. If no one else complains then maybe most users prefer the new behavior. I've already added advice to compilation-start so it's not hard for me that I prefer the old behavior. From debbugs-submit-bounces@debbugs.gnu.org Sat May 02 19:40:18 2020 Received: (at 40919) by debbugs.gnu.org; 2 May 2020 23:40:18 +0000 Received: from localhost ([127.0.0.1]:54156 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jV1k1-0002JV-Cq for submit@debbugs.gnu.org; Sat, 02 May 2020 19:40:18 -0400 Received: from relay5-d.mail.gandi.net ([217.70.183.197]:43289) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jV1jz-0002JE-IE for 40919@debbugs.gnu.org; Sat, 02 May 2020 19:40:16 -0400 X-Originating-IP: 91.129.106.11 Received: from mail.gandi.net (m91-129-106-11.cust.tele2.ee [91.129.106.11]) (Authenticated sender: juri@linkov.net) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id EDF7F1C0002; Sat, 2 May 2020 23:40:07 +0000 (UTC) From: Juri Linkov To: Trevor Spiteri Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented Organization: LINKOV.NET References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> Date: Sun, 03 May 2020 02:38:10 +0300 In-Reply-To: <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> (Trevor Spiteri's message of "Fri, 1 May 2020 01:18:49 +0200") Message-ID: <87d07lykkd.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40919 Cc: 40919@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.7 (-) >> But I'm still not sure if this is a preferable behavior for most users. >> Maybe this needs a user option? > > I thought that the change was unintentional. If it's intentional that's > another thing. If no one else complains then maybe most users prefer the > new behavior. I've already added advice to compilation-start so it's not > hard for me that I prefer the old behavior. I think the problem occurs only because compilation/grep pop up their output buffer in another window - this creates ambiguity whether to use navigation from the current buffer or from another (new) buffer. It seems there is no right answer suitable for all users. So I propose to add more options. Eli, do you agree with adding more options to `next-error-find-buffer-function' in emacs-27? Currently it has one option that defines one of possible behaviors existed in older versions. Now we need to add other option for compatibility with pre-27 versions. Then users of emacs-27 could decide whether they want to keep the old behavior or use the new. I'm not sure about the default value: should it default to pre-27 behavior. From debbugs-submit-bounces@debbugs.gnu.org Sat May 02 22:40:38 2020 Received: (at 40919) by debbugs.gnu.org; 3 May 2020 02:40:38 +0000 Received: from localhost ([127.0.0.1]:54401 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jV4YY-0004tC-6D for submit@debbugs.gnu.org; Sat, 02 May 2020 22:40:38 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44532) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jV4YW-0004sz-Ld for 40919@debbugs.gnu.org; Sat, 02 May 2020 22:40:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44099) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jV4YP-0001eD-W5; Sat, 02 May 2020 22:40:30 -0400 Received: from [176.228.60.248] (port=1617 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jV4YP-0008RV-Eg; Sat, 02 May 2020 22:40:29 -0400 Date: Sun, 03 May 2020 05:40:22 +0300 Message-Id: <83bln5rbah.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <87d07lykkd.fsf@mail.linkov.net> (message from Juri Linkov on Sun, 03 May 2020 02:38:10 +0300) Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 40919 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.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.3 (---) > From: Juri Linkov > Date: Sun, 03 May 2020 02:38:10 +0300 > Cc: 40919@debbugs.gnu.org > > It seems there is no right answer suitable for all users. So I propose > to add more options. > > Eli, do you agree with adding more options to `next-error-find-buffer-function' > in emacs-27? > > Currently it has one option that defines one of possible behaviors existed > in older versions. Now we need to add other option for compatibility > with pre-27 versions. > > Then users of emacs-27 could decide whether they want to keep > the old behavior or use the new. I think the time for adding new options to Emacs 27 has come and gone long ago. We should defer that to future releases. From debbugs-submit-bounces@debbugs.gnu.org Sun May 03 18:38:32 2020 Received: (at 40919) by debbugs.gnu.org; 3 May 2020 22:38:32 +0000 Received: from localhost ([127.0.0.1]:58353 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVNFo-0004BB-2I for submit@debbugs.gnu.org; Sun, 03 May 2020 18:38:32 -0400 Received: from relay10.mail.gandi.net ([217.70.178.230]:58575) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVNFm-0004Ax-1w for 40919@debbugs.gnu.org; Sun, 03 May 2020 18:38:30 -0400 Received: from mail.gandi.net (m91-129-106-11.cust.tele2.ee [91.129.106.11]) (Authenticated sender: juri@linkov.net) by relay10.mail.gandi.net (Postfix) with ESMTPSA id 1F9C3240003; Sun, 3 May 2020 22:38:22 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented Organization: LINKOV.NET References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> Date: Mon, 04 May 2020 01:36:43 +0300 In-Reply-To: <83bln5rbah.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 03 May 2020 05:40:22 +0300") Message-ID: <87zhaozlvo.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40919 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.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.7 (-) >> It seems there is no right answer suitable for all users. So I propose >> to add more options. >> >> Eli, do you agree with adding more options to `next-error-find-buffer-function' >> in emacs-27? >> >> Currently it has one option that defines one of possible behaviors existed >> in older versions. Now we need to add other option for compatibility >> with pre-27 versions. >> >> Then users of emacs-27 could decide whether they want to keep >> the old behavior or use the new. > > I think the time for adding new options to Emacs 27 has come and gone > long ago. We should defer that to future releases. To do nothing in emacs-27 is one variant, indeed. Another variant would be to add an optional choice to the existing option that allows to restore the old behavior and doesn't affect the current behavior in any way. A third variant is to explain in the documentation what defadvice the users could add to their init files to restore the old behavior. From debbugs-submit-bounces@debbugs.gnu.org Mon May 18 21:49:02 2020 Received: (at 40919) by debbugs.gnu.org; 19 May 2020 01:49:03 +0000 Received: from localhost ([127.0.0.1]:48703 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jarNO-0007j3-OJ for submit@debbugs.gnu.org; Mon, 18 May 2020 21:49:02 -0400 Received: from mail-wr1-f42.google.com ([209.85.221.42]:39946) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jarNL-0007iY-VO for 40919@debbugs.gnu.org; Mon, 18 May 2020 21:49:00 -0400 Received: by mail-wr1-f42.google.com with SMTP id e16so13979618wra.7 for <40919@debbugs.gnu.org>; Mon, 18 May 2020 18:48:59 -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=5yFFepbIcbYpeswCdRL6dzjSEssEcGIWh3IazDgMj1c=; b=DB+PqFahGkWFPMNjBxtHHkswkpQkIitRwHXoOqqXVYyTKvlM9BtBhimdS8Qd/kuhNe wSmRhuPQ/RzZu+ah/g20jaak+hEp9FP6J6rMnDN42nMxvhCYP2uFAGkpFIBt+wNHpWXR itZ0gPcDQDcqKmrF398lfj3GDjhGuOug2tl5uugET/NxGEGGfoNX8g8/BjKx67y5LobQ PDPJFIf+Pqie72Fto7D+jbwuccWnAprpyJnY1+aLfmfvAfCzbFxuXVTfxhxaWMuvM+cb 5zql+Np7wGZF0jL85HLo4g8ww965HqDhglBZDSDvA66ul+Dg8OZBhBMkcMkZ6Nq7HszL 5TFw== 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=5yFFepbIcbYpeswCdRL6dzjSEssEcGIWh3IazDgMj1c=; b=GCKU3eE5Rqqei2VjcNcr5vB5JVtQqUNFh2Jy6AXDhL8Jx/+aljQNgd6AqMqrv4HAiL gtHKO5Yc4VrHm7mCZYKZyfYCEQtKN5D2V7GaHNzV2YfI0cs9eB/EGBVvz8c7/XZnhCrj s2ZKG92tyEQPsHUjgQOKcldfRUW/AphMq3N1AzH7EY/dX1zBUNLJih3FwEWxVSUcdVdm 0Or/ohWpvVHKNWMEfFc/6rjB+3Pa3OPZbJuAKeGSrodYbhyYlyGF9OJVXXRYVEJPzMtH UurzCNuV+Tsd5BBnvgEM9dQASTCdjOfERdx72+KkwFjqPBMF5S9lGY21RDTnXAEcyMDf WXIg== X-Gm-Message-State: AOAM531LfwoxWVrNeFtFWZqLgvtXdZgW9ow4kJ82d0kMiAFFk+cUmPk5 tu5EoMw7thsnij0PGjfNSh4= X-Google-Smtp-Source: ABdhPJzEMMfknwkyYxzyd+LyB6L3wyuMPKxi//qAWtc47Xu/sQqPydpR2n2XWVi511DC5Uv2Aic3fg== X-Received: by 2002:a5d:69c3:: with SMTP id s3mr22257572wrw.305.1589852933756; Mon, 18 May 2020 18:48:53 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id z11sm17983172wrr.32.2020.05.18.18.48.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 May 2020 18:48:53 -0700 (PDT) Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented To: Juri Linkov , Eli Zaretskii References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: Date: Tue, 19 May 2020 04:48:51 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <87zhaozlvo.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: 40919 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.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 04.05.2020 01:36, Juri Linkov wrote: > Another variant would be > to add an optional choice to the existing option that allows to restore > the old behavior and doesn't affect the current behavior in any way. FWIW, I'd consider that more of a documentation change. More importantly, and certainly only for Emacs 28, Juri could you remind me what we'll be losing by removing the case no. 2 from next-error-find-buffer? The ability to switch to an arbitrary Grep buffer and start using it with 'M-x next-error'? E.g. if there are several of them. That's more of a backward compatibility concern, right? Or do you have scenarios in mind where this will really save on keystrokes? On another note, perhaps we could add a message to next-error-select-buffer that would be shown if we suspect this command will not have the expected result for the user. From debbugs-submit-bounces@debbugs.gnu.org Tue May 19 18:25:32 2020 Received: (at 40919) by debbugs.gnu.org; 19 May 2020 22:25:32 +0000 Received: from localhost ([127.0.0.1]:51352 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbAfz-0003rn-Qj for submit@debbugs.gnu.org; Tue, 19 May 2020 18:25:32 -0400 Received: from relay12.mail.gandi.net ([217.70.178.232]:35503) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbAfx-0003rG-1S for 40919@debbugs.gnu.org; Tue, 19 May 2020 18:25:29 -0400 Received: from mail.gandi.net (m91-129-97-200.cust.tele2.ee [91.129.97.200]) (Authenticated sender: juri@linkov.net) by relay12.mail.gandi.net (Postfix) with ESMTPSA id 97EAA200003; Tue, 19 May 2020 22:25:21 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented Organization: LINKOV.NET References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> Date: Wed, 20 May 2020 01:21:35 +0300 In-Reply-To: (Dmitry Gutov's message of "Tue, 19 May 2020 04:48:51 +0300") Message-ID: <87v9kr8t1s.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40919 Cc: Eli Zaretskii , 40919@debbugs.gnu.org, tspiteri@ieee.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.7 (-) >> Another variant would be >> to add an optional choice to the existing option that allows to restore >> the old behavior and doesn't affect the current behavior in any way. > > FWIW, I'd consider that more of a documentation change. > > More importantly, and certainly only for Emacs 28, Juri could you remind me > what we'll be losing by removing the case no. 2 from > next-error-find-buffer? It is used to handle such cases when navigating one next-error list visits a buffer that contains another next-error list - visiting such buffer should not switch the navigation, it should continue the initial navigation. But I'm not proud of the case no. 2, so you can drop it :) Or better move it to a separate function and provide this function as an option in next-error-find-buffer-function. > The ability to switch to an arbitrary Grep buffer and start using it with > 'M-x next-error'? E.g. if there are several of them. That's more of > a backward compatibility concern, right? Or do you have scenarios in > mind where this will really save on keystrokes? The ability to visit an arbitrary Grep buffer and use 'next-error' in it to switch navigation should always work as the most reliable and implicit way to switch navigation. This is the case no. 3 in next-error-find-buffer. > On another note, perhaps we could add a message to next-error-select-buffer > that would be shown if we suspect this command will not have the expected > result for the user. Or maybe ask the user using the minibuffer to resolve ambiguity. From debbugs-submit-bounces@debbugs.gnu.org Thu May 21 19:57:47 2020 Received: (at 40919) by debbugs.gnu.org; 21 May 2020 23:57:47 +0000 Received: from localhost ([127.0.0.1]:57596 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbv4N-00051N-4k for submit@debbugs.gnu.org; Thu, 21 May 2020 19:57:47 -0400 Received: from mail-wr1-f42.google.com ([209.85.221.42]:37911) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jbv4M-00051B-56 for 40919@debbugs.gnu.org; Thu, 21 May 2020 19:57:46 -0400 Received: by mail-wr1-f42.google.com with SMTP id e1so8405011wrt.5 for <40919@debbugs.gnu.org>; Thu, 21 May 2020 16:57:46 -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; bh=+NliZw2joC5srp+vgKbLowcYyq7MFFHHwrouRXPAdbs=; b=Ob5tOjphgEjF0pElVLpRAmoGiS/t9MtBmyh7IqtypjQQCvgzd+O9G7ce+6RJhaCYhM SoU7nvExyJ6qI6E5hravZ6BnFJ0aQLN0eVbcFGqPYTc2fEKz43sT/eeZ0eew43LWuU3t Dz2Hk+Z86zZaxEf9Hy8u2ECUabjV4jQhlipfGQGZNSRnVPKWHgsFTrCkv4BQ5/Mk7Rr6 9vq0IUFhvF2BnkRyJDSqt74eGDdN+vGUir1iJuG7UT5Gh52iNCxtJhzbRVOza1gt3YjU noXEZXRV6L2Bu48noc+flQf/irBnTTfxzQmDJJzojr8E8T8WgPJqOTrltYNV96YgllC4 5Tdw== 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; bh=+NliZw2joC5srp+vgKbLowcYyq7MFFHHwrouRXPAdbs=; b=jj5t7OMfCn7ASI543mGtY/07TwWOyJmsn+qIweXo3zTwE/vZokBoWk7oj1l7M0HYDe szMkq10QJdaV2YLoarXI9JkhZJe2m9sygdx0ZDFAKWI2ZMG9SRWomDkxXe08WEIIL5Xj yNmEG1nhJIl3rrWHcuVwng6IAkVI/Tq/WvV2rvoBNJGvH3u5xUL+3heMsDhGNzKFD93p Yw4ZUUcqSiIJIIrJ64PVOhfu315vVJ23KAraVeHJymDIX2nVhDR/CgVVkjbxZdF2zSPw Loa7JCqrZWn/1q7C5ZB4Ldx7PZ7KDRzDwuIdxOf/zzm9hV9hZDxr9Swo9arfwVVdrH2z +zeQ== X-Gm-Message-State: AOAM530xpaQkSuwdaJRCErDhn5LtHploOhF+yAHz9y8p/RK7b4FNHjJX sCq7iDmW+KScDjJVHo3U+/4= X-Google-Smtp-Source: ABdhPJwDbNFgYPLQhDPjTudjsmajPeCm+ZzmrEewG1FgPr81J1JXRel3DteGb8KYbHmKoMkLBXS2Gw== X-Received: by 2002:adf:dd50:: with SMTP id u16mr958768wrm.58.1590105460161; Thu, 21 May 2020 16:57:40 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id w15sm7750599wmi.35.2020.05.21.16.57.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 May 2020 16:57:39 -0700 (PDT) Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented To: Juri Linkov References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: Date: Fri, 22 May 2020 02:57:37 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <87v9kr8t1s.fsf@mail.linkov.net> Content-Type: multipart/mixed; boundary="------------999E6205C3908AAA7F507F55" Content-Language: en-US X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 40919 Cc: Eli Zaretskii , 40919@debbugs.gnu.org, tspiteri@ieee.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. --------------999E6205C3908AAA7F507F55 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 20.05.2020 01:21, Juri Linkov wrote: >>> Another variant would be >>> to add an optional choice to the existing option that allows to restore >>> the old behavior and doesn't affect the current behavior in any way. >> >> FWIW, I'd consider that more of a documentation change. >> >> More importantly, and certainly only for Emacs 28, Juri could you remind me >> what we'll be losing by removing the case no. 2 from >> next-error-find-buffer? > > It is used to handle such cases when navigating one next-error list > visits a buffer that contains another next-error list - visiting > such buffer should not switch the navigation, it should continue > the initial navigation. Didn't we fix changelog-mode so this doesn't happen anymore? I think as long as file major modes don't set next-error-last-buffer (and minor modes either, on initialization), we should be safe. Can you reproduce a problematic scenario with the attached patch? > But I'm not proud of the case no. 2, so you can drop it :) > > Or better move it to a separate function and provide this function > as an option in next-error-find-buffer-function. Patch attached. Comments welcome. >> The ability to switch to an arbitrary Grep buffer and start using it with >> 'M-x next-error'? E.g. if there are several of them. That's more of >> a backward compatibility concern, right? Or do you have scenarios in >> mind where this will really save on keystrokes? > > The ability to visit an arbitrary Grep buffer and use 'next-error' in it > to switch navigation should always work as the most reliable and implicit > way to switch navigation. This is the case no. 3 in next-error-find-buffer. Not if there are, say, two Compilation buffers (or Grep and Occur, etc), and you switch to the least recently used one, and press M-g n. It's probably fine, though. >> On another note, perhaps we could add a message to next-error-select-buffer >> that would be shown if we suspect this command will not have the expected >> result for the user. > > Or maybe ask the user using the minibuffer to resolve ambiguity. Resolve it how? I think we can safely guess their intention, it's just not trivial to execute it. Anyway, this problem should go away with the attached patch. --------------999E6205C3908AAA7F507F55 Content-Type: text/x-patch; charset=UTF-8; name="next-error-extract-case-2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="next-error-extract-case-2.diff" diff --git a/lisp/simple.el b/lisp/simple.el index 111afa69d1..31d6cbcef2 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -211,6 +211,8 @@ next-error-find-buffer-function :type '(choice (const :tag "No default" ignore) (const :tag "Single next-error capable buffer on selected frame" next-error-buffer-on-selected-frame) + (const :tag "Current buffer if next-error capable and outside navigation" + next-error-buffer-try-current-outside-navigation) (function :tag "Other function")) :group 'next-error :version "27.1") @@ -240,6 +242,21 @@ next-error-buffer-on-selected-frame (if (eq (length window-buffers) 1) (car window-buffers)))) +(defun next-error-buffer-try-current-outside-navigation (&optional + avoid-current + extra-test-inclusive + extra-test-exclusive) + "Maybe Return current buffer if it's next-error capable. +But return nil if we navigated to the current buffer by the means +of `next-error' command." + ;; Check that next-error-buffer has no buffer-local value + ;; (i.e. never navigated to the current buffer from another), + ;; and the current buffer is a `next-error' capable buffer. + (if (and (not (local-variable-p 'next-error-buffer)) + (next-error-buffer-p (current-buffer) avoid-current + extra-test-inclusive extra-test-exclusive)) + (current-buffer))) + (defun next-error-find-buffer (&optional avoid-current extra-test-inclusive extra-test-exclusive) @@ -260,24 +277,16 @@ next-error-find-buffer (funcall next-error-find-buffer-function avoid-current extra-test-inclusive extra-test-exclusive) - ;; 2. If next-error-buffer has no buffer-local value - ;; (i.e. never navigated to the current buffer from another), - ;; and the current buffer is a `next-error' capable buffer, - ;; use it unconditionally, so next-error will always use it. - (if (and (not (local-variable-p 'next-error-buffer)) - (next-error-buffer-p (current-buffer) avoid-current - extra-test-inclusive extra-test-exclusive)) - (current-buffer)) - ;; 3. If next-error-last-buffer is an acceptable buffer, use that. + ;; 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 extra-test-inclusive extra-test-exclusive)) next-error-last-buffer) - ;; 4. If the current buffer is acceptable, choose it. + ;; 3. If the current buffer is acceptable, choose it. (if (next-error-buffer-p (current-buffer) avoid-current extra-test-inclusive extra-test-exclusive) (current-buffer)) - ;; 5. Look for any acceptable buffer. + ;; 4. Look for any acceptable buffer. (let ((buffers (buffer-list))) (while (and buffers (not (next-error-buffer-p @@ -285,7 +294,7 @@ next-error-find-buffer extra-test-inclusive extra-test-exclusive))) (setq buffers (cdr buffers))) (car buffers)) - ;; 6. Use the current buffer as a last resort if it qualifies, + ;; 5. Use the current buffer as a last resort if it qualifies, ;; even despite AVOID-CURRENT. (and avoid-current (next-error-buffer-p (current-buffer) nil @@ -293,7 +302,7 @@ next-error-find-buffer (progn (message "This is the only buffer with error message locations") (current-buffer))) - ;; 7. Give up. + ;; 6. Give up. (error "No buffers contain error message locations"))) (defun next-error (&optional arg reset) --------------999E6205C3908AAA7F507F55-- From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 18:56:32 2020 Received: (at 40919) by debbugs.gnu.org; 23 May 2020 22:56:32 +0000 Received: from localhost ([127.0.0.1]:36000 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcd4C-00088K-AD for submit@debbugs.gnu.org; Sat, 23 May 2020 18:56:32 -0400 Received: from relay2-d.mail.gandi.net ([217.70.183.194]:52511) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcd4A-00087u-Fq for 40919@debbugs.gnu.org; Sat, 23 May 2020 18:56:30 -0400 X-Originating-IP: 91.129.97.200 Received: from mail.gandi.net (m91-129-97-200.cust.tele2.ee [91.129.97.200]) (Authenticated sender: juri@linkov.net) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 7246040005; Sat, 23 May 2020 22:56:22 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented Organization: LINKOV.NET References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> Date: Sun, 24 May 2020 01:24:51 +0300 In-Reply-To: (Dmitry Gutov's message of "Fri, 22 May 2020 02:57:37 +0300") Message-ID: <87zh9yuw5o.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40919 Cc: Eli Zaretskii , 40919@debbugs.gnu.org, tspiteri@ieee.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.7 (-) >> But I'm not proud of the case no. 2, so you can drop it :) >> Or better move it to a separate function and provide this function >> as an option in next-error-find-buffer-function. > > Patch attached. Comments welcome. Is this patch for master? So there is enough time for thorough testing? From debbugs-submit-bounces@debbugs.gnu.org Sat May 23 19:30:37 2020 Received: (at 40919) by debbugs.gnu.org; 23 May 2020 23:30:37 +0000 Received: from localhost ([127.0.0.1]:36043 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcdbB-0000Vi-7Q for submit@debbugs.gnu.org; Sat, 23 May 2020 19:30:37 -0400 Received: from mail-wr1-f51.google.com ([209.85.221.51]:43952) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcdb9-0000VV-9U for 40919@debbugs.gnu.org; Sat, 23 May 2020 19:30:35 -0400 Received: by mail-wr1-f51.google.com with SMTP id i15so13795609wrx.10 for <40919@debbugs.gnu.org>; Sat, 23 May 2020 16:30:35 -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=Av3XlEm5KzPKDaLmQH9giiXZ3BoWp36LhVUs1WFjFR4=; b=Alh14oq2iXXgnNpL8ydkmmeEJVbaHYf80HM9sHRCpbECMC3F1u/UBRwzFMO0hrSY3E EoFOgtwxsrB6uFRjKdzUFO0PFUUDWv1Qj6gyXHKE0++CeJ6T+kz2bXbnUZHU32fM7znZ e6rO9ULZ+b6Or6A0tEq0Ct7brOJ3j9e1GhXDGWMKQ4tVRyVzlAIwqofpXx23Xk6zZex6 7/LtZoLaArnXALh7XiAzbpI9uc018f1lmtzv+bEy5ErmyFciHKrABO51Pzk4+2nJAVmV WmhJSHFyHGqPzW7kZbFl4yPUc2pq3Eou3UzsfaJG9KV9mwQqgHjCPRm/Rcwe7cyHaZYV cxeg== 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=Av3XlEm5KzPKDaLmQH9giiXZ3BoWp36LhVUs1WFjFR4=; b=Ynn+H3UVFXuXQdXjLfxeH4melHlZmOgbIPds+pal4LmZFGVrHSwFJeDiaVTsKCpshz MjcRkSFH65vn0R/jmhQXKSRNcmBHwY34kxxHYOhGktwdgYkyd8M7Tlu98LNbTgIKxuc0 +AYatI+PiP2bqNskXHDgUmjmK4Vl5EtqHmbXauZh0+QAF3BujG8TXDy7t4CE9+Tj6+e6 Fw1AiGVMKeFItQttRKnsqwDXKo4aderWW8sZ1FaWGZi+g2LkRZ0VcihsRckYnR0XBJQk V/evVhIpeT4C93UfXYiBm0UGOr0X4RkgVPFmKO4tiPW6+H75606hf7nI4T7tkw9U3GtW mdFg== X-Gm-Message-State: AOAM533A/2gJtutySOMcGC/Wl8utRsR/jjWBQpqdPF2ThkZAVVOAYxkg MBEyDInvh31xFnuQecw0cFI= X-Google-Smtp-Source: ABdhPJzEvmsjp5YH1oo8/I81Z3vTpOZzxb4q//xM+sUAJj56YM/xW9X5Bgop30X73U9SuMS23sV+bQ== X-Received: by 2002:adf:a1d3:: with SMTP id v19mr7699404wrv.245.1590276629025; Sat, 23 May 2020 16:30:29 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id e5sm5735409wrw.19.2020.05.23.16.30.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 23 May 2020 16:30:28 -0700 (PDT) Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented To: Juri Linkov References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: Date: Sun, 24 May 2020 02:30:27 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <87zh9yuw5o.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: 40919 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.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 24.05.2020 01:24, Juri Linkov wrote: > Is this patch for master? So there is enough time for thorough testing? I think it's for master. Though if we put it into emacs-27 and changed the default to the name of the new function, the behavior shouldn't change, and yet it would be easier to "fix" this bug through user configuration... (ʘ‿ʘ) But your question seems to confirm that it's for master. Suggestions for a better (shorter?) name for the new function welcome, by the way. From debbugs-submit-bounces@debbugs.gnu.org Sun May 24 18:10:26 2020 Received: (at 40919) by debbugs.gnu.org; 24 May 2020 22:10:26 +0000 Received: from localhost ([127.0.0.1]:38989 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcyp8-0000AI-4S for submit@debbugs.gnu.org; Sun, 24 May 2020 18:10:26 -0400 Received: from relay7-d.mail.gandi.net ([217.70.183.200]:51541) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcyp0-00009U-0R for 40919@debbugs.gnu.org; Sun, 24 May 2020 18:10:18 -0400 X-Originating-IP: 91.129.108.6 Received: from mail.gandi.net (m91-129-108-6.cust.tele2.ee [91.129.108.6]) (Authenticated sender: juri@linkov.net) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id 47F8C20008; Sun, 24 May 2020 22:10:10 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented Organization: LINKOV.NET References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> Date: Mon, 25 May 2020 00:48:53 +0300 In-Reply-To: (Dmitry Gutov's message of "Sun, 24 May 2020 02:30:27 +0300") Message-ID: <87zh9xuhq2.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40919 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.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.7 (-) >> Is this patch for master? So there is enough time for thorough testing? > > I think it's for master. Though if we put it into emacs-27 and changed the > default to the name of the new function, the behavior shouldn't change, and > yet it would be easier to "fix" this bug through user > configuration... (ʘ‿ʘ) Yes, this will fix the reported problem of customizability. Maybe Eli will agree to fix this in emacs-27. > Suggestions for a better (shorter?) name for the new function welcome, by > the way. Maybe next-error-find-keep-navigation. From debbugs-submit-bounces@debbugs.gnu.org Sun May 24 21:58:15 2020 Received: (at 40919) by debbugs.gnu.org; 25 May 2020 01:58:16 +0000 Received: from localhost ([127.0.0.1]:39217 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jd2Nb-0005lE-N4 for submit@debbugs.gnu.org; Sun, 24 May 2020 21:58:15 -0400 Received: from mail-wm1-f51.google.com ([209.85.128.51]:38701) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jd2NZ-0005l2-TX for 40919@debbugs.gnu.org; Sun, 24 May 2020 21:58:14 -0400 Received: by mail-wm1-f51.google.com with SMTP id u12so10544866wmd.3 for <40919@debbugs.gnu.org>; Sun, 24 May 2020 18:58:13 -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=FyK76rVmmtk/kf57S8hxgY7GhKGeGx8BlbbueEdsPsU=; b=rTD+Kl6H5Av0XDoGd6j7lKlySMlmBA94L29l42lJLWxs8QfpEP1Yj7Qpizmr2FBH5Y yQle36NQkZq1UwYDHa8pTqfgR5qZHVTDkVNKzbtzavICZazBNPgRUsKDwDJCi2aF1bBl JDDnDk+xwcdTIfsuUplT+PXcqVTnoGQrBiU7sEQBLsSvCfwCY1SAinfLeYAl5L5HEt3A VHDp5nxH7bAO/ps/qRZAv0C/VbXngUdAjSXBM4ZTBYCyBXmyIu4Y6VI0qG5/kyXGLNBE L9TTlQbw+Fcx9l8RT4jfLCTBF6U9mtmOHK/bw2da+USLBR0ywXzWs6HRc73v8BiQevBK aHAg== 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=FyK76rVmmtk/kf57S8hxgY7GhKGeGx8BlbbueEdsPsU=; b=PAtQVjHO+in+OIp4++pE0IBEn8scsJDIrhpMWouN1gFFjbFRzqwCCouU20Lx9INahL KFZDhHTGhHI0cFybeoAmxjT98LelGEliK0WODuMt+xFVkk4Z6y3Cs9a85wD89sN5PbHR XU3Vj1w7imra+mENnaq7u02bbOuks38qd8dr3DFcUjl5uFKE9SA12df8m5NX0xz01LnN ZvWZV75OJb0d+YE1JG6GfVbuoGfSJqgf9t9owjZa8sho0YP/ZBlQdrn3eWAzBgB4s3jl 0hQsCurfn4oFJItZkWogwZbUWm7QmyZmxw9sGTg6bzXQA9hgQ6nKpy2PgFrTsC/W/udG ZBnw== X-Gm-Message-State: AOAM53298V1UABdPuF8THMYJAUoVFdXtrYYQDP9t512vLEzdeacBDWMo XtR9qk4JzoaLIRPAiVvtU9I= X-Google-Smtp-Source: ABdhPJzC8E7opaeDE4U/qwQ83WEr9gXPVUNGZFYwnq/46i/aBPijwTYxQJ3hE8+dwtP5T8sBCZQHTg== X-Received: by 2002:a7b:c096:: with SMTP id r22mr8301780wmh.92.1590371887975; Sun, 24 May 2020 18:58:07 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id n17sm16258501wrr.42.2020.05.24.18.58.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 24 May 2020 18:58:07 -0700 (PDT) Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented To: Juri Linkov References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> <87zh9xuhq2.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <5c6d82c4-436e-9014-7dc7-0897caf76403@yandex.ru> Date: Mon, 25 May 2020 04:58:05 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <87zh9xuhq2.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: 40919 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.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 25.05.2020 00:48, Juri Linkov wrote: >>> Is this patch for master? So there is enough time for thorough testing? >> I think it's for master. Though if we put it into emacs-27 and changed the >> default to the name of the new function, the behavior shouldn't change, and >> yet it would be easier to "fix" this bug through user >> configuration... (ʘ‿ʘ) > Yes, this will fix the reported problem of customizability. > Maybe Eli will agree to fix this in emacs-27. I can post the corresponding patch, if it helps. >> Suggestions for a better (shorter?) name for the new function welcome, by >> the way. > Maybe next-error-find-keep-navigation. Short, but kinda cryptic (why "find"?). Not bad, but some other options: next-error-maybe-current-keep-navigation next-error-no-navigation-try-current From debbugs-submit-bounces@debbugs.gnu.org Mon May 25 11:17:55 2020 Received: (at 40919) by debbugs.gnu.org; 25 May 2020 15:17:55 +0000 Received: from localhost ([127.0.0.1]:42167 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdErT-000765-1Z for submit@debbugs.gnu.org; Mon, 25 May 2020 11:17:55 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48220) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdErS-00075t-6u for 40919@debbugs.gnu.org; Mon, 25 May 2020 11:17:54 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:50885) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jdErK-0001OA-Di; Mon, 25 May 2020 11:17:46 -0400 Received: from [176.228.60.248] (port=4701 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jdErJ-0006fj-Mq; Mon, 25 May 2020 11:17:46 -0400 Date: Mon, 25 May 2020 18:17:58 +0300 Message-Id: <83367ovyah.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <5c6d82c4-436e-9014-7dc7-0897caf76403@yandex.ru> (message from Dmitry Gutov on Mon, 25 May 2020 04:58:05 +0300) Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> <87zh9xuhq2.fsf@mail.linkov.net> <5c6d82c4-436e-9014-7dc7-0897caf76403@yandex.ru> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 40919 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.org, juri@linkov.net 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.3 (---) > From: Dmitry Gutov > Date: Mon, 25 May 2020 04:58:05 +0300 > Cc: 40919@debbugs.gnu.org, tspiteri@ieee.org > > On 25.05.2020 00:48, Juri Linkov wrote: > >>> Is this patch for master? So there is enough time for thorough testing? > >> I think it's for master. Though if we put it into emacs-27 and changed the > >> default to the name of the new function, the behavior shouldn't change, and > >> yet it would be easier to "fix" this bug through user > >> configuration... (ʘ‿ʘ) > > Yes, this will fix the reported problem of customizability. > > Maybe Eli will agree to fix this in emacs-27. > > I can post the corresponding patch, if it helps. It's okay to add a defcustom and a new function, but the other part of the patch changes the default behavior, and that is less okay. Can we do one without the other? (Btw, the textual descriptions of the options both in the patch and those already in the code are confusingly obscure, so much so that I don't think I could understand what each one does.) All in all, I feel (for quite some time) that this area is over-engineered and keeps bumping into more and more unintended consequences. Maybe it's time to take a step back and rethink the entire subject? (But definitely not on the release branch.) From debbugs-submit-bounces@debbugs.gnu.org Mon May 25 19:17:47 2020 Received: (at 40919) by debbugs.gnu.org; 25 May 2020 23:17:47 +0000 Received: from localhost ([127.0.0.1]:42805 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdMLq-0006PC-JE for submit@debbugs.gnu.org; Mon, 25 May 2020 19:17:47 -0400 Received: from mail-wr1-f43.google.com ([209.85.221.43]:41796) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdMLo-0006Ow-C7 for 40919@debbugs.gnu.org; Mon, 25 May 2020 19:17:44 -0400 Received: by mail-wr1-f43.google.com with SMTP id j10so2987194wrw.8 for <40919@debbugs.gnu.org>; Mon, 25 May 2020 16:17:44 -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; bh=O3WyNIFptkEUkXdNcTnOvrUyXidlj1SR+IMskXZqyPg=; b=n8sCgiYX1bgQLMIQaKpk8mVOiGuGRDTevm9H0G+0I/6G0s6ZCSIC7WPQuTdrqLCzOt 9DeDrgi6rgwVTqAv/oscWxRREZ04MKXQz8qnxAOE42oE1bRzzLGqZU/KRYbEFSygWgzY ki+pG5n4pZ16flUcQ0NWo3WB2/qkuN0acX9aCa4Fhr4Bgd8ml7I2SpfzmrTA29gJl3LI 8kHjOfCzrTEfdcYAsoNTAc0sL6bxqDtn3f3DAjBPt9hLCoxwIky1ZZk+C5gsT9/Sv3Bh dbPR5/B9xzg4U0AmEI34A9dQiljSKm1KP8VVIJhIgg0ebCY6adOKTK0PbgA6E2lj+/MR s4Mw== 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; bh=O3WyNIFptkEUkXdNcTnOvrUyXidlj1SR+IMskXZqyPg=; b=Oak/qz9E18E7OvDSssySd/6Pey1HSZPZgtyfrGbF/V//f23vEbm1C3xbp2mSmFVkPg 263NFXzb81rSw1d0Gbdw9O5RXZm8qiktsbH85cVHPTJxZI+OCDRiWQ9bghO9jwr0Js9d afWVJn5nmqPIdNyscXq92swYxejzBE7UJZA1xWoDtFKWUCSB4v1iYf63OBuHCaYSlgNH 3Hd+baklC0MbFDM5CTvwl6Gll7+26/8Nfhw7e1g6K04Z+PSqNukM+VELHOhuw3Fo2lAw N0gt7m4RAKfPEkIoVrhVuhcW+pWuGFp48YkMzYdVSYdHSPWYs9d11v9V9Zr4qkP1DYAM b+UQ== X-Gm-Message-State: AOAM5338bLzffvVlcRbM8l9N+NdGDkRyb2EBz3XYqCVqzj79JEgPCPUL bca+OF+/Fzx58ZkNXm56QqI= X-Google-Smtp-Source: ABdhPJwTrHnNyIY+9QRMjto9KmV5KhAZe46dcszBWAy7Ge9sZ6XK/+6sbB4t/d+LsI2h8uHUbG5jnw== X-Received: by 2002:adf:ecc8:: with SMTP id s8mr16377588wro.279.1590448658116; Mon, 25 May 2020 16:17:38 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id y37sm2409773wrd.55.2020.05.25.16.17.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 May 2020 16:17:37 -0700 (PDT) Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented To: Eli Zaretskii References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> <87zh9xuhq2.fsf@mail.linkov.net> <5c6d82c4-436e-9014-7dc7-0897caf76403@yandex.ru> <83367ovyah.fsf@gnu.org> From: Dmitry Gutov Message-ID: Date: Tue, 26 May 2020 02:17:34 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <83367ovyah.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------46E2D8ADF5B4FEA8A17A437F" Content-Language: en-US X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 40919 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.org, juri@linkov.net 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. --------------46E2D8ADF5B4FEA8A17A437F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 25.05.2020 18:17, Eli Zaretskii wrote: >>> Yes, this will fix the reported problem of customizability. >>> Maybe Eli will agree to fix this in emacs-27. >> >> I can post the corresponding patch, if it helps. > > It's okay to add a defcustom and a new function, but the other part of > the patch changes the default behavior, and that is less okay. Can we > do one without the other? The defcustom already exists. It currently defaults to #'ignore (do nothing). It is called in case #1. The attached patch moves case #2 into a new function and makes it the default value of the said defcustom (thus case #2 effectively moves into case #1). As a result, the default behavior doesn't change, but the user will have a much easier time turning off case #2. > (Btw, the textual descriptions of the options both in the patch and > those already in the code are confusingly obscure, so much so that I > don't think I could understand what each one does.) Knowing the subject matter somewhat, I think the descriptions are meaningful enough, but to make sense of them one has to understand how the whole feature comes together. E.g. at what times next-error-find-buffer is called. > All in all, I feel (for quite some time) that this area is > over-engineered and keeps bumping into more and more unintended > consequences. Maybe it's time to take a step back and rethink the > entire subject? (But definitely not on the release branch.) That's what we're doing here. If the attached patch is accepted for emacs-27, then on master we'll change next-error-find-buffer-function's default back to #'ignore (thus reverting to the previous path that I sent). And see if we find problems with how the result is working. So in the end, next-error-find-buffer-function will have three possible values: - Pre Emacs 27 behavior. - Emacs 27 behavior (extracted in the attached patch). - Simplified behavior with less buffer-local state (Emacs 28, hopefully). --------------46E2D8ADF5B4FEA8A17A437F Content-Type: text/x-patch; charset=UTF-8; name="next-error-extract-case-2-keep-current-behavior.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="next-error-extract-case-2-keep-current-behavior.diff" diff --git a/lisp/simple.el b/lisp/simple.el index 111afa69d1..a4b81719ce 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -199,7 +199,7 @@ next-error-buffer-p (and extra-test-inclusive (funcall extra-test-inclusive)))))) -(defcustom next-error-find-buffer-function #'ignore +(defcustom next-error-find-buffer-function #'next-error-no-navigation-try-current "Function called to find a `next-error' capable buffer. This functions takes the same three arguments as the function `next-error-find-buffer', and should return the buffer to be @@ -211,6 +211,8 @@ next-error-find-buffer-function :type '(choice (const :tag "No default" ignore) (const :tag "Single next-error capable buffer on selected frame" next-error-buffer-on-selected-frame) + (const :tag "Current buffer if next-error capable and outside navigation" + next-error-no-navigation-try-current) (function :tag "Other function")) :group 'next-error :version "27.1") @@ -240,6 +242,22 @@ next-error-buffer-on-selected-frame (if (eq (length window-buffers) 1) (car window-buffers)))) +(defun next-error-no-navigation-try-current (&optional + avoid-current + extra-test-inclusive + extra-test-exclusive) + "Try the current buffer when outside navigation. +But return nil if we navigated to the current buffer by the means +of `next-error' command. Othewise, return it if it's next-error +capable." + ;; Check that next-error-buffer has no buffer-local value + ;; (i.e. we never navigated to the current buffer from another), + ;; and the current buffer is a `next-error' capable buffer. + (if (and (not (local-variable-p 'next-error-buffer)) + (next-error-buffer-p (current-buffer) avoid-current + extra-test-inclusive extra-test-exclusive)) + (current-buffer))) + (defun next-error-find-buffer (&optional avoid-current extra-test-inclusive extra-test-exclusive) @@ -260,24 +278,16 @@ next-error-find-buffer (funcall next-error-find-buffer-function avoid-current extra-test-inclusive extra-test-exclusive) - ;; 2. If next-error-buffer has no buffer-local value - ;; (i.e. never navigated to the current buffer from another), - ;; and the current buffer is a `next-error' capable buffer, - ;; use it unconditionally, so next-error will always use it. - (if (and (not (local-variable-p 'next-error-buffer)) - (next-error-buffer-p (current-buffer) avoid-current - extra-test-inclusive extra-test-exclusive)) - (current-buffer)) - ;; 3. If next-error-last-buffer is an acceptable buffer, use that. + ;; 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 extra-test-inclusive extra-test-exclusive)) next-error-last-buffer) - ;; 4. If the current buffer is acceptable, choose it. + ;; 3. If the current buffer is acceptable, choose it. (if (next-error-buffer-p (current-buffer) avoid-current extra-test-inclusive extra-test-exclusive) (current-buffer)) - ;; 5. Look for any acceptable buffer. + ;; 4. Look for any acceptable buffer. (let ((buffers (buffer-list))) (while (and buffers (not (next-error-buffer-p @@ -285,7 +295,7 @@ next-error-find-buffer extra-test-inclusive extra-test-exclusive))) (setq buffers (cdr buffers))) (car buffers)) - ;; 6. Use the current buffer as a last resort if it qualifies, + ;; 5. Use the current buffer as a last resort if it qualifies, ;; even despite AVOID-CURRENT. (and avoid-current (next-error-buffer-p (current-buffer) nil @@ -293,7 +303,7 @@ next-error-find-buffer (progn (message "This is the only buffer with error message locations") (current-buffer))) - ;; 7. Give up. + ;; 6. Give up. (error "No buffers contain error message locations"))) (defun next-error (&optional arg reset) --------------46E2D8ADF5B4FEA8A17A437F-- From debbugs-submit-bounces@debbugs.gnu.org Tue May 26 12:07:26 2020 Received: (at 40919) by debbugs.gnu.org; 26 May 2020 16:07:26 +0000 Received: from localhost ([127.0.0.1]:46245 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdc6n-0006QV-Ir for submit@debbugs.gnu.org; Tue, 26 May 2020 12:07:25 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45298) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdc6m-0006QH-0d for 40919@debbugs.gnu.org; Tue, 26 May 2020 12:07:16 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46936) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jdc6e-0005mk-Gi; Tue, 26 May 2020 12:07:08 -0400 Received: from [176.228.60.248] (port=1413 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jdc6d-0000K1-Hy; Tue, 26 May 2020 12:07:08 -0400 Date: Tue, 26 May 2020 19:06:53 +0300 Message-Id: <83367mvfxe.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: (message from Dmitry Gutov on Tue, 26 May 2020 02:17:34 +0300) Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> <87zh9xuhq2.fsf@mail.linkov.net> <5c6d82c4-436e-9014-7dc7-0897caf76403@yandex.ru> <83367ovyah.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 40919 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.org, juri@linkov.net 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.3 (---) > Cc: juri@linkov.net, 40919@debbugs.gnu.org, tspiteri@ieee.org > From: Dmitry Gutov > Date: Tue, 26 May 2020 02:17:34 +0300 > > The attached patch moves case #2 into a new function and makes it the > default value of the said defcustom (thus case #2 effectively moves into > case #1). As a result, the default behavior doesn't change, but the user > will have a much easier time turning off case #2. Maybe I don't understand something, but it looks to me that this changes the behavior if next-error-find-buffer-function has a non-default value: previously what's now next-error-no-navigation-try-current would be executed after calling next-error-find-buffer-function, now it isn't. Is that really necessary? > > (Btw, the textual descriptions of the options both in the patch and > > those already in the code are confusingly obscure, so much so that I > > don't think I could understand what each one does.) > > Knowing the subject matter somewhat, I think the descriptions are > meaningful enough, but to make sense of them one has to understand how > the whole feature comes together. E.g. at what times > next-error-find-buffer is called. I think I know something about the subject matter, and still the text is quite impenetrable for me. > > All in all, I feel (for quite some time) that this area is > > over-engineered and keeps bumping into more and more unintended > > consequences. Maybe it's time to take a step back and rethink the > > entire subject? (But definitely not on the release branch.) > > That's what we're doing here. Sigh. From debbugs-submit-bounces@debbugs.gnu.org Tue May 26 12:21:00 2020 Received: (at 40919) by debbugs.gnu.org; 26 May 2020 16:21:00 +0000 Received: from localhost ([127.0.0.1]:46254 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdcK4-0006k7-9r for submit@debbugs.gnu.org; Tue, 26 May 2020 12:21:00 -0400 Received: from mail-wm1-f50.google.com ([209.85.128.50]:50912) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdcK3-0006jv-4c for 40919@debbugs.gnu.org; Tue, 26 May 2020 12:20:59 -0400 Received: by mail-wm1-f50.google.com with SMTP id v19so141150wmj.0 for <40919@debbugs.gnu.org>; Tue, 26 May 2020 09:20:59 -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=q6zI8pumNUFbsmlCIQfSpn8M0pgc62J0KHMPHoTxB18=; b=PZ+Qb8mPMcrjaW4VWjUMwZoyDRl40BANeSawp0She+zJs9SmF3ps7JuLWWIKdlJFVI uK+WYAPdQu+Az9mUgLgU8VjbCM2E+QB/81JjnwU6zVjP9GCg8L12Sm/xcPNKdxndGglh 9QaYVRmMZwD0Lfm0In8MrnYLY2RUxkCW07gZXotUuLxVGt02P/iTl1fxqX10KOpp2sI5 ONPKvDOkEWpVMjxUTLg16cQpkrQEmrsZSjI8+h8iR3iLgHps5OrKJikhw7zAW3O/SiYw mFsEo4r7Dl1lXnwz6s5d/XbciEY8mGsWgcij7F1waYJZumxNeyX2M9GnpyNe9QOpQ5RO mYjg== 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=q6zI8pumNUFbsmlCIQfSpn8M0pgc62J0KHMPHoTxB18=; b=WbA/MmstZQt3M2P6EIBGfE86ERm6dXVbYpX/iN0cicLm1APLn/1X0f2YMdyNRVgVLh X8PZNuypNgQ65Lcur232Z7sn7UuE+IRv5gFDMRUwchslHNUsSZ7vVm/wGDkMcNm+/dV3 rbiDE8ZjmK0I2iZf/+iFr/6gmzs5xkwdtB9gaF7khbYEMuX+NHKS8xBaXXs76JzEBSMt pdHcrRDMFM1ynCFHSuqOiw+tUKoWdmsU+UuxGEWWXKf+ImANgLsucLP4RS1ht1PiJ0+/ VJUQfyqX/01KpaqPjqzd3tKeTbnJvVg8PklGMh47dXhsn0dcirmxxxOrvdEFA3o2we1x TKBQ== X-Gm-Message-State: AOAM5319eMHvlMPIm/UddfHfLpHedsVunR98Yx2WnWYoUZHftvjelq6i ck/qEOCmG98tRMFRzpf44OA= X-Google-Smtp-Source: ABdhPJxLWsrfCksQfUs1n51oiqoj50xoam1Ml6euRus7CDxJUgOIhd9qYlyJ8qw/YOp88tHRxND1uA== X-Received: by 2002:a7b:c7d8:: with SMTP id z24mr53625wmk.28.1590510053283; Tue, 26 May 2020 09:20:53 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id p3sm279571wru.95.2020.05.26.09.20.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2020 09:20:52 -0700 (PDT) Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented To: Eli Zaretskii References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> <87zh9xuhq2.fsf@mail.linkov.net> <5c6d82c4-436e-9014-7dc7-0897caf76403@yandex.ru> <83367ovyah.fsf@gnu.org> <83367mvfxe.fsf@gnu.org> From: Dmitry Gutov Message-ID: <22867ca3-1fa8-96d0-4895-4875eba6ff87@yandex.ru> Date: Tue, 26 May 2020 19:20:50 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <83367mvfxe.fsf@gnu.org> 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: 40919 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.org, juri@linkov.net 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 26.05.2020 19:06, Eli Zaretskii wrote: >> Cc: juri@linkov.net, 40919@debbugs.gnu.org, tspiteri@ieee.org >> From: Dmitry Gutov >> Date: Tue, 26 May 2020 02:17:34 +0300 >> >> The attached patch moves case #2 into a new function and makes it the >> default value of the said defcustom (thus case #2 effectively moves into >> case #1). As a result, the default behavior doesn't change, but the user >> will have a much easier time turning off case #2. > > Maybe I don't understand something, but it looks to me that this > changes the behavior if next-error-find-buffer-function has a > non-default value: Yes. I only claimed that the _default_ behavior doesn't change. The user option was only added in Emacs 27, so this doesn't seem to be a big problem. > previously what's now > next-error-no-navigation-try-current would be executed after calling > next-error-find-buffer-function, now it isn't. Is that really > necessary? It seems to be the best and safest option at the moment. I imagine that if someone customized the variable they either used the only available non-#'ignore value and thus want the Emacs 26 behavior (so taking out case #2 would only make them happier), or wrong their own function, in which case they might need to update that function. >>> (Btw, the textual descriptions of the options both in the patch and >>> those already in the code are confusingly obscure, so much so that I >>> don't think I could understand what each one does.) >> >> Knowing the subject matter somewhat, I think the descriptions are >> meaningful enough, but to make sense of them one has to understand how >> the whole feature comes together. E.g. at what times >> next-error-find-buffer is called. > > I think I know something about the subject matter, and still the text > is quite impenetrable for me. Perhaps they could be improved. Still, the situation is probably better than it was before. Do the 'next-error' entries in NEWS.27 make sense to you, BTW? >>> All in all, I feel (for quite some time) that this area is >>> over-engineered and keeps bumping into more and more unintended >>> consequences. Maybe it's time to take a step back and rethink the >>> entire subject? (But definitely not on the release branch.) >> >> That's what we're doing here. > > Sigh. Also see the related discussion in emacs-devel (one that stems from 2018). From debbugs-submit-bounces@debbugs.gnu.org Tue May 26 12:34:36 2020 Received: (at 40919) by debbugs.gnu.org; 26 May 2020 16:34:36 +0000 Received: from localhost ([127.0.0.1]:46290 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdcWz-00076A-7e for submit@debbugs.gnu.org; Tue, 26 May 2020 12:34:36 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53230) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdcWx-00075y-39 for 40919@debbugs.gnu.org; Tue, 26 May 2020 12:34:19 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47693) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jdcWo-0005TN-2K; Tue, 26 May 2020 12:34:11 -0400 Received: from [176.228.60.248] (port=3082 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jdcWn-0003qc-CT; Tue, 26 May 2020 12:34:09 -0400 Date: Tue, 26 May 2020 19:33:54 +0300 Message-Id: <83tv02u03x.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <22867ca3-1fa8-96d0-4895-4875eba6ff87@yandex.ru> (message from Dmitry Gutov on Tue, 26 May 2020 19:20:50 +0300) Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> <87zh9xuhq2.fsf@mail.linkov.net> <5c6d82c4-436e-9014-7dc7-0897caf76403@yandex.ru> <83367ovyah.fsf@gnu.org> <83367mvfxe.fsf@gnu.org> <22867ca3-1fa8-96d0-4895-4875eba6ff87@yandex.ru> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 40919 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.org, juri@linkov.net 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.0 (-) > Cc: 40919@debbugs.gnu.org, tspiteri@ieee.org, juri@linkov.net > From: Dmitry Gutov > Date: Tue, 26 May 2020 19:20:50 +0300 > > > Maybe I don't understand something, but it looks to me that this > > changes the behavior if next-error-find-buffer-function has a > > non-default value: > > Yes. I only claimed that the _default_ behavior doesn't change. The user > option was only added in Emacs 27, so this doesn't seem to be a big problem. OK. From debbugs-submit-bounces@debbugs.gnu.org Tue May 26 16:39:41 2020 Received: (at 40919) by debbugs.gnu.org; 26 May 2020 20:39:41 +0000 Received: from localhost ([127.0.0.1]:46475 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdgMO-0004Ss-R6 for submit@debbugs.gnu.org; Tue, 26 May 2020 16:39:41 -0400 Received: from mail-wm1-f44.google.com ([209.85.128.44]:55549) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdgMM-0004Sc-Gu for 40919@debbugs.gnu.org; Tue, 26 May 2020 16:39:38 -0400 Received: by mail-wm1-f44.google.com with SMTP id c71so947159wmd.5 for <40919@debbugs.gnu.org>; Tue, 26 May 2020 13:39:38 -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=9s4TePam84CJMqua6KdyNSkmwFmfZjSxbwkqBRsZEoM=; b=k2bTp/iI/DY3+pTLFyhrpRNmEw6taopxsaiPWjfZYejFfVO7/7I0fpq30gAJWOeSk6 PKGn+ZxldDdrLeRSdfJEfIQX0Tu7YtwJNRQ/LO83HL2LN7UdpWGAoR3N5Rg75yi1I6DK N2aNRBVoX73GzKoHfaAutMs6KWiriIFYkbp6B/IYiSCZPcFj70DRvWzxGe9jUyVUD/CL 1d2tOfkcXXhyehm4V3quLQPEdd2NYGwIBkZOzZSzZv1C6tkPhgJqpG1Mjq4v90z+BCDJ nSNY86esqhLniY0yFg9yo3xCMa8cGGXTaK7EQMuWdNU7IZIedc+EwZ5dx4moe5HuB7VO J04w== 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=9s4TePam84CJMqua6KdyNSkmwFmfZjSxbwkqBRsZEoM=; b=ICE/yeYfWwCW7+sQ5XHdwH2reZ2Uj24EG0gLrh+SVnO6GazIumIKBoxLOIceoo/ww7 99MVoLzEleewnUGN5pBauHP6nUI0vWCc8+lhDMjcMD+vwkEp4xHX762RpDBOxN1pH6kf vcGrmJeS86isVgKni9+x3vGyfnNuolecn6YSu+D6X0DIpfjtU4C5KLb9ui/TwLQbNelF i4GZCeRic30TjP9p+ZIgsL3QesThQp6w6AOc/ieGoP5edxpn5vclf6FKzj20/MlEuyfE VkV2WUwxyXW3R7uP11tBi+JTMCKt8zbkA/EGQIUs70oRfGbxF0xGhrjJ0CoojyoKQUxF xKfA== X-Gm-Message-State: AOAM531TdH7IA3BR18G6INXCIS66C+NpVik/p4yViCvyWPIjdJIsPYGf Mc5OM2vPdgS4fPg+sfRf+Ks= X-Google-Smtp-Source: ABdhPJwl/Lv8wWNKyKIEga//TYD5N6EjdYNsard0qyu0PawlY5DxDTp8ohQp4dv0xMrCFVpkiJU7kQ== X-Received: by 2002:a1c:1b11:: with SMTP id b17mr885461wmb.123.1590525572622; Tue, 26 May 2020 13:39:32 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id h5sm822205wrw.85.2020.05.26.13.39.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2020 13:39:31 -0700 (PDT) Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented To: Eli Zaretskii References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> <87zh9xuhq2.fsf@mail.linkov.net> <5c6d82c4-436e-9014-7dc7-0897caf76403@yandex.ru> <83367ovyah.fsf@gnu.org> <83367mvfxe.fsf@gnu.org> <22867ca3-1fa8-96d0-4895-4875eba6ff87@yandex.ru> <83tv02u03x.fsf@gnu.org> From: Dmitry Gutov Message-ID: <2460caac-bd76-f177-1583-c2c6ab6f74e7@yandex.ru> Date: Tue, 26 May 2020 23:39:30 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <83tv02u03x.fsf@gnu.org> 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: 40919 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.org, juri@linkov.net 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 26.05.2020 19:33, Eli Zaretskii wrote: >> Cc:40919@debbugs.gnu.org,tspiteri@ieee.org,juri@linkov.net >> From: Dmitry Gutov >> Date: Tue, 26 May 2020 19:20:50 +0300 >> >>> Maybe I don't understand something, but it looks to me that this >>> changes the behavior if next-error-find-buffer-function has a >>> non-default value: >> Yes. I only claimed that the_default_ behavior doesn't change. The user >> option was only added in Emacs 27, so this doesn't seem to be a big problem. > OK. Thank you. (I'll take this to mean that the patch is OK for emacs-27.) From debbugs-submit-bounces@debbugs.gnu.org Wed May 27 15:18:17 2020 Received: (at 40919-done) by debbugs.gnu.org; 27 May 2020 19:18:17 +0000 Received: from localhost ([127.0.0.1]:50012 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1je1ZB-0004md-59 for submit@debbugs.gnu.org; Wed, 27 May 2020 15:18:17 -0400 Received: from mail-wr1-f48.google.com ([209.85.221.48]:38372) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1je1Z8-0004mP-Rd for 40919-done@debbugs.gnu.org; Wed, 27 May 2020 15:18:15 -0400 Received: by mail-wr1-f48.google.com with SMTP id e1so25283271wrt.5 for <40919-done@debbugs.gnu.org>; Wed, 27 May 2020 12:18:14 -0700 (PDT) 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=7kCT4BYMT4iLnfPQ2SDinOVDWdiaTItaJoImdE3w6MI=; b=bul55CJaEN1xS+AmWG/ndyxv+G8GOIS3sxU+uvKfxbk3g5PKmIUboyq19F45hOlBrI pRIxjzBFAaEV3FlbQFAHu/hcTJ/35UeIWGWOP/3uOF6Bt0UCfDI8hmqknzWZKnh5t4SX xddMfr+IT8OvahcNBiJknnOvQ24ceNLhDnLACsMBXSeVjiBUfneNR4qRc1Jvivx450CD YcuQ51X1YwTCRqFomtorWS2gPeC/UG7ilRCUoPLeR1Ilh1JXR7Fj162gflxJPKD9ofJZ V4KEpDF9oMGUhrdedxnCPSGxafUSgdgDiSCxtqU6MQJCDKreqLnF3umDGsqmX7HXVpOA 9HfA== 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=7kCT4BYMT4iLnfPQ2SDinOVDWdiaTItaJoImdE3w6MI=; b=GhGBVNPNph+NRkOj4gpa/r7wPzto59NEKOam/1x4qsCs/jWWoRkqWgbAJbAaBWHSr8 wIu9ffQ+nF1lqFmHjiedifggASXt6AUejAnxCYdepxrExTxZBFzvJCiDLsIvSesS6VyH y610yVV8uneRg0mQI+VEP990pvstblwEqYk/xzYonl0r7uWdJZ4Z7/O66/jtbnzcdEa+ vgzFLwxMNNm4/9D2Hj5VFM461w1bbzrCS5P15UXEzJXa3xhh0uu/NW95X9qQ/S78SWXb vvsSkanR7wP8ja/j77qTyaax4XiFXnxtPCLClcvjX/1FgikDJVBVdlZtuk6PnLQwmg6Y 3twQ== X-Gm-Message-State: AOAM531yXb1RoAwQOPa2HyCV83KCEuN7oEcJge0cnVFMmugt2PdHW+S7 kXqcK06ZbN5CgzgA7fML7XY= X-Google-Smtp-Source: ABdhPJzGy4nqt3q6R+5eWqVpJowHQPYy03UXH6XCfSyNowo4gBucoYbsf5ou2rFlC2Jsme+5qTGwlg== X-Received: by 2002:adf:a4d6:: with SMTP id h22mr18880987wrb.300.1590607088968; Wed, 27 May 2020 12:18:08 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id t13sm3700296wrn.64.2020.05.27.12.18.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 May 2020 12:18:08 -0700 (PDT) Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented From: Dmitry Gutov To: Eli Zaretskii References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> <87zh9xuhq2.fsf@mail.linkov.net> <5c6d82c4-436e-9014-7dc7-0897caf76403@yandex.ru> <83367ovyah.fsf@gnu.org> <83367mvfxe.fsf@gnu.org> <22867ca3-1fa8-96d0-4895-4875eba6ff87@yandex.ru> <83tv02u03x.fsf@gnu.org> <2460caac-bd76-f177-1583-c2c6ab6f74e7@yandex.ru> Message-ID: Date: Wed, 27 May 2020 22:18:06 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <2460caac-bd76-f177-1583-c2c6ab6f74e7@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: 40919-done Cc: 40919-done@debbugs.gnu.org, tspiteri@ieee.org, juri@linkov.net 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 (/) Version: 27.1 Aand pushed. Trevor, you can now try different values of next-error-find-buffer-function (in particular, #'ignore) and see which behaves more to your liking. Thanks all, closing. From debbugs-submit-bounces@debbugs.gnu.org Thu May 28 19:07:28 2020 Received: (at 40919) by debbugs.gnu.org; 28 May 2020 23:07:28 +0000 Received: from localhost ([127.0.0.1]:53244 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeRcW-0006cv-2X for submit@debbugs.gnu.org; Thu, 28 May 2020 19:07:28 -0400 Received: from mail-wr1-f49.google.com ([209.85.221.49]:43877) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jeRcT-0006cg-2o for 40919@debbugs.gnu.org; Thu, 28 May 2020 19:07:26 -0400 Received: by mail-wr1-f49.google.com with SMTP id l10so1124974wrr.10 for <40919@debbugs.gnu.org>; Thu, 28 May 2020 16:07:25 -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=T4BmaYpsYsj1vlFakpxpw/0PmmYpZwvaXtVRhr7umjc=; b=rcN7S5DHI47iByNVS31pUIj9m9o9eVQQWM6oWeoTQ9rPbuU9ySnU4MPmsB7yvobrjC zO8EQ31CQ9+O3v0r7F+FUVFwpHf7mRlyxMgwLUjkT/DrXODA8REhmHrnyiZMbHVLh+ea tGk/205Kho06tTiF3XepH0/h3FhYr5HzB8GhCP3t/kJm3pfmBLqT9vs4FEWTxEB3ka8b r+aSrNkZvLAQjH2FourcGzyqp9QEy7BNIRG8S9+3hzIvMF2BvvPJQdfxqG6jd7GIYrjm o6ynOZrTpbNXWNSgaVjWlz6faIu0bG1l+y97T3h+m5guCBzs8xDERzcWK5FIfI9cBgq/ b12A== 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=T4BmaYpsYsj1vlFakpxpw/0PmmYpZwvaXtVRhr7umjc=; b=eQMSuzbtbe1KN/udeHmEzVCgx55BtUB0X3fd+pAEywH6wPM4kk11YYIa0TaeolD5jZ SMLp2X7W0IuK0F1WhBsL7f3OAeEGwnfLSmbfrZ4KT0PuIkoXKbB0eHXODSG1xSnFTOfp JaWus7215xzutG28YYzovJA3wHLKcWt3x66pyDUm647OgOCqMQAgQLx0WTGvvc7I71g9 RhPdpqd1d79b4yC30t5meIVXeSLRZjACSFSo6rWrpRaNJqgTUEWhmn9flYjsTOyev1Ou maKWPpAWcBCce0yt+DSGJo8oT4Ye0az084TbY/B0gJdtJ4zpyU5ri3krdA/j3sxyFvyG wh7g== X-Gm-Message-State: AOAM530DQoSKFj9Kt1CbMxGbfq2BbBGp7YpKhK8aiV+oie+d+5Ni8VkQ 3J9D6+D+47X4Hv1L6FKdbmo= X-Google-Smtp-Source: ABdhPJy7KPoc3O4gmqS5/u3lY0K6EZqXQh+GUHLNIT0Ve/3M+H4b2PmgFvi0tAVu4qZ26i4CkATNMQ== X-Received: by 2002:adf:f0c3:: with SMTP id x3mr5540531wro.35.1590707239267; Thu, 28 May 2020 16:07:19 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id z6sm7443665wrh.79.2020.05.28.16.07.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 May 2020 16:07:18 -0700 (PDT) Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented To: Juri Linkov References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <251b7e0d-ef94-e438-4023-a6513b611725@yandex.ru> Date: Fri, 29 May 2020 02:07:17 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <87zh9yuw5o.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: 40919 Cc: Eli Zaretskii , 40919@debbugs.gnu.org, tspiteri@ieee.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 24.05.2020 01:24, Juri Linkov wrote: >>> But I'm not proud of the case no. 2, so you can drop it:) >>> Or better move it to a separate function and provide this function >>> as an option in next-error-find-buffer-function. >> Patch attached. Comments welcome. > Is this patch for master? So there is enough time for thorough testing? And it's now in master. From debbugs-submit-bounces@debbugs.gnu.org Sat May 30 18:34:26 2020 Received: (at 40919) by debbugs.gnu.org; 30 May 2020 22:34:26 +0000 Received: from localhost ([127.0.0.1]:59372 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jfA3e-0004g9-Et for submit@debbugs.gnu.org; Sat, 30 May 2020 18:34:26 -0400 Received: from relay7-d.mail.gandi.net ([217.70.183.200]:59095) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jfA3a-0004ff-UJ for 40919@debbugs.gnu.org; Sat, 30 May 2020 18:34:23 -0400 X-Originating-IP: 91.129.108.6 Received: from mail.gandi.net (m91-129-108-6.cust.tele2.ee [91.129.108.6]) (Authenticated sender: juri@linkov.net) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id 1F06620003; Sat, 30 May 2020 22:34:14 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented Organization: LINKOV.NET References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> <87zh9xuhq2.fsf@mail.linkov.net> <5c6d82c4-436e-9014-7dc7-0897caf76403@yandex.ru> Date: Sun, 31 May 2020 01:29:07 +0300 In-Reply-To: <5c6d82c4-436e-9014-7dc7-0897caf76403@yandex.ru> (Dmitry Gutov's message of "Mon, 25 May 2020 04:58:05 +0300") Message-ID: <87eer1njkc.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40919 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.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.7 (-) >>> Suggestions for a better (shorter?) name for the new function welcome, by >>> the way. >> Maybe next-error-find-keep-navigation. > > Short, but kinda cryptic (why "find"?). Not bad, but some other options: Sorry, a typo, I meant next-error-keep-navigation. > next-error-maybe-current-keep-navigation > next-error-no-navigation-try-current Not bad, I guess it's difficult to find a name that it both short and self-describing. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 01 19:03:00 2020 Received: (at 40919) by debbugs.gnu.org; 1 Jun 2020 23:03:00 +0000 Received: from localhost ([127.0.0.1]:37279 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jftSO-0004G0-6M for submit@debbugs.gnu.org; Mon, 01 Jun 2020 19:03:00 -0400 Received: from relay9-d.mail.gandi.net ([217.70.183.199]:54115) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jftSM-0004Fj-Ce for 40919@debbugs.gnu.org; Mon, 01 Jun 2020 19:02:58 -0400 X-Originating-IP: 91.129.108.6 Received: from mail.gandi.net (m91-129-108-6.cust.tele2.ee [91.129.108.6]) (Authenticated sender: juri@linkov.net) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id 52152FF802; Mon, 1 Jun 2020 23:02:49 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented Organization: LINKOV.NET References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> <251b7e0d-ef94-e438-4023-a6513b611725@yandex.ru> Date: Tue, 02 Jun 2020 01:41:39 +0300 In-Reply-To: <251b7e0d-ef94-e438-4023-a6513b611725@yandex.ru> (Dmitry Gutov's message of "Fri, 29 May 2020 02:07:17 +0300") Message-ID: <87lfl6tojw.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40919 Cc: Eli Zaretskii , 40919@debbugs.gnu.org, tspiteri@ieee.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.7 (-) >>>> But I'm not proud of the case no. 2, so you can drop it:) >>>> Or better move it to a separate function and provide this function >>>> as an option in next-error-find-buffer-function. >>> Patch attached. Comments welcome. >> Is this patch for master? So there is enough time for thorough testing? > > And it's now in master. Thanks. Tho I think in master next-error-find-buffer-function should support a list of functions, so the user could customize their order to arrange their priorities. Then they could be called with run-hook-with-args-until-success. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 01 19:04:50 2020 Received: (at 40919) by debbugs.gnu.org; 1 Jun 2020 23:04:50 +0000 Received: from localhost ([127.0.0.1]:37289 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jftUA-0004JA-MY for submit@debbugs.gnu.org; Mon, 01 Jun 2020 19:04:50 -0400 Received: from mail-wm1-f53.google.com ([209.85.128.53]:52537) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jftU8-0004Iw-Gn for 40919@debbugs.gnu.org; Mon, 01 Jun 2020 19:04:48 -0400 Received: by mail-wm1-f53.google.com with SMTP id r9so1074291wmh.2 for <40919@debbugs.gnu.org>; Mon, 01 Jun 2020 16:04:48 -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=bQDVjF4e+yWg5fAC8LYRUFWegRkdvVWVFkSluvQEEmg=; b=pGOo6c8BB3tnSdBMkCUCsTF6gTeMYkrxVbXH9ua6+tS3EDVcl0kPR8OSDzRXrZVMhd vT97CxI/8GCJR2Z9BNYdLmsbrc5yJgxgg2okEaAeji98usg6//2gUgcSAUaw3RVLvYuY aJEtVhTK57RIM7gVAitSxzeZ3sfWiTW+MR+p+Ao6RmZDg43Dq4w5wstWyXL1XqVI+edu EI+aj5RI5qkPZiO62TJNJsNTFJrjg3SQk5SCMEA2Y58IDYQ1yXUJGEuYOpMtJfiokKcz A9LXjNGwvMBRlsZxnXV0BZNV8kZDRLbS7Zaqi+m0qddqmCWGMWfaCQqWDTnSh+a6Nqop 9sog== 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=bQDVjF4e+yWg5fAC8LYRUFWegRkdvVWVFkSluvQEEmg=; b=O9Wt380X3QaFEX0QvLA8KqtJVo+1h5EVzFfmXaP87oVR7tTimKd8khnemiNiir58wD ncRGsH+NnzRhHFIXd8q1Od09+YcN++3MV9iz8CyXYJShHTP2PEHr4yqzrjv5aGT82h6S Xmn1BYG+Y04ngyr1dnvZN5CKmbKPkUO55nGHoLy20Lg/3eLu2Kb4tH/jzeFvZ58ixpwb RHs5Btlwh77r3RIm9ezW9SfU2MxvDIOTFtomqb4Wcn6qjtDUPihdX3x7fmI0tfCc+eeo SFM9EG+kXQsABbsQ49rLtmC2sFlsz9Z5oDFCsz4uJZlIxxCY+QZL+Jm6qJAf+2saAnbj Hczw== X-Gm-Message-State: AOAM5322673dtqPXb46l4deknUBqIqUYo3yshKZxTG2cOUwjNjLSCxb5 Ico62BWYxwOGJ7adGDLYa88= X-Google-Smtp-Source: ABdhPJyjTvebDaDmrWdb/V1azoABslW4qpmDcsWKSQgeJVtbfMFRVD3xhC5+yc4a3qBgvMM3mA0wEw== X-Received: by 2002:a1c:408:: with SMTP id 8mr1336946wme.15.1591052682554; Mon, 01 Jun 2020 16:04:42 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id 23sm1018412wmo.18.2020.06.01.16.04.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Jun 2020 16:04:41 -0700 (PDT) Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented To: Juri Linkov References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> <251b7e0d-ef94-e438-4023-a6513b611725@yandex.ru> <87lfl6tojw.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: Date: Tue, 2 Jun 2020 02:04:39 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <87lfl6tojw.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: 40919 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.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.06.2020 01:41, Juri Linkov wrote: > Tho I think in master next-error-find-buffer-function > should support a list of functions, so the user could customize > their order to arrange their priorities. Then they could be called > with run-hook-with-args-until-success. I suppose. We should perhaps wait and see if people do customize that variable at all. But the idea is solid. From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 10 19:20:38 2020 Received: (at 40919) by debbugs.gnu.org; 10 Jun 2020 23:20:38 +0000 Received: from localhost ([127.0.0.1]:35596 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jjA1O-0000zF-AY for submit@debbugs.gnu.org; Wed, 10 Jun 2020 19:20:38 -0400 Received: from relay7-d.mail.gandi.net ([217.70.183.200]:45703) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jjA1M-0000yz-Ly for 40919@debbugs.gnu.org; Wed, 10 Jun 2020 19:20:37 -0400 X-Originating-IP: 91.129.108.6 Received: from mail.gandi.net (m91-129-108-6.cust.tele2.ee [91.129.108.6]) (Authenticated sender: juri@linkov.net) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id E64E920006; Wed, 10 Jun 2020 23:20:28 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented Organization: LINKOV.NET References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> <87zh9xuhq2.fsf@mail.linkov.net> <5c6d82c4-436e-9014-7dc7-0897caf76403@yandex.ru> <87eer1njkc.fsf@mail.linkov.net> Date: Thu, 11 Jun 2020 02:03:11 +0300 In-Reply-To: <87eer1njkc.fsf@mail.linkov.net> (Juri Linkov's message of "Sun, 31 May 2020 01:29:07 +0300") Message-ID: <87sgf2mt44.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40919 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.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.7 (-) >> next-error-maybe-current-keep-navigation >> next-error-no-navigation-try-current > > Not bad, I guess it's difficult to find a name that it both short and self-describing. I found a better name: next-error-buffer-unnavigated-current From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 10 19:20:46 2020 Received: (at 40919) by debbugs.gnu.org; 10 Jun 2020 23:20:47 +0000 Received: from localhost ([127.0.0.1]:35599 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jjA1T-0000zX-Gn for submit@debbugs.gnu.org; Wed, 10 Jun 2020 19:20:46 -0400 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:39035) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jjA1R-0000z6-AT for 40919@debbugs.gnu.org; Wed, 10 Jun 2020 19:20:41 -0400 X-Originating-IP: 91.129.108.6 Received: from mail.gandi.net (m91-129-108-6.cust.tele2.ee [91.129.108.6]) (Authenticated sender: juri@linkov.net) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 5DBCCE0002; Wed, 10 Jun 2020 23:20:32 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented Organization: LINKOV.NET References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> <251b7e0d-ef94-e438-4023-a6513b611725@yandex.ru> <87lfl6tojw.fsf@mail.linkov.net> Date: Thu, 11 Jun 2020 02:05:39 +0300 In-Reply-To: (Dmitry Gutov's message of "Tue, 2 Jun 2020 02:04:39 +0300") Message-ID: <87a71amsho.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40919 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.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.7 (-) --=-=-= Content-Type: text/plain >> Tho I think in master next-error-find-buffer-function >> should support a list of functions, so the user could customize >> their order to arrange their priorities. Then they could be called >> with run-hook-with-args-until-success. > > I suppose. > > We should perhaps wait and see if people do customize that variable at > all. But the idea is solid. Actually, people already want to customize it to a list (at least, I know one such user :) So here is a patch: --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=next-error-find-buffer-function-repeat.patch diff --git a/lisp/simple.el b/lisp/simple.el index 0fe8a1025c..646236879c 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -199,7 +199,7 @@ next-error-buffer-p (and extra-test-inclusive (funcall extra-test-inclusive)))))) -(defcustom next-error-find-buffer-function #'ignore +(defcustom next-error-find-buffer-function '(ignore) "Function called to find a `next-error' capable buffer. This functions takes the same three arguments as the function `next-error-find-buffer', and should return the buffer to be @@ -208,12 +208,13 @@ next-error-find-buffer-function If the function returns nil, `next-error-find-buffer' will try to use the buffer it used previously, and failing that all other buffers." - :type '(choice (const :tag "No default" ignore) - (const :tag "Single next-error capable buffer on selected frame" - next-error-buffer-on-selected-frame) - (const :tag "Current buffer if next-error capable and outside navigation" - next-error-no-navigation-try-current) - (function :tag "Other function")) + :type '(repeat + (choice (const :tag "No default" ignore) + (const :tag "Single next-error capable buffer on selected frame" + next-error-buffer-on-selected-frame) + (const :tag "Current buffer if next-error capable and outside navigation" + next-error-no-navigation-try-current) + (function :tag "Other function"))) :group 'next-error :version "28.1") @@ -275,9 +276,13 @@ next-error-find-buffer that buffer is rejected." (or ;; 1. If a customizable function returns a buffer, use it. - (funcall next-error-find-buffer-function avoid-current - extra-test-inclusive - extra-test-exclusive) + (or (and (functionp next-error-find-buffer-function) + (funcall next-error-find-buffer-function avoid-current + extra-test-inclusive extra-test-exclusive)) + (and (listp next-error-find-buffer-function) + (run-hook-with-args-until-success + '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 Wed Jun 10 19:28:40 2020 Received: (at 40919) by debbugs.gnu.org; 10 Jun 2020 23:28:40 +0000 Received: from localhost ([127.0.0.1]:35620 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jjA9A-0001D8-E0 for submit@debbugs.gnu.org; Wed, 10 Jun 2020 19:28:40 -0400 Received: from mail-wr1-f45.google.com ([209.85.221.45]:33618) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jjA98-0001Ct-JY for 40919@debbugs.gnu.org; Wed, 10 Jun 2020 19:28:39 -0400 Received: by mail-wr1-f45.google.com with SMTP id l11so4214661wru.0 for <40919@debbugs.gnu.org>; Wed, 10 Jun 2020 16:28:38 -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=7cvcp+WlaSsvNS/HJPsj4q1U+MbwsYyPqFW5A3aLjc4=; b=KkxJomCaAoW2NtWOOeUfraJTSBlFHuV3fH7SfsRGT90cUKRCW0WdD3GScmhnYzXUDz ts13J11XzScRV4G6ncXbmO3uCfMpyusV0prbbeHre9XC05ix9umJfKO2tr1XhZtSQNXh kTix2a2vVRXBx0O4MxV9xIdv929SA67tCgwKEnf4gVh0m/Z2591bXOGxgQeTx391IrxQ ojpaIp82GDd5VYezV/5pZnnZWyqk9pXEt/K1yWx9I9DRTXWI1M70knO/N8d4ULZcoL6d NucMQlRMyig0UBul2QCtgpy4BYsh3iyBuGhko0KfsQ/fkCesGK5+3e5JmK04HoUdGBrY 7/iA== 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=7cvcp+WlaSsvNS/HJPsj4q1U+MbwsYyPqFW5A3aLjc4=; b=oIS34w8PkfRabFiLrLCO0BGpz8qU9ue2CIdzamh0dBUDPjMJ9EiMuepiGtEGECwx0i hQO6jpZdA2J5NFOT7iCy57SUa/Q1/zIkRuLXRqIYUQIEmQcaLHFo00jP1vsu+LI0Q3VP oyppohfANCCbk88vBvqHJrACsedaG2M3ShvpWzYwLm/UPvky/zDXe7cNYGhCrznuYibk cLDwnxoF0bL+eRaQU4lCR5HablnO4aGhcJlExBsHjg2mhh0N1X23c2kIqCO+MiO15y8z zrI0cx1Kwgciz+oJ918G+KFmOA7AfJJ/Sf/yaONp9rMhw2eATO8J+KPexaP72W4vyrKF x1Gw== X-Gm-Message-State: AOAM530h7vUQC9FBLOR1WWlnXG9YOsiDe5HyGUS2cUBua1I5U4+PMO/X 9kPiGmLf3UAzbWuZugN8kfpx79bT X-Google-Smtp-Source: ABdhPJyhcwgEnOGPmBq57BwTvXuujVy7Z3IkBtJ+L16/X9di4ggBU9s6z+7XliQJClG+pC65/MAmeA== X-Received: by 2002:a5d:49c5:: with SMTP id t5mr6367745wrs.18.1591831713054; Wed, 10 Jun 2020 16:28:33 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id q8sm1419277wmq.1.2020.06.10.16.28.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Jun 2020 16:28:32 -0700 (PDT) Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented To: Juri Linkov References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> <87zh9xuhq2.fsf@mail.linkov.net> <5c6d82c4-436e-9014-7dc7-0897caf76403@yandex.ru> <87eer1njkc.fsf@mail.linkov.net> <87sgf2mt44.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <69953e39-7d0d-54d4-1a5d-6c1bb6563523@yandex.ru> Date: Thu, 11 Jun 2020 02:28:30 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <87sgf2mt44.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: 40919 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.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 11.06.2020 02:03, Juri Linkov wrote: >>> next-error-maybe-current-keep-navigation >>> next-error-no-navigation-try-current >> Not bad, I guess it's difficult to find a name that it both short and self-describing. > I found a better name: > > next-error-buffer-unnavigated-current Sounds okay to me. But... do we rename it on the emacs-27 branch? Or do we keep it and introduce an obsolete alias in master? Considering the above complication, I would just keep the current name. But it's up to you (and Eli, I guess). From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 10 19:32:53 2020 Received: (at 40919) by debbugs.gnu.org; 10 Jun 2020 23:32:53 +0000 Received: from localhost ([127.0.0.1]:35625 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jjADE-0001Ka-W5 for submit@debbugs.gnu.org; Wed, 10 Jun 2020 19:32:53 -0400 Received: from mail-wm1-f45.google.com ([209.85.128.45]:55737) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jjADD-0001KN-Py for 40919@debbugs.gnu.org; Wed, 10 Jun 2020 19:32:52 -0400 Received: by mail-wm1-f45.google.com with SMTP id c71so3360218wmd.5 for <40919@debbugs.gnu.org>; Wed, 10 Jun 2020 16:32:51 -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=6SBnZuj2g99Y6v2nFutxzjwX1kfo4xrIeNtEJEN1PLU=; b=L3kaeydKeHaq+YV79/A+b3T7LhH3MtPEGh1sGD1TTR7ho/E+9tfGrliCNNugd/F8mi DfnoSO8GV+OmvfpWYbvipldwF0PssccL6inV2avIpM4pCfknXxhW+8I9whfBmtlNq402 uStLmzNfxmPoVIZ7EUaZ+x0TwTaJTZVStn2yhvbRZnMTN4aJ5c6f3pJv/xF6c7yKvlG8 3n+v1Qjkg+3PA2JeSn1/iTsz9p20t4PTrj0z5DkaQtl3xKPmPRmMfFi4TqvwkkW48F4D fEgRjhi9FIcnRzFtTz4aTgf6hPibZ2ZUhBQwozx/WSYYLIT6aZBijJLntjR0NjkpCyUX Eq2Q== 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=6SBnZuj2g99Y6v2nFutxzjwX1kfo4xrIeNtEJEN1PLU=; b=RzpsurAybja6/MVRFgGOFcJhMLLaDL3PBinfHTaANiRVx4VPufwiz2CVMiVgdbvaZI mlLrlmAXyyT5BmXYxViSpP9w14N2lp1t+D4SAqzDB9LhdjJNLcw4Msmh1ONGrOsV1t3l tVPYTkH8LYC1FxtxO+TfXQWbqBGAmRjN+/CKkn3rlBEFymF2bOaupJP+uRlaITB4wsX8 LzmR15vgcstbIyGQfJokGpwsftou3Evgt4rAS285PyG7ZeAlpaDNrzqcYMQXdU+6aoMT hfhXRHQi4wpJq9rH/Tw/6tkkcWRod7yyu1eCUdnuEA8sexrZxwR3BhJKhY8sA+wG8j4y 3ttA== X-Gm-Message-State: AOAM531VruCZbK/nEbPlV0EJophxGmE0agbG2cECGFiK72U/YRSht3vz 23fF2VBDUru0p7izw5t1gaw= X-Google-Smtp-Source: ABdhPJyeLLOahZdKDVQKl+PHyhVo7UYb22YloC3gptgVHCievaStppBRJh4heW7jEKn/i4yUhF4qiQ== X-Received: by 2002:a7b:cb91:: with SMTP id m17mr5548775wmi.126.1591831965971; Wed, 10 Jun 2020 16:32:45 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id y14sm1474067wma.25.2020.06.10.16.32.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Jun 2020 16:32:45 -0700 (PDT) Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented To: Juri Linkov References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> <251b7e0d-ef94-e438-4023-a6513b611725@yandex.ru> <87lfl6tojw.fsf@mail.linkov.net> <87a71amsho.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <0138e3ed-2bf7-1d07-b5d1-7a4f3786e865@yandex.ru> Date: Thu, 11 Jun 2020 02:32:44 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <87a71amsho.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: 40919 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.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 11.06.2020 02:05, Juri Linkov wrote: > Actually, people already want to customize it to a list (at least, I know one such user:) Say hello to the user to me. ;-) And maybe ask a question: what kind of functions do they want to put on there? And/or would they be content to advice-add on next-error-find-buffer-function instead? > -(defcustom next-error-find-buffer-function #'ignore > +(defcustom next-error-find-buffer-function '(ignore) ^s, maybe? > + (or (and (functionp next-error-find-buffer-function) > + (funcall next-error-find-buffer-function avoid-current > + extra-test-inclusive extra-test-exclusive)) > + (and (listp next-error-find-buffer-function) > + (run-hook-with-args-until-success > + 'next-error-find-buffer-function avoid-current > + extra-test-inclusive extra-test-exclusive))) Looks like run_hook_with_args can deal with the case where the value of the hook is a single function. > ;; 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 Should we take the rest of the cases in next-error-find-buffer and move them to the default value of the above hook? From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 11 09:11:32 2020 Received: (at 40919) by debbugs.gnu.org; 11 Jun 2020 13:11:32 +0000 Received: from localhost ([127.0.0.1]:36292 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jjMzU-0001UG-6x for submit@debbugs.gnu.org; Thu, 11 Jun 2020 09:11:32 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47936) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jjMzT-0001U4-1V for 40919@debbugs.gnu.org; Thu, 11 Jun 2020 09:11:31 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:32840) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jjMzM-00055P-OF; Thu, 11 Jun 2020 09:11:24 -0400 Received: from [176.228.60.248] (port=2411 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jjMzL-0008DM-Q1; Thu, 11 Jun 2020 09:11:24 -0400 Date: Thu, 11 Jun 2020 16:11:06 +0300 Message-Id: <83ftb1693p.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <69953e39-7d0d-54d4-1a5d-6c1bb6563523@yandex.ru> (message from Dmitry Gutov on Thu, 11 Jun 2020 02:28:30 +0300) Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> <87zh9xuhq2.fsf@mail.linkov.net> <5c6d82c4-436e-9014-7dc7-0897caf76403@yandex.ru> <87eer1njkc.fsf@mail.linkov.net> <87sgf2mt44.fsf@mail.linkov.net> <69953e39-7d0d-54d4-1a5d-6c1bb6563523@yandex.ru> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 40919 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.org, juri@linkov.net 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.3 (---) > From: Dmitry Gutov > Date: Thu, 11 Jun 2020 02:28:30 +0300 > Cc: 40919@debbugs.gnu.org, tspiteri@ieee.org > > But... do we rename it on the emacs-27 branch? Or do we keep it and > introduce an obsolete alias in master? The latter, I think. From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 11 19:38:49 2020 Received: (at 40919) by debbugs.gnu.org; 11 Jun 2020 23:38:49 +0000 Received: from localhost ([127.0.0.1]:38371 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jjWmP-0005nK-FK for submit@debbugs.gnu.org; Thu, 11 Jun 2020 19:38:49 -0400 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:42967) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jjWmN-0005n1-QZ for 40919@debbugs.gnu.org; Thu, 11 Jun 2020 19:38:40 -0400 X-Originating-IP: 91.129.108.6 Received: from mail.gandi.net (m91-129-108-6.cust.tele2.ee [91.129.108.6]) (Authenticated sender: juri@linkov.net) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id EB44160002; Thu, 11 Jun 2020 23:38:31 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented Organization: LINKOV.NET References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> <87zh9xuhq2.fsf@mail.linkov.net> <5c6d82c4-436e-9014-7dc7-0897caf76403@yandex.ru> <87eer1njkc.fsf@mail.linkov.net> <87sgf2mt44.fsf@mail.linkov.net> <69953e39-7d0d-54d4-1a5d-6c1bb6563523@yandex.ru> Date: Fri, 12 Jun 2020 01:39:29 +0300 In-Reply-To: <69953e39-7d0d-54d4-1a5d-6c1bb6563523@yandex.ru> (Dmitry Gutov's message of "Thu, 11 Jun 2020 02:28:30 +0300") Message-ID: <87a7192pxi.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40919 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.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.0 (-) >> I found a better name: >> next-error-buffer-unnavigated-current > > Sounds okay to me. > > But... do we rename it on the emacs-27 branch? Or do we keep it and > introduce an obsolete alias in master? It makes no sense to introduce an obsolete alias for the function added two weeks ago. From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 11 19:38:49 2020 Received: (at 40919) by debbugs.gnu.org; 11 Jun 2020 23:38:49 +0000 Received: from localhost ([127.0.0.1]:38376 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jjWmX-0005nj-9u for submit@debbugs.gnu.org; Thu, 11 Jun 2020 19:38:49 -0400 Received: from relay1-d.mail.gandi.net ([217.70.183.193]:45363) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jjWmQ-0005n6-Qb for 40919@debbugs.gnu.org; Thu, 11 Jun 2020 19:38:43 -0400 X-Originating-IP: 91.129.108.6 Received: from mail.gandi.net (m91-129-108-6.cust.tele2.ee [91.129.108.6]) (Authenticated sender: juri@linkov.net) by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id 10F5F240002; Thu, 11 Jun 2020 23:38:34 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented Organization: LINKOV.NET References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> <251b7e0d-ef94-e438-4023-a6513b611725@yandex.ru> <87lfl6tojw.fsf@mail.linkov.net> <87a71amsho.fsf@mail.linkov.net> <0138e3ed-2bf7-1d07-b5d1-7a4f3786e865@yandex.ru> Date: Fri, 12 Jun 2020 01:43:29 +0300 In-Reply-To: <0138e3ed-2bf7-1d07-b5d1-7a4f3786e865@yandex.ru> (Dmitry Gutov's message of "Thu, 11 Jun 2020 02:32:44 +0300") Message-ID: <87bllp1b1e.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40919 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.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.7 (-) > what kind of functions do they want to put on there? Both next-error-buffer-on-selected-frame and next-error-no-navigation-try-current. > And/or would they be content to advice-add on > next-error-find-buffer-function instead? Is it possible to add advice-add by using customization? >> -(defcustom next-error-find-buffer-function #'ignore >> +(defcustom next-error-find-buffer-function '(ignore) > > ^s, maybe? Ok, when using as a hook it could be '-functions', but in case of using advice-add it should be still '-function'. >> + (or (and (functionp next-error-find-buffer-function) >> + (funcall next-error-find-buffer-function avoid-current >> + extra-test-inclusive extra-test-exclusive)) >> + (and (listp next-error-find-buffer-function) >> + (run-hook-with-args-until-success >> + 'next-error-find-buffer-function avoid-current >> + extra-test-inclusive extra-test-exclusive))) > > Looks like run_hook_with_args can deal with the case where the value of the > hook is a single function. Ok, if it's impossible to use advice-add then lets simplify the hook case. >> ;; 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 > > Should we take the rest of the cases in next-error-find-buffer and move > them to the default value of the above hook? I don't think so, I don't believe someone might want to customize the rest of the cases. From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 12 03:06:48 2020 Received: (at 40919) by debbugs.gnu.org; 12 Jun 2020 07:06:48 +0000 Received: from localhost ([127.0.0.1]:38772 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jjdm4-0008R4-Cp for submit@debbugs.gnu.org; Fri, 12 Jun 2020 03:06:48 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38046) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jjdm2-0008Qr-Rg for 40919@debbugs.gnu.org; Fri, 12 Jun 2020 03:06:47 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48217) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jjdlv-0003El-HR; Fri, 12 Jun 2020 03:06:39 -0400 Received: from [176.228.60.248] (port=4923 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jjdlu-0003Yt-Mz; Fri, 12 Jun 2020 03:06:39 -0400 Date: Fri, 12 Jun 2020 10:06:26 +0300 Message-Id: <83zh984vbh.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <87a7192pxi.fsf@mail.linkov.net> (message from Juri Linkov on Fri, 12 Jun 2020 01:39:29 +0300) Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> <87zh9xuhq2.fsf@mail.linkov.net> <5c6d82c4-436e-9014-7dc7-0897caf76403@yandex.ru> <87eer1njkc.fsf@mail.linkov.net> <87sgf2mt44.fsf@mail.linkov.net> <69953e39-7d0d-54d4-1a5d-6c1bb6563523@yandex.ru> <87a7192pxi.fsf@mail.linkov.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 40919 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.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: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Juri Linkov > Date: Fri, 12 Jun 2020 01:39:29 +0300 > Cc: 40919@debbugs.gnu.org, tspiteri@ieee.org > > >> I found a better name: > >> next-error-buffer-unnavigated-current > > > > Sounds okay to me. > > > > But... do we rename it on the emacs-27 branch? Or do we keep it and > > introduce an obsolete alias in master? > > It makes no sense to introduce an obsolete alias for the function > added two weeks ago. Then what was the part about renaming it on emacs-27 about? From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 13 18:59:13 2020 Received: (at 40919) by debbugs.gnu.org; 13 Jun 2020 22:59:13 +0000 Received: from localhost ([127.0.0.1]:42617 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jkF7J-0006So-49 for submit@debbugs.gnu.org; Sat, 13 Jun 2020 18:59:13 -0400 Received: from relay10.mail.gandi.net ([217.70.178.230]:56367) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jkF7G-0006SN-UV for 40919@debbugs.gnu.org; Sat, 13 Jun 2020 18:59:11 -0400 Received: from mail.gandi.net (m91-129-108-6.cust.tele2.ee [91.129.108.6]) (Authenticated sender: juri@linkov.net) by relay10.mail.gandi.net (Postfix) with ESMTPSA id 7CB80240002; Sat, 13 Jun 2020 22:59:02 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented Organization: LINKOV.NET References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> <87zh9xuhq2.fsf@mail.linkov.net> <5c6d82c4-436e-9014-7dc7-0897caf76403@yandex.ru> <87eer1njkc.fsf@mail.linkov.net> <87sgf2mt44.fsf@mail.linkov.net> <69953e39-7d0d-54d4-1a5d-6c1bb6563523@yandex.ru> <87a7192pxi.fsf@mail.linkov.net> <83zh984vbh.fsf@gnu.org> Date: Sun, 14 Jun 2020 01:53:19 +0300 In-Reply-To: <83zh984vbh.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 12 Jun 2020 10:06:26 +0300") Message-ID: <87tuzewpb4.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40919 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.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: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> >> I found a better name: >> >> next-error-buffer-unnavigated-current >> > >> > Sounds okay to me. >> > >> > But... do we rename it on the emacs-27 branch? Or do we keep it and >> > introduce an obsolete alias in master? >> >> It makes no sense to introduce an obsolete alias for the function >> added two weeks ago. > > Then what was the part about renaming it on emacs-27 about? If you think that the new name is better than the name added 2 weeks ago, then it's better to rename it on emacs-27, or not to rename it at all. From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 14 07:50:45 2020 Received: (at 40919) by debbugs.gnu.org; 14 Jun 2020 11:50:45 +0000 Received: from localhost ([127.0.0.1]:43021 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jkR9x-0001km-62 for submit@debbugs.gnu.org; Sun, 14 Jun 2020 07:50:45 -0400 Received: from mail-wr1-f45.google.com ([209.85.221.45]:44116) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jkR9u-0001kY-US for 40919@debbugs.gnu.org; Sun, 14 Jun 2020 07:50:43 -0400 Received: by mail-wr1-f45.google.com with SMTP id y17so14236366wrn.11 for <40919@debbugs.gnu.org>; Sun, 14 Jun 2020 04:50:42 -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=9dxuZtx6cyY3pLl31KrmrnZCsNmh+T4nwkcEwqtHT+w=; b=JfXb11Pxnijhr1PPgkzvofNeAY3fYOWU44aO7FqzNoXyMjWxZE7OL5c2IAGAWY5DRB 2BDliXroG8gFYBnQh7WKVUbsSxNaclu0G11fj9ApQ8mI3fhoIEkyZqsKI4zMBYWb9jix 6yluPbEWhNNn/5ZJqX0U/+gmULK5lWdQgZ0qrY3m3RD0QThkVEgIiyWxrR/DAvwRMSiq Vyg01SxLmn26LRs1b5Z+klOVdCNW50+yPwfaY0UolrgXBNix/QKOMal7/HIhN8QAo0Pq 3XSinsLQbNFuIxzFjuw9WT/yIPuouFUFdf8TvGMVw7A73Uz+ZBotQbSpwOVkfE2WfCTT 2RMw== 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=9dxuZtx6cyY3pLl31KrmrnZCsNmh+T4nwkcEwqtHT+w=; b=fJ1Tc/miqeXoygO016V1/hB/FJnH7FG1WTEs4Vj9S0CHzoG+S/FmlEpyF9AvOH8PEq ORwpTQStkZXL80myaZDXipgiowc0OArE7kpss/u4TB68Q9Lk8CpyLMrs2Lm24/jJixWh 71f0/8uJCpRXpmObefEoDxzxoWW3iOTPIBPMfn4Kdl0Ur/zN1y2Q1z6uTcw0b1rs7mLP 9cMlH+vJp+uGnv35EVIh2ER90+EEOf8sDEi48cUHkBU2xmmRWYHLmW4oaDJHCzq7zWEt ZIbzCmt1V41/0wzPOmF8p6g/8IldGz9uYhc/Vxq60Ab/Y6axc1uQE4Y1pUd0qqqPLn6c EamQ== X-Gm-Message-State: AOAM533I9Z4//DBEKh/3LElMrO4SjKKaOFaQfwOf2dIylpxNjhXgX5vq Z2yb7OpUbVHfrqNd7cWBgy4= X-Google-Smtp-Source: ABdhPJwEVZb4E4Y5rTSd0HgAbzku3/jNGPXFT4gk3QndlfI6dRMLW4NaVXuowa3+SoV+hz7rn+qAlw== X-Received: by 2002:a5d:6288:: with SMTP id k8mr22795243wru.94.1592135436931; Sun, 14 Jun 2020 04:50:36 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id o6sm17090286wmc.39.2020.06.14.04.50.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 14 Jun 2020 04:50:34 -0700 (PDT) Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented To: Juri Linkov References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> <251b7e0d-ef94-e438-4023-a6513b611725@yandex.ru> <87lfl6tojw.fsf@mail.linkov.net> <87a71amsho.fsf@mail.linkov.net> <0138e3ed-2bf7-1d07-b5d1-7a4f3786e865@yandex.ru> <87bllp1b1e.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <619c3a9f-6c68-cd58-9e94-076cd424ad20@yandex.ru> Date: Sun, 14 Jun 2020 14:50:33 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <87bllp1b1e.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: 40919 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.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 12.06.2020 01:43, Juri Linkov wrote: >> what kind of functions do they want to put on there? > > Both next-error-buffer-on-selected-frame and next-error-no-navigation-try-current. > >> And/or would they be content to advice-add on >> next-error-find-buffer-function instead? > > Is it possible to add advice-add by using customization? No, or at least not yet. But if we know of only one user that wants this setup, surely that's not a problem? By the way, you were going to evaluate the new default. Do you now think that it's problematic somehow (and, for instance, the previous was a better default), or do you want to change it as a purely personal preference? >>> -(defcustom next-error-find-buffer-function #'ignore >>> +(defcustom next-error-find-buffer-function '(ignore) >> >> ^s, maybe? > > Ok, when using as a hook it could be '-functions', but in case > of using advice-add it should be still '-function'. Yup. These are the two options. >>> ;; 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 >> >> Should we take the rest of the cases in next-error-find-buffer and move >> them to the default value of the above hook? > > I don't think so, I don't believe someone might want to customize the > rest of the cases. Well, if you're sure about that. Having them all on the hook seemed logical to me, but indeed I don't know how necessary that is. From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 14 19:55:35 2020 Received: (at 40919) by debbugs.gnu.org; 14 Jun 2020 23:55:35 +0000 Received: from localhost ([127.0.0.1]:44728 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jkcTO-00051O-Qn for submit@debbugs.gnu.org; Sun, 14 Jun 2020 19:55:35 -0400 Received: from relay8-d.mail.gandi.net ([217.70.183.201]:46267) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jkcTM-000512-Or for 40919@debbugs.gnu.org; Sun, 14 Jun 2020 19:55:33 -0400 X-Originating-IP: 91.129.108.6 Received: from mail.gandi.net (m91-129-108-6.cust.tele2.ee [91.129.108.6]) (Authenticated sender: juri@linkov.net) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 013A91BF203; Sun, 14 Jun 2020 23:55:24 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented Organization: LINKOV.NET References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> <251b7e0d-ef94-e438-4023-a6513b611725@yandex.ru> <87lfl6tojw.fsf@mail.linkov.net> <87a71amsho.fsf@mail.linkov.net> <0138e3ed-2bf7-1d07-b5d1-7a4f3786e865@yandex.ru> <87bllp1b1e.fsf@mail.linkov.net> <619c3a9f-6c68-cd58-9e94-076cd424ad20@yandex.ru> Date: Mon, 15 Jun 2020 02:15:30 +0300 In-Reply-To: <619c3a9f-6c68-cd58-9e94-076cd424ad20@yandex.ru> (Dmitry Gutov's message of "Sun, 14 Jun 2020 14:50:33 +0300") Message-ID: <87imft8b51.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40919 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.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.7 (-) >>> what kind of functions do they want to put on there? >> Both next-error-buffer-on-selected-frame and >> next-error-no-navigation-try-current. >> >>> And/or would they be content to advice-add on >>> next-error-find-buffer-function instead? >> Is it possible to add advice-add by using customization? > > No, or at least not yet. But if we know of only one user that wants this > setup, surely that's not a problem? It's a general problem that hindered the development of other features that might benefit from customizable advice-add (namely set-multi-message). > By the way, you were going to evaluate the new default. Do you now think > that it's problematic somehow (and, for instance, the previous was a > better default), or do you want to change it as a purely > personal preference? Only personal preference, it seems the default in master is fine for most users. >>>> ;; 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 >>> >>> Should we take the rest of the cases in next-error-find-buffer and move >>> them to the default value of the above hook? >> I don't think so, I don't believe someone might want to customize the >> rest of the cases. > > Well, if you're sure about that. > > Having them all on the hook seemed logical to me, but indeed I don't know > how necessary that is. The reason why I think no one might want to customize the rest of the cases is because I believe that next-error-last-buffer is always non-nil, so all other cases (i.e. 3, 4, 5, 6) are useless and never used. Isn't it so? From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 14 19:55:38 2020 Received: (at 40919) by debbugs.gnu.org; 14 Jun 2020 23:55:38 +0000 Received: from localhost ([127.0.0.1]:44731 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jkcTS-00051j-1l for submit@debbugs.gnu.org; Sun, 14 Jun 2020 19:55:38 -0400 Received: from relay11.mail.gandi.net ([217.70.178.231]:50953) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jkcTQ-00051F-4y for 40919@debbugs.gnu.org; Sun, 14 Jun 2020 19:55:36 -0400 Received: from mail.gandi.net (m91-129-108-6.cust.tele2.ee [91.129.108.6]) (Authenticated sender: juri@linkov.net) by relay11.mail.gandi.net (Postfix) with ESMTPSA id 5898C100005; Sun, 14 Jun 2020 23:55:28 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented Organization: LINKOV.NET References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> <87zh9xuhq2.fsf@mail.linkov.net> <5c6d82c4-436e-9014-7dc7-0897caf76403@yandex.ru> <87eer1njkc.fsf@mail.linkov.net> <87sgf2mt44.fsf@mail.linkov.net> <69953e39-7d0d-54d4-1a5d-6c1bb6563523@yandex.ru> <87a7192pxi.fsf@mail.linkov.net> <83zh984vbh.fsf@gnu.org> <87tuzewpb4.fsf@mail.linkov.net> Date: Mon, 15 Jun 2020 02:17:13 +0300 In-Reply-To: <87tuzewpb4.fsf@mail.linkov.net> (Juri Linkov's message of "Sun, 14 Jun 2020 01:53:19 +0300") Message-ID: <878sgp8b26.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40919 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.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: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >>> >> I found a better name: >>> >> next-error-buffer-unnavigated-current >>> > >>> > Sounds okay to me. >>> > >>> > But... do we rename it on the emacs-27 branch? Or do we keep it and >>> > introduce an obsolete alias in master? >>> >>> It makes no sense to introduce an obsolete alias for the function >>> added two weeks ago. >> >> Then what was the part about renaming it on emacs-27 about? > > If you think that the new name is better than the name added 2 weeks ago, > then it's better to rename it on emacs-27, or not to rename it at all. I have to point out that according to the naming convention the function should have the prefix next-error-buffer-, so it seems the renaming in emacs-27 is inevitable? From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 15 03:58:39 2020 Received: (at 40919) by debbugs.gnu.org; 15 Jun 2020 07:58:39 +0000 Received: from localhost ([127.0.0.1]:45090 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jkk0t-00005M-Df for submit@debbugs.gnu.org; Mon, 15 Jun 2020 03:58:39 -0400 Received: from mail-wm1-f53.google.com ([209.85.128.53]:39810) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jkk0r-00004u-Q5 for 40919@debbugs.gnu.org; Mon, 15 Jun 2020 03:58:38 -0400 Received: by mail-wm1-f53.google.com with SMTP id o8so4154892wmh.4 for <40919@debbugs.gnu.org>; Mon, 15 Jun 2020 00:58:37 -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=63h8s0S6ShtI/fPBnOx7zm4yVsPTJ9GOkYN/WZf8Y2c=; b=Xn9Wz10kgQEAx12RnNK0renjoyLcQiM/LW2OwgS88oSayz3lBocuYW7YDLo6LiFRlv gcEKFFfOHmkNs04usmVhQKN40yj6WKMxHJhNa80lcAE7OqnQrBJVgXa8LBSNtHqlyPW1 1P33lvpzw8vkaQvluoEVhwvbz4qhv2xXXOIHy36DVdiOjbVgurj4BpESwsmDNg8OLPUR xEigpZMGExGuzHphMYyMKtS8HJFRxhT4mRo/obyE64T2U8/gUt7yM+Nt+mqoUUEJS8Wd 9AOrL4w9ewSkn3pafCd5bOVakm2ZxiWR0aD7qyrMQSaPAHWqg6/bAMleGr1G8axCPgTN itPA== 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=63h8s0S6ShtI/fPBnOx7zm4yVsPTJ9GOkYN/WZf8Y2c=; b=JtELZGMsjbaeniVeZLoE8ZHzd+ZtCbKwgM/7LO+zFTang3HrI9KPtbCs502aloWjYl 0+jClqJx1nuTwA5X4QbuPHPu3Rx8i1s2UqqpyW4qfKtHUMEgX8psBsz7JQrkISWfBMTI klwWZaXASYqkkVoYR95YiDPhvBd0VR0AE4v6enSQtfqqwsAJPPQKLBjdi9Y5FNVMo78G IDa4HqBnCQU5QXcuQ+RLdLH8lGDBGtc3tGz9EOKj40+OOALwYZ6iPjyT5+qcatqyzD7J PZ4ZluvZS5NcHae246tJ+XSliZWfYmASPjz7HzigYDkdWZIIbcs/rg9kQIIfk3a91Big Bymw== X-Gm-Message-State: AOAM5331NlAQUaxa/0aNofgw+KrN/2w2iTzCAAkO3Xy1y8nHQg10AKqy yAOLDJaL0MZJzeMPdczlbR8= X-Google-Smtp-Source: ABdhPJyKnSA+Epd1/TMKMrz1mwyy1kLARZpGvDvx51eUFr5NnTa2ASAOG5xCHGfKlM8PXKPGs2EkQw== X-Received: by 2002:a1c:3286:: with SMTP id y128mr11113939wmy.29.1592207911899; Mon, 15 Jun 2020 00:58:31 -0700 (PDT) Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id c206sm23852235wmf.36.2020.06.15.00.58.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Jun 2020 00:58:30 -0700 (PDT) Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented To: Juri Linkov References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87d07rmb6j.fsf@mail.linkov.net> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> <251b7e0d-ef94-e438-4023-a6513b611725@yandex.ru> <87lfl6tojw.fsf@mail.linkov.net> <87a71amsho.fsf@mail.linkov.net> <0138e3ed-2bf7-1d07-b5d1-7a4f3786e865@yandex.ru> <87bllp1b1e.fsf@mail.linkov.net> <619c3a9f-6c68-cd58-9e94-076cd424ad20@yandex.ru> <87imft8b51.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <65331965-9ca9-f915-d06e-1b545e08011c@yandex.ru> Date: Mon, 15 Jun 2020 10:58:29 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <87imft8b51.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: 40919 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.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 15.06.2020 02:15, Juri Linkov wrote: >>>> And/or would they be content to advice-add on >>>> next-error-find-buffer-function instead? >>> Is it possible to add advice-add by using customization? >> >> No, or at least not yet. But if we know of only one user that wants this >> setup, surely that's not a problem? > > It's a general problem that hindered the development of other features > that might benefit from customizable advice-add (namely set-multi-message). The Customize UI is definitely not my area, sorry (not as developer, nor as a user). >> By the way, you were going to evaluate the new default. Do you now think >> that it's problematic somehow (and, for instance, the previous was a >> better default), or do you want to change it as a purely >> personal preference? > > Only personal preference, it seems the default in master is fine > for most users. Very good. >> Having them all on the hook seemed logical to me, but indeed I don't know >> how necessary that is. > > The reason why I think no one might want to customize the rest of the cases > is because I believe that next-error-last-buffer is always non-nil, so > all other cases (i.e. 3, 4, 5, 6) are useless and never used. Isn't it so? change-log-mode doesn't set it (and it shouldn't). Maybe there will be other major modes like that. So #3 should be used sometimes. #4 doesn't seem very intuitive/useful to me, and I don't understand #5 (when is AVOID-CURRENT non-nil?) From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 24 19:47:00 2020 Received: (at 40919) by debbugs.gnu.org; 24 Jun 2020 23:47:00 +0000 Received: from localhost ([127.0.0.1]:39332 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1joF6Z-0005Ww-RR for submit@debbugs.gnu.org; Wed, 24 Jun 2020 19:47:00 -0400 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:55577) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1joF6T-0005W1-H7 for 40919@debbugs.gnu.org; Wed, 24 Jun 2020 19:46:54 -0400 X-Originating-IP: 91.129.108.6 Received: from mail.gandi.net (m91-129-108-6.cust.tele2.ee [91.129.108.6]) (Authenticated sender: juri@linkov.net) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id DD59E60003; Wed, 24 Jun 2020 23:46:45 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented Organization: LINKOV.NET References: <53913bd9-2bdc-0f70-f7b4-744283e0512f@ieee.org> <87zhau5bfw.fsf@mail.linkov.net> <66f63b16-307a-919c-1d25-60ff63f92ae6@ieee.org> <87bln8u3xq.fsf@mail.linkov.net> <851cd382-4b2e-447a-2212-919c8a4ce908@ieee.org> <87d07lykkd.fsf@mail.linkov.net> <83bln5rbah.fsf@gnu.org> <87zhaozlvo.fsf@mail.linkov.net> <87v9kr8t1s.fsf@mail.linkov.net> <87zh9yuw5o.fsf@mail.linkov.net> <251b7e0d-ef94-e438-4023-a6513b611725@yandex.ru> <87lfl6tojw.fsf@mail.linkov.net> <87a71amsho.fsf@mail.linkov.net> <0138e3ed-2bf7-1d07-b5d1-7a4f3786e865@yandex.ru> <87bllp1b1e.fsf@mail.linkov.net> <619c3a9f-6c68-cd58-9e94-076cd424ad20@yandex.ru> <87imft8b51.fsf@mail.linkov.net> <65331965-9ca9-f915-d06e-1b545e08011c@yandex.ru> Date: Thu, 25 Jun 2020 02:38:45 +0300 In-Reply-To: <65331965-9ca9-f915-d06e-1b545e08011c@yandex.ru> (Dmitry Gutov's message of "Mon, 15 Jun 2020 10:58:29 +0300") Message-ID: <87lfkcavay.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40919 Cc: 40919@debbugs.gnu.org, tspiteri@ieee.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.7 (-) >>>>> And/or would they be content to advice-add on >>>>> next-error-find-buffer-function instead? >>>> Is it possible to add advice-add by using customization? >>> >>> No, or at least not yet. But if we know of only one user that wants this >>> setup, surely that's not a problem? >> It's a general problem that hindered the development of other features >> that might benefit from customizable advice-add (namely set-multi-message). > > The Customize UI is definitely not my area, sorry (not as developer, nor as > a user). I retract my patch to use a list of next-error functions, because it's easy to configure this using add-function: (add-function :override next-error-find-buffer-function #'next-error-buffer-on-selected-frame) (add-function :after-until next-error-find-buffer-function #'next-error-buffer-unnavigated-current) From unknown Tue Sep 09 13:17:19 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 23 Jul 2020 11:24:05 +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