Hi Dmitry, Stefan M and Stefan K, Here's the latest patch, with most of the modifications requested by Stefan K. The code populating `semantic-symref-filepattern-alist` I've left in tex-mode.el, because I wasn't sure how to adjudicate the differing opinions on where it should go. Moving it won't take any time, should that be the verdict. I've had a stab at a NEWS entry, and included the patches to the manual etags test files. The diffs for the test files are large, since we remove the TeX escape char from any tag names where it occurs, as discussed elsewhere on this thread. Please let me know if more changes are needed. Best, David. On Sun, 9 Jun 2024 at 23:13, Dmitry Gutov wrote: > > On 10/06/2024 00:03, Stefan Monnier via Bug reports for GNU Emacs, the > Swiss army knife of text editors wrote: > >>>> +;; Populate `semantic-symref-filepattern-alist' for the in-tree modes; > >>>> +;; AUCTeX is doing the same for its modes. > >>>> +(with-eval-after-load 'semantic/symref/grep > >>>> + (defvar semantic-symref-filepattern-alist) > >>>> + (push '(latex-mode "*.[tT]e[xX]" "*.ltx" "*.sty" "*.cl[so]" > >>>> + "*.bbl" "*.drv" "*.hva") > >>>> + semantic-symref-filepattern-alist) > >>>> + (push '(plain-tex-mode "*.[tT]e[xX]" "*.ins") > >>>> + semantic-symref-filepattern-alist) > >>>> + (push '(doctex-mode "*.dtx") semantic-symref-filepattern-alist)) > >>> Doesn't this stuff rather belong in semantic itself? > >> Good point. > > FWIW, I think the responsability of `symref.el` is to provide hooks like > > the `semantic-symref-filepattern-alist` var along with the code that > > uses them, but the mode-specific settings, such as knowledge about which > > glob patterns should be used for `latex-mode` belong to the > > corresponding mode. > > I've been looking at semantic-symref-filepattern-alist like a workaround > for the fast that the major modes don't provide enough relevant > information in auto-mode-alist (or, to look at it differently, don't > provide such info in some other variable which the auto-mode-alist entry > would be computed from). > > From that perspective, storing the missing association inside the > semantic-symref package seems suitable. But a more "proper" place for it > would be better, of course.