[Trennmuster] neuer Arbeitsansatz

[Werner LEMBERG]

>> Nun ja, wir leben im Jahr 2016, und vielen Menschen ist die
>> reformierte Rechtschreibung bereits in Fleisch und Blut
>> übergegangen – oder sind nur mit ihr aufgewachsen.  Aus diesem
>> Grund kann meiner Meinung die traditionelle Variante nicht als
>> Grundlage genommen werden.
>
> Eben.  Es bleibt also nur die "fragile", komplexe Wandlung
> de-1996->de-1901, welche erst nach ausgiebigem Testen als
> zuverlässig arbeitend angenommen werden kann.

Das ist eigentlich nicht mehr fragil, denn...

> Ich sehe natürlich auch die Vorteile eines vereinfachten
> Datenformats.  Wenn nach einer Testphase klar ist, dass die
> "original wortliste" aus der "Reformliste"+Ausnahmenliste
> zuverlässig fehlerfrei rekonstruiert werden kann begrüße ich dem
> Umstieg auf die Reformliste als Quelldatei.

... das wird bereits »zuverlässig fehlerfrei« rekonstruiert!  Ich hab
das Projekt erst vorgestellt, als dieser Schritt absolviert war.

> Anders sehe ich es mit der Aufteilung:
>
> +1 git blame geht schneller
>
>    z.Zt. liefert `git blame -L "2300,+1" wortliste`
>    auf meinem etwas älterem Rechner bei gleichzeitigem patgen-Lauf nach ca.
>    1 min
>    bc77ba4b (Guenter Milde 2014-03-07 09:47:54 +0100 2300)
>      Abfallentsorgungsgesellschaft;Ab<fall=ent<sor-gungs=ge<sell>schaft

Genau!  Eine Minute ist eine Ewigkeit!  Normalerweise kommen Resultate
innerhalb einer Sekunde.

> -1 alle Editieraufgaben werden umständlicher (brauchen mehr Nachdenken,
>    mehr Zeit, Spezialtools, ...)
>
>    Das ist insbesondere bei kleineren Korrekturen die jetzt im
>    Texteditor mit den Standardwerkzeugen (Suche, regexp-Replace)
>    gehen ein deutlicher Nachteil.

Wirklich?  Ich arbeite jetzt hauptsächlich mit meiner neuen
Aufteilung, und ich konnte bis jetzt keinen gravierenden Unterschied
entdecken.  Mein neues »wlgrep«-Skript funktioniert sogar besser als
erwartet :-)

Ich denke vielleicht eher wie ein Programmierer, der darauf Wert legt,
die Strukturen in einem Programm so klein wie möglich zu halten, damit
die Arbeit übersichtlich bleibt.

> Die Frage ist, was wird öfter gebraucht?

Ich würde »git blame« schon gerne öfters einsetzen, habe aber wegen
der mangelnden Geschwindigkeit (und des unglaublichen Speicherbedarfs)
darauf verzichten müssen...

> Und, wie langsam wäre `blame`, wenn wir das schon mal angedachte
> "aspell format" für die Ableitungen verwenden?  Bei de_DE.dic gibt
> es damit eine Reduktion von 350 000 auf 75 000 Einträge, also auf
> 20%.

Prinzipiell bin ich einer weiteren Reduktion von Eingabedaten nicht
abgeneigt, ganz im Gegenteil!  Aber wiederum stellt sich die Frage,
wie zuverlässig die Generierung der Ableitungen ist.  Was geschieht
mit Wörtern, wo es keine Mehrzahl gibt, oder wo es mehr als eine
Mehrzahlform gibt, etc., etc.  Das bedarf einer ausgiebigen Prüfung.
Hast Du damit schon einmal gearbeitet?  Würde sich die Anzahl der
Ausnahmen erhöhen, oder wird das anders gelöst?

>> > Ich müsste wahrscheinlich die git Aufrufe "wrappen" um bei mir
>> > eine Datei stehen zu haben. Alles in allem auf jeden Fall
>> > komplizierter als einfach
>> >
>> >    xjed wortliste
>
>> Wie wär's mit einem Shell-Skript »xjedwl« folgenden Inhalts
>> (ungetestet).
> ...
>
> Immer noch deutlich komplizierter, ich müßte bei jedem Aufruf vorher
> dran denken, ob ich evt. auch die Wortliste bearbeiten will.

Wieso?  Das von mir vorgeschlagene Shell-Skript kümmert sich genau
darum, indem es nichts tut, wenn's keine Veränderung gibt.

> Ein automatischer Abgleich der vollständigen Liste beim Laden und
> der Einzellisten beim Speichern wäre eine mögliche Lösung.  Immer
> noch komplizierter aber evt. nicht mehr so sehr
> "arbeitsverhindernd".

Ich kenne Deinen Arbeitsfluß nicht, daher sehe ich nicht genau das
Problem, das Du hast.

> Ich mags nicht aber könnte damit leben.

OK, danke.  Lassen wir noch ein bißchen Zeit verstreichen, und
vielleicht könntest Du ja einmal probehalber mit dem
»wortlisten«-Zweig arbeiten.

> Könnte wenigstens die Ausnahmeliste zusammenhängend bleiben?

Das ist kein Problem; ich hab's gerade im Repositorium geändert.


    Werner