Sie sind hier

Sollen neue Möglichkeiten, die im Widerspruch zu alten stehen, in der Voreinstellung ein- oder ausgeschaltet sein?

neue Möglichkeiten per Option (kompatible Voreinstellung)
40% (19 Stimmen)
altes Verhalten per Option (inkompatibles Voreinstellung)
60% (28 Stimmen)
Gesamte Stimmenzahl: 47

Kommentare

Entschuldigung,

aber in dieser Abstraktion ist das doch kaum zu entscheiden. Könnte man nicht wenigsten zwei Beispiele nennen, an welche Features gedacht ist?

Beispiel: Die Kopfzeile soll von jetzt an immer farbig sein. Da wäre ich sehr stark dafür, dass ich derartiges bewußt anschalten muss.

Gruß,
Alexander

Es geht hier nicht um konkrete Beispiele neuer Features, sondern um eine generelle Frage. Wobei es ausdrücklich nicht um Bugs, sondern um neue Möglichkeiten geht, die in Widerspruch zu alten stehen. Eins kann als sicher angenommen werden. Ich werde die Entscheidung nicht bei jedem Feature neu treffen, denn wer soll noch den Überblick behalten, wenn mal so mal so entschieden wird.

Letztlich ist die Frage: Ist es eher zuzumuten, dass man in fünf Jahren herausfinden muss, dass ein altes Dokument ggf. mit geänderten Optionen zu setzen ist oder dass man bei neuen Dokumenten einen Rattenschwanz an Optionen angibt, um KOMA-Script ausreizen zu können. Wobei das schon wieder eine andere Designentscheidung beinhaltet, die gar nicht zur Abstimmung stellen wollte. es kann genauso gut sein, dass es nur um eine einzige Option geht, die alles entscheidet.

Zugunsten neuer Möglichkeiten favorisiere ich die Verwendung aktueller Optionen für neue Dokumente. Für ältere reicht mir - analog der Verwendung von KOMAold.lco - eine Kompatibilitätseinstellung in der Form "\setkomamode=2.9".

Für den (hoffentlich anzunehmenden) Fall einer kontinuierlichen Weiterentwicklung von KOMA-Script wird der angesprochene "Rattenschwanz an Optionen" ansonsten zum Beginn einer unendlichen Optionskette, die irgendwann doch aufgebrochen werden muss oder nicht mehr händelbar ist.

Bild von mada

Mir wäre es lieber, wenn alte Dokumente sich auch zukünftig ohne Anpassungen problemfrei kompilieren lassen.

Auch sehe ich nicht, wie sich eine "unendliche Optionskette" entwickeln soll. Derartig viele Mankos sehe ich im KOMA-Paket nicht -- wenn ich ehrlich sein soll vermisse ich nur einen Schalter nexthead==firsthead für scrlttr2 ;)

Dem Vorschlag einer Kompatibilitätseinstellung schließe ich mich an. Jeder der KOMA-Script nutzen will, sollte nicht erst etwas aktivieren müssen um UpToDate zu sein. Auf der anderen Seite ist der Wunsch nach einem Code verständlich, der in 10 Jahren noch das gleiche Ergebnis liefert. Wer soll den Überblick darüber behalten, was bis dahin alles geändert wurde. Diesen Wünschen könnte man nachkommen indem man als optionale Angabe im Dokument die KOMA-Version angiebt. Wird sie nicht gegeben, so gilt die aktuelle Einstellung.

Ab Version 3.01a wird die Voreinstellung von KOMA-Script auf version=last geändert. Dafür wird bei Verwendung einer der alten Optionen von KOMA-Script 2, die seit KOMA-Script 3 als obsolet deklariert sind, automatisch auf version=first umgeschaltet und eine entsprechende Warnung ausgegeben, die auch erklärt, wie man diese automatische Umschaltung verhindern kann.

Bewogen hat mich dazu, dass viele Anwender einfach dadurch von Verbesserungen in KOMA-Script ausgeschlossen waren, dass sie in der Anleitung nie bis zur Beschreibung der Option version vorgedrungen sind. Die Aufklärung dazu ist weit schwieriger als bei Beschwerden zu Umbruchänderungen darauf hinzuweisen, dass Option version mit passendem Wert (im Zweifelsfall first) als letztes bei \documentclass angegeben werden sollte.

Comments for "Sollen neue Möglichkeiten, die im Widerspruch zu alten stehen, in der Voreinstellung ein- oder ausgeschaltet sein?" abonnieren