GNU bug report logs - #28456
11.90.2.2017-07-25; \\input parsing

Previous Next

Package: auctex;

Reported by: Pierre Lorenzon <devel <at> pollock-nageoire.net>

Date: Thu, 14 Sep 2017 06:17:01 UTC

Severity: normal

Tags: fixed

Found in version 11.90.2.2017

Done: Arash Esbati <arash <at> gnu.org>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-auctex <at> gnu.org:
bug#28456; Package auctex. (Thu, 14 Sep 2017 06:17:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Pierre Lorenzon <devel <at> pollock-nageoire.net>:
New bug report received and forwarded. Copy sent to bug-auctex <at> gnu.org. (Thu, 14 Sep 2017 06:17:01 GMT) Full text and rfc822 format available.

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

From: Pierre Lorenzon <devel <at> pollock-nageoire.net>
To: bug-auctex <at> gnu.org
Subject: 11.90.2.2017-07-25; \\input parsing
Date: Thu, 14 Sep 2017 07:55:43 +0200 (CEST)
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.

Be sure to consult the FAQ section in the manual before submitting
a bug report.  In addition check if the bug is reproducable with an
up-to-date version of AUCTeX.  So please upgrade to the version
available from http://www.gnu.org/software/auctex/ if your
installation is older than the one available from the web site.

If the bug is triggered by a specific (La)TeX file, you should try
to produce a minimal sample file showing the problem and include it
in your report.

Your report will be posted for the auctex package at the GNU bug
tracker.  Visit http://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=auctex
to browse existing AUCTeX bugs.
------------------------------------------------------------------------

Hi,

Here is the sample file:

>>>  -- .tex 

\begin{plnpsudpb}{À rendre le 19 octobre 2016}
  \label{PB-I}
  %%
  \input{Introduction}
  %% 
  \input{../../Exercices/Ensembles/Applications-Proprietes}
  %%
  \begin{exercice}[L'addition dans $\Nat$]

   
  \end{exercice}
  %% 
\end{plnpsudpb}
%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "Header"
%%% End: 

>>>  -- End .tex 

And here is the style .el file produced by auctex:

>>>  -- .el 

(TeX-add-style-hook
 "Probleme-I"
 (lambda ()
   (TeX-run-style-hooks
    "Introduction")
   (LaTeX-add-labels
    "PB-I"))
 :latex)


>>>  -- End .el

As if second \input
  \input{../../Exercices/Ensembles/Applications-Proprietes}

were not parsed when first one

  \input{Introduction}

is. In fact looking carefully at regexp used to match \\input
which is part of the LaTeX-auto-regexp-list variable, it
clearly appears that an path like \input{../../something} will
not be parsed.

Question is why? When LaTex allows inputs with so complexe
paths, why are they not parse by auctex?

Surely I can add somehting suitable to the parse variables so
that these inputs will be detected but why is it not done by
default in auctex?


Regards

Pierre




Emacs  : GNU Emacs 26.0.50 (build 1, x86_64-pc-linux-gnu)
 of 2017-09-11
Package: 11.90.2.2017-07-25

current state:
==============
(setq
 AUCTeX-date "2017-07-25"
 window-system nil
 LaTeX-version "2e"
 TeX-style-path '("~/.emacs.d/auctex"
		  "/home/devel/.emacs.d/elpa/auctex-11.91.0/style"
		  "/usr/local/share/texmf/tex/latex/auto/"
		  "/usr/local/share/texmf/tex/latex/style/" "auto" "style")
 TeX-auto-save t
 TeX-parse-self t
 TeX-master nil
 TeX-command-list '(("pdf" "ps2pdf13 %s.ps" TeX-run-command nil t)
		    ("Hacha" "hacha %s.html" TeX-run-command nil t)
		    ("PHPindex" "hacha -o index.php %s.html" TeX-run-command
		     nil t)
		    ("PHP" "hevea -fix -o %s.php %t" TeX-run-command nil t)
		    ("Info" "hevea -fix -info %t" TeX-run-command nil t)
		    ("Txt" "hevea -fix -text %t" TeX-run-command nil t)
		    ("Hevea" "hevea -fix %t" TeX-run-command nil t)
		    ("TeX" "%(PDF)%(tex) %`%S%(PDFout)%(mode)%' %t"
		     TeX-run-TeX nil
		     (plain-tex-mode texinfo-mode ams-tex-mode) :help
		     "Run plain TeX")
		    ("LaTeX" "%`%l%(mode)%' %t" TeX-run-TeX nil
		     (latex-mode doctex-mode) :help "Run LaTeX")
		    ("Makeinfo" "makeinfo %t" TeX-run-compile nil
		     (texinfo-mode) :help "Run Makeinfo with Info output")
		    ("Makeinfo HTML" "makeinfo --html %t" TeX-run-compile nil
		     (texinfo-mode) :help "Run Makeinfo with HTML output")
		    ("AmSTeX" "%(PDF)amstex %`%S%(PDFout)%(mode)%' %t"
		     TeX-run-TeX nil (ams-tex-mode) :help "Run AMSTeX")
		    ("ConTeXt" "texexec --once --texutil %(execopts)%t"
		     TeX-run-TeX nil (context-mode) :help "Run ConTeXt once")
		    ("ConTeXt Full" "texexec %(execopts)%t" TeX-run-TeX nil
		     (context-mode) :help "Run ConTeXt until completion")
		    ("BibTeX" "bibtex %s" TeX-run-BibTeX nil t :help
		     "Run BibTeX")
		    ("View" "dvi2tty -q -w 132 %s" TeX-run-command t t :help
		     "Run Text 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-command t t :help
		     "Generate PostScript file")
		    ("Index" "makeindex %s" TeX-run-command nil t :help
		     "Create index file")
		    ("Check" "lacheck %s" TeX-run-compile nil (latex-mode)
		     :help "Check LaTeX file for correctness")
		    ("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")
		    )
 )




Information forwarded to bug-auctex <at> gnu.org:
bug#28456; Package auctex. (Fri, 15 Sep 2017 16:46:01 GMT) Full text and rfc822 format available.

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

From: Mosè Giordano <mose <at> gnu.org>
To: Pierre Lorenzon <devel <at> pollock-nageoire.net>
Cc: 28456 <at> debbugs.gnu.org
Subject: Re: bug#28456: 11.90.2.2017-07-25; \\input parsing
Date: Fri, 15 Sep 2017 18:44:15 +0200
Hi Pierre,


2017-09-14 7:55 GMT+02:00 Pierre Lorenzon <devel <at> pollock-nageoire.net>:
> As if second \input
>   \input{../../Exercices/Ensembles/Applications-Proprietes}
>
> were not parsed when first one
>
>   \input{Introduction}
>
> is. In fact looking carefully at regexp used to match \\input
> which is part of the LaTeX-auto-regexp-list variable, it
> clearly appears that an path like \input{../../something} will
> not be parsed.

I can reproduce the error and confirm your analysis.

> Question is why? When LaTex allows inputs with so complexe
> paths, why are they not parse by auctex?

It's hard to answer the question: that regexp has been there for more
than 20 years now ;-)

I don't have the time to do it now (I also have a flaky Internet
connection in this period), but if someone wants to tackle this issue,
I fixed something similar for \addbibresource a few months ago:

    * b2f69e18 (2017-03-31)  Fix detection of bibliography files with
    dots in path

Please, also add a test.  Maybe this could be an occasion to review
similar regexps (for \include, \bibliography, etc), or maybe have a
common variable for all this cases.

Bye,
Mosè




Information forwarded to bug-auctex <at> gnu.org:
bug#28456; Package auctex. (Sat, 16 Sep 2017 03:44:01 GMT) Full text and rfc822 format available.

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

From: Pierre Lorenzon <devel <at> pollock-nageoire.net>
To: mose <at> gnu.org
Cc: 28456 <at> debbugs.gnu.org
Subject: Re: bug#28456: 11.90.2.2017-07-25; \\input parsing
Date: Sat, 16 Sep 2017 05:23:06 +0200 (CEST)
Hi Mosè,

Here is a small hack to fix this bug in particular case I
encountered but I am not sure that the regexp is able to render
the whole complexity of expressions that might be parsed.


>>>  -- Patch 
(defconst regexp-input
  "\\\\input{\\(\\(\\(\\.*\\)/\\)*[^#}%\\\\\\.\n\r]+\\)\\(\\.[^#}%\\\\\\.\n\r]+\\)?}"
  "Regexp used to match \\input{something}")

(defconst regexp-include
  "\\\\include{\\(\\(\\(\\.*\\)/\\)*[^#}%\\\\\\.\n\r]+\\)\\(\\.[^#}%\\\\\\.\n\r]+\\)?}"
  "Regexp used to match \\include{something}")

(add-to-list 'LaTeX-auto-regexp-list
	      (list regexp-input 1 'TeX-auto-file))
(add-to-list 'LaTeX-auto-regexp-list
	      (list regexp-include 1 'TeX-auto-file))

>>>  -- End Patch


It is clear that two constants above derive from the same
expression and that a common model might certainly be defined
for all these regexps.



Pierre



From: Mosè Giordano <mose <at> gnu.org>
Subject: Re: bug#28456: 11.90.2.2017-07-25; \\input parsing
Date: Fri, 15 Sep 2017 18:44:15 +0200

> Hi Pierre,
> 
> 
> 2017-09-14 7:55 GMT+02:00 Pierre Lorenzon <devel <at> pollock-nageoire.net>:
>> As if second \input
>>   \input{../../Exercices/Ensembles/Applications-Proprietes}
>>
>> were not parsed when first one
>>
>>   \input{Introduction}
>>
>> is. In fact looking carefully at regexp used to match \\input
>> which is part of the LaTeX-auto-regexp-list variable, it
>> clearly appears that an path like \input{../../something} will
>> not be parsed.
> 
> I can reproduce the error and confirm your analysis.
> 
>> Question is why? When LaTex allows inputs with so complexe
>> paths, why are they not parse by auctex?
> 
> It's hard to answer the question: that regexp has been there for more
> than 20 years now ;-)
> 
> I don't have the time to do it now (I also have a flaky Internet
> connection in this period), but if someone wants to tackle this issue,
> I fixed something similar for \addbibresource a few months ago:
> 
>     * b2f69e18 (2017-03-31)  Fix detection of bibliography files with
>     dots in path
> 
> Please, also add a test.  Maybe this could be an occasion to review
> similar regexps (for \include, \bibliography, etc), or maybe have a
> common variable for all this cases.
> 
> Bye,
> Mosè




Information forwarded to bug-auctex <at> gnu.org:
bug#28456; Package auctex. (Mon, 30 May 2022 09:39:02 GMT) Full text and rfc822 format available.

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

From: Arash Esbati <arash <at> gnu.org>
To: Pierre Lorenzon <devel <at> pollock-nageoire.net>
Cc: 28456 <at> debbugs.gnu.org
Subject: Re: bug#28456: 11.90.2.2017-07-25; \\input parsing
Date: Mon, 30 May 2022 11:38:14 +0200
Hi Pierre,

Pierre Lorenzon <devel <at> pollock-nageoire.net> writes:

> As if second \input
>   \input{../../Exercices/Ensembles/Applications-Proprietes}
>
> were not parsed when first one
>
>   \input{Introduction}
>
> is. In fact looking carefully at regexp used to match \\input
> which is part of the LaTeX-auto-regexp-list variable, it
> clearly appears that an path like \input{../../something} will
> not be parsed.

I think this issue is now addressed in commit d47a6e8716.  Do you have
the possibility to update your AUCTeX installation (or apply that patch)
and see if works for you as well?

TIA.  Best, Arash




Information forwarded to bug-auctex <at> gnu.org:
bug#28456; Package auctex. (Mon, 04 Mar 2024 11:49:01 GMT) Full text and rfc822 format available.

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

From: Arash Esbati <arash <at> gnu.org>
To: Pierre Lorenzon <devel <at> pollock-nageoire.net>
Cc: 28456 <at> debbugs.gnu.org
Subject: Re: bug#28456: 11.90.2.2017-07-25; \\input parsing
Date: Mon, 04 Mar 2024 12:47:24 +0100
Arash Esbati <arash <at> gnu.org> writes:

> Hi Pierre,
>
> Pierre Lorenzon <devel <at> pollock-nageoire.net> writes:
>
>> As if second \input
>>   \input{../../Exercices/Ensembles/Applications-Proprietes}
>>
>> were not parsed when first one
>>
>>   \input{Introduction}
>>
>> is. In fact looking carefully at regexp used to match \\input
>> which is part of the LaTeX-auto-regexp-list variable, it
>> clearly appears that an path like \input{../../something} will
>> not be parsed.
>
> I think this issue is now addressed in commit d47a6e8716.  Do you have
> the possibility to update your AUCTeX installation (or apply that patch)
> and see if works for you as well?

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

More information was requested, but not provided.  Therefore I'm closing
this report for now.  We can reopen if new input arrives.

Best, Arash




Added tag(s) fixed. Request was from Arash Esbati <arash <at> gnu.org> to control <at> debbugs.gnu.org. (Mon, 04 Mar 2024 11:51:02 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 28456 <at> debbugs.gnu.org and Pierre Lorenzon <devel <at> pollock-nageoire.net> Request was from Arash Esbati <arash <at> gnu.org> to control <at> debbugs.gnu.org. (Mon, 04 Mar 2024 11:51:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 02 Apr 2024 11:24:23 GMT) Full text and rfc822 format available.

This bug report was last modified 24 days ago.

Previous Next


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