Dennis Heidsiek schrieb:
Pascal Hauck ſchrieb am 29.07.2009 10:25 Uhr:
Ebenso ist es nicht das Ziel von Neo, möglichst viele oder gar alle
Zeichen des Unicodes umzusetzen!
Also unter dem NeoVars ist das grundsätzlich schon jetzt nach dem
Strickmuster ſ=♫uu17f möglich … wenn da von Linux-Seite aus Interesse
bestehen sollte, könnte man durchaus ein entsprechendes Modul
generieren. Okay, den letzten Satz bitte aus dem Gedächtnis streichen,
da ich mich nicht streiten will ;-).
Also, ich wäre an einer unicode.module durchaus interessiert. :) Wenn
schon klingonische und römische Zahlen im Repo sind, dann kommen auch
problemlos Unicode-Codepoints durch.
Die vorgenommene Modularisierung soll dazu beitragen, eine sinnvolle
Ordnung der vielen aufgenommenen Zeichen zu schaffen. Entsprechend
müssen die Zeichen nach ihrer Funktion geordnet werden. […]
Afrikanische, asiatische Sprachen oder IPA-Zeichen sind in der
base.module eindeutig falsch aufgehoben.
Wunderschön formuliert.
Eine sinnvolle Auswahl kann aber nicht darin bestehen, ständig mehr
Module anzubieten – das ist auch nicht der Sinn der Modularisierung.
Hm, ich glaube da bin ich tatsächlich anderer Meinung. Ich halte es da
eher mit der Wikipedia: […] Von daher bin ich neuen Modulen gegenüber grundsätzlich aufgeschlossen.
Das heißt aber nicht, das sie auch in die Standarddistribution gehören.
Um in Ubuntu-Terminologie zu sprechen: Man muss zwischen Main und
Universe unterscheiden.
Neue Module, wenn sie neue Themen behandeln, sind sicherlich
begrüßenswert. Nicht jedoch die Aufsplittung der vorhandenen 2+3+(2) Pakete.
Darum schlage ich etwas anderes vor: problematische oder sehr
strittige Definitionen wie die hier behandelten landen in einer
separaten Datei weite_Definitionen.txt (also bewusst kein .module),
aus der sich Anwender Definitionen in eine eigene user.module kopieren
können, die durch das Makefile automatisch (und korrekt) ans Ende
gesetzt wird.
Ne, also das finde ich nicht gut. Der Vorteil des jetzigen Systems ist
ja gerade, dass man nicht Copy&Paste machen muss, sondern bequem aus den
benötigten Paketen auswählen kann (und konfliktierende oder überladene
(Dennis: ;)) hinzunehmen oder weglassen kann).
Mit dieser Lösung kann ich grundsätzlich leben, wobei ich die andere
Dateiendung allerdings etwas albern finde. Ich hätte die Datei eher
»Uncommon.module« genannt. Schließlich sind die neuen Build-Skripte doch
extra darauf ausgelegt, dass sich der Nutzer seine eigene Compose
zusammenpusseln kann. Aber wenn Dir das so wichtig ist, will ich mich
deswegen nicht streiten. <humor meta="Nicht ernst gemeint!">Von mir aus
können wir die Datei auch
Weite_Definitionen.Werden_diese_eingebunden_bricht_das_Abendland_zusammen_Flüsse_aus_Blut_werden_durchs_Land_fließen_und_Nazis_werden_wieder_auf_Dinosauriern_durch_die_Gegend_reiten.
nennen</humor>.
Ohne Dennis auf die Füße treten zu wollen, ist die Ligatur ſs (
stellen die meisten Schriftarten nicht dar) nicht von allgemeinem
Interesse; darum ist sie in einer user.module besser aufgehoben.
Keine Angst, ich fühle mich nicht auf die Füße getreten, denn genau das
habe ich ja auch gesagt. Ich war nur strikt dagegen, dass diese Coko
komplett aus dem Repository verbannt/gelöscht wird, und das auch noch
ohne Diskussion.
Moment mal, du nutzt doch momentan Windows, da kannst du zur Not Cokos
in deiner Konfigurationsdatei einstellen. Wenn du GNU/Linux benutzt,
kannst du die Ligaturen in eine user.module (wie auch immer benannt)
schreiben. Ich frag mich auch, wofür du die allen Ernstes benutzt (würde
mich ehrlich interessieren). Und wie bereits gesagt, im VCS verschwindet
nichts.
Gruß,
Martin
