bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers

[David Fussner]

Thanks, Dmitry.

> Last I checked, semantic-symref-filepattern-alist had explicit entries
> only for languages whose auto-mode-alist entries were deemed too complex
> to parse out the matching extensions from the corresponding regexps.
>
> Or had other difficulties like the c-or-c++-mode dispatcher.

That makes sense, and clarifies a few things for me. I guess TeX has
the "plain-tex or latex or context or ams-tex" dispatcher and also
in-tree vs. AUCTeX mode names, both of which at least for the moment
make semantic-symref-filepattern-alist seem a better fit.

Best,

David.

On Wed, 24 Apr 2024 at 01:09, Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> On 22/04/2024 20:16, Stefan Monnier via Bug reports for GNU Emacs, the
> Swiss army knife of text editors wrote:
> >> (I'm wondering whether it might be useful, for example, for
> >> semantic-symref-derive-find-filepatterns to add extensions from
> >> auto-mode-alist even when some extensions are found in
> >> semantic-symref-filepattern-alist.)
> > Assuming we can get good enough results from `auto-mode-alist and
> > friends, I think we'd want to mark `semantic-symref-filepattern-alist`
> > as obsolete.
> > But before that, we need to check the assumption.
>
> Last I checked, semantic-symref-filepattern-alist had explicit entries
> only for languages whose auto-mode-alist entries were deemed too complex
> to parse out the matching extensions from the corresponding regexps.
>
> Or had other difficulties like the c-or-c++-mode dispatcher.