Hallo!
Könnte man nicht auf \input{*.tex} ausweichen? ggf in Kombination mit % davor?
Gruß Max
P.S.: Dazu möchte ich sagen, dass es irgendwann natürlich zu umständlich werden würde...
Druckbare Version
Hallo!
Könnte man nicht auf \input{*.tex} ausweichen? ggf in Kombination mit % davor?
Gruß Max
P.S.: Dazu möchte ich sagen, dass es irgendwann natürlich zu umständlich werden würde...
Danke für den Hinweis. Ich werde versuchen, es in den Teil "Vom Dokument zum Minimalbeispiel" einzubauen, es fehlt nämlich tatsächlich noch ein Hinweis darauf, wie mit solchen inputs/includes umgegangen werden soll (unabhängig davon, ob sie der Fehler sind). Ich denke, dort kann man deinen Vorschlag gut unterbringen.
Dass include Probleme machen kann, wusste ich bisher noch nicht.
Soweit ich verstanden habe, ist input nur eine "Umleitung" im Code, während include auf einer neuen Seite anfängt und .aux-Dateien erzeugt.
Weshalb und in welchen Fällen kann es da zu Problemen mit include kommen? Wo liegen genau die Unterschiede? Das wäre für mich interessant zu wissen, damit ich den Text entsprechend korrekt anpassen kann.
Diese Diskussion wurde schon verschiedentlich geführt, beispielsweise hier:
http://www.wer-weiss-was.de/theme155...le3325219.html
Vielleicht kannst Du da wesentliche Argumente übernehmen?
Für mich als Nicht-Guru bestehen die Unterschiede im Wesentlichen darin,
dass ich (a) \input's schachteln kann (im Gegensatz zu \include), (b) \include's immer eine neue Seite beginnen und (c) mir \include die Möglichkeit eines selektiven Vorgehens mittels \includeonly erlaubt.
Es gibt anscheinend auch Unterschiede, ob die Logdatei zuverlässig von einem Programm ausgewertet werden kann, so dass auch alle gemeldeten Fehler der richtigen Datei zugeordnet werden.
Zumindest steht im Kile-Quellcode, dass man nicht \input, sondern entweder \Input (wohl noch eine dritte Variante) oder \include verwenden sollte.
Und \Input aus srcltx.sty
Das Problem sind wohl die Dateinamen. Bei \input schreibt TeX bei einer neuen Datei im Log "(dateiname" und nachdem alle Fehler in dieser Datei ausgegeben wurden, fährt es nach der Ausgabe einer schließende Klammer mit den Fehlern in der Datei mit dem \input fort.
Wenn die fehlerhafte Dokumentstelle jetzt aber eine ) enthält, gibt es im Log zu viele schließende Klammern und es ist nicht eindeutig, welche Klammer zum Text und welche zum Log gehört.
für LaTeX uninteressant ...
es bleibt trotzdem ein Problem der GUIs und nicht LaTeX, dass sieZitat:
Das Problem sind wohl die Dateinamen. Bei \input schreibt TeX bei einer neuen Datei im Log "(dateiname" und nachdem alle Fehler in dieser Datei ausgegeben wurden, fährt es nach der Ausgabe einer schließende Klammer mit den Fehlern in der Datei mit dem \input fort.
Wenn die fehlerhafte Dokumentstelle jetzt aber eine ) enthält, gibt es im Log zu viele schließende Klammern und es ist nicht eindeutig, welche Klammer zum Text und welche zum Log gehört.
das nicht vernünftig scannen können.
Herbert
Die Anregungen zu input/include sind jetzt in der Anleitung unter "Vom Dokument zum Minimalbeispiel - Variante 1" -> Absatz "6." eingefügt.
Auf Erklärungen zu input/include habe ich verzichtet, da der Beitrag ja "nur" eine Anleitung sein soll, die Probleme einzugrenzen und ein Minimalbeispiel zu erstellen.
Hallo,
mir ist gerade aufgefallen, dass es durch das Auskommentieren zu Missverständnissen kommen kann:
Z.B. hat jemand ein langes Dokument und kommentiert darin aus, um ein Minimalbesipiel zu erstellen. Anschließend kopiert er das in eine CODE-Umgebung und löscht dabei alle Kommentare, da die ja niemanden etwas angehen.
Das Problem daran ist, dass jetzt die Zeilenzähler der beiden Dokumente (MB mit und ohne Kommentare) verschieden sind, also z.B. log-Ausgaben nicht mehr so richtig verglichen werden können.
Vielleicht sollte das in der Anleitung zum Minimalbeispiel klarer gemacht werden...
Christian.
PS. Ach ja, fast vergessen ;)
führt zu:Code:\documentclass{article}
%\usepackage{usefulstuff}
\begin{document}
TEST \wrongCommand
\end{document}
! Undefined control sequence.
l.5 TEST \wrongCommand
, wohingegen
ergibt:Code:\documentclass{article}
\begin{document}
TEST \wrongCommand
\end{document}
! Undefined control sequence.
l.4 TEST \wrongCommand
Du musst halt die zum Beispiel passende Log-Datei mitposten - dann gibts auch kein Problem ;)
MfG Bischi
Aber du testest doch das verkürzte MB nochmal, bevor du es ins Forum stellst. Du willst ja sichergehen, dass nicht versehentlich zu viel oder das Falsche gelöscht wurde, und ob der Fehler in genau diesem Code noch reproduzierbar ist.
Und du postest die zum _MB_ gehörende log-Datei, die bei dir entsteht und per Definition das Problem noch immer aufweist. Dann passts doch wieder.
Zitat aus dem Fehlersuche-Beitrag:
Wenn der Fehler im MB gefunden ist, musst du sowieso die entsprechende Stelle im Ursprungsdokument finden und korrigieren.Zitat:
Das fertige MB kompilierst Du dann und überprüfst, ob das Ergebnis (z.B. die Fehlermeldung) tatsächlich noch das gleiche ist wie beim Ausgangsdokument.
Und dann stellst Du diesen Code als Minimalbeispiel mit einer kurzen, aussagekräftigen Erklärung hier ins Forum.
Ja, mir ist das schon klar. Aber ich glaube, halt anderen nicht. Und dann kann es zu Missverständnissen kommen. Siehe z.B. hier: http://www.mrunix.de/forums/showpost...58&postcount=3 und meine Antwort...
War ja nur eine Anregung, das klar zu stellen...
Christian.