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

[jfbu]

Hi Mosè

Le 25/10/2017 à 00:59, Mosè Giordano a écrit :
> 2017-10-24 9:25 GMT+02:00 jfbu <address@hidden>:
> > What about spaces? I know there isn't
> > a single file with spaces in its path on my TeX installation,
> > and I personally will never ever attempt to use such in my
> > TEXMFHOME or in the document repertory or sub-repertories.
>
> TeX and AUCTeX don't have problems with spaces in file names.  I also
> avoid spaces in file names, but asking people to completely stop using
> spaces in order to make AUCTeX work doesn't look good.
>
> > People doing
> >
> > \section{foo}\label{sec:1: (authorA)}
> >
> > See \ref{sec:1: (authorA)}
> >
> > will similarly get bitten by this problem.
>
> Are there really people mixing numeric style and literal style in
> labels? :-)  Using anything beside [a-zA-Z0-9-:] in LaTeX labels is
> usually a bad idea, just because there are packages playing with
> catcodes.  For example, underscores are legal in labels, but there are
> cases where you can get into troubles if you use them, see for example
> https://tex.stackexchange.com/q/121416/31416 or
> https://tex.stackexchange.com/a/18312/31416.

--- start of slightly off-topic LaTeX considerations

As is explained in the answer by HO:

> Usually the underscore with its standard catcode "subscript" (8) does
> not cause problems, if used inside \label or \ref:
>
> [...]
>
> Also shorthands of package babel are not a problem, because babel
> patches the \label/\ref system to add support for shorthands.

Any package making  a character like the underscore globally
active without at the same time using the babel patches for making
it safe in \label/\ref would simply be a buggy package.
HO does end his answer with the "underscore" package and mentions
that package is a good citizen.

A user making the underscore globally active with no further
ado is simply breaking LaTeX and not informed enough.

Notice that babel-french turns the colon : into an active
character, of course in a way compatible with babel's mechanism.
This mechanism is applied by hyperref package in \href parsing.

Ironically, there are issues with xelatex/lualatex where babel-french
does *not* use active characters at all; because the babel
mechanisms do not apply, the behaviour of \href is unexpected.
Very recently indeed, babel-french maintainer pushed a
fix to CTAN to handle that specific issue.

> Version:  3.3d  2017-10-19
>
>  Slight change for LuaTeX only:
>
>  The automatic insertion of non-breaking spaces before the colon
>  character has been improved: a spurious space is no longer inserted
>  in strings like "http://mysite";, "C:\textbackslash Program Files"
>  or "10:55".

Regarding that piece of the answer by egreg

> Warning. Some characters might give problems when babel is loaded
> along with varioref (for example the colon : with French and the
> double quote " with many languages). Without varioref these should be
> OK. As Martin points out, some packages might redefine _, making it
> unusable in labels.

it indicates a bug of varioref, that's all.

--- end of off-topic digression

Now,AUCTeX prompts user at each equation insertion with

(Optional) What label: eq:

now in a paper when it is not sure in advance which
equations one will link to, one is not going to invent
a name each time, and simply using numeric labels eq:1,
eq:2, is rather natural and I am sure people do this.

Or am I really as bezerk I tend to believe, years passing by?

I do agree AUCTeX is still rather robust here because even
using eq:1: as label appears to be ok, problems may arise
when having a space after the second colon.

As people have not complained too much on this issue it
is to some extent indication indeed that AUCTeX's minimal
regex to identify error messages is quite effective.

About

> TeX and AUCTeX don't have problems with spaces in file names.

Are spaces escaped in anyway when writing a filename to log?
Unfortunately, here it is not only TeX from TeXBook but rather
also the pdfTeX etc... rules which matters:

They introduced the
filename:linenumber: notation,
dropping the !<space> at start of line thus making log-parsing
more difficult. Perhaps they could have used a

! filename:linenumber: error

format, but would have this broken expectations from other contexts?

Best

Jean-François