CodeEdit: Erste Vorabversion des Code-Editors für den Mac ist da
CodeEdit ist ein Code-Editor, der laut der Entwickler-Beschreibung von der Community für die Community entwickelt wurde und vollständig und ohne Kompromisse für macOS geschrieben wurde. Zu den Funktionen gehören Syntaxhervorhebung, Codevervollständigung, Suchen und Ersetzen von Projekten, Snippets, Terminal, Aufgabenausführung, Debugging, Git-Integration, Code-Review, Erweiterungen und mehr. Man möchte die Anwendung so leicht wie TextEdit halten, aber eine ähnliche Erfahrung wie Xcode bieten. Nun ist die erste Prerelease-Version erschienen, die ihr euch bei Interesse direkt bei GitHub herunterladen könnt, um die Open-Source-Software auszuprobieren.
Transparenz: In diesem Artikel sind Partnerlinks enthalten. Durch einen Klick darauf gelangt ihr direkt zum Anbieter. Solltet ihr euch dort für einen Kauf entscheiden, erhalten wir eine kleine Provision. Für euch ändert sich am Preis nichts. Partnerlinks haben keinerlei Einfluss auf unsere Berichterstattung.
„CodeEdit is currently in development and we do not yet offer a download.
We will post a link here when we have an alpha release ready for testing. Until then, we welcome contributors to help bring this project to life.“ ? :/
Steht doch ganz klar im Post und linkt zu GitHub. Man kann bei GitHub die Pre-release Version laden.
Seltsam, gerade hat sich aber über den Link am Ende des Artikels oben eine dmg-Datei auf meinem Rechner materialisiert.
https://github.com/CodeEditApp/CodeEdit/releases/tag/latest
Artikel vollständig gelesen?
“ … die ihr euch bei Interesse direkt bei GitHub herunterladen könnt“ 😉
Dort auf > Assets klicken und da gibt es dann auch das dmg
Ohne genau hinzuschauen hätte ich keinen Unterschied zu VSCode feststellen können :-).
Kein SSH Integration, kein Klassenbaum, keine PlugIns etc. etc..
Ich staune immer wieder welche Motivation die Leute von solchen Projekten treibt.
Gute Entwicklungsumgebungen scheitern jedenfalls ganz sicher nicht an Elektron-basierten UIs wie bei VSCode.
Also SSH Verbindungen würde ich schon aus Prinzip nicht einbauen. Wir sollten eigentlich lange darüber hinweg sein, auf irgendwelchen Servern direkt etwas zu editieren. Was die Klassenbäume angeht kann man bereits über dem Dateibaum erkennen, dass da noch viele weitere Features geplant sind. Wenn man bei der ersten _Vorab_version schon Plugins haben will frage ich mich aber schon, wo die denn herkommen sollen. Der Bereich „Components“ ist jedenfalls schon vorbereitet.
Schon aus Prinzip? So, so … Da kennt sich jemand so richt aus … Schon mal was von Development-Servern gehört? Und was man angeblich „erkennen“ kann ist Deinerseits auch nicht mehr als Spekulation
Du solltest mal an deinem Beißreflex arbeiten. Die Entwicklung steht erst am Anfang und da kann alles mögliche passieren.
Na klar gibts Entwicklungsserver. Aber selbst da sollte man nicht direkt Dateien editieren können. Wenn da mehrere Leute drauf arbeiten gehen wir einfach 20 Jahre zurück in der Zeit, abgesehen dass wir heute per Slack nachfragen, wessen Popup das ist 🙂
Modern und sicherer wären lokale Entwicklungsmöglichkeiten und eine klare Deployment Pipeline auf die diversen Test- und Produktivumgebungen. Für sich alleine brauchts das vielleicht nicht, aber selbst hierbei würde ich Github Hooks und ähnliches empfehlen.
Und dann landen die Credentials auf Github, weil kein Entwickler die direkt auf dem Server bearbeiten konnte…
Mehr als native single instances scheint es in Deinen Denk- und Wissensmustern nicht zu geben …
Ich glaube, Du siehst nicht den Unterschied zwischen einem „Editor“ und einer „Entwicklungsumgebung“.
Ich möchte nicht jede piffelige Textdatei in in Projekt-orientierten Tools wie PHPStorm oder VisualStudio öffnen. Dafür nehme ich mal eben die kostenlose Version von BBedit, und da habe ich dann generische Funktionen wie „Doppelte Zeilen entfernen“ oder „Text alphabetisch sortieren“, oder ich editiere eine CSV einfach direkt.
Ich habe ja auch ein Fahrrad UND ein Auto.