Hallo Chris,
danke für deine spontanen Gedanken. daraus habe ich gleich wieder Ideen und
weitere Umsetzungspunkte entwickelt.
Am 28.08.2025 21:15, schrieb Chris K via Diskussion:
Hallo qwertfisch,
vorweg: ich brauche so ein Tool (aktuell) nicht, aber finde das Projekt an
sich schön, und an Motivation scheint es dir ja nicht nicht zu mangeln.
Hm, das würde ich mit einem klaren Jein beantworten. ;) Ich würde dieses
Projekt sehr gerne umsetzen und erweitern. Auf der anderen Seite hatte ich
schon vor zwei Jahren diesen Blocker mit den Fragen, wie eine gute DSL
ausschaut und wie man sie parst, ohne dass das aufwendiger wird als das
eigentliche Keyboard-Mapping. Aber vielleicht ist das am Ende so … auch die
anderen Projekte sparen sich die Arbeit, indem sie sie dem Lisp-Interpreter,
dem C-Präprozessor oder einer JSON-Bibliothek überlassen. Ich bin aber der
Ansicht, das tauscht einmaligen Implementierungsaufwand gegen dauerhafte
Umständlichkeit in der Sprache aus.
Wenn dir das Parsen einer eigenen DSL Spaß macht -- ok, verstehe ich :-)
Vielleicht? Es kann ja nicht so schwierig sein!
Aber dein Beispiel -- und viele andere, die man in Keyboard Layout
Konversationen und Tools auf und ab sieht -- legen nahe, dass etwas
einfaches Tabellarisches ausreichen sollte. Dein Beispiel ist
"space-separated data"; noch häufiger ist comma-separated. Ich persönlich
bin großer Fan von tab-separated. Das ist zufällig auch sehr passend für
Tastaturbelegungen, wo man Leerzeichen und Komma vielleicht gern als
"Label" benutzen möchte.
Tabellarisch ist schonmal ein guter Punkt. Tab-separated wäre eine
Möglichkeit, auch wenn ich überzeugt bin, dass man es widerspruchsfrei auch
mit Leerzeichen hinbekommt. Aber mal sehen. Tab und Enter als Begrenzer für
Spalten und Zeilen sind ja auf jeder Tastatur vorhanden. Nur sieht man Tab
nicht so direkt, und das könnte zu Schwierigkeiten führen (wie Python, das
mag Mischungen von Tab und Space auch so gar nicht).
Einzelne Ebenen könnten vielleicht in jeweils eine eigene .tsv Datei (u.U.
zusammen-gezippt). Das erleichtert teilweise Wiederverwendung (man denke an
die Ebenen 3 und 4 aus der Neo Familie).
Hm, das wird hoffentlich nicht nötig sein. Eine Abschnittskennzeichnung wie
bei .ini-Dateien mit [] erscheint mir doch etwas hilfreicher. Wer dann
Ebenen wiederverwenden möchte in seinen eigenen Layouts, kann diese ja
kopieren. Oder man kann diese Abschnitte in mehreren definierten Layouts
referenzieren.
Ah guter Punkt, ich brauche noch eine Möglichkeit, zwischen mehreren Layouts
zu wechseln und mehrere Definitionen in einer Datei vorzuhalten.
qwertfisch
_______________________________________________
Diskussion mailing list -- [email protected]
To unsubscribe send an email to [email protected]
