Druckbare Version
Dieser Thread ist gedacht, um über den folgenden Beitrag zu diskutieren:
http://www.mrunix.de/forums/showthread.php?t=66921
----------------------------------------------
Falls jemand noch etwas dazu zu ergänzen hat - jetzt wär die Gelegenheit :D
MfG Bischi
Zwei Änderungs- bzw. Ergänzungsvorschläge:
- Statt "Bilder können ersetzt werden[...]" würde ich "Bilder sollten ersetzt werden[...]" schreiben. Die tatsächliche Bilddatei ist meistens nicht Ursache des Problems, ein \includegraphics ohne entsprechendes Bild ergibt jedoch kein lauffähiges Beispiel.
- Ein Hinweis auf die filecontents-Umgebung wäre praktisch. Vielleicht etwa so (einzufügen nach dem Absatz über Bilder):
Wenn du in deinem Beispiel auf weitere Dateien zugreifen musst (häufig ist das eine bib-Datei, die als Literaturverzeichnis dient), kannst du diese Dateien mittels einer filecontents-Umgebung zum Teil deines Beispiels machen und potentiellen Helfern so einige Arbeit ersparen. Der Code dafür sieht so aus (einzufügen vor \begin{document}):
Code:\usepackage{filecontents}
\begin{filecontents}{dateiname.bib}
(Inhalt der Datei)
\end{filecontents}
lockstep
Es ist zwar nur eine Kleinigkeit, sollte aber nicht unerwähnt bleiben: da fehlt ein Leerzeichen :)
Zitat:
Zitat von Xenara
@lockstep:
vielen Dank für die Anmerkungen.
Zum filecontents: Das ist so jetzt fast wortgenau aus deinem Vorschlag mit drin.
Zu den Bildern: Den Passus habe ich auf deine Anregung hin ziemlich überarbeitet. So müsst es klarer sein.
@Hobbes: Danke :o Ich bin um solche Hinweise echt froh, irgendwann sieht man es selber einfach nicht mehr...
außer wird immer noch mit ß geschrieben ...Zitat:
Zitat von Hobbes
Herbert
Da wir gerade dabei sind: Auch Spaß macht sich mit Doppel-s nicht so gut - das meinen sowohl die amtliche Schreibung in Deutschland als auch ich als Wiener. :DZitat:
Zitat von voss
Sorry, aber ich tippe den Text von der Schweiz aus, und da gibts nunmal überhaupt kein "ß".
Klein, aber fein: Es heißt nunmehr Tipp (= neue Rechtschreibung), nicht mehr Tip (= alte Rechtschreibung).
@bischi: Ich nehme an, du möchtest den ursprünglichen Thread schließen.
lockstep
Nö - sonst hätte ich es gemacht :D Aber danke für den Hinweis ;)Zitat:
Zitat von lockstep
(Ich will ihn vorderhand nicht sperren, damit Xenara den Beitrag bei Bedarf verändern kann... Keine Ahnung, ob das bei gesperrtem Beitrag auch noch einfach ginge... Und solange kein Missbrauch betrieben wird :))
MfG Bischi
Wenns zum Inhalt nichts gibt, kann man den Ausgangsthread gerne schliessen, von mir aus passt das mal soweit.
Edit: Grad noch die verschiedenen Komplierungsmöglichkeiten eingefügt (dvips, pdflatex) und die Erwähnung von BibTeX hat auch gefehlt.
Habe noch den Hinweis auf das Löschen der von LaTeX erstellten Dateien eingefügt, Absatz "Von LaTeX erzeugte Dateien gelöscht?".
Schon witzig - ein klassischer Stolperstein für LaTeX-Anfänger, den wir bis jetzt alle zu erwähnen vergessen haben.
lockstep
Aufgrund dieses Threads (insbesondere ab Beitrag Nr. 13) rege ich an, eine Anmerkung zu den Tücken von \include einzufügen. Ich bin mir zwar nicht sicher, wie oft dieser Befehl problematische Nebenwirkungen hat, aber aufgrund des Hinweises von Ulrike Fischer kann man durchaus auf \include verzichten.
Die Formulierung könnte etwa so lauten (Verbesserungsvorschläge erwünscht!): "Falls du Dateien mittels \include einbindest: Tritt der Fehler auch auf, wenn du die entsprechenden Textteile direkt in dein Hauptdokument einbindest?"
lockstep
auf \include kann man definitiv _nicht_ verzichten, wenn man mitZitat:
Zitat von lockstep
großen Dokumenten arbeitet und nicht jedesmal alles
übersetzen will.
Herbert
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.Zitat:
Zitat von lockstep
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.
Es gibt in LaTeX \include{Datei} und \input{Datei} und es gibt inZitat:
Zitat von BeniBela
TeX \input Datei
Und die Fehldermeldungen sind eindeutig! Wenn GUIs zu blöd sind,
diese richtig zu interpretieren, dann sollte man eine andere wähken.
Herbert
Wieso soll \include Probleme machen?Zitat:
Zitat von Xenara
Herbert
Und \Input aus srcltx.styZitat:
Zitat von voss
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.Zitat:
Zitat von voss
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 ...Zitat:
Zitat von BeniBela
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.Zitat:
Zitat von lockstep
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
Doch! Ich poste meine log-Datei (Fehler in Zeile 5) und gebe aber die verkürzte Version als MB an. Dann ist es schwer, beim Testen des MB (Fehler in Zeile 4), dies in Übereinstimmung mit dem log-File zu bekommen!Zitat:
Zitat von bischi
Christian.
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.
Du gibst das Logfile passend zum MB an, sonst kannst duZitat:
Zitat von tral
dir auch alles sparen und Kommentare in einem Minimalbeispiel
sind nur dann von Interesse, wenn sie den Tester etwas zu sagen
haben.
Herbert
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...Zitat:
Zitat von voss
War ja nur eine Anregung, das klar zu stellen...
Christian.
Ich hab den Abschnitt im Anleitungsbeitrag leicht umformuliert, es gibt jetzt für einen bestehenden Absatz eine neue Überschrift "Wichtig: Wie kommts ins Forum?" und da ist auch der Umgang mit dem .log-File beschrieben.
Ist das so eindeutig?
Btw: Es wäre echt klasse, wenn es Rückmeldung von jemandem gäbe, der versucht hat, anhand der Anleitung ein MB zu erstellen, um Feedback von einem "Anwender" zu bekommen.
Danke erstmal, Xenara.
Kleine Korrektur:Zitat:
Zitat von Xenara
"das fix und fertige Minimalbeispiels"
Vielleicht könnte man auch schreiben:
"wenn Du exakt das Minimalbeispiels kompilierst, welches du im Posting verwendest."
Christian.
Ok, danke, habs mit deiner Anregung umformuliert, es sollte jetzt klarer und einfacher sein.
Moin moin,
irgendwie stell ich mir gerade so einen armen Tropf vor, der alles so macht, wie in Xenaras Anleitung beschrieben -- bis auf `backup' (wer backups macht, ist feige, oder?;-) und `neuen Ordner' ... und schwupps wird seine `dateiname.bib' überschrieben.Zitat:
Zitat von lockstep
Dabei wird bereits im LaTeX-Kern eine filecontents-Umgebung definiert -- und die überschreibt nicht eine evtl bereits bestehende Datei.
@Xenara: ich würde zumindest darauf hinweisen, daß die filecontents-Umgebung des filecontents-Pakets eine ggf bereits vorhandene Datei gleichen Namens standardmäßig überschreibt ... oder \usepackage{filecontents} weglassen.
Davon abgesehen: Super Anleitung! :cool:
MfG
Hi rais,Zitat:
Zitat von rais
berechtigter Hinweis, danke. Ich werd eine Anmerkung dazu machen.
Aber: Es war durchaus Absicht, \usepackage{filecontents} mir reinzunehmen, _damit_ es überschrieben wird. Denn imho ist es tierisch lästig, wenn man an einem Literatureintrag was ausprobieren will, jedesmal in Explorer&Co. die entsprechende .bib-Datei zu suchen, "Löschen", "Ja, wirklich löschen", und dann kann man erst kann man ein simples Leerzeichen oder wasauchimmer einfügen.
Ausserdem (aus eigener Erfahrung) ist es als Anfänger unlogisch: Man macht eine Änderung, sie wird aber nicht umgesetzt... grosses Fragezeichen... und irgendwann kommt man drauf, dass die Datei ja gar nicht aktualisiert wird.
Und den Teil mit dem Backup werd ich vielleicht mal noch in fett, riesig und rot hervorheben. Eine überschriebene Filecontents-Datei ist sonst wohl noch das kleinste Problem.
es ist aber für den Anfänger genauso nervig, wenn er ÄnderungenZitat:
Zitat von rais
in seiner filecontents-Umgebung vornimmt und sich wundert, warum
ständig die alte Variante genommen wird ...
Das mögliche Überschreiben von Dateien ist immer gegeben, daher stellt
das Einbinden des filecontents-Paket kein wirkliches PRoblem dar,
sondern ist eher hilfreich!
Herbert
Gut, dass du das auch so siehst, Herbert.
Ich hab jetzt in die Anleitung eine kleine Erläuterung zu den beiden Varianten und ihren Tücken aufgenommen und nochmal explizit die Sache mit dem Backup hervorgehoben.
Würdet ihr es kurz mal durchschauen?
Nun, ich empfehle:
Führe Tests (wie z.B. das Erstellen eines Minimalbeispiel oder das Ausprobieren eines Codes) nie mit deinem Originaldokument durch.
Ganz besonders dann nicht, wenn du den Code nicht wirklich verstehst.
Erzeuge stattdessen irgendwo einen Ordner "Test", fülle ihn mit einigen Beispieldateien (test.tex, testbild.eps, testbild.png, testbib.bib). Kurze Dokumente können einfach an den Anfang von test.tex kopiert und dann kompiliert werden. Für größere Tests kann man das Originaldokument als Ganzes in den Testordner kopieren und dann rumspielen.
LaTeX kann existierende Dateien überschreiben - es muss das können, um z.B. die toc-Datei immer wieder neu zu erzeugen. Denke also nach, bevor du neuen Code in dein Originaldokument kopierst, und mache regelmäßig Backups.
An dieser Stelle sollte wohl auch makeindex erwähnt werden. Formulierungsvorschlag: "Ähnliches gilt für die Erstellung von Stichwortverzeichnissen, Glossaren und Abkürzungsverzeichnissen: Hier muss auch mit makeindex kompiliert werden - wie oft und in welcher Reihenfolge, entnimmst du den Dokumentationen zu den jeweiligen Verzeichnissen."Zitat:
Zitat von Xenara
Übrigens heißt es kompilieren. ;)
lockstep
Hi lockstep,
danke für den Hinweis, habs genau so eingebaut. Und den Rechtschreibfehler bei der Gelegenheit natürlich auch korrigiert.