[AUCTeX] Tricky: Master document not recognized

[Matthias Kempka]

Hi there,

I believe I have found a document that - while included - prevents
Auctex from recognizing the master document. It is not clear to me what
part of the document could trigger that as will be discribed in the
following.

The appended document master.tex is the master file, slave.tex is
included and the usual local variables pointing to the master file are
at the beginning of slave.tex.
As you see, master.tex loads german input encoding. This means to me
that typing the quotes " actually results in exactly the character " and
is not replaced by two single quotes. I use this to easier check the
behaviour, alternatively you may C-c C-c a few dozen times :-)

Now, actually, if I have loaded the master.tex file in emacs and I open
the file slave.tex as it is, the master file is not recognized as such:
" is replaced by two single quotes and C-c C-c tries to compile slave.tex.
If I modify slave.tex, i.e. delete the first text line, save and close
the buffer and load slave.tex again, it recognizes the master file. I
see this because " is no longer replaced.

I have reduced the document as far as I could, now I am at a point where
it seems to me that removing every further line results in recognizing
the master file (though I won't lay my hand into fire on this).  Adding
new text won't remove the ill behaviour.

Hopefully you see some more logic in this than I do.

Matthias Kempka



Emacs  : GNU Emacs 21.4.1 (i386-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2005-03-17 on trouble, modified by Debian
Package: AUCTeX 11.55

current state:
==============
(setq
 window-system 'x
 LaTeX-version "2e"
 TeX-style-path '("style/" "auto/"
                  "/usr/share/emacs21/site-lisp/auctex/style/"
                  "/var/lib/auctex/emacs21/")
 TeX-auto-save t
 TeX-parse-self t
 TeX-master nil
 )

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: t
%%% End: 
\documentclass{article}
\usepackage{graphicx}
\usepackage[utf8]{inputenc}
\usepackage[ngerman]{babel}

\begin{document}

\include{slave}

\end{document}

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "master"
%%% End: 






In der professionellen Software-Entwicklung hat sich mittlerweile die
Erkenntnis durchgesetzt, dass Unit-Tests ein unabdingbares Mittel f"ur ein
Mindestma{\ss} an Qualit"at darstellen. Daher mag die Entscheidung, Unit-Tests
einzusetzen leicht fallen, nicht enthalten ist allerdings die Aussage, wie
viel getestet wird. Ein ersch"opfendes Testen kommt alleine aufgrund der
Gr"o{\ss}e des Eingaberaums nicht-trivialer Programme nicht in Frage. Jedes


Testen kann die Korrektheit von Programmen nicht beweisen, und kann lediglich
als Ma{\ss}nahme betrachtet werden, die Vertrauen in die Qualit"at des Produkts
schafft. Die Aufgabe der Wissenschaft an dieser Stelle ist es, Vorgehensweisen

Solche Auswahlstrategien basieren allein auf der Spezifikation und stehen und
fallen mit derer Korrektheit. Diese Art des Testens nennt man
\textit{Black-Box-Testen}. Es ist naheligend, dass man ohne Spezifikation
keine vern"unftigen Tests schreiben k"onnen wird. Dennoch stellt die
Spezifikation allein nur einen Teil eines Software-Produktes dar. Leicht
einzusehend ist, dass allein auf der Grundlage der Spezifikation
einprogrammierte "Uberaschungen\footnote{nicht beabsichtigte Funktionalit"at}
oder unn"utzer Code, der lediglich die Wartung erschwert, nicht gefunden wird.
Schwerwiegender ist meines Erachtens anzusehen, dass Black-Box-Testen nicht
auf die Struktur des Codes eingeht. So werden einerseits Testf"alle
produziert, die f"ur den Code nicht wirklich eine Herausforderung darstellen.
Andererseits werden kritische Bereiche im Code, die allein auf der Art der
Implementierung beruhen, nicht gen"ugend abgedeckt.


Das \textit{White-Box-Testen} stellt dem Black-Box-Testen gegen"uber die
Implementierung in den Vordergrund. Der Quellcode ist hierbei bekannt, und es
werden Bedingungen angegeben, wie die Tests den Code durchlaufen m"ussen, um
\textit{"Uberdeckungen} zu erreichen. Ein Beispiel hierf"ur ist, dass jede
Anweisung mindestens einmal abgearbeitet werden muss\footnote{So einfach diese
  Bedingung auch ist, so stellt dieses primitivste aller
  "Uberdeckungsverfahren f"ur Sprachen mit schwacher oder g"anzlich ohne
  statischer Typisierung schon eine nicht zu untersch"atzende
  Qualit"atssicherung her.}. Diese Bedingungen zielen auf die Struktur des
Codes ab und werden daher \textit{strukturelle Testverfahren} genannt
\ref{balzert}. Man unterscheidet dabei zwischen Verfahren, die auf den
Kontrollflu\ss abzielen und Verfahren, die Bedingungen f"ur den Datenflu\ss
vorgeben. Unter Kontrollflu\ss versteht man die Reihenfolge, in der die
Anweisungen abgearbeitet werden. Sprechen wir von Datenflu\ss, so meinen wir
die Reihenfolge und Kombinationen vom Setzen und Lesen der Variablen. Im
den folgenden beiden Abschnitten werden einige Standard-Verfahren f"ur beide
Arten von "Uberdeckungsverfahren vorgestellt und damit die Grundlagen gelegt
f"ur die weitere Diskussion. Zun"achst aber ben"otigen wir noch eine Definition: