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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 65912 in the body.
You can then email your comments to 65912 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: David Fussner <dfussner <at> googlemail.com>
To: bug-auctex <at> gnu.org
Subject: 2023-08-31; Fix xref errors when matching in unvisited files
Date: Wed, 13 Sep 2023 11:00:41 +0100

[Message part 1 (text/plain, inline)]

Hi.

I've been working on getting the main xref commands working in TeX
files, and ran into a couple of issues.  To reproduce the first one, in
an empty directory put something like the following text into a file,
mwe.ltx (the file extension matters -- please don't try .tex, as that
encounters a separate bug which is better fixed in Emacs itself, I
think):

\documentclass[12pt]{article}
\usepackage{fontspec}
\usepackage{xparse}
\ExplSyntaxOn
\bool_new:N \g__hook_debug_bool
\cs_new_eq:NN \__hook_debug:n \use_none:n
\ExplSyntaxOff
\begin{document}
\thispagestyle{empty}
\end{document}

Then copy mwe.ltx to mwe2.ltx, and visit mwe.ltx without visiting
mwe2.ltx.  Place point on "fontspec" and hit M-?, RTN, then "..." to
choose a search directory, then choose the current one (the default).
Here I see this error:

Font-lock trying to use keywords before setting them up

The end of the backtrace looks like this:

