4 Punkte von GN⁺ 2024-09-18 | 1 Kommentare | Auf WhatsApp teilen
  • Void war ein VS-Code-Fork, der die Nutzung von AI-Agenten in der Codebasis ermöglichte, Änderungen als Checkpoints visualisierte und das Einbinden lokaler Modelle oder Hosts erlaubte, befindet sich inzwischen jedoch im Status deprecated und nimmt keine Beiträge mehr an
  • Das Projekt bleibt weiterhin Open Source, und Entwickler, die VS Code forken möchten, können sich an Logik und Struktur von Void orientieren
  • Die README nennt als Referenzpunkte die Integration von React + Tailwind, GitHub Actions für Paketierung, Signierung und automatische Updates, selbst implementierten AI-Provider-Code sowie eine Struktur für IPC- und CSP-Unterstützung
  • Void gibt an, Nachrichten direkt an den Provider zu senden und keine Daten zu speichern, und unterstützt Antwortsyntax wie Autocomplete (FIM), <thinking>-Tags und Tool-Tags
  • Statt eine neue Version zu entwickeln, unterstützt das Projekt Forks und Wiederverwendung über Materialien wie Void Forks, frühere Releases, den Codebase Guide, HOW_TO_CONTRIBUTE und void-builder

Projektstatus

  • Void ist deprecated und nimmt keine weiteren Beiträge mehr an
  • Das Team bedankt sich für Code-Beiträge und Unterstützung aus der Community, und Void bleibt weiterhin Open Source
  • Es wird erklärt, dass das Projekt als gute Referenz für Entwickler bestehen bleibt, die VS Code forken möchten

Downloads und Materialien für Forks

Referenzpunkte für die Umsetzung eines VS-Code-Forks

  • Void bindet React + Tailwind ein
    • In normalem VS Code ist das nicht möglich, daher wurde die Build-Pipeline erweitert, um React-Kompilierung und Tailwind-Scoping zu unterstützen
    • Für das Tailwind-Scoping wird scope verwendet
  • Durch Kopieren der GitHub Actions lässt sich Void paketieren, signieren und automatisch aktualisieren
    • Es wird erklärt, dass dies normalerweise sehr schwierig ist, weil die Build-Pipeline von VS Code nicht öffentlich ist
  • Der AI-Provider-Code wurde von Grund auf selbst implementiert
    • Er unterstützt Autocomplete (FIM) und benutzerdefinierte Antworten
    • Er stellt Syntax für gemeinsame <thinking>-Tags, Tool-Tags usw. bereit
    • Die Architektur für den Einsatz von IPC und zur Erfüllung von CSP-Anforderungen kann als Referenz dienen
  • Für die Dateibearbeitung werden benutzerdefinierte Services verwendet
    • EditCodeService kann Diffs sogar auf Token-Ebene anzeigen, während Code gestreamt wird
    • VoidModelService bearbeitet Dateien im Hintergrund und synchronisiert OS-Dateien mit dem Textpuffer
  • Eine vollständige Liste der zu Void gehörenden Repositories ist unter repos verfügbar

Funktionsbeschreibung von Void

  • Void ermöglicht die Nutzung von AI agents in der Codebasis
  • Änderungen können als Checkpoints gespeichert und visualisiert werden
  • Beliebige Modelle oder Hosts können lokal eingebunden werden
  • Es wird angegeben, dass Nachrichten direkt an den Provider gesendet werden und keine Nutzerdaten gespeichert werden
  • Dieses Repository enthält den vollständigen Quellcode der Void-Desktop-App

Referenzlinks und Unterstützung

