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

["João Távora" <joaotavora@gmail.com>]

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