Debugger entered--Lisp error: (error "Font-lock trying to use keywords
before setting th...")
  signal(error ("Font-lock trying to use keywords before setting th..."))
  error("Font-lock trying to use keywords before setting th...")
  font-lock-compile-keywords((("\\\\\\(?:\\(?:verb\\*?\\)\\)\\(?:\\[[^][]*\\(?:\\[[^][]*\\][^]..."
(1 "\"") (2 ".") (3 "\"")) ("\\(\\\\\\)end
*{\\(?:\\(?:filecontents\\*?\\|verbatim\\*?\\)..." (1 "|" t)) ("^[
\11]*\\\\begin *{\\(?:\\(?:filecontents\\*?\\|verbatim\\..." (1 "|"
t))) t)
  font-lock-fontify-syntactic-keywords-region(1 22)
  #f(compiled-function (start end) #<bytecode 0x835be9f85adc43b>)(1 22)
  syntax-propertize(22)
  xref--collect-matches-1("\\_<fontspec\\_>" "~/src/testing/mwe2.ltx" 2 1 22 0)

The compiled function here is
font-latex--make-syntax-propertize-function, which is a wrapper for
syntax-propertize-via-font-lock, which is a standard value for
syntax-propertize-function, but the in-tree tex-mode.el uses a
different function, and the error doesn't appear there.  Here
syntax-propertize-via-font-lock calls
font-lock-fontify-syntactic-keywords-region, which calls
font-lock-compile-keywords, which errors out because in the temporary
buffer (" *xref-temp*") we haven't yet called font-lock-set-defaults.

The in-tree bibtex.el uses the same syntax-propertize-function but
doesn't error here, because it calls font-lock-set-defaults, with a
comment explaining why, at the end of the definition of bibtex-mode
itself.  If you visit both mwe2.ltx and mwe.ltx, the error won't appear,
because the font-locking mechanism calls font-lock-set-defaults when
setting up the buffer.

I enclose a patch (0001), which puts the required call, with a comment, at
the end of font-latex-set-syntactic-keywords, which seems to work for
all the AUCTeX modes, but there may be a better place for it.

If you apply patch 0001, and make sure font-latex.el is reloaded, you
can then see the next bug: in specific cases, xref-find-references
reports a hit only in visited files, despite there being identical text
in the unvisited one.

To reproduce, move point in mwe.ltx from "fontspec" to
"\__hook_debug:n", then call M-? just as before. You'll only see the hit
in mwe.ltx in the xref buffer, not the one in mwe2.ltx.  The problem is
that the search string called by xref-find-references has the format
"\\_<%s\\_>", so that any search term which doesn't start and end with
chars having either word or symbol syntax won't be returned.  Now,
assuming that parsing is enabled, AUCTeX does the right thing here and
parses this file as containing expl3 constructs, and therefore gives "_"
symbol syntax.  Unfortunately, the style file expl3.el will not be
applied to temporary, non-file-visiting buffers like " *xref-temp*",
because the find-file-hook set at the end of
VirTeX-common-initialization won't be called in such buffers.  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,
which I think covers all the modes.

My profoundest apologies for the long bug report, and thanks,

David.

Emacs  : GNU Emacs 30.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version
3.24.31, cairo version 1.16.0)
 of 2023-09-11
Package: 2023-08-31

current state:
==============
(setq
 AUCTeX-date "2023-08-31"
 window-system 'x
 LaTeX-version "2e"
 TeX-style-path '("/usr/local/var/auctex" "/home/dfussner/src/auctex/style"
          "/home/dfussner/.emacs.d/auctex/auto"
          "/home/dfussner/.emacs.d/auctex/style" "auto" "style")
 TeX-auto-save t
 TeX-parse-self t
 TeX-master nil
 TeX-command-list '(("TeX"
             "%(PDF)%(tex) %(file-line-error) %`%(extraopts)
%S%(PDFout)%(mode)%' %(output-dir) %t"
             TeX-run-TeX nil
             (plain-tex-mode ams-tex-mode texinfo-mode) :help
             "Run plain TeX")
            ("LaTeX" "%`%l%(mode)%' %T" TeX-run-TeX nil
             (latex-mode doctex-mode) :help "Run LaTeX")
            ("Makeinfo" "makeinfo %(extraopts) %(o-dir) %t"
             TeX-run-compile nil (texinfo-mode) :help
             "Run Makeinfo with Info output")
            ("Makeinfo HTML"
             "makeinfo %(extraopts) %(o-dir) --html %t"
             TeX-run-compile nil (texinfo-mode) :help
             "Run Makeinfo with HTML output")
            ("AmSTeX"
             "amstex %(PDFout) %`%(extraopts) %S%(mode)%' %(output-dir) %t"
             TeX-run-TeX nil (ams-tex-mode) :help "Run AMSTeX")
            ("ConTeXt"
             "%(cntxcom) --once --texutil %(extraopts) %(execopts)%t"
             TeX-run-TeX nil (context-mode) :help "Run ConTeXt once")
            ("ConTeXt Full" "%(cntxcom) %(extraopts) %(execopts)%t"
             TeX-run-TeX nil (context-mode) :help
             "Run ConTeXt until completion")
            ("BibTeX" "bibtex %(O?aux)" TeX-run-BibTeX nil
             (plain-tex-mode latex-mode doctex-mode ams-tex-mode
              texinfo-mode context-mode)
             :help "Run BibTeX")
            ("Biber" "biber %(output-dir) %s" TeX-run-Biber nil
             (plain-tex-mode latex-mode doctex-mode ams-tex-mode
              texinfo-mode)
             :help "Run Biber")
            ("Texindex" "texindex %s.??" TeX-run-command nil
             (texinfo-mode) :help "Run Texindex")
            ("Texi2dvi" "%(PDF)texi2dvi %t" TeX-run-command nil
             (texinfo-mode) :help "Run Texi2dvi or Texi2pdf")
            ("View" "%V" TeX-run-discard-or-function t t :help
             "Run Viewer")
            ("Print" "%p" TeX-run-command t t :help "Print the file")
            ("Queue" "%q" TeX-run-background nil t :help
             "View the printer queue" :visible TeX-queue-command)
            ("File" "%(o?)dvips %d -o %f " TeX-run-dvips t
             (plain-tex-mode latex-mode doctex-mode ams-tex-mode
              texinfo-mode)
             :help "Generate PostScript file")
            ("Dvips" "%(o?)dvips %d -o %f " TeX-run-dvips nil
             (plain-tex-mode latex-mode doctex-mode ams-tex-mode
              texinfo-mode)
             :help "Convert DVI file to PostScript")
            ("Dvipdfmx" "dvipdfmx -o %(O?pdf) %d" TeX-run-dvipdfmx nil
             (plain-tex-mode latex-mode doctex-mode ams-tex-mode
              texinfo-mode)
             :help "Convert DVI file to PDF with dvipdfmx")
            ("Ps2pdf" "ps2pdf %f %(O?pdf)" TeX-run-ps2pdf nil
             (plain-tex-mode latex-mode doctex-mode ams-tex-mode
              texinfo-mode)
             :help "Convert PostScript file to PDF")
            ("Glossaries" "makeglossaries %(d-dir) %s" TeX-run-command
             nil
             (plain-tex-mode latex-mode doctex-mode ams-tex-mode
              texinfo-mode)
             :help "Run makeglossaries to create glossary file")
            ("Index" "makeindex %(O?idx)" TeX-run-index nil
             (plain-tex-mode latex-mode doctex-mode ams-tex-mode
              texinfo-mode)
             :help "Run makeindex to create index file")
            ("upMendex" "upmendex %(O?idx)" TeX-run-index t
             (plain-tex-mode latex-mode doctex-mode ams-tex-mode
              texinfo-mode)
             :help "Run upmendex to create index file")
            ("Xindy" "texindy %s" TeX-run-command nil
             (plain-tex-mode latex-mode doctex-mode ams-tex-mode
              texinfo-mode)
             :help "Run xindy to create index file")
            ("Check" "lacheck %s" TeX-run-compile nil (latex-mode)
             :help "Check LaTeX file for correctness")
            ("ChkTeX" "chktex -v6 %s" TeX-run-compile nil (latex-mode)
             :help "Check LaTeX file for common mistakes")
            ("Spell" "(TeX-ispell-document \"\")" TeX-run-function nil
             t :help "Spell-check the document")
            ("Clean" "TeX-clean" TeX-run-function nil t :help
             "Delete generated intermediate files")
            ("Clean All" "(TeX-clean t)" TeX-run-function nil t :help
             "Delete generated intermediate and output files")
            ("Other" "" TeX-run-command t t :help
             "Run an arbitrary command")
            )
 )

[0001-Fix-xref-error-when-matching-in-unvisited-files.patch (text/x-patch, attachment)]

[0002-Fix-xref-error-when-matching-in-unvisited-files.patch (text/x-patch, attachment)]

Message #8 received at 65912 <at> debbugs.gnu.org (full text, mbox):

From: David Fussner <dfussner <at> googlemail.com>
To: 65912 <at> debbugs.gnu.org
Subject: 2023-08-31; Fix xref errors when matching in unvisited files
Date: Thu, 14 Sep 2023 13:46:15 +0100

Hi,

As my initial report mentioned, I've been working on getting xref
commands to work in TeX buffers (see bug 53749), and while we've not
exactly reached a consensus on how this might best be done, I was
reminded by Dmitry Gutov that I really should check with the AUCTeX
developers about how you might like to go about using such
functionality, whenever it reaches its final form, in AUCTeX.
Currently, if you look at the latest patch in 53749 you'll see that
I've added a TeX-mode hook in tex-mode.el, with a note wondering
whether such a thing should be in AUCTeX instead. (The other
AUCTeX-specific stuff is just accounting for differences in the syntax
table between the in-tree modes and the AUCTeX modes.) If this is the
right place to ask such a question, I wondered whether you'd prefer
that such a hook be called somewhere in AUCTeX (or not at all), and /
or whether you might prefer it to be behind some sort of option so
that it wouldn't be turned on by default.

Personally, as an AUCTeX user myself, I don't find the current state
of xref commands in TeX buffers very useful, but opinions may differ
and I'd certainly be happy to remove the call from tex-mode.el should
you desire it.

Sorry if this is the wrong place to ask this question!

David.

Message #11 received at 65912 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: David Fussner <dfussner <at> googlemail.com>
Cc: 65912 <at> debbugs.gnu.org
Subject: Re: bug#65912: 2023-08-31;
 Fix xref errors when matching in unvisited files
Date: Fri, 15 Sep 2023 14:45:17 +0900

[Message part 1 (text/plain, inline)]

Hi David, thanks for raising these issues.

>>>>> David Fussner via bug-auctex via Bug reporting list for AUCTeX <bug-auctex <at> gnu.org> writes:

> I enclose a patch (0001), which puts the required call, with a comment, at
> the end of font-latex-set-syntactic-keywords, which seems to work for
> all the AUCTeX modes, but there may be a better place for it.

1. This breaks doctex fontification. Doctex mode calls
   `font-latex-setup' twice; once in `VirTeX-common-initialization',
   once in `docTeX-mode'. Since the first one calls
   `font-lock-set-defaults' which sets the variable
   `font-lock-set-defaults' to t (and `major-mode' isn't `doctex-mode'
   yet), the second call to `font-lock-set-defaults' does nothing and
   doctex specific fontification isn't taken into account.
   Adding
(setq font-lock-set-defaults nil)
   before (funcall TeX-install-font-lock) in `docTeX-mode' addresses
   this problem.

2. I think better place for `(font-lock-set-defaults)' is
   `font-latex-setup' rather than `font-latex-set-syntactic-keywords';
   the latter is sometimes called afterwards by AUCTeX style files.

I modified your proposal to make the attached patch. This fixes your
first bug keeping the doctex fontification.

> If you apply patch 0001, and make sure font-latex.el is reloaded, you
> can then see the next bug: in specific cases, xref-find-references
> reports a hit only in visited files, despite there being identical text
> in the unvisited one.

I confirmed the reported result.

> 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,
> which I think covers all the modes.

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?

Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine

[patch (text/x-diff, attachment)]

Message #14 received at 65912 <at> debbugs.gnu.org (full text, mbox):

From: David Fussner <dfussner <at> googlemail.com>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: 65912 <at> debbugs.gnu.org
Subject: Re: bug#65912: 2023-08-31;
 Fix xref errors when matching in unvisited files
Date: Fri, 15 Sep 2023 07:37:01 +0100

[Message part 1 (text/plain, inline)]

Thanks Ikumi. I should have run more tests myself, so apologies for making
it harder for you. I'll let you know if I figure anything out.

David.

On Fri, 15 Sept 2023, 06:45 Ikumi Keita, <ikumi <at> ikumi.que.jp> wrote:

> Hi David, thanks for raising these issues.
>
> >>>>> David Fussner via bug-auctex via Bug reporting list for AUCTeX <
> bug-auctex <at> gnu.org> writes:
>
> > I enclose a patch (0001), which puts the required call, with a comment,
> at
> > the end of font-latex-set-syntactic-keywords, which seems to work for
> > all the AUCTeX modes, but there may be a better place for it.
>
> 1. This breaks doctex fontification. Doctex mode calls
>    `font-latex-setup' twice; once in `VirTeX-common-initialization',
>    once in `docTeX-mode'. Since the first one calls
>    `font-lock-set-defaults' which sets the variable
>    `font-lock-set-defaults' to t (and `major-mode' isn't `doctex-mode'
>    yet), the second call to `font-lock-set-defaults' does nothing and
>    doctex specific fontification isn't taken into account.
>    Adding
> (setq font-lock-set-defaults nil)
>    before (funcall TeX-install-font-lock) in `docTeX-mode' addresses
>    this problem.
>
> 2. I think better place for `(font-lock-set-defaults)' is
>    `font-latex-setup' rather than `font-latex-set-syntactic-keywords';
>    the latter is sometimes called afterwards by AUCTeX style files.
>
> I modified your proposal to make the attached patch. This fixes your
> first bug keeping the doctex fontification.
>
> > If you apply patch 0001, and make sure font-latex.el is reloaded, you
> > can then see the next bug: in specific cases, xref-find-references
> > reports a hit only in visited files, despite there being identical text
> > in the unvisited one.
>
> I confirmed the reported result.
>
> > 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,
> > which I think covers all the modes.
>
> 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?
>
> Regards,
> Ikumi Keita
> #StandWithUkraine #StopWarInUkraine
>
>

[Message part 2 (text/html, inline)]

Message #17 received at 65912 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: David Fussner <dfussner <at> googlemail.com>
Cc: 65912 <at> debbugs.gnu.org
Subject: Re: bug#65912: 2023-08-31;
 Fix xref errors when matching in unvisited files
Date: Sun, 17 Sep 2023 22:02:40 +0900

[Message part 1 (text/plain, inline)]

Hi David,

> On Fri, 15 Sept 2023, 06:45 Ikumi Keita, <ikumi <at> 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

[patch2 (text/x-diff, attachment)]

Message #20 received at 65912 <at> debbugs.gnu.org (full text, mbox):

From: David Fussner <dfussner <at> googlemail.com>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: 65912 <at> debbugs.gnu.org
Subject: Re: bug#65912: 2023-08-31;
 Fix xref errors when matching in unvisited files
Date: Sun, 17 Sep 2023 14:51:53 +0100

[Message part 1 (text/plain, inline)]

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 <at> ikumi.que.jp> wrote:

> Hi David,
>
> > On Fri, 15 Sept 2023, 06:45 Ikumi Keita, <ikumi <at> 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
>
>

[Message part 2 (text/html, inline)]

Message #23 received at 65912 <at> debbugs.gnu.org (full text, mbox):

From: David Fussner <dfussner <at> googlemail.com>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: 65912 <at> debbugs.gnu.org
Subject: Re: bug#65912: 2023-08-31;
 Fix xref errors when matching in unvisited files
Date: Sun, 17 Sep 2023 18:19:43 +0100

[Message part 1 (text/plain, inline)]

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 <at> 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 <at> ikumi.que.jp> wrote:
>
>> Hi David,
>>
>> > On Fri, 15 Sept 2023, 06:45 Ikumi Keita, <ikumi <at> 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
>>
>>

[Message part 2 (text/html, inline)]

Message #26 received at 65912 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: David Fussner <dfussner <at> googlemail.com>
Cc: 65912 <at> debbugs.gnu.org
Subject: Re: bug#65912: 2023-08-31;
 Fix xref errors when matching in unvisited files
Date: Tue, 19 Sep 2023 15:19:46 +0900

Hi David,

>>>>> David Fussner <dfussner <at> googlemail.com> writes:
> 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.

I pushed the fix to the git repo. I modified the addition of
`font-lock-set-defaults' in `font-latex-setup' to run only in temporal
buffers in order to minimize influence on the behavior for file-visiting
buffers.

I'll close this bug.

Regards,
Ikumi Keita
#StandWithUkraine #StopWarInUkraine

Message #31 received at 65912 <at> debbugs.gnu.org (full text, mbox):

From: David Fussner <dfussner <at> googlemail.com>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: 65912 <at> debbugs.gnu.org
Subject: Re: bug#65912: 2023-08-31;
 Fix xref errors when matching in unvisited files
Date: Tue, 19 Sep 2023 08:26:15 +0100

It all looks good here. Thank you, Keita!

On Tue, 19 Sept 2023 at 07:19, Ikumi Keita <ikumi <at> ikumi.que.jp> wrote:
>
> Hi David,
>
> >>>>> David Fussner <dfussner <at> googlemail.com> writes:
> > 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.
>
> I pushed the fix to the git repo. I modified the addition of
> `font-lock-set-defaults' in `font-latex-setup' to run only in temporal
> buffers in order to minimize influence on the behavior for file-visiting
> buffers.
>
> I'll close this bug.
>
> Regards,
> Ikumi Keita
> #StandWithUkraine #StopWarInUkraine

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.