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

[João Távora]

On Mon, Jul 5, 2021 at 5:51 PM Philipp <p.stephani2@gmail.com> wrote:
>
>
>
> > 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."

And yet, but experience shows that programs rely on externally
observable behaviour again and again, and I have little reason
to believe errors are an exception to that. So unless we're reasonably
sure that the changes we make to a piece of behavior make sense
in the long run, better not do them.

I think there's prior art with negative overlay priorities, for example:
last I checked manual said "please don't use these, as we haven't
decided on what they might mean".  Or something like that.
I don't think an error make sense there, either.

João