Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Software>Guter Texteditor

Guter Texteditor

Der Mike
Der Mike26.10.0812:04
Was ist bei Texteditoren unter Mac OS X denn aktuell besonders beliebt?

Wichtig ist mir nicht nur eine gute Integration ins Mac-Look-&-Feel, also AHIG-Konsistenz, sondern auch insgesamt ausgereifte Funktionalität (bei einem aufgeräumten UI!). Schön wäre auch eine ordentliche deutsche Lokalisierung, vor allem wiederum wegen UI-Konsistenz, da hier nun mal ein deutsches System läuft.

Ja, ich kenne EMACS, ich kenne vi, pico, nano uswusf., so seit 20 Jahren.

Ist aber jeweils keinerlei Alternative, wenn's ums Texteditoren außerhalb des CLIs geht.

(Auch deren "Aqua-Portierungen" nicht.)

Habe jahrelang BBEdit benutzt, gibt's da mittlerweile was besseres? (Alleine dessen Suche-Funktion, insbesondere auch im Dateisystem und vor allem in Dateien ist sehr mächtig.)

Der Texteditor ist übrigens für eine ziemlich allgemeine Verwendung gedacht. Hatte mir schon mal Smultron angeschaut, doch leider sieht das noch eher nach einer Baustelle aus, von der sehr schlampigen Lokalisierung ganz zu schweigen.

Kann auch gerne was kosten (Shareware). Hauptsache: mir genehm.
0

Kommentare

Dr. Seltsam
Dr. Seltsam26.10.0812:19
Smultron ist gut und frei, nutze ich sehr gerne. Offenbar nicht dein Geschmack

Wenn man es heavy mag: TextMate. Kann alles.
0
Dr. Seltsam
Dr. Seltsam26.10.0812:25
Ach ja - wenn man auch mal 50 MB - Files aus nem SQL-Dump ansehen will, bleibt außer Textwrangler (BBEdit) und TextMate sowieso kaum was. Die organisieren die Daten im Speicher ohne Cocoa-Objekte und haben keine Probleme mit diesen Mengen. Smultron, SubEthaEdit & Co sind damit hoffnungslos überfordert.
0
fallenpieces
fallenpieces26.10.0812:47
Ich habe mit TextMate ganz gute erfahrungen gemacht, aber leider ist das prog nicht kostenlos - 50€ die sich aber lohnen
0
ZitronenZisterne26.10.0813:13
Probier mal Mellel, vielleicht gefällt dir das.
Hier gibts auch einige Videos dazu, kannst du dir ja erstmal anschauen.

0
sierkb27.10.0810:16
Der Mike:

Nur mal so am Rande, wo ich lese, dass Du BBEdit wohl seit Jahren kennst und benutzt und mit dessen Suchfunktion so zufrieden bist: den kostenfreien TextWrangler aus demselben Hause wie BBEdit kennst Du bereits? Zumindest die Suchfunktion dürfte die gleiche sein wie unter BBEdit.
Der Unterschied zwischen TextWrangler und BBEdit liegt wohl in der jeweiligen Ausrichtung: TextWrangler ist eher der Generalist, mit dem man u.a. auch Programm-Code schreiben kann, und BBEdit ist der Spezialist von beiden, der sich voll und ganz und nur dem dem Schreiben von Programm-Code widmet... Dafür ist TextWrangler kostenfrei, und BBEdit kostet was. Dafür, dass TextWrangler kostenfrei vom selben Hersteller angeboten wird und das Hauptprodukt sicherlich BBEdit ist, kann er, finde ich, erstaunlich viel.
Trotzdem benutze ich gewohnheitsmäßig was Anderes, obwohl TextWrangler (noch) bei mir auf der Platte schlummert. Ich benutze fürs Kleine und schnelle Editieren lieber den kostenfreien Smultron und für größere Dinge/Projekte gleich eine IDE in Form von Eclipse . Als IDE-Konkurrenzprodukt zu Eclipse wäre da sicher auch NetBeans als einen Blick wert zu nennen, aber ob eine so umfassende IDE wie Eclipse oder NetBeans für Dich überhaupt infragekommt, musst Du selbst entscheiden.
Da Du die klassischen Unix-Editoren Vi, Emacs, Pico, Nano, etc. anscheinend schon kennst, zumindest deren CLI-Version, suchst Du sicher auch einen Editor mit ähnlicher Machtfülle. Da die Aqua-Portierungen dieser Editoren Dir anscheinend nicht gefallen, wird die Auswahl da wohl etwas dünner, und vielleicht kommt für Dich dann doch eher eine IDE wie Eclipse oder NetBeans in Betracht, um Dir die Funktionsfülle zu bieten, die Dir zum Beispiel Emacs und Vi bzw. deren Aqua-Portierungen bieten. Wobei ich zugestehen muss, dass ich die Aqua-Portierung/-Umsetzung von Aquamacs bzgl. Emacs und MacVim bzgl. Vi(m) gar nicht mal so ungelungen finde...
Geschmackssache eben.
0
Dr. Seltsam
Dr. Seltsam27.10.0811:06
sierkb

Obwohl ich prinzipiell Gegner der Todesstrafe bin und einem Jahrgang angehöre, der Vi tatsächlich als Normalität kannte, schießen mir heute allein beim Anblick dieses Editors immer noch die wenigen poitiven Aspekte einer Hinrichtung durch den Kopf.

Klar, man kann sich an alles gewöhnen, an eitrigen Ausschlag, Keuchhusten, Phantomschmerzen und letztlich auch an vi...
0
bernddasbrot
bernddasbrot27.10.0811:11
Etwas besseres als TextWrangler dürfte m.E. schwer zu finden sein.

Vielleicht wäre SubEthaEdit noch eine Alternative?
0
Schläfer27.10.0811:53
Kommt darauf an, was du mit deinem Texteditor hauptsächlich machst. Wenn du nicht hauptamtlich programmierst und eine der nicht gerade billigen Lizenz besitzt, gibt es imo keinen Grund, von BBEdit wegzuswitchen.

Ich verwende hauptsächlich MacVim (kostenlos und imho exzellenter Port), wenn das nichts ist, würde ich zu TextMate raten.

Im Gegensatz zu Dr. Seltsam muss ich sagen, dass bei mir bei großen Dateien auch TextMate äußerst zäh wird. Bei Dateien in mehreren MB-Bereicht geht bei GUI-Anwendungen nach meiner Erfahrung eigentlich nur BBedit/TextWrangler.
0
MacRabbitPro27.10.0812:08
Dr. Seltsam
Ach ja - wenn man auch mal 50 MB - Files aus nem SQL-Dump ansehen will, bleibt außer Textwrangler (BBEdit) und TextMate sowieso kaum was. Die organisieren die Daten im Speicher ohne Cocoa-Objekte und haben keine Probleme mit diesen Mengen. Smultron, SubEthaEdit & Co sind damit hoffnungslos überfordert.

Also jetzt muss ich doch mal Cocoa in Schutz nemhen!

Das verschiedene Editoren mit großen Dateien nicht umgehen können hat sicher nix mit Cocoa zu tun sondern damit, wie der Entwickler das programmiert hat. Auch mit Cocoa (besser: Obj-C) kann man große Mengen an Daten bearbeiten ohne alles komplett in den Speicher zeihen zu müssen.
Umgekehrt kann man in plain C auch so ungeschickt programmieren, dass ein Programm bei großen Datenmengen nicht mehr brauchbar ist.
0

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.