GNU bug report logs - #32607
27.0.50; pop-to-buffer in next-error-no-select

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 32607 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: bug#32607: 27.0.50; pop-to-buffer in next-error-no-select
Date: Sun, 16 Sep 2018 17:19:24 -0400

>>>        (save-selected-window
>>>          (let ((next-error-highlight next-error-highlight-no-select)
>>>                (display-buffer-overriding-action
>>>                 '(nil (inhibit-same-window . t))))
>>>            (next-error n)))
>>
>> This is much simpler.  Actually, this is what I wanted to propose as
>> a solution to Martin in one of previous messages, but I mistakenly wrote
>> save-window-excursion whereas I actually intended save-selected-window.
>
> I still do not understand whether we are sure that at the time the
> code above gets called 'next-error-last-buffer' is really shown in the
> selected window.

Indeed, I don't see any obvious indication that this is the case.
I suspect it's *usually* the case because next-error-no-select is only
bound to keys in "error buffers", but if you

    M-x next-error-no-select

from a C file, I suspect that the buffer shown in the selected-window at
the beginning of the command won't be equal to the next-error-last-buffer.

I'm not sure what would be considered the *right* behavior in that case:
should the selected-window at the end display the same buffer as at the
beginning, or should it show the buffer that contains the error
(e.g. *grep* or *compilation*)?

My own take on it is that it's perfectly OK to have the final
selected-window show the buffer in which the command was typed (rather
than the *grep*/*compilation* buffer).


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.