From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#32607: 27.0.50; pop-to-buffer in next-error-no-select Date: Sun, 09 Sep 2018 10:40:12 +0200 Message-ID: <5B94DC6C.6090107@gmx.at> References: <87a7p0alxv.fsf@mail.linkov.net> <5B8B8DCE.4070704@gmx.at> <87efebjzbd.fsf@mail.linkov.net> <5B8CE360.5030700@gmx.at> <877ek2tdqx.fsf@mail.linkov.net> <5B8E3998.3050907@gmx.at> <87o9ddc8yc.fsf@mail.linkov.net> <5B8F8A1B.3030807@gmx.at> <8736unzjit.fsf@mail.linkov.net> <5B90D17D.5080605@gmx.at> <87efe6iaws.fsf@mail.linkov.net> <5B9228A3.4020700@gmx.at> <87sh2j36jw.fsf@mail.linkov.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1536482351 13067 195.159.176.226 (9 Sep 2018 08:39:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 9 Sep 2018 08:39:11 +0000 (UTC) Cc: 32607@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Sep 09 10:39:07 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fyvFK-0003Jb-VQ for geb-bug-gnu-emacs@m.gmane.org; Sun, 09 Sep 2018 10:39:07 +0200 Original-Received: from localhost ([::1]:46501 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fyvHR-0001oR-EE for geb-bug-gnu-emacs@m.gmane.org; Sun, 09 Sep 2018 04:41:17 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:47320) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fyvHI-0001o6-CV for bug-gnu-emacs@gnu.org; Sun, 09 Sep 2018 04:41:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fyvHD-0002nn-8i for bug-gnu-emacs@gnu.org; Sun, 09 Sep 2018 04:41:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45798) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fyvHC-0002mr-If for bug-gnu-emacs@gnu.org; Sun, 09 Sep 2018 04:41:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fyvHC-0001ZQ-A3 for bug-gnu-emacs@gnu.org; Sun, 09 Sep 2018 04:41:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 09 Sep 2018 08:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32607 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 32607-submit@debbugs.gnu.org id=B32607.15364824275968 (code B ref 32607); Sun, 09 Sep 2018 08:41:02 +0000 Original-Received: (at 32607) by debbugs.gnu.org; 9 Sep 2018 08:40:27 +0000 Original-Received: from localhost ([127.0.0.1]:50813 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fyvGd-0001YB-4v for submit@debbugs.gnu.org; Sun, 09 Sep 2018 04:40:27 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:53411) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fyvGb-0001Xy-AZ for 32607@debbugs.gnu.org; Sun, 09 Sep 2018 04:40:25 -0400 Original-Received: from [192.168.1.101] ([46.125.250.125]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MEbYb-1g5o4n15Td-00Fn9A; Sun, 09 Sep 2018 10:40:16 +0200 In-Reply-To: <87sh2j36jw.fsf@mail.linkov.net> X-Provags-ID: V03:K1:0KkHH2PCn3z51Oh4ooz9jwkqX+8txk33c2UrlajxW7FblVxmi+S nNak7u5+vjCh3rkAamyOLoXbzVlLE8JTBLD7dTfjI2Sr4muZFfVqEcoa+IOq+5Gs7g6mujS TADgYtymvkcs67fEUXQ4mQfQK9Y0vb+myfNXC5p/sD/Kb/e9X1qttllKtvVlNNtW1+ykHCU xSA73aOob9RhkWuvlvogg== X-UI-Out-Filterresults: notjunk:1;V01:K0:pV/BxMfACkA=:mTzMZSg+83R5z3dxoW8Z8a PEu4s/W2Ei0LJU0YoM175cSzE7zvNkZ8oS43MDG/ccmoLae5zq144i5dt2rsCX36padURAtxW 9UAVURXovdtumbFIab5UuR+IvKLw4AT2KV/LXzKgpflyUeFsDs1urXC1AwWzf7pfQmwYiLGq2 7WtDOOe18DnlZqHGxiSvA8D2h9arnsL+Hmf0cyJytjWYBbMp6wt51aGlnycXIHsbmHfI9EXph cGshcG2UKYH5OQnaeuYkDUVdu2uiFUIduCh9pOYlevwsvL3qce6TQYn6EMU8ZKH781AByk/na VEQdkuJkbo6BIsjRUPDt9VC2e4pK0xoyznhL63ayhnDptLbOzZoWpv4PWKhfjNm4U5BdxJSwc 9wqMJcPnoiTFPd03rn0nhNa63N8SrLeYNXuPt05bNGkn3Ch1lBttQ+K39JskjPTiFlwDquXDz 7kC8x3zdnQj9PGkOsAncPH03EbRiUcs7bX+OeuASSLgITeG86kYN3KeGabGf1ShY14DOtGRdI cARYj6l8qQoH3cHr8v1jmC6w956FieEM7/gD3TXBbWk4OsdtBXG+VJ7C+sG2JgbbObusyeas7 P3XwwiQdUk+wEWvUZPjAb3FQB8nh8D8OqviCrkzEy1grt2BmiAf9U7JzgKJuYA5FvhFqlBtDB 8D1g7Xtq++G3i8VSwkdn+XJvpypEOFqvnjVnQqYsu+0bxLp1BAZoxJmGqEX0Dkz9eILOMjul9 yYT/MH50fp63iB4n1mnCsjQM3PDrJrmyw/ELBk7EvxTRcEJKvUV+9sM74Mmn2WHPc/ko1opU X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:150154 Archived-At: > Sorry that I failed to explain this earlier, but it just occurred to me > that the purpose of pop-to-buffer in next-error-no-select is to switch > the selected window to next-error-last-buffer from the buffer's window > with next-error. Because when I tried your code it failed by leaving > point in wrong window: after this command point should be back in the > next-error-last-buffer window, but without calling pop-to-buffer > it remains in the window with the next-error buffer. The solution > with using display-buffer-overriding-action correctly puts point back > to select next-error-last-buffer window. I have no idea what the precise semantics of "visit" in Compilation Mode or the first line of the 'next-error' doc-string "Visit next `next-error' message and corresponding source code. are. I suspect that the initial idea of compilation mode was to keep or make the buffer with the error messages visible and pop to a window showing the error locus. Later on, the capability to keep the window with the error messages selected was added which means that the selected window jumps from that of the messages buffer to that of the locus buffer and then back to that of the messages buffer. That later capability seems to be that of 'next-error-no-select' whose doc-string should probably not say what the function does not ("Finds and highlights the source line like \\[next-error], but does not select the source buffer.") but rather what the function is supposed to do instead. I have no idea why the messges buffer should be made or kept visible (a user might want to keep a completely unrelated window selected and navigate the messages buffer from there with the help of some private key binding). If the purpose of 'next-error-no-select' is simply to not select the window of the locus buffer, then 'next-error-no-select' should no rely on 'next-error'. Rather we should provide a generic function to display the locus buffer and have 'next-error' select the window used and 'next-error-no-select' not select that window. martin