bug#34418: 27.0.50; Flymake adds markup to buffers not specified in `flymake-make-diagnostic'

[Philipp]

> Am 02.11.2019 um 17:04 schrieb João Távora <joaotavora@gmail.com>:
> 
> Philipp <p.stephani2@gmail.com> writes:
> 
>> 1. Create two scratch buffers *a* and *b* (e.g. C-x b *a* RET).
>> 
>> 2. Insert some text into the buffers (e.g. "text a" and "text b",
>>   respectively)
>> 
>> 3. Add a trivial Flymake backend to buffer *b*.  E.g., select *b* and
>>   run M-: with the following code:
>> 
>>   (add-hook 'flymake-diagnostic-functions
>>             (lambda (report-fn &rest _args)
>>                    (funcall report-fn (list (with-current-buffer "*a*"
>>                    (flymake-make-diagnostic (current-buffer)
>>                                             (point-min) (point-max)
>>                     :error "message"))))))
>> 
>>   Note that this backend adds a diagnostic for buffer *a*, not *b*.
>> 
>> 4. Enable Flymake mode in buffer *b*.
>> 
>> Buffer *b* will now show a diagnostic, even though it was reported for
>> buffer *a*.  This should either add a diagnostic for buffer *a* or
>> signal an error.
> 
> Hi Phillip,
> 
> Sorry for the very slow turnaround.
> 
> The behaviour for handling the mismatch between the (1) the buffer
> passed to flymake-make-diagnostic (2) the buffer where the report
> function executes is unspecified and it is so by design.
> 
> I've yet to come to a good conclusion on what that behaviour should be,
> and maybe you can help me.  Let's see some plausible real-world scenarios.
> 
> 1. Some uses of Flymake, notably Eglot's via LSP (Language Server
>   Protocol) can possibly take advantage of a good definition of this
>   behaviour, for aggregating the errors reports across a project for
>   example.  So `flymake-make-diagnostic` could be specified to take a
>   BUFFER-OR-FILE, and we could heuristically decide to add the
>   diagnostic to, say, a per-project database.
> 
> 2. In another simpler scenario, checking .c file might issue errors for
>   included .h files, and if that file is open in a buffer, we could go
>   there and highlight the error.  Could we really?  Maybe not, because
>   the error was probably generated for the on-disk copy of the .h file,
>   whose contents might differ wildly from the buffer's.  Then again, a
>   smart backend could consider that.
> 
> So maybe your "error" proposal makes sense, maybe it doesn't.  I'd
> rather not commit to an API right now that could block evolution.

I wouldn't say signaling an error now would block evolution.  I don't think we 
have a principle like "anything that signals an error now will continue doing 
so in the future."

> 
> For now I've added a note to the manual's description of
> flymake-make-diagnostic and a protection to flymake--handle-report that
> will ignore such diagnostics.  What do you think?

Adding a note to the manual is definitely a good idea.  I'm not so sure about 
(silently) ignoring "wrong" diagnostics -- after all, the backend definition 
then contains a bug, and it's generally a good idea to help developers find and 
fix bugs by being explicit about them.  So I'd still favor signaling an error, 
with the potential to change the behavior if we find a good use for such 
diagnostics.