bug#65912: 2023-08-31; Fix xref errors when matching in unvisited files

[David Fussner]

Strike that last paragraph please, Keita. Whatever the new backend looks like, it will always be possible to continue to use the old one, so these fixes will be important no matter what I come up with.

Sorry for the noise. 

David. 

On Sun, 17 Sept 2023, 14:51 David Fussner, <dfussner@googlemail.com> wrote:

Hi Keita,

Thanks for this. Texinfo mode is out of scope, so I'll have a look and get back to you once I'm back on the computer.

To be honest, other changes might also make this fix unnecessary, depending on what Dmitry thinks works best. 

Best, and I'll be in touch. 

David. 

On Sun, 17 Sept 2023, 14:02 Ikumi Keita, <ikumi@ikumi.que.jp> wrote:

Hi David,

> On Fri, 15 Sept 2023, 06:45 Ikumi Keita, <ikumi@ikumi.que.jp> wrote:
>> It seems reasonable basically. However, this makes two regression tests
>> fail:
>> 2 unexpected results:
>> FAILED  LaTeX-filling
>> FAILED  LaTeX-style-hook-with-class-option
>>
>> I thought the following advice in latex-test.el is interfering badly:
>> ----------------------------------------------------------------------
>> ;; We need to ensure that font-lock has put the syntax properties
>> ;; already which won't happen in batch mode.  So trigger font-lock
>> ;; immediately.
>> (define-advice LaTeX-common-initialization (:after ())
>> (font-lock-ensure))
>> ----------------------------------------------------------------------
>> However, the failures remain even after I deleted this advice. I haven't
>> figured out what's going on yet. (Maybe the failures only appear in
>> batch mode and aren't real issues.) Does anyone out there have insights?

I think I now understand the reason. Some of the style hooks presume
that the file local variables are already established. Therefore,
I have to arrange regression tests so that `TeX-update-style' in
`latex-mode' runs inside `let' form where relevant variables are bound.

Attached is my current proposal.

>> > The attached patch (0002) parses and applies styles in the temp
>> > buffer, and only in such non-file-visiting buffers. It does so both in
>> > LaTeX-common-initialization and in plain-TeX-common-initialization,

LaTeX-common-initialization isn't a suitable place because of the
following reasons:
1. LaTeX mode makes addtion to `TeX-update-style-hook' after it calls
   LaTeX-common-initialization.
2. It is legitimate for style hooks to assume that they are called after
   mode hooks (e.g. LaTeX-mode-hook) run.
I moved the call to TeX-update-style at the last of latex-mode,
plain-tex-mode and ams-tex-mode. This doesn't cover context mode, but I
think it doesn't harm.
It still doesn't wait mode hooks in doctex mode since doctex mode is
defined by `define-derived-mode', but I'd postpone that issue for now.
I'll do I can do in feature/fix-mode-names-overlap branch later.

>> > which I think covers all the modes.

Actually it (and my patch as well) doesn't cover Texinfo mode, but I
suppose texinfo mode is out of the scope for the first place. Is this
right?

Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine