bug-auctex
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#28953: 11.91.0; wrong alert about inexistent LaTeX errors


From: jfbu
Subject: bug#28953: 11.91.0; wrong alert about inexistent LaTeX errors
Date: Thu, 16 Jun 2022 15:27:28 +0200

Hi Mosé, (replying about 56 months later)

> 
> Le 24 oct. 2017 à 00:24, Mosè Giordano <mose@gnu.org> a écrit :
> 
> 2017-10-23 18:35 GMT+02:00 jfbu <jfbu@free.fr>:
>> 
>> Le 23 oct. 2017 à 17:09, Mosè Giordano <mose@gnu.org> a écrit :
>> 
>>> 2017-10-23 14:47 GMT+02:00 jfbu <jfbu@free.fr>:
>>>> In real life example the ``:1: `` pattern appeared farther away on the line
>>>> inside a sentence. To a human, it is obvious it is not a LaTeX error
>>>> message. I am confident the logic for recognizing such error messages
>>>> is improvable. I plan to look at it when I get time to make
>>>> concrete proposal.
>>> 
>>> The relevant regexp is at line 1507 of tex-buf.el:
>>> https://git.savannah.gnu.org/gitweb/?p=auctex.git;a=blob;f=tex-buf.el;h=f458651c2cffc110ef4af4541c6b08af976907fb;hb=HEAD#l1507
>>> Perhaps ".*" is too greedy, anyway that regexp should match anything
>>> that is a legal path.  I don't expect it to be supereasy to find a
>>> regexp matching a path but not a whole sentence ;-)
>> 
>> 
>> Indeed. But the regexp is really minimal, is there some documentation
>> about the underlying difficulties?
> 
> I don't think there is such documentation, but I'd be happy to be proven 
> wrong.
> 

about this:

> As far as I know, using exclamation mark to start an error message is
> just a widespread convention, there is nothing fundamental in it.  For


Only to point out that it is core TeX behaviour in errorstopmode:
(quoting from tex.web sources:)

> The print_err procedure supplies a ‘!’ before the official message, and makes 
> sure that the terminal is awake if a stop is going to occur. 
> 
> @ The global variable |interaction| has four settings, representing increasing
> amounts of user interaction:
> 
> @d batch_mode=0 {omits all stops and omits terminal output}
> @d nonstop_mode=1 {omits all stops}
> @d scroll_mode=2 {omits error stops}
> @d error_stop_mode=3 {stops at every opportunity to interact}
> @d print_err(#)==begin if interaction=error_stop_mode then wake_up_terminal;
>   print_nl("! "); print(#);
>   end


Any LaTeX \PackageError ultimately goes through TeX’s \errmessage and \errhelp 
mechanisms.

But the change file tex.ch implements -file-line-error option and this is 
relevant:

> @x [6.73] l.1734 - file:line:error style error messages.
>   print_nl("! "); print(#);
> @y
>   if file_line_error_style_p then print_file_line
>   else print_nl("! ");
>   print(#);
> @z


The procedure print_file_line has coding

> procedure print_file_line;
> var level: 0..max_in_open;
> begin
>   level:=in_open;
>   while (level>0) and (full_source_filename_stack[level]=0) do
>     decr(level);
>   if level=0 then
>     print_nl("! ")
>   else begin
>     print_nl (""); print (full_source_filename_stack[level]); print (":");
>     if level=in_open then print_int (line)
>     else print_int (line_stack[level+1]);
>     print (": ");
>   end;
> end;


Some other relevant pieces from tex.ch from web2c 

> % Plus, it's nicer just to do an exit with the appropriate status code
> % under Unix.  We call it `uexit' because there's a WEB symbol called
> % `exit' already.  We use a C macro to change `uexit' back to `exit'.


> @d do_final_end==begin
>    update_terminal;
>    ready_already:=0;
>    if (history <> spotless) and (history <> warning_issued) then
>        uexit(1)
>    else
>        uexit(0);
>    end


and from tex.web:

> @d spotless=0 {|history| value when nothing has been amiss yet}
> @d warning_issued=1 {|history| value when |begin_diagnostic| has been called}
> @d error_message_issued=2 {|history| value when |error| has been called}
> @d fatal_error_stop=3 {|history| value when termination was premature}



which is probably related to the exit status returned by binary
in case \errmessage has been made used of

Cheers,

Jean-François






reply via email to

[Prev in Thread] Current Thread [Next in Thread]