bug#39190: 28.0.50; two buffers with same buffer-file-name (diff-syntax-fontify-props)

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Stefan, do you think diff-syntax-fontify-props should let-bind
> after-change-major-mode-hook to nil to not allow running this hook
> on an internal buffer.

No, that's definitely not the right fix.  It's at best a weak
workaround, but it won't handle the case where the code that depends on
`buffer-file-name` is placed on `foo-mode-hook` rather than on
`after-change-major-mode-hook`.

>> If I read correctly, diff-syntax-fontify-props sets buffer-file-name of
>> a temporary buffer to an existing one.  This is not necessarily a bug,
>> but it definitely looks strange that we have two buffers with different
>> contents and the same buffer-file-name.

Yes, it's definitely borderline.  I remember feeling a bit uneasy about
it at the time.  Maybe a better fix would be to be able to pass the
file-name to `set-auto-mode` (or some new function created for that
purpose) as an argument (instead of passing it via dynamic scoping in
`buffer-file-name`).

BTW, I see somewhat similar code in `xref--collect-matches`, so maybe
there's a need for a more general solution (haven't looked any further,
but I'd be surprised if there aren't other cases).

> Or it's the responsibility of the eglot package to check for the
> leading space in the buffer name when its after-change-major-mode-hook
> is called?

The eglot package could protect itself from such things by making its
`after-change-major-mode-hook` just add the buffer to a global var, and
then process this global var in `post-command-hook` or in a timer.


        Stefan