GNU bug report logs -
#39190
28.0.50; two buffers with same buffer-file-name (diff-syntax-fontify-props)
Previous Next
Full log
View this message in rfc822 format
> 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
This bug report was last modified 5 years and 83 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.