Außerirdische Magie aus der Zukunft: „Cursorless“
(xeiaso.net)- Durch das Wiederauftreten von RSI musste die Art der Code-Eingabe erneut geändert werden, und die VS-Code-Erweiterung Cursorless wurde zum zentralen Werkzeug für sprachbasiertes Code-Editing
- Cursorless versieht Code-Tokens mit farb- und buchstabenbasierten hat-Markierungen, sodass Nutzer Positionen auf dem Bildschirm per Sprache benennen und Aktionen wie Löschen, Verschieben und Einfügen ausführen können
- Leistungsstärker als eine bloße Cursorbewegung ist die Kombination aus Pfadangaben wie
green urge past green batund Sprach-AST-Erkennung, mit der sich Struktureinheiten wie Funktionen, Lambdas und Definitionskörper bearbeiten lassen - Wer Talon-Befehle direkt schreibt, kann Einfügungen wie
async <destination>oder lange Eingaben wie Go-Methodendeklarationen zu kürzeren Sprachbefehlen automatisieren - Sprachbasiertes Coden beseitigt die zu sprechenden Wörter nicht, kann aber ein Befehlssystem schaffen, das der Art näherkommt, wie man Code im Kopf versteht
Kontext: Wiederauftretendes RSI und der Einsatz von Cursorless
- Zum Start in einen neuen Job trat RSI erneut auf, und statt sich wie zuvor auf technisches Schreiben zu stützen, wurde wieder eine Möglichkeit gebraucht, tatsächlich zu programmieren
- Obwohl eigentlich Emacs genutzt wird, kommt diesmal wegen einer bestimmten Erweiterung Visual Studio Code zum Einsatz
- Diese Erweiterung ist Cursorless, das in Verbindung mit Sprachsteuerungssoftware Code-Editing auf AST-Ebene ermöglicht
- Zuvor wurde Cursorless hauptsächlich nur für die Navigation auf dem Bildschirm verwendet, diesmal soll es tiefer auf möglichst viele Arbeitsabläufe angewendet werden
- Es gibt den Wunsch, eine solche Eingabemethode auch für Nachrichten in Slack und Discord zu haben
Mit hat, target und destination Positionen per Sprache benennen
- Die Grundeinheiten von Cursorless sind target und destination
- target bezeichnet einen einzelnen Anker im Dokument
- destination meint eine relative Position bezogen auf ein bestimmtes target
- Die Tokens im Dokument erhalten einen hat, der aus Farbe und Buchstaben besteht
- Die Position des hat bestimmt seinen Namen
- Die Farbe des hat löst Mehrdeutigkeiten auf
- Befindet sich im JavaScript-Beispiel ein grüner hat über dem
uim Wortfunction, kann dieses Wort alsgreen urgebezeichnet werden - Für dieses target lassen sich dann Befehle erteilen, um das Wort zu löschen oder an eine andere Position zu verschieben
- Schon allein damit sind per Sprache Operationen möglich, die Vim-Motions nahekommen
Strukturelles Editing durch AST-Erkennung
- Die Stärke von Cursorless liegt darin, nicht bei bloßer Positionsangabe stehenzubleiben, sondern Pfade (path) und Sprach-AST-Erkennung gemeinsam zu nutzen
- Mit Ausdrücken wie
green urge past green batlässt sich der Bereichfunction fetchBlogauf dem Bildschirm auswählen - Weil die AST-Struktur der Sprache verstanden wird, können auch ganze Funktionen gelöscht oder an andere Stellen verschoben werden
- Der Befehl
visualize lambdasvisualisiert die Lambdas innerhalb einer Funktion als eigene Struktureinheiten - Da auch AST-Einheiten zu targets werden, lässt sich etwa der Body einer Definition auswählen und das Refactoring in diesem Bereich fortsetzen
- Im Beispiel wird so das Refactoring zu einer asynchronen Funktion vereinfacht
Sprachbasiertes Coden mit Talon erweitern
- Mit Talon zusammen lässt sich Cursorless durch selbst geschriebene Sprachbefehle erweitern
- Das Beispiel
async <user.cursorless_destination>ist ein Befehl, der"async"vor der angegebenen destination einfügt
[state] async <user.cursorless_destination>:
user.cursorless_insert(cursorless_destination, "async")
- Talon-Befehle bestehen im Wesentlichen aus zwei Teilen
- pattern: die Wörter, die der Nutzer spricht
- capture: das Ziel, das aus dem Gesagten extrahiert wird
- In diesem Beispiel ist pattern
async, und capture ist das Ziel, an demasynceingefügt werden soll - Das Capture
<user.cursorless_destination>ist ein spezielles Capture, mit dem sich vor oder hinter einem beliebigen target eine Position angeben lässt - Auch komplexere Befehle sind möglich; als Beispiel dient eine Talon-Regel zum Erstellen einer Go-Methodendeklaration
(method|meth) <user.letter> [<user.go_pointer>] [<user.go_visibility>] <user.text> [over] [<user.go_visibility>] named <user.text> [over]:
user.go_method(go_pointer or "", letter, go_visibility_1 or "public", text_1, go_visibility_2 or "public", text_2)
Experimente mit Go-Methodendeklarationen und der Darstellung von Pointern
- In Go haben Methoden die folgende Form
func (reciever *Type) MethodName() {
// function body here or something
}
- Dazu wird erklärt, dass Go keine Methoden im traditionellen Sinn hat, sondern Funktionen mit einem receiver, der in einem bestimmten Namespace einer struct zugeordnet ist
- Ohne Automatisierung müsste man für die sprachbasierte Eingabe dieses Codes einen langen Befehl sprechen
state funk args word reciever space star hammer type over go right space hammer method name args go right brack enter
- Mit der Talon-Regel lässt sich das deutlich kürzer sagen
meth r raised type named method name over
- Es müssen zwar weiterhin viele Wörter gesprochen werden, doch die Eingabe wird effizienter und kommt der gedanklichen Konzeptualisierung näher
raisedist ein Experiment, um das Go-Pointer-Konzept anders auszudrücken- Die Pointer-Syntax in Go folgt dem C-Stil; dabei wird
*als Operator interpretiert, der einen Pointer-Wert zu einem normalen Wert herunterstuft (lower), und&als Operator, der einen normalen Wert zu einem Pointer-Wert heraufstuft (raise) - Beim Neuentwurf der Talon-Bindings für Go wird experimentiert, Pointer-Werte über die Konzepte raising/lowering zusammenzufassen, um zu prüfen, ob das leichter verständlich ist
- Die Pointer-Syntax in Go folgt dem C-Stil; dabei wird
- Es besteht Interesse daran, an der GitHub Copilot Voice beta teilzunehmen, um sie mit Talon-basiertem Sprach-Coding zu vergleichen
1 Kommentare
Meinungen auf Hacker News
Ich bin der Autor und hätte nicht erwartet, dass die Reaktion hier so positiv ausfällt.
Falls es euch interessiert: Mein experimentelles Talon-Konfigurations-Repository habe ich hier abgelegt: https://github.com/Xe/invocations
Ich glaube, irgendwann wird es Tage geben, an denen diese Arbeitsweise gegenüber der Tastatur nicht unbedingt notwendig, aber deutlich weniger schmerzhaft ist, und ich bin froh zu wissen, dass es eine praktikable Option gibt.
Jedes Mal, wenn ich so eine Konfiguration sehe, merke ich, dass meine Neurodiversität sich ziemlich von der anderer Menschen unterscheidet. Der Kontext und die Abstraktionen, die man im Kopf behalten muss, um den Bildschirm zu verstehen und sich darin zu bewegen, sind enorm, und es wirkt, als sei das nur möglich, wenn man über Jahrzehnte mit Sprache und IDE/CLI vertraut geworden ist.
Auch der Teil „mit der Zeit wird es wie Vim-Befehle zur zweiten Natur“ scheint etwas zu sein, das man wirklich so verinnerlichen muss. Ich arbeite seit 30 Jahren mit Computern, aber dieses Maß an Coding-Routine ist für mich immer noch verwirrend und zugleich beeindruckend.
Mich würde interessieren, ob sie nicht so gut war oder ob die VS-Code-Lösung einfach deutlich besser wirkte.
An Cursorless selbst bin ich nicht besonders interessiert, weil ich VSCode nicht nutze und die Textobjekte im Vim/Evil-Modus genauso mächtig und visuell weniger laut sind. Das ganze Konzept finde ich sehr vielversprechend.
Das sieht nach einer Methode aus, mit einer tree-sitter-AST Operationen auf „Teilen“ des Buffers auszuführen.
Wenn ja, ist es den Textobjekten von Vim/Evil sehr ähnlich, nur mit einer Sprachkomponente.
Mit Funktionen wie „aufzeichnen und später ausführen“ hätte das großes Potenzial. Während man X mit der Tastatur erledigt, sieht man als Nächstes Y auf dem Bildschirm, und wenn es eine einfache Aufgabe ist, könnte man den Y-Befehl schon aussprechen und nach Abschluss von X per Knopfdruck den Sprachbefehl ausführen. Das wäre deutlich besser, als ständig zwischen Tippen und Sprechen zu wechseln.
Tippen und Sprechen nutzen unterschiedliche kognitive Bereiche, und Software zu schreiben, nachdem man die Grammatik verstanden hat, ist gar nicht so sprachlich. Wenn man gleichzeitig tippen und sprechen kann, käme man vermutlich leichter in den Flow; das wirkt wie eine Art verstärktes Rubber-Duck-Debugging. Notizen wären auch möglich.
Ich könnte mir vorstellen, dass ein Emacs-Paket erscheint.
Aber es dürfte dauern, bis es in diesem Bereich aufholt. Die Rendering-Engine kann Cursorless-artige Markierungen nicht verarbeiten, und die tree-sitter-Integration ist noch nicht ausgereift. Ich habe es selbst ausprobiert.
Trotzdem wäre eine native Version für Emacs schön.
Es geht zwar nicht direkt um Cursorless, aber hier gibt es einen hervorragenden Vortrag samt Demo zu Sprachprogrammierung: https://youtu.be/GM_siEPD4Ws?si=99ZhC1P4irOyu1pH
Macht Spaß anzusehen, und der Vortragende behandelt auch die aktuellen gemeinsamen Probleme dieses Bereichs gut.
Ich versuche noch, die Funktionsweise vollständig zu verstehen.
Es klingt ähnlich wie avy mit Sprache statt Tastatur, plus AST-bewussten Befehlen: https://karthinks.com/software/avy-can-do-anything/
Danach wollte ich die Overlays dauerhaft sichtbar machen, bin aber irgendwo steckengeblieben.
Strange-Loop-Vortrag des Cursorless-Autors: https://www.youtube.com/watch?v=NcUJnmBqHTY
Ich frage mich, warum „urge“ und „bat“ verwendet werden.
Könnte man nicht einfach beliebige Wörter nehmen, die mit den jeweiligen Buchstaben beginnen?
Mehr dazu hier: https://whalequench.club/blog/2019/09/03/learning-to-speak-c...
Wenn man früher 6–8 Stunden am Tag per Sprache codiert hat, weiß man jede einzelne dieser Mikro-Optimierungen zu schätzen.
Würde es mit heutiger Eye-Tracking-Technik nicht reichen, den Cursor an die Stelle zu setzen, auf die man länger als 2 Sekunden schaut?
Ich denke da an Studien dazu, wo der Blick beim Autofahren oder beim Betrachten von Kunstwerken verweilt.
Beim Coden hält man auf diese Weise sehr oft inne.
Nötig wäre ein extrem reaktionsschnelles und präzises Eye-Tracking-Gerät, das mindestens 3–5 Buttons erkennen kann: Klicken, Drücken, Loslassen, nach rechts bewegen, nach links bewegen.
Dieser Schreibstil erinnert mich stark an die Dialoge zwischen der Schildkröte und Achilles in Gödel, Escher, Bach.
Ich bin 52 und tippe seit 1995 täglich in technischen Berufen. Um 2000 herum hatte ich Repetitive Strain Injury, und ich habe ergonomische Hilfsmittel ausprobiert, etwa weiche Polster, auf die man die Handgelenke vor der Tastatur legt, oder ausziehbare Vorrichtungen zum Ablegen der Ellbogen, aber nichts davon hat geholfen.
Stattdessen habe ich meine Art zu tippen geändert. Ich ließ Hände und Handgelenke entspannt und bewegte die Arme, statt die Finger auszustrecken, um Tasten zu drücken — das hat funktioniert.
Ich tippe auch heute noch jeden Tag viel, bin aber seit 20 Jahren schmerzfrei. Das ist von Person zu Person verschieden, aber es kann sehr helfen, die Art zu ändern, wie man Arme und Hände benutzt.
Wenn man Bewegung auf größere Muskelgruppen verlagern kann, ist das meistens besser: Schulter/Rücken statt Arme, Arme statt Hände, Hände statt Finger.
Das ist je nach Person unterschiedlich, aber ein Trackball hat mir sehr geholfen. Eine Zeit lang hatte ich links eine Maus und rechts einen Trackball und habe abwechselnd beide benutzt, aber inzwischen ist das nicht mehr nötig.
Pausen zu machen und auf die Haltung zu achten ist ebenfalls wichtig. Besonders wichtig ist die Haltung der Handgelenke: Ich stütze Handgelenke oder Arme nirgends ab und lasse nur die Finger die Tastatur berühren.
Viel später habe ich mit Krafttraining mit Kettlebells angefangen und gemerkt, dass Kraft und Durchblutung sich ziemlich verbessert haben.
Vor etwa 10 Jahren hatte ich Probleme mit Rückenschmerzen, Nackenschmerzen und Repetitive Strain Injury. Ich habe gelernt, mit geradem Rücken zu sitzen, die Schreibtischhöhe angepasst und die Dinge auf dem Schreibtisch so umgestellt, dass ich nicht mehr wie eine Garnele gekrümmt tippe. Außerdem wurde mir klar, dass ich tatsächlich gar nicht so viel tippen muss.
Seitdem habe ich überhaupt keine Schmerzen mehr.
Wenn man einen allgemeinen Überblick über Cursorless und seinen Einsatz in der Praxis sehen möchte, war der diesjährige Strange-Loop-Vortrag gut: https://youtube.com/watch?v=NcUJnmBqHTY
Ich mag es sehr und freue mich, dass die Entwicklung weitergeht, aber um wirklich tief einzusteigen, müsste man sich wohl die Arme oder Hände verletzen oder eine schwere Repetitive Strain Injury haben.
Die mentale Einstiegshürde wirkt hoch.
Die größte Einschränkung scheint mir allerdings zu sein, dass man das praktisch nur allein im Homeoffice verwenden kann. Ich kann mir schwer vorstellen, es draußen oder im Büro zu benutzen.
Wenn ich meine Hände nicht mehr benutzen könnte, würde ich es wohl verwenden.