von MoeWe » Fr 23. Apr 2021, 09:46
Bilder von Code und Fehlermeldungen sind im Allgemeinen eher unhandlich. Sie sind oftmals schlechter zu lesen (der Zoom funktioniert nicht so gut wie bei echtem Text), sind ein Problem für Leute mit Vorlesesoftware und haben den großen Nachteil, dass der Code händisch abgetippt werden muss, wenn man Deinen Code ausprobieren (oder verbessern) möchte. Daher ist es eigentlich immer eine viel bessere Idee ein vollständiges, aber möglichst minimales Beispiel hier direkt als Code anzufügen. Der Vorteil davon ist es, dass der Code sogar hier direkt online kompiliert werden kann. Wenn es dann wichtig ist, wo ein Editor irgendwelche Icons anzeigt, kannst Du ja immer noch zusätzlich Bilder anfügen.
Die Icons, die bei Overleaf an der Seite erscheinen, haben zwei Ursprünge: Nach einem echten TeX-Lauf werden die roten Kreuze an den Zeilen platziert, in denen TeX einen Fehler meldet, die Ausrufezeichen an den Zeilen, an denen TeX eine Warnung meldet. (Das muss nicht immer der Ort des Fehlers sein, manchmal manifestieren sich Fehler erst in folgenden Zeilen.) Gleichzeitig hat Overleafs Editor aber noch eine Heuristik, die Deinen Code auf mögliche Fehler überprüft. Auch Meldungen dieser Heuristik werden mit roten Kreuzen an der Seite angezeigt. (Solche Meldungen bekam ich z.B. wenn ich einen Befehle wie \Phi, der den Mathemodus braucht, außerhalb des Mathemodus gesetzt habe.) Bei dem Meldungen der zweiten Kategorie ist es wichtig, im Auge zu behalten, dass Overleafs Heuristik nicht TeX ist und daher auch nicht genau wie TeX denkt. Es ist ein Leichtes die Heuristik zu verwirren. Ich würde mich daher ausschließlich auf die Fehlermeldungen in dem Icon neben dem "Recompile"-Knopf verlassen.
Bei den echten Fehlermeldungen von TeX hilft es zu wissen, dass bei "undefined control sequence"-Meldungen das nicht definierte Makro immer am Ende der oberen Zeile steht. Im ersten Bild ist also \exist undefiniert (und sollte wohl \exists sein, wie bereits besprochen).
Die anderen Fehler sind Probleme mit & und auch da steht in der Fehlermeldung das problematische Zeichen am Ende der oberen Zeile. Das Zeichen & hat für LaTeX eine spezielle Bedeutung: es wechselten in Tabellen und tabellenähnlichen Umgebungen (u.a. auch den Matheumgebungen align und align*) in die nächste Spalte. Wenn Du ein "&" ausgeben möchtest, muss es eigentlich immer \& sein (außer wenn Du mit Source-Code-Umgebungen wie verbatim oder mit speziell für URL gedachten Makros arbeitest).
----
An den Bildern fällt noch auf, dass da immer noch verdammt viele \\ sind. Wie bereits erwähnt, sollte man \\ normalerweise nur in Tabellen und tabellenähnlichen Umgebungen benutzen (analog zu &).
Für Aufgabenblätter gibt es spezielle Pakete (oben schon erwähnt), aber auch sonst gibt es wesentlich bessere Möglichkeiten, Theoreme etc. mit etwas Abstand vom restlichen Text zu setzen (amsthm).
Die vielen Aufrufe von \fbox und \boxed wirken auch etwas merkwürdig. Ich weiß nicht genau, was die machen sollen und ich habe es nicht ausprobiert (keine Lust den Code abzutippen), aber ich vermute, es gibt elegantere Wege dafür. Bei collen Boxen muss ich immer gleich an tcolorbox denken.
Auch die vielen \: sehen etwas ad hoc aus. Eventuell gibt es da wesentlich bessere Methoden, das gewünschte Ergebnis zu erreichen.
Über die Überschriften "Aufgabe 1" etc. würde ja oben schon diskutiert.
Bilder von Code und Fehlermeldungen sind im Allgemeinen eher unhandlich. Sie sind oftmals schlechter zu lesen (der Zoom funktioniert nicht so gut wie bei echtem Text), sind ein Problem für Leute mit Vorlesesoftware und haben den großen Nachteil, dass der Code händisch abgetippt werden muss, wenn man Deinen Code ausprobieren (oder verbessern) möchte. Daher ist es eigentlich immer eine viel bessere Idee ein vollständiges, aber möglichst minimales Beispiel hier direkt als Code anzufügen. Der Vorteil davon ist es, dass der Code sogar hier direkt online kompiliert werden kann. Wenn es dann wichtig ist, wo ein Editor irgendwelche Icons anzeigt, kannst Du ja immer noch zusätzlich Bilder anfügen.
Die Icons, die bei Overleaf an der Seite erscheinen, haben zwei Ursprünge: Nach einem echten TeX-Lauf werden die roten Kreuze an den Zeilen platziert, in denen TeX einen Fehler meldet, die Ausrufezeichen an den Zeilen, an denen TeX eine Warnung meldet. (Das muss nicht immer der Ort des Fehlers sein, manchmal manifestieren sich Fehler erst in folgenden Zeilen.) Gleichzeitig hat Overleafs Editor aber noch eine Heuristik, die Deinen Code auf mögliche Fehler überprüft. Auch Meldungen dieser Heuristik werden mit roten Kreuzen an der Seite angezeigt. (Solche Meldungen bekam ich z.B. wenn ich einen Befehle wie `\Phi`, der den Mathemodus braucht, außerhalb des Mathemodus gesetzt habe.) Bei dem Meldungen der zweiten Kategorie ist es wichtig, im Auge zu behalten, dass Overleafs Heuristik nicht TeX ist und daher auch nicht genau wie TeX denkt. Es ist ein Leichtes die Heuristik zu verwirren. Ich würde mich daher ausschließlich auf die Fehlermeldungen in dem Icon neben dem "Recompile"-Knopf verlassen.
Bei den echten Fehlermeldungen von TeX hilft es zu wissen, dass bei "undefined control sequence"-Meldungen das nicht definierte Makro immer am Ende der oberen Zeile steht. Im ersten Bild ist also `\exist` undefiniert (und sollte wohl `\exists` sein, wie bereits besprochen).
Die anderen Fehler sind Probleme mit `&` und auch da steht in der Fehlermeldung das problematische Zeichen am Ende der oberen Zeile. Das Zeichen `&` hat für LaTeX eine spezielle Bedeutung: es wechselten in Tabellen und tabellenähnlichen Umgebungen (u.a. auch den Matheumgebungen `align` und `align*`) in die nächste Spalte. Wenn Du ein "&" ausgeben möchtest, muss es eigentlich immer `\&` sein (außer wenn Du mit Source-Code-Umgebungen wie `verbatim` oder mit speziell für URL gedachten Makros arbeitest).
----
An den Bildern fällt noch auf, dass da immer noch verdammt viele `\\` sind. Wie bereits erwähnt, sollte man `\\` normalerweise nur in Tabellen und tabellenähnlichen Umgebungen benutzen (analog zu `&`).
Für Aufgabenblätter gibt es spezielle Pakete (oben schon erwähnt), aber auch sonst gibt es wesentlich bessere Möglichkeiten, Theoreme etc. mit etwas Abstand vom restlichen Text zu setzen (`amsthm`).
Die vielen Aufrufe von `\fbox` und `\boxed` wirken auch etwas merkwürdig. Ich weiß nicht genau, was die machen sollen und ich habe es nicht ausprobiert (keine Lust den Code abzutippen), aber ich vermute, es gibt elegantere Wege dafür. Bei collen Boxen muss ich immer gleich an `tcolorbox` denken.
Auch die vielen `\:` sehen etwas ad hoc aus. Eventuell gibt es da wesentlich bessere Methoden, das gewünschte Ergebnis zu erreichen.
Über die Überschriften "Aufgabe 1" etc. würde ja oben schon diskutiert.