GNU bug report logs -
#53749
29.0.50; [PATCH] Xref backend for TeX buffers
Previous Next
Reported by: David Fussner <dfussner <at> googlemail.com>
Date: Thu, 3 Feb 2022 15:10:02 UTC
Severity: normal
Tags: patch
Found in version 29.0.50
Fixed in version 31.1
Done: Stefan Kangas <stefankangas <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Hi Mattias, Arash,
Here's a patch to fix the regexps and delete the unnecessary variable.
Any thoughts?
I'll look at adding new vars for the TeX escape and grouping chars,
creating a new bug number when I have a working patch.
Thanks, David.
On Mon, 16 Sept 2024 at 09:33, David Fussner <dfussner <at> googlemail.com> wrote:
>
> Hi Mattias,
>
> Thanks for this, and of course you are quite right on both counts:
>
> > but it also depends on what you want that `tex-thingatpt-exclude-chars` variable to be
>
> I believe it's time I abandoned this piece of idiocy, already flagged
> by several commentators before you. The basic motivation was to allow
> using the new xref code in TeX files that used non-standard escape and
> grouping characters. Both etags and AUCTeX address this possibility,
> but the latter does it right by having three separate variables:
> TeX-esc, TeX-grop, and TeX-grcl, so that these can be part of the
> whole regular expression apparatus for syntax highlighting and
> everything else. I had in the back of my mind to implement something
> similar in tex-mode, but the half-measure of
> `tex-thingatpt-exclude-chars` is the wrong way to go.
>
> I propose, therefore, to eliminate this variable from tex-mode and
> just hard code the standard escape and grouping characters for the
> time being, as in the rest of tex-mode.el, then to submit later a
> patch to implement something similar to what AUCTeX does, and one
> interoperable with AUCTeX, also.
>
> > This is not a correct way to build a regexp;
>
> Given the above changes, would you and your electronic servant be OK
> with code like the following?
>
> (re-search-forward "[][\\{}\"*`'#=&()%,|$[:cntrl:][:blank:]]")
>
> (I still, I'm ashamed to confess, find the traditional regexp syntax
> easier to read than rx notation, but could overcome this if you think
> rx is a better fit here.)
>
> What do you think?
>
> Best, David.
>
> On Sat, 14 Sept 2024 at 18:26, Mattias EngdegÄrd
> <mattias.engdegard <at> gmail.com> wrote:
> >
> > Thanks for the contribution, David! My electronic servant complained about some regexps:
> >
> > 3881 (re-search-backward (concat "[]["
> > 3882 (mapconcat #'regexp-quote
> > 3883 (mapcar #'char-to-string
> > 3884 tex-thingatpt-exclude-chars))
> > 3885 "\"*`'#=&()%,|$[:cntrl:][:blank:]]"))
> >
> > This is not a correct way to build a regexp; `regexp-quote` can only be used to quote strings that should match literally, not characters inside [...], where backslashes have no escaping power.
> >
> > There are various ways of doing this properly. I would suggest something like
> >
> > (rx-to-string `(or (in "\"#$%&'()*,=[]`|" cntrl blank)
> > ,@tex-thingatpt-exclude-chars)
> > t))
> >
> > but it also depends on what you want that `tex-thingatpt-exclude-chars` variable to be. Should it be a user option (defcustom)? The variable's doc string is a wall of text that basically says that it can be set to whatever you want but things will stop working so you'd better not.
> >
[0001-Fix-regexps-for-TeX-xref-backend-Bug-53749.patch (text/x-patch, attachment)]
This bug report was last modified 243 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.