Avoid opening a buffer showing origin of an error (or warning) from \PackageError (Warning)

[jfbu]

Hello,

This is a request for keeping some current behavior
only under some option, which will default to nil,
i.e. will say not to behave as has been the case
so far.

When an error is created by some conditions triggering
a \PackageError in original LaTeX support files, such
as package sources, or sometimes more obscure support
files, Emacs/AUCTeX opens this file in
a buffer.  Very rarely is this useful, even to hardcore
LaTeX developers.  And it is dangerous when the LaTeX
installation was not done under restricted file
permissions, as then one can by mistake modify in place
the said file.  And sometimes one has some package
installed under $HOME for various reasons where most
likely user has write permission on the file so the
danger of overwriting something is high then.

I have very very often
been confronted with that and never ever was it
useful, even though I do LaTeX macro programming.
Knowing the filename originating the \PackageError
would be almost always largely sufficient.

This becomes even more problematic when Debug Warnings
is activated, because Warnings tend to be emitted very
often by packages, sometimes for not so urgent reasons,
so here the risks are increased.

Regarding errors, going to the source line of the
error is definitely a good thing (more than that,
it is crucial to AUCTeX usefulness) *when* limited
to going to *current* document.  LaTeX Package Errors
have a definite pattern (hmm... make this plural due
to LaTeX3, see for example what happens when one
attempts to compile via pdflatex a document using
fontspec -- which I know AUCTeX guards against,
usually) and it should be feasible to distinguish
between a deliberate \PackageError and a core TeX error.

Presumably this is what AUCTeX knows already to do,
and anyhow the simplest could be to keep current code
but by default add to it a check whether
the-file-where-lies-the-offending-error is in
current directory and display it only then, except
if some
customizable option "always-go-to-error-originating-file"
has been made use of.

Best,
Jean-François