Re: next-error use cases

[Clément Pit-Claudel]

On 22/05/2020 19.50, Dmitry Gutov wrote:
> On 22.05.2020 04:31, Clément Pit-Claudel wrote:
>> On 21/05/2020 18.49, Dmitry Gutov wrote:
>>> On 22.05.2020 01:06, Juri Linkov wrote:
>>>>> A binding for flymake-show-diagnostics-buffer in goto-map?
>>>> Good idea, not only for flymake, but for all next-error capable buffers:
>>>> a keybinding in goto-map to show the buffer with a list of errors/matches.
>>>> For example, the user is navigating using 'M-g M-n' when the next-errors 
>>>> buffer
>>>> is not visible, then wants to see all errors/matches, so the user needs to 
>>>> type
>>>> some M-g key to show it.
>>>
>>> So we'll have 'M-g l' to pop up the current 'next-error-last-buffer'.
>>>
>>> And 'C-c ! l' to pop Flymake's diagnostics buffer specifically (and change 
>>> next-error-last-buffer's value appropriately). 'C-c ! n' and 'C-c ! p' 
>>> could work along the same idea.
>>
>> Does this mean that Flycheck should override M-g l too, or will that work 
>> automatically (how will M-g l know which one to pick?)
> 
> I think this will work simply like:
> 
> (defun next-error-show-list ()
>   (interactive)
>   (pop-to-buffer next-error-last-buffer))
> 
> But for this to be okay, we'd have to decide on a principle, and Flycheck 
> would have to agree, that next-error-function is set in 
> flycheck-error-list-mode, and not in flycheck-mode.

Ah, how surprising.  Currently we set next-error-function in the main buffer, 
not in the error list, in part because the error list is built lazily (we don't 
construct the error list buffer until you've requested it, so 
next-error-last-buffer would be nil most of the time)