1 Kommentare

 
GN⁺ 2024-09-18
Meinungen auf Hacker News
  • Ich habe kürzlich versucht, VSCode als Plattform zu nutzen, um eine App zu refaktorisieren, und bin dabei wegen UI-Designentscheidungen, die weder leicht zu umgehen noch leicht zu warten waren, ziemlich auf die Nase gefallen.
    Auch Microsofts nicht öffentlicher Extension-Marketplace war für Open-Source-Ziele nicht hilfreich.
    Stattdessen habe ich auf HN Theia (https://theia-ide.org) kennengelernt, und wegen der Trägerschaft durch eine Stiftung, des Open-Source-Marketplace und der Möglichkeit, alles anzupassen, wirkte es deutlich besser passend zu Open-Source-Zielen.
    Theoretisch ist es auch mit der VSCode Extension API kompatibel, daher würde ich empfehlen, für diese App auch Theia zu prüfen.

    • Zur Info: Extensions können auf OpenVSX veröffentlicht werden.
      Viele Projekte machen das inzwischen so, nicht alle, aber doch ziemlich viele.
    • Ich frage mich, ob Theia etwas mit der bestehenden Java-IDE Eclipse zu tun hat.
      Oder ob die Erwähnung von „eclipse“ einfach nur eine unglückliche Namenskollision ist.
    • Wenn Theia auf Monaco gebaut ist, frage ich mich, ob auch so etwas wie ein Wechsel per Ein-Klick möglich wäre.
      Der Monaco-Editor ist theoretisch Teil des vscode-Repositorys, und die „Workbench“ mit Einstellungen/Konfiguration liegt als Schicht darüber.
  • Es wäre gut, wenn es einen gut aufbereiteten Text dazu gäbe, warum Tools wie Cursor und Void sich dafür entschieden haben, statt bestehender Editor-Erweiterungen (VSCode-Extensions, JetBrains-Plugins) neue Editoren zu bauen.
    Ich frage mich, ob das an technischen Grenzen der Extension API liegt oder daran, dass sich ein neuer Editor leichter vermarkten lässt als eine Editor-Erweiterung.
    Für Einzelpersonen oder kleine Firmen kann die Einführung leicht sein, aber große Organisationen haben bereits bestehende IDEs und viele Integrationen eingerichtet; sie zu einem weiteren IDE-Wechsel zu bewegen, dürfte eine schwierige Anforderung sein.

    • Nach der Antwort des Cursor-Teams ist die Fähigkeit von VSCode-Extensions, die Editor-UI zu steuern, sehr begrenzt.
      Command-K und Copilot++ seien als Extension nicht möglich, und dasselbe gelte für viele Funktionen, die sie künftig bauen möchten.
      https://forum.cursor.com/t/why-not-a-plugin/2448/2
    • Gute Frage.
      Extensions sind oft fehleranfällig oder lassen sich nur schwer natürlich integrieren. Bei Copilot springt zum Beispiel die Auswahl herum, und Codeium oder andere Open-Source-Extensions haben ähnliche Grenzen.
      Viele Extensions nutzen für die Prompt-Eingabe der Nutzer ein Quick-Pick-Dropdown, was sich unnatürlich anfühlt.
      Um solche Probleme zu vermeiden, ist es wichtig, wie Cursor die IDE selbst zu besitzen, und ich denke, das ist auch der Grund für Cursors Popularität.
      Dass die Einführung einer IDE schwierig ist, stimmt. Wenn man auf einer bereits beliebten Basis aufsetzt, kann man eine kleinere Nutzergruppe besser erreichen; langfristig möchte man wohl auch große Firmen mit Privacy und der Zentralisierung guter KI-Funktionen überzeugen.
    • Cody ist genau auf die beschriebene Weise als Extension implementiert und ist gegenüber Cursor wettbewerbsfähig.
      Ich habe noch keinen Grund gefunden, Cursor zu nutzen und dafür den Nachteil eines „Forks“ in Kauf zu nehmen.
      Allerdings bin ich inzwischen größtenteils zu Aider gewechselt.
      Jemand anderes hat Monetarisierung erwähnt; das könnte tatsächlich der wahre Grund sein.
  • Mehr Wettbewerb ist gut, aber auch wenn es etwas unhöflich klingen mag: Die meisten Software-Forks verschwinden wieder.
    Ich würde gern überzeugt werden, warum ich das hier statt Continue + Claude-dev nutzen sollte, also Open-Source-Extensions, die im normalen VSCode oder VSCodium laufen.
    Es hieß: „Auch Microsoft hat den Extension-Marketplace geschlossen gemacht“, aber es gibt die Open VSX Registry.

    • Ich frage mich, ob du mit Continue lokale Modelle nutzt.
  • Dass ihr es bis hierhin geschafft habt, ist Glückwunsch wert, und jetzt scheint der interessante Teil anzufangen.
    Es gibt ziemlich viele Extensions mit Tab-Autocomplete im Stil von Snippets und KI-Editoren, aber meines Wissens hat nur Cursor den Workflow richtig umgesetzt, bei dem ohne Blick auf die ganze Datei per „tab-tab-tab-tab“ automatisch korrigiert wird.
    Vermutlich ist das eine Kombination aus Monaco/VSCode-Hacks und einem eigens feinabgestimmten Modell, also nicht einfach ein fertiges großes Sprachmodell. Wenn ihr von „allen Kernfunktionen von Cursor“ sprecht, frage ich mich, ob genau das der Zielbereich ist oder ob ihr euch auf etwas anderes konzentriert.
    Cursor konnte bereits lokal heruntergeladene Extensions aus dem lokalen VSCode-Profil ziemlich gut „importieren“, hatte aber gelegentlich Schwierigkeiten bei der Nutzung der Marketplace-API für die Extension-Suche.
    Als Ausgangspunkt sollte man mit einer solchen Vorgehensweise besser zufrieden sein, und da man es mit Microsoft zu tun hat, sollte man auch auf Dinge wie die Brand Guidelines achten.
    Es ist besser, der Welt nicht zu erzählen, dass man Microsoft-APIs „hackt“. Selbst etwas, das klein wirkt, kann bei Erfolg zum Problem werden.
    Wenn das Ziel auch ist, Mitwirkende zu gewinnen, sollte man GitHub-Workflows und CI stark aufräumen.
    Die aktuelle Commit-Historie besteht größtenteils aus direkten Commits auf den main-Branch nach Dokumentationsänderungen, ohne Review oder Checks; der einzige frühe Commit mit Checks sieht so aus, als sei nach einem fehlgeschlagenen Monaco-Check dieser einfach deaktiviert worden.
    Wenn ihr das Projekt vergrößern oder Mitwirkende auf dem nötigen Niveau anziehen wollt, müsst ihr eine Test-Baseline etablieren und deutlich mehr Ordnung schaffen.

    • Das ist auch der einzige Grund, warum ich Cursor nutze.
      Die Autocomplete-Funktion ist so gut und beim Refactoring fast magisch.
      Nachdem ich einen ganzen Monat lang Cursor genutzt hatte und dann wieder VSCode ausprobiert habe, war Copilot im Vergleich wirklich miserabel.
      Ich möchte Cursor weiter nutzen, aber ich möchte nicht zweimal ein Claude-Abo kaufen. Cursor nutzt intern Claude, und ich bevorzuge Claude Sonnet gegenüber ChatGPT.
    • Eine sehr nützliche Funktion in Cursor ist apply.
      Sie merged den von der KI erzeugten Code automatisch mit meinem Code, und ich muss nur noch zustimmen oder ablehnen.
      Auch dafür scheint eine Custom-KI genutzt zu werden; es funktioniert nicht so, dass ich meinen API-Key einbringe, sondern erfordert ein Abo.
  • Es ist gut, dass es im Bereich „AI-Editoren“ mehr Wettbewerb gibt, aber ich frage mich, warum man das nicht als VSCode-Erweiterung baut
    Eine Erweiterung wirkt deutlich zugänglicher
    Ich frage mich, ob es Einschränkungen der Extension-API gibt, die die Umsetzung erschweren

    • Vermutlich, weil Erweiterungen schwer zu monetarisieren sind und sich damit auch eine große VC-Bewertung schwer rechtfertigen lässt
      Void wird von HN unterstützt
    • Stimme zu. VSCode ist zwar nicht perfekt, hat aber ein ziemlich reichhaltiges Ökosystem
      Man muss die Unterschiede zwischen Fork und Originalprodukt ständig im Blick behalten, und ich möchte in meinem Workflow nicht damit leben müssen, dass dabei Funktionen fehlen oder Erweiterungen kaputtgehen
      Cursor bietet eine ziemlich ausgereifte Erfahrung, aber am Ende bin ich wieder zu VSCode zurückgekehrt und nutze continue.dev. Es ist zwar deutlich unausgereifter, aber die UI funktioniert gut genug
    • Gute Frage, und es stimmt, dass eine Erweiterung leichter zugänglich ist
      Allerdings gibt es mit einer reinen Erweiterung keinen guten Weg, die gewünschte native UI zu bauen
      Zum Beispiel ist das Anzeigen von Vorher/Nachher-Änderungen zentral, fühlt sich innerhalb einer Erweiterung aber nicht natürlich an
      Erweiterungen wie Codeium verwenden den einfachsten Ansatz und schreiben Dinge wie <<<<<<< DIFF >>>>>>>> direkt in die Datei, wodurch das Syntax-Highlighting kaputtgeht
      Andere Erweiterungen wie Copilot sind sehr fehleranfällig
      Aktuell ist Void auf einer Erweiterung aufgebaut, aber um eine nativere Nutzererfahrung zu schaffen, werden auch Teile der IDE geändert und integriert
    • Viele Leute bevorzugen JetBrains gegenüber VSC
      Mein derzeitiger AI-Editor erster Wahl ist zum Beispiel Zed.dev, dort lassen sich mehrere Keymaps einschließlich JetBrains sehr einfach einrichten
      https://zed.dev/
    • Ich weiß nicht genau, aber continue ist derzeit wirklich schlecht
      Es ruiniert meine gesamte VSCode-Umgebung, einschließlich der Vim-Shortcuts
  • Ich weiß nicht, ob man dafür wirklich den gesamten Editor „besitzen“ muss
    Schon allein mit Upstream synchron zu bleiben ist eine enorme Belastung, und ich sehe nicht, was man dadurch gewinnt
    Wie andere gesagt haben, gibt es auch alternative Registries, und eine Anleitung zur Installation eines eigenständigen Plugins ist einfacher, als Nutzer den gesamten Editor herunterladen und installieren zu lassen
    Ich frage mich, ob man nicht einfach eine eigene Copilot-Erweiterung bauen und sie mit einer ollama-Instanz verbinden kann
    Ist das nicht genau das, was Continue macht? https://marketplace.visualstudio.com/items?itemName=Continue...

  • Ist das noch so früh, dass man es nicht einmal herunterladen kann? Ich verstehe nicht, warum ich wegen eines Code-Editors einem Discord-Server beitreten soll
    Ich frage mich, was der Plan ist, wenn VS Code alle Funktionen übernimmt

    • Der Code ist hier: https://github.com/voideditor/void/tree/main/extensions/void
      Im Moment ist er aber wirklich sehr grundlegend. Es ist eher eine Minimalimplementierung, die in einem Seitenfenster große Sprachmodelle aufruft und eine Ansicht zum Anwenden/Ablehnen von Diffs bereitstellt
      Derzeit ist es fast auf dem Niveau eines Wochenendprojekts
    • Das könnte auch der Kern der Sache sein
      Vielleicht ist es ein Spiel darum, wer von Microsoft übernommen wird und am Ende Teil von VS Code wird
  • Es gibt auch PearAI. Es wird als „Open-Source-AI-Code-Editor, ein Fork von VSCode und Continue“ beschrieben
    Dieser Bereich wird immer voller: cursor.sh, continue.dev, double.bot, supermaven, codium.ai, PearAI und jetzt auch Void
    https://github.com/trypear/pearai-app

    • Falls du die anderen ausprobiert hast, würde ich gern wissen, was dir konkret nicht gefallen hat
      Ich bin einer der Entwickler von https://double.bot
  • Ich wünschte, jemand würde Omnivim2 forken, damit es besser mit VS Code konkurrieren kann
    Soweit ich es verstehe, sieht dieser Editor wie VS Code aus, wird aber nativ kompiliert und unterstützt VS-Code-Plugins
    Leider scheint das Projekt verwaist zu sein und ist in ReasonML geschrieben
    Ich habe es satt, dass Entwicklungswerkzeuge rund um Webbrowser gebaut werden
    In den 90ern und 00ern gab es vollwertige native Apps, die nicht so komplex sein mussten wie heute
    Außerdem läuft es intern auf Basis von Vim, was in meinen Augen eher eine Stärke ist
    https://github.com/onivim/oni2

  • Sieht aus wie ein Doppelpost zu einem anderen Show-HN-Beitrag desselben Nutzers von vor 4 Tagen
    https://news.ycombinator.com/item?id=41523197

    • Ein paar Reposts sind in Ordnung, wenn der Beitrag noch nicht genug Aufmerksamkeit bekommen hat
      Steht auch in der FAQ: https://news.ycombinator.com/newsfaq.html#reposts
    • Wir hatten vor ein paar Tagen einen kleineren Launch, haben aber auf Basis des Feedbacks die GitHub-Beitragsseite, die Website und das Logo ziemlich stark verändert
      Wir versuchen einfach, schnell zu launchen
    • Also zweimal gelauncht? In einem hart umkämpften Umfeld sollte man so oft wie möglich launchen
    • Gilt als sehr angemessene Praxis