Diskussion:Emacs

aus Wikipedia, der freien Enzyklopädie
Letzter Kommentar: vor 2 Tagen von Alissem in Abschnitt Mythos Emacs
Zur Navigation springen Zur Suche springen

Entwickler Stallman?

[Quelltext bearbeiten]

Ich meine mich zu erinnern, daß es neben dem GNU Emacs noch einige Jahre den Gosling Emacs gab. Die englische Wikipedia-Ausgabe nennt James Gosling als Entwickler der ersten Emacs-Version. (nicht signierter Beitrag von 217.84.191.37 (Diskussion) 20:56, 13. Mär. 2006 (CET)) Beantworten

Dazu sollte man dringend http://www.jwz.org/doc/emacs-timeline.html beachten. Ebenso die auf verschiedenen Listen veröffentlichte Zusammenstellung von Implementierungen, die man unter http://www.finseth.com/~fin/emacs.html einsehen kann. -- Kai Wasserbäch 20:03, 27. Jun 2006 (CEST)
Der letzte Link ist jetzt unter http://www.finseth.com/emacs.html zu finden. --H3xc0d3r (Diskussion) 16:19, 27. Apr. 2013 (CEST)Beantworten

Ja, über diese Aussage gleich zu Beginnn des Artikels bin ich ebenfalls gestolpert. Stallman kann nicht den ersten emacs geschrieben haben. Das widerspricht der oben genannte Quelle und sogar dem folgenden Abschnitt "Geschichte" in diesem Artikel selbst. Außerdem widerspricht es diesem englischen Wikipedia Artikel: http://en.wikipedia.org/wiki/Gosling_Emacs (nicht signierter Beitrag von 141.71.30.160 (Diskussion) 09:32, 3. Mär. 2011 (CET)) Beantworten

Es wird doch in http://www.jwz.org/doc/emacs-timeline.html sehr schön dargestellt. Du verwechselst "Emacs" mit "GNU Emacs". --91.32.83.107 09:44, 3. Mär. 2011 (CET)Beantworten

Vermisste Screenshots?

[Quelltext bearbeiten]

Falls jemand seine Screenshots vermissen sollte, Paddy hat sie gelöscht. Eine Auseinandersetzung darüber findet ihr unter Wikipedia Diskussion:Bildrechte#Screenshots. --Meph666 21:07, 27. Feb 2005 (CET)



Ich habe vor geraumer Zeit mal eine kurze Einführung für den XEmacs geschrieben. Mittlerweile ist die Seite schon lange offline. Eine kurze Zusammenstellung der wichtigsten/gängigsten Tastaturbefehlen fänd ich an dieser Stelle noch sinnvoll (ähnlich wie beim vi Beitrag). Ich weiss nur nicht, ob das bei den vielen Distributionen die im Umlauf sind Sinn macht. Andsonsten würde ich diese Seite gerne etwas erweitern, wenn nichts dagegen spricht?! --uvb


"emacs" ist ein gutes Betriebssystem, ein guter editor fehlt halt noch...:) --nerd


Vielleicht sollte man nicht im ersten Satz schreiben, in welcher Sprache das Ding geschrieben ist. Duerfte nicht so viele Leute interessieren, eher interessant sind die Erweiterbarkeit, Flexibilitaet, Komplexitaet und Integration von Emacs in die Unix-/Linux-Umgebung, oder?

Vgl. en:Emacs Keichwa


Die unmoegliche Wiedervereinigung von Xemacs und GNU Emacs liegt nicht an der grafischen Oberflaeche (die hat GNU Emacs auch schon), sondern an Lizenzproblemen: Die Free Software Foundation will, dass das Copyright fuer GNU-Software von ihr gehalten wird, damit die GPL vor amerikanischen Gerichten einklagbar ist. Leider sind bei Xemacs m.W. nach sehr viele Leute beteiligt gewesen, und es ist schwierig, sie alle dazu zu bringen, das (c) an die FSF zu ueberschreiben.--zeno 08:01, 27. Jan 2003 (CET)----

Aber nicht unmöglich... Man unterzeichnet einfach ein Papier bei der FSF, das habe ich auch schon getan. Fertig. cconrad


ELIZA ein Programm zur Psychotherapie? Für Nichtkenner des Emacs und Eliza völlig irreführend, man stellt sich ja sonst was vor. Eliza ist ein Spielzeug.. Ich werde die Formulierung demnächst streichen, wenn keiner hier was gegen hat. cconrad

Ich bin dafür die bestehende Formulierung durch eine etwas abgespecktere Aussage zu ersetzen wie etwa: Dem Funktionsumfang ist eine Frage-Antwort Applikation namens ELIZA beigefügt, welche die Erweiterungsmöglichkeiten durch LISP eindrucksvoll demonstriert. Elch 02:04, 5. Jun 2004 (CEST)

"Aus oben erwähnten Gründen scheint es unwahrscheinlich, dass die beiden Projekte GNU Emacs und XEmacs in naher Zukunft zusammengeführt werden können." Was ist denn damit gemeint? Die "religiösen Züge"? Warum sprechen sich die Auguren nicht ab? Ein bißchen Background zum historischen Zwist dazu bringt The Lemacs/FSFmacs Schism cconrad


Der Witz mit "(E)ight (M)egabytes (A)nd (C)onstantly (S)wapping" ist ja noch gerechtfertigt, da er in einem Kontext zum Artikel steht und erklärt wird. Die bloße Aneinanderreihung der Witze weiter unten scheint mir jedoch überflüssig. Mit etwas Kreativität oder Recherche kann man zu jedem Artikel eine Witzliste erstellen, die unendlich lang werden kann und außerdem keinerlei Information vermittelt. — Matthäus Wander 17:11, 29. Jan 2004 (CET)


Unendlich?? Fang schon mal an =;-)

Der erste Satz

[Quelltext bearbeiten]

Der erste Satz, der momentan so lautet:

Emacs ist ein ursprünglich von Richard Stallman entwickelter Texteditor, der durch seine Programmierschnittstelle in der Programmiersprache LISP mit beliebigen Erweiterungen ausgestattet werden kann

sollte meiner Ansicht nach geändert werden in:

GNU Emacs ist ein von Richard Stallman entwickelter Texteditor, der durch seine Makrosprache Emacs-LISP von versierten Anwendern dynamisch erweitert und angepasst werden kann.

Begründung: 1.) Es gibt auch andere (ältere und jüngere) Editoren, die den Namen Emacs tragen. Dieser Artikel handelt aber von GNU Emacs (und seinem Spin-Off XEmacs). 2.) »Ursprünglich« kann weg, weil RMS immer noch der Chefentwickler ist. 3.) »Programmierschnittstelle« ist etwas verwirrend, und der Wikilink auf Schnittstelle hilft hier auch nicht weiter. Viele Programme benutzen intern APIs. Das ist aber hier nicht gemeint. Das besondere am Einsatz von Emacs-Lisp ist die Tatsache, dass der Benutzer zur Laufzeit darauf Zugriff hat und den Editor so dynamisch verändern kann.

Einwände? --Thüringer ☼ 09:16, 9. Nov 2004 (CET)

Keine Einwände. Stallman selber sagt, dass GNU Emacs seine zweite Implementation von Emacs ist. Emacs ist IMHO definitiv keine Erfindung von RMS - vielmehr ist es ein Editor der durch seine Version so richtig bekannt geworden ist. Ich finde den ersten Satz wirklich nicht passend. --WanjaChresta 14:51, 12. Sep 2005 (CEST)

Emacs Wikipedia mode

[Quelltext bearbeiten]

Hi.

I'm writing an Emacs Wikipedia mode. See the homepage for details (in English.) I can add support for the German Wikipedia domain. For this I need the following information:

  • What are the proper quotes for the German language? For instance, these are the English quotes: “…”, Russian quotes: «…». In Russian nested quotes are usually formatted this way: «… „…“ …».
  • Is there a translated version of [[Image:…]] tag for the German domain, and what is it?
  • Does German language use en-dash («–») in any way? Or does it only use em-dash («—»), like Russian?

Please either send this information (in UTF-8) to [wikipedia-el-dev@gna.org] or leave me a message in the Russian Wikipedia. I also appreciate any feedback on the mode itself.

Thanks in advance. Paul Pogonyshev. (Der vorstehende, nicht signierte Beitrag stammt von 195.50.12.22 (DiskussionBeiträge) 18:08, 1. Dez. 2004)

Salut, german uses „...‚...’...“ for quotes, [[Bild:...]]for pics and as far as i know only hyphens.--Patrick 02:34, 26. Aug 2006 (CEST)
English Tags like [[Image:...]] work on all Wiikpedias --Oms 20:36, 18. Jul. 2007 (CEST)Beantworten

Kaffee-Anekdote

[Quelltext bearbeiten]

Folgender Absatz wurde mit dem Kommentar "IMHO keine Anekdoten in einem Artikel statthaft" entfernt ...

Lange Zeit wurde Emacs häufig so umschrieben: "With Emacs you can do everything, except making coffee." ("Mit Emacs kann man alles machen außer Kaffee kochen"). Aber selbst diese Aussage entspricht nicht mehr den Fakten, seit der Franzose Eric Marsden ein Modul entwickelt hat, mit dem in Emacs eine RFC2324-kompatible Kaffeemaschine über das Hyper Text Coffee Pot Control Protocol (HTCPCP) gesteuert werden kann.

Ich finde immer noch, dass der Absatz dem Laien gut & bündig die Komplexität von Emacs verdeutlichen kann ... brunft 23:48, 13. Mai 2005 (CEST)Beantworten

gudn tach! da das langsam zu nem edit-war ausartet, stimme ich dem vorschlag Amtiss' mit der uebersetzung zu. wie steht's damit:
Emacs is a great operating system - it lacks a good editor, though.
Emacs ist ein großartiges Betriebssystem - es ermangelt ihm jedoch daran, ein guter Editor zu sein
das kann bestimmt jemand besser. ich versuche damit bloss den stein ins rollen zu bringen. -- seth 21:59, 18. Jun 2006 (CEST)

Hallo lustiger seth,
Danke, dass du schon mal eine Übersetzung vorgeschlagen hast.
es ermangelt ihm jedoch daran, ein guter Editor zu sein
Ich denke, dass das genau der Punkt ist, den ihr falsch versteht (man korrigiere mich, wenn ich falsch liege). Das Zitat ist eigentlich nur ein Ausschnit aus einem Zitat. (siehe Wikiquote) "to lack" heißt u.a. fehlen, ermangeln
Ich würde seine Aussage so übersetzen: "Emacs ist ein tolles/großartiges Betriebssystem - obwohl ein guter Editor fehlt." Ich denke, dass er ausdrücken (und anerkennen) wollte, dass Emacs schon mit so vielen Erweiterungen ausgestattet ist. Der zweite Teil nach dem Bindestrich soll witzig sein und zugleich seine Meinung widergeben (weil er vi*-Nutzer ist). Daher halte ich die ursprüngliche Version für gut.
Gruß, Ri st 03:52, 19. Jun 2006 (CEST)
oh, du hast bzgl. der uebersetzung recht; "einen guten editor zu haben" waere richtiger gewesen. ich finde deine uebersetzung ok. und sie laesst noch immer genausoviel spielraum, eine schlechte bedienbarkeit reinzuinterpretieren. (vim ist halt leichter zu bedienen und sowieso und ueberhaupt besser! *g*) -- seth 23:10, 19. Jun 2006 (CEST)

Mythos Emacs

[Quelltext bearbeiten]

Es gibt nicht wirklich Leute, die Emacs benutzen, oder? Das mit den Rivalitätskämpfen zwischen Vim und Emacs ist glaub ich nur eine Legende. Schaut doch mal in euren Bekanntenkreis. Vim ist zweifelsfrei der zweckmäßigere Editor. Ich wurde noch nie von wem angemacht, weil ich Vim-User bin.--Briks 02:05, 13. Mär. 2007 (CET)Beantworten

Ich benutze Emacs und habe auch schon mit Vim-Users über Vor- und Nachteile der jeweiligen Editoren diskutiert. Und nu? --SteBo 07:24, 13. Mär. 2007 (CET)Beantworten
Hm, ok, dann ziehe ich meine These erstmal zurück.--Briks 22:05, 13. Mär. 2007 (CET)Beantworten
Ich benutze auch den Emacs; ich keine leider nur wenige andere Emacs-Enthusiasten im näheren Umfeld. Ein Juniorprofessor gehört dazu. Die Masse nutzt vi, was ich unerklärlich finde, wenn ich sehe, wie langsam die den Code hacken (langsam wie Schnecken!). Und da niemand intelligente Vim-Modi benutzt (Gibt's die überhaupt?), ist mir die Beliebtheit unerklärlich. Und dann gibt's da noch die, die weder mit vi noch mit Emacs können, aber völlig unüberlegt auf den vi zurückgreifen, wenn sie keinen Klickibunti-Teil zur Verfügung haben. Empfehlungen zum Emacs meinerseits werden zurückgewiesen, obwohl sie sehen können, wie gut ich damit arbeite. Insbesondere auf dem Feld VHDL und LaTeX ist Emacs unschlagbar. --134.109.184.168 13:35, 14. Jun. 2007 (CEST)Beantworten
Nja, mir schien Emacs einfach nur das Textverarbeitende Monster mit eingebautem OS zu sein, anfänglich bekam ich nicht mal die Hilfe her, da war VI doch schneller beherrscht. Der durchschnitts-User sieht im emacs eher ein Überbleibsel aus alter Zeit, X11 sei dank. Mittlerweile nutze ich den emacs recht gern, doch schreibe ich keine Texte mit ihm, um Mails und Infoseiten sowie Manpages zu lesen als auch zum spilen nehme ich ihn allerdings gerne. Zum schreiben nutze ich Textedit.--apfelfreund 20:04, 23. Aug. 2007 (CEST)
Das sehe ich nicht so... Bin Physikstudent und an meiner alten Uni hat mein Bachelorarbeits-Betreuer emacs benutzt wodurch ich dann auch zum emcas-user wurde. Aber einige Kommolitonen haben vim Benutzt, weil das in ihrer Arbeitsgrupper mehr Leute benutzt haben. Nun bin ich im Maser an einer anderen Uni und dort wird emacs wieder intensiv genutzt (wir schreiben das Jahr 2011). In meinem Freundeskreis befinden sich ca. 20% vim-user, 30%-emacs-user, 20% kate-user und 30% benutzen kein linux X-D --85.178.143.3 17:58, 22. Mai 2011 (CEST)Beantworten

Bzgl:"Die Masse nutzt vi, was ich unerklärlich finde" - Naja, es gab Systeme, auf denen unmittelbar nach dem Mounten der Root-Partition vi verfügbar war. Damit konnte man also die Boot-Scripte editieren. Mit emacs unmöglich, da die libs auf anderen volumes lagen. Da hat sich die Masse evtl. am Sysadmin orientiert, obwohl unangemessen. Ein Kult? (KL) 85.177.150.230 08:33, 6. Nov. 2008 (CET)Beantworten

Wie auch immer. vi ist unerfahrenen Unixern wohl näher an "notepad.exe", aber emacs ist einfach meistseitiger. Wenn man erstmal die Alt-Meta-Shift-Angst überstanden hat. Not for necessity but honesty has emacs been termed the Swiss Army Knife of IT. greybeard 18:17, 15. Dez. 2024 (CET)Beantworten

Lemmaklärung *Emacs

[Quelltext bearbeiten]

Nach der überstandenen LD zu XEmacs frage ich mal: Wie lassen sich die Lemmata Emacs, GNU Emacs und XEmacs zweckmäßig per BKL von einander abgrenzen? --grixlkraxl 15:15, 23. Jun. 2009 (CEST)Beantworten

Mein Vorschlag:

  1. Nach löschen der bestehenden Weiterleitung diesen Artikel nach GNU Emacs verschieben
  2. eine Emacs (Begriffsklärung) einrichten mit Verweisen auf GNU Emacs, XEmacs, Microemacs, weitere Flavours?

Hinweis: hier wird nicht über "vi(m)", "nano", "ed" usw. diskutiert ;-) --grixlkraxl 15:29, 23. Jun. 2009 (CEST)Beantworten

Nachtrag: Ich habe mich mal an einer "minimal invasiven" BKL versucht, auch um deutlicher auf den inzwischen entstandenen Artikel XEmacs hinzuweisen. --grixlkraxl 19:16, 23. Jun. 2009 (CEST)Beantworten

Aber über EMACS im allgemeinen und die ganzen Flavors, die weder GNU noch XEmacs noch Microemacs sind gibt es doch mehr zu sagen, als in eine BKL passt. diese Varianten sind doch alles relativ späte Entwicklungen in der EMACS-Geschichte. --Joachim Pense (d) 20:51, 23. Jun. 2009 (CEST)Beantworten

Ich habe das etwas unglückliche Gleichsetzen von Emacs mit GNU Emacs jetzt versucht zu verbessern, indem GNU Emacs nur noch ein Unterpunkt ist. Ich hoffe, das reicht so. --Tuxman (Diskussion) 14:07, 18. Aug. 2020 (CEST)Beantworten

Abschnitt "Terminologie"?

[Quelltext bearbeiten]

Moin, die russische Schwesterseite hat einen kurzen Abschnitt über so grundlegende Konzepte wie "Buffer", "Window", etc. (Mit Illustration) mir gefällt das eigentlich ganz gut und vielleicht sollte man das auch in diesen Artikel einbringen? Den Text würde ich schreiben, aber als der unfähigste Grafiker auf diesem Planeten kann ich keine solche Grafik basteln. Bin an eurer Meinung interessiert, ob das für den Artikel wichtig ist oder ob man es lassen soll - und wenn es wichtig ist, ob jemand so eine Grafik bauen kann/will. --Sarwrik 01:55, 7. Sep. 2009 (CEST)Beantworten

Es gibt bereits die Artikel Puffer (Informatik) und Fenster (Computer). War das gemeint? --91.32.100.149 23:10, 8. Sep. 2009 (CEST)Beantworten
Nein, wohl eher im Zusammenhang, was man bei Emacs darunter versteht, siehe auch die verlinkte Zeichnung. --Snuffels 23:40, 8. Sep. 2009 (CEST)Beantworten
So was hat m. E. eher was bei Wikibooks verloren, die Bedienung eines Programms ist nicht Gegenstand einer Enzyklopädie.
-- Tuxman 02:30, 9. Sep. 2009 (CEST)Beantworten
Konzepte sind doch keine Bedienung. Es geht hierbei gar nicht um das Wie macht man das, nur um Begriffsklärung und Wie wird etwas realisiert. -- Snuffels 12:52, 9. Sep. 2009 (CEST)Beantworten
Und wie willst du das trennen?
-- Tuxman 17:30, 9. Sep. 2009 (CEST)Beantworten
Etwa so, wie in der russischen WP. Da werden ja auch erklärt, was das Konzept "Fenster" in Emacs bedeutet, weil der Normalbenutzer das am ehesten mit einem "Fenster" in dem Sinne, wie das unter Windows oder vielen X11-Fenstermanagern verstanden wird, assoziiert. Die Befehle, die damit zusammenhängen, etwa daß C-x 2 die Funktion split-window-vertically ausführt, gehört natürlich nicht rein. --Sarwrik 18:12, 9. Sep. 2009 (CEST)Beantworten
Warum sollten Bedienkonzepte von Emacs in einem enzyklopädischen Artikel auftauchen? Vim besitzt ein ähnliches Bedienkonzept (Tabs - Buffers - Windows), auch dieses wird aber, so weit mir bekannt, nur in Handbüchern erklärt...
-- Tuxman 23:20, 9. Sep. 2009 (CEST)Beantworten
Den Link zu der russischen Grafik hattest du dir mal angeschaut? Den Text dazu könnte ich natürlich nicht lesen, aber für mich sieht das durchaus recht brauchbar und interessant aus, und auch als Bereicherung des Lemmas, in Zusammenhang mit einem entsprechenden Text. Und das ganze fällt zwar m.E. durchaus unter "Konzept", aber nicht so recht unter "Bedienkonzept", immerhin gehts ja eher um die Aufteilung und die Klarstellung von Begrifflichkeiten im zugehörigen Kontext. Bedienung wäre m.E. auch eher das von Sarwrik zuletzt angebrachte Beispiel. -- Snuffels 13:49, 10. Sep. 2009 (CEST)Beantworten
@Tuxman: Was spricht dagegen, das vi-konzept ebenfalls dort zu erwähnen? Beide Bedienkonzepte ("Tabs", "Buffers", "Windows") unterscheiden sich deutlich vom inzwischen(!) üblich gewordenen Verständnis. Relevanz vergeht nicht. --grixlkraxl 14:50, 10. Sep. 2009 (CEST)Beantworten
Richtig, das steht aber bereits im Artikel.
-- Tuxman 17:34, 10. Sep. 2009 (CEST)Beantworten

Zurück zum Thema: Die Frage ist doch zuerst: relevant genug für WP? Falls ja, wie darstellen? Die Konzepte Buffer, Window, Frame und Tabs bedeuten doch bei emacs/vi etwas deutlich anderes, wie die angegeben Linkziele! So habe ich die Frage von sarwrik verstanden. Mit dem ru-Bild kann ich übrigens gar nichts anfangen, die ASCII-Grafik bei vi ist da besser. --grixlkraxl 19:47, 10. Sep. 2009 (CEST)Beantworten

Ich meine schon, daß man einiges über den Editor noch hinzunehmen könnte, eben darum um deutlich zu machen, inwiefern er "eigen" ist. Neben der gerade diskutierten Terminologiegeschichte könnte auch eine kurze Unterscheidung von "major mode" und "minor mode" nicht schaden. Das scheinen mir so elementare Konzepte zu sein, daß eine Emacs-Darstellung ohne sie unvollständig ist. Im Vim-Artikel stehen auch die verschiedenen Betriebsmodi drin. Ich denke deshalb, weil dem Durchschnittsuser, der vielleicht nur mit notepad oder Ähnlichem gearbeitet hat, dieses ihm fremde Verhalten von vim direkt ins Auge springt. Beim Emacs ist es ähnlich, Konzepte wie etwa den Minibuffer kennen viele Leute einfach nicht und ich glaube, daß es sinnvoll ist, diese "herausstechenden Merkmale", die auch dem Laien sofort ins Auge springen, kurz zusammenzufassen. De facto steht nämlich im Emacs-Artikel, verglichen mit dem Vim-Artikel sehr sehr wenig und ich finde der Editor hätte einen umfangreicheren Artikel verdient. Das kann man nämlich durchaus realisieren ohne in unverständlichen Fachjargon abzudriften.--Sarwrik 22:29, 11. Sep. 2009 (CEST)Beantworten

Frühkindliche Prägungen

[Quelltext bearbeiten]

Von einigen Benutzern, die mit anderen Editoren aufgewachsen sind, wird die Vielfalt der Emacs-Modi als wenig überschaubar und der Editor selbst wegen seiner „umständlichen Tastenbindungen“ als schwierig zu erlernen bezeichnet.

Wer wächst denn schon mit einem Editor auf? Die Formulierung ist schon etwas seltsam. 77.23.23.75 07:10, 17. Feb. 2010 (CET)Beantworten
Ja. Die Änderung war gut. :)
-- Tuxman 07:54, 17. Feb. 2010 (CET)Beantworten

Neutralität

[Quelltext bearbeiten]

Der Abschnitt "Vor- und Nachteile" enthält einige nichtneutrale Sätze, z.B.:"Die größten Vorteile des Editors sind sein konsequent durchdachtes Konzept und seine gute Dokumentation.". Das dürfte kaum ein Kritiker des Projekts so stehen lassen.

Der letzte Abschnitt "Die vordefinierten Tastenbindungen... Entscheidend ist, dass sämtliche Belegungen beliebig geändert werden können und die Zahl der möglichen Tastenkombinationen nicht begrenzt ist." drückt anscheinend die Meinung des Autors aus, die Tastenbindungsproblematik sei beim Emacs gelöst. Da kann man denke ich anderer Meinung sein, folglich ist der Abschnitt nicht neutral. --Deprecated 19:05, 18. Jun. 2010 (CEST)Beantworten

Ich als Vim-Nutzer find die Problematik ja bei Emacs ganz besonders furchtbar, ähm.
Soll der Abschnitt ganz rausfliegen oder nur umgeschrieben werden?
-- Tuxman 19:50, 18. Jun. 2010 (CEST)Beantworten
Wenn er umgeschrieben wird, sollte er von einem Emacs-Benutzer (wie mir) geschrieben werden, der dem Programm aufgeschlossen gegenüber steht und sich trotzdem mit anderen Ansichten auseinandersetzen mag.--Aschmidt 21:09, 18. Jun. 2010 (CEST)Beantworten
Ich würde damit beginnen, daß Emacs ganz sicherlich der mächtigste und der effizienteste Editor ist, den es gibt und daß er auf jeder Plattform gleich zu bedienen ist. Und genau dies (letzteres) lehnen viele Anwender ab, weil sie etwa ihre gewohnten Tastaturkürzel auch im Emacs haben möchten. Auch das kann man zwar anpassen, aber ... usw.--Aschmidt 21:17, 18. Jun. 2010 (CEST)Beantworten
"ganz sicherlich der mächtigste und der effizienteste Editor ist, den es gibt", nein, das ganz sicher nicht, abgesehen davon, dass "is halt so" keine valide Quelle ist.
-- Tuxman 23:09, 18. Jun. 2010 (CEST)Beantworten
Siehste, und deshalb hab ich den Text gar nicht erst angefaßt. ;-) --Aschmidt 23:29, 18. Jun. 2010 (CEST)Beantworten
Dzz, fies. Ich bin tatsächlich darauf hereingefallen. Mach doch nicht immer so was mit einem alten Mann.
-- Tuxman 05:05, 19. Jun. 2010 (CEST)Beantworten

Wir könnten doch einfach mal die Vor- und Nachteile hier stichwortartig sammeln und, sobald die Liste einigermaßen vollständig ist, den entsprechenden Absatz überarbeiten oder neuschreiben. Ich fang mal an, auch wenn ich nicht glaube, dass wirklich die komplette Liste mit in den Absatz gehört. Welche Punkte dann wirklich (ir)relevant sind, muss man dann halt auch nochmal schauen. -- Snuffels 14:38, 19. Jun. 2010 (CEST)Beantworten

Meine ersten (und letzten) Gehversuche mit dem Emacs liegen einige Jahre zurück, vermutlich hat sich der Funktionsumfang seither verdoppelt. Daher interessiert mich folgendes: Gibt es überhaupt Sinn, Emacs als Editor zu bezeichnen? Die ganzen Erweiterungen wie Kalender, Mail etc. deuten doch darauf hin, dass das eben nicht mehr der Fall ist. Ich würde auch nicht auf die Idee kommen, eine Entwicklungsumgebung wie Eclipse als Editor mit zahlreichen Zusatzfunktionen zu bezeichnen. Gibt es beim Emacs irgendeine andere Kategorie, die besser passt? --Deprecated 09:11, 22. Jun. 2010 (CEST)Beantworten
IDE?
-- Tuxman 12:22, 22. Jun. 2010 (CEST)Beantworten

Liste Vorteile (bitte ergänzen):

  • Enthält von Haus aus viele Erweiterungen (Kalender, Mail, Org-Mode, etc)
  • Unterstützung für sehr viele Sprachen (sowohl Programmier- als auch z.B. Markupsprachen, und vieles mehr)
  • Umfangreiches Hilfe-System
  • Vollständig konfigurierbar/anpassbar
  • Viele verfügbare Zusatzpakete (z.B. für Wikipedia ;-) )
  • Daemon-Mode (für mich eindeutig ein nennenswerter Vorteil)
  • Für sehr viele verschiedene Plattformen verfügbar
  • Aktive Community

Liste Nachteile (bitte ergänzen):

  • Nicht einsteigerfreundlich
  • Wird oft als überladen bezeichnet
  • Standard-Tastenbelegung weicht in praktisch allen Punkten von der ab, die viele andere Programme verwenden
  • Zum Einstellen/Verändern/Erweitern vieler Dinge werden LISP-Kentnisse benötigt
  • Kann nur Dateien bis zu bestimmter Maximalgröße öffnen
  • Anbindung an die Kaffeemaschine alles andere als trivial
    • *lol*
    • Altbacken wirkende grafische Oberfläche
    • Hat keinen brauchbaren Texteditor ;)

Im Ernst: Gehört eine solche Liste überhaupt in einen enzyklopädischen Artikel? Ich meine: Nein.
-- Tuxman 15:51, 19. Jun. 2010 (CEST)Beantworten

Siehe oben, ich will doch auch gar nicht, dass diese Liste ihren Weg in den Artikel findet. Sie soll nur als Grundlage für einen überarbeiteten Abschnitt "Vor- und Nachteile" dienen und dient nur der Sammlung für Punkten für ebendiesen. -- Snuffels 16:48, 19. Jun. 2010 (CEST)Beantworten

Eben: Gehört ein solcher Abschnitt denn überhaupt in den Artikel?
-- Tuxman 17:18, 19. Jun. 2010 (CEST)Beantworten
Nuja, Texteditoren gibts wie Sand am Meer. Da machts doch Sinn, die größten Unterschiede (sowohl positive als auch negative) nochmal herauszustellen. Und man sollte nicht vergessen, dass Emacs durchaus gerne entzweit und oftmals entweder geliebt oder gehasst wird. Für beide Standpunkte gibts Gründe, aber so große Meinungsverschiedenheiten gibts bei keinem anderen mir bekannten Editor (nicht mal beim Vim :-)). Von daher würd ich durchaus sagen, dass ein solcher (neutral gehaltener) Abschnitt hier Sinn machen würde. --Snuffels 12:04, 20. Jun. 2010 (CEST)Beantworten
Ich oute mich auch mal als Emacsnutzer der das Teil nicht nur zum Texte editieren und LaTeX-Schreiben, sondern auch für Dateiverwaltung, Mail, News, Literaturverwaltung, jabber, Tagesplanung, IRC, teilweise Webbrowsing, als shell und zum Musikhören verwendet. Nur damit keine Zweifel an meiner Neutralität aufkommen... ;-) Trotzdem muß ich sagen, daß ich diese Listen problematisch finde, weil das teilweise eine Perspektivfrage ist. Ich greife nur zwei Punkte aus der Negativliste heraus: 1. Zur Standard-Tastenbelegung: Das scheint mir zu kurz gedacht zu sein. Als Emacs-Nutzer argumentiere ich, daß man sinnvollerweise sowieso jede Art von Textbearbeitung im selben Editor durchführt - daher ist die Standardtastenbelegung anderer Programme irrelevant, weil man der optimalerweise ausweichen kann. 2. Zur Größe: Das ist wohl bei keinem durchschnittlichen Desktop-Rechner, der heute genutzt wird ein wirkliches Problem. Mein Firefox ist um einiges ressourcenhungriger als der viel vielfältiger genutzte Emacs. Wie gesagt, man muß diese Ansicht nicht teilen, aber gerade die Standardtastenbelegung scheint mir ein schlechter Kritikpunkt zu sein, weil die von vielen in der Community ja gerade als Vorteil von Emacs empfunden und teilweise im usenet oder sonstwo energisch verteidigt wird. Ein "allgemeingültiger" Kritikpunkt ist das also nicht. --Sarwrik 21:00, 6. Jul. 2010 (CEST)Beantworten
"Jede Art von Textbearbeitung" wohl kaum, Emacs kann kein WYSIWYG. ;-) Ansonsten gilt 1. doch auch für jeden anderen Texteditor?
-- Tuxman 22:17, 6. Jul. 2010 (CEST)Beantworten
Wieso kann Emacs kein WYSIWYG? AucTeX/Preview-LaTeX kommt dem schon sehr nahe. Wenn Du das wordmäßige Darstellen des Layouts des Textes meint, bleibt fraglich, ob das überhaupt zur Textbearbeitung gehört - an sich nicht, wie ich finde, aber auch das ist eine Glaubensfrage. Und zu Punkt zwei: Ja, im Prinzip gilt das auch für jeden anderen Texteditor. Ich halte es für ganz natürlich, das die Leute einen Editor, den sie gut beherrschen, so oft wie möglich einsetzen - auch viele Vim-User lassen ja Vim von ihrem Mailclient bzw. Newsreader aufrufen um dann den Nachrichtentext im Vim zu schreiben, u.ä. - für Emacs gilt das vielleicht lediglich aus zwei Gründen besonders - 1. (für uns besonders interessant) - hier ist der Emacs-Artikel, 2. Viele solcher Anwendungen sind ja selbst schon in Emacs Lisp geschrieben und werden im Emacs ausgeführt, weswegen Emacs seltener von anderen Anwendungen aufgerufen werden muß, was aber über z.B. emacsclient auch sehr gut geht. --Sarwrik 22:32, 6. Jul. 2010 (CEST)Beantworten
LateX ist und bleibt WYSIWYM und wird auch in Emacs nie WYSIWYG "nahe kommen". ;-)
WYSIWYM-Textverarbeitung kann ich mit jedem Texteditor dieses Planeten durchführen, von Notepad bis Vim; und lassen wir Emacs als furchtbaren Texteditor gelten (noch mal: warum nicht IDE?), dann ist das kein Alleinstellungsmerkmal mehr. Dank It's all text!, External editor und ähnlichen Firefox-, Thunderbird- und sonstwas-Erweiterungen kann heutzutage auch jeder Hansfranz, wenn nötig, seine komplette Korrespondenz über einen Texteditor seiner Wahl (inkl. Notepad) durchführen. Wieso also ist die Möglichkeit, dass du in einem Texteditor Texte aller Art verfassen kannst, im Emacs-Artikel eher zu erwähnen als in allen anderen Editorartikeln?
-- Tuxman 03:34, 7. Jul. 2010 (CEST)Beantworten
Hallo Tuxman, mir scheinen so Sachen wie inline-Formel-Rendering aber etwas über das "it's all text" hinauszugehen. Außerdem hatte ich in meinem Beitrag davor ja selbst geschrieben, daß man de facto auch alle anderen Texteditoren etwa zur Bearbeitung von Mail und News nutzen kann, sofern der entsprechende Client externe Editoren aufrufen kann (obwohl die meisten anderen Editoren vermutlich keinen eigenden Mail/News-Client implementiert haben). Sei dem, wie es sei, ich glaube, Du hast meine Intention nicht ganz verstanden. Meine Argumentation ging ja nicht darauf, das alles in den Artikel zu schreiben. Da hättest Du nun natürlich recht: Die Tatsache, daß man mit dem Emacs im Prinzip jede Form von Plain-Text-Dateien bearbeiten kann, gilt analog für alle anderen Editoren auch, auch wenn die vielleicht in vielen Fällen nicht über so komfortable Modes dafür verfügen. Das ist trivial und verdient keine Erwähnung im Artikel. Mir ging es um den Punkt auf der Negativliste bzgl. der für die heutige Zeit etwas unkonventionellen Tastenbelegung. Der relativiert sich ja in dem Maße, wie Emacs für Arbeiten aller Art herangezogen wird. Es ist ja offensichtlich, daß jemand, je mehr Zeit er im Emacs verbringt, desto weniger Zeit andere Software nutzt. Nun kommt es natürlich auf das konkrete Nutzungsschema des Rechners an, aber wenn jemand den Rechner hauptsächlich für die Bearbeitung von Texten nutzt und dafür den Emacs verwendet, dann nimmt sich die Differenz zwischen Emacs-Tastenbindungen und CUA-Tastenbindungen nicht so bedrohlich aus.
Mein Punkt war also, daß die Emacs-Tastenbindungen kein Punkt für eine Negativliste sind. Ich finde, man muß sozusagen absolute und relative Kritikpunkte unterscheiden. Ein absoluter Kritikpunkt an einem Editor wäre z.B. "unterstützt kein UTF-8" (was auf Emacs natürlich nicht zutrifft), was im Jahre 2010 einfach anachronistisch ist. Klar, streiten kann man über alles, aber wir wollen keine Haare spalten. Ein relativer Kritikpunkt wäre eben die Sache mit den Tastenbindungen, weil derselbe Sachverhalt hier von den einen als Vorteil, von den anderen als Nachteil angesehen wird. Daher sollte dieser Kritikpunkt nicht auf einer Liste, sondern im Fließtext vorkommen. Ich würde das ungefähr so formulieren: "Kritiker, verweisen auf eine vergleichbare Handhabung der meisten heute im Desktopbereich eingesetzten Programme. So finden sich für viele elementare Funktionen (z.B. Ausschneiden, Kopieren oder Einfügen) standardisierte Tastenkombinationen, während der Emacs in der Standardkonfiguration von diesen Tastenbelegungen teils drastisch abweicht. Daher sei der Nutzer oft gezwungen, zwei ganz unterschiedliche Bedienkonzepte zu verinnerlichen." Oder sowas halt. Zur IDE-Problematik: Auch IDE scheint mir nicht passend zu sein, weil Emacs sich eben nicht nur auf die Softwareentwicklung beschränkt. Sachen wie Mail/News-Client, Webbrowser, IRC-Clients, Jabber-Client sind im allgemeinen ja nicht Bestandteil einer IDE. Ich finde auch den Begriff "Editor" etwas zu eingeschränkt, aber mir fällt kein besserer ein. Irgendwer hat Emacs mal eine LISP-basierte RAD-Umgebung zur Entwicklung von Spezialeditoren genannt, was mit gut gefällt, aber "irgendwer" ist natürlich keine sehr belastbare Quelle... --Sarwrik 13:59, 7. Jul. 2010 (CEST)Beantworten
Eigentlich entwickelst du ja mit einem Editor keine Editoren... RAD-Umgebung wäre doch ebenfalls zu eingeschränkt. Bei Emacs geht es ja nicht nur um das Editieren.
-- Tuxman 23:24, 7. Jul. 2010 (CEST)Beantworten

Ok, ich melde mich mal selbst zu Wort, weil ich diesen Artikel "Vor- und Nachteile" vor einiger Zeit verbrochen habe. Beim Editor "vim" fand sich ein solcher Abschnitt, beim Emacs fehlte er. Leider muss ich sagen, dass ich diese Diskussion hier nur teilweise für ergiebig halte, da sie die Neutralität des Artikels zum Thema hat und selbst in vielen Punkten alles Andere als neutral verläuft, zumal hier anscheinend-- wenn auch mehr oder weniger verschleiert -- mal wieder vim- und Emacs-Welten aufeinanderprallen. Zur Liste: Mir ist nicht klar, inwiefern hier die Neutralität gewährleistet ist. Allein der Punkt "nicht einsteigerfreundlich". Wenn das keine rein subjektive Wertung ist! Zum Satz "die größten Vorteile des Editors sind sein konsequent durchdachtes Konzept ...". Natürlich würde diesen Satz kein Kritiker stehen lassen. Es gibt allerdings gerade im Zusammenhang mit diesem Editor eine ganze Reihe Kritiker, die ihre Aufgabe darin sehen, nur zu kritisieren, ohne sich mit der Zielsetzung der Entwickler auseinander zu setzen. Es ist ein Faktum, dass das Konzept wohldurchdacht ist. Ob es einem gefällt ist eine andere Sache. Sicherlich ist es besser, den Superlativ zu entfernen und stattdessen vielleicht eine Änderung im Sinne von "als Vorteil des Editors kann angesehen werden ..." zu ersetzen. Und der Abschnitt "Entscheidend ist, dass sämtliche Belegungen geändert werden können ... usw." ist nicht der Ausdruck meiner Meinung, sondern als Hinweis auf den eigentlichen Sinn des Editors, den Editor für jede Art von Text optimieren zu können. Ich stimme Aschmidt vollkommen zu, dass ein wirklicher Emacs-Nutzer den Text neu schreiben sollte. Ich hoffe ich fahre auch niemandem mit der Bemerkung gegen den Schlitten, wenn ich mich frage, ob es sinnvoll ist, wenn sich Autoren, die Emacs nichts abgewinnen können oder User, die seit längerer Zeit nicht mehr mit Emacs gearbeitet haben (weil das erste und letzte Mal verhältnismäßig weit zurückliegt), sich an diesem Artikel beteiligen. Es wäre gut, wenn es jemand wäre, der Emacs gegenüber neutral aufgeschlossen ist und eine Vielzahl von Editoren kennt, so wie es Aschmidt auch schon sagte. Ich selbst nutze Emacs jeden Tag mehrere Stunden, neben vim. Betrachte mich aber weder als Experten (wann darf man sich bei Emacs als ein solcher bezeichnen?) noch als Fan irgendeines Produkts. Ich hoffe, wir finden einen Weg, den Artikel zu optimieren. Wenn Ihr der Meinung seid, er soll verschwinden -- na, dann ist das eben so. Ob das der Sache dient, ist eine andere Sache ;-). Wichtig ist, dass es gut wird. Davon sind wir wohl noch ziemlich weit entfernt.--Heiko Schröder 22:56, 6. Jan. 2011 (CET)Beantworten

Grundsätzlich sollten Diskussionen hier nie neutral verlaufen, sondern dazu dienen, dass man versucht, aus seinen eigenen Standpunkten einen Konsens zu formen. Deswegen ist es gut, dass es Diskussionsseiten hier überhaupt gibt. Wenn man indes Vor- und Nachteile aufzählt, muss man immer auch das Vergleichsobjekt benennen, und da hapert es bisher...
-- Tuxman 05:45, 7. Jan. 2011 (CET)Beantworten
Gut, dem ersten Punkt stimme ich grundsätzlich zu und es ist natürlich sehr gut, dass es solche Boards gibt. Aber wir sollten auch sehen, dass sich diese Diskussion bereits lange hinzieht, ohne dass sich Ansätze zu einem Konsens erkennen lassen (vielleicht könnt Ihr einen erkennen; ich nicht). Und das liegt möglicherweise gerade an dem zweiten Punkt, dem ich wirklich nicht zustimmen kann. Im Gegenteil! Ich halte es für den größten Fehler, Emacs mit überhaupt irgendetwas Anderem zu vergleichen, das nicht die gleiche Zielsetzung verfolgt. Emacs ist kein Editor, sondern eine Toolbox, um optimal ein Produkt für eine spezifische Textaufgabe zu erstellen, wofür auch immer. Ich verstehe vor diesem Hintergrund nicht, wieso immer wieder die vom *Standard* abweichenden Tastaturbelegungen ins Feld geführt werden. Was Emacs mitbringt ist ein Vorschlag, weiter nichts. Obwohl ich wirklich für jeden Quatsch zu haben bin: Jener Satz von Thomer M. Gil, den Ihr alle kennt ... ich weiss nicht, wie es Euch geht. Mir geht das Ding wirklich auf die Nerven. Es ist aus meiner Sicht ganz und gar nicht witzig, sondern absolut hohl. Natürlich fehlt Emacs ein guter Editor, solange der Anwender nicht weiß, was er will. Emacs liefert keine fertigen Werkzeuge, sondern die Möglichkeit, sich eigene Werkzeuge zu bauen. Ich selbst setze vim sehr viel ein und halte ihn für ein Ausnahmeprodukt. Gerade deshalb gehe ich aber jedem Vergleich aus dem Weg. Was soll es bringen, einen Park fertiger Maschinen, die man optimieren kann, mit einem Maschinenpark zu vergleichen, den man sich selbst baut? Nur weil es sich in beiden Fällen um einen Maschinenpark handelt? Der Leser will doch wissen, wofür Emacs gedacht ist, was seine Zielsetzung ist, und ob er sie erfüllt. Vor allem sollten wir uns nicht durch Vergleiche dazu hinreißen lassen, dem Leser die Freiheit zu nehmen, selbst eine Entscheidung zu treffen, was für ihn gut ist. Wer eine Seite besucht, ist ohnehin interessiert an dem Thema und will sich nicht gleich abwimmeln lassen. Vermutungen wie *steile Lernkurve* oder *nicht einsteigerfreundlich*, die auf den Leser gar nicht zutreffen müssen, sollte sich kein Autor einer Enzyklopädie erlauben. Auf andere Editoren sollten wir hinweisen, aber einen Vergleich (der den Leser möglicherweise gar nicht interessiert) vermeiden. Wenn wir diese Vergleiche aber trotzdem ständig in die Diskussion einbringen, kommen wir nicht weiter, meine ich. Gruss --Heiko Schröder 15:36, 8. Jan. 2011 (CET)Beantworten
Meinte ich doch. Aber warum sollte man "auf andere Editoren hinweisen", wenn wir doch eigentlich im Artikel gleichzeitig behaupten wollen, dass Emacs eben kein Editor sei?
-- Tuxman 17:37, 8. Jan. 2011 (CET)Beantworten
Stimmt, das ist obsolet. --Heiko Schröder 21:16, 8. Jan. 2011 (CET)Beantworten

Humor

[Quelltext bearbeiten]

Oh, wie tut das gut mal was humorvolles in Wikipedia zu lesen. Herzlichen Dank! Zabia 18:44, 30. Jul. 2011 (CEST)Beantworten

Vor- und Nachteile entweder komplett überarbeiten oder entfernen

[Quelltext bearbeiten]

Ich möchte erstmal zwei Dinge anmerken:

  1. Ich bin langjähriger Vim- wie Emacs-Nutzer, womit ich meiner Meinung nach eine gewisse Objektivität gewährleisten kann.
  2. Habe ich an besagtem Abschnitt soviel auszusetzen, dass ich hier einen neuen aufmache, anstatt mich hier in der Diskussion bei "Neutralität" einzuklinken und möglicherweise unterzugehen.

Nun Punkt für Punkt:

  • Von einigen Benutzern, die vorher andere Editoren benutzt haben, wird die Vielfalt der Emacs-Modi als wenig überschaubar und der Editor selbst wegen seiner „umständlichen Tastenbindungen“ als schwierig zu erlernen bezeichnet.

Was heißt hier "von einigen Benutzern"? Das Prädikat "Einige Benutzer behaupten <man suche sich irgend einen Irrsinn aus>" kann ich fast immer erfüllen. Und der Teil "vorher andere Editoren benutzt haben" macht die Aussage ohnehin noch schwammiger und in einer Pro- Kontra-Analyse noch obsoleter, da hier überhaupt nicht darauf eingegangen wurde, inwieweit die Umgewöhnung dazu beiträgt. Und auch wenn ich selbst die Default Key Bindings von Emacs für nicht optimal halte, kenne ich genug Leute die damit hervorragend arbeiten können. Zudem existiert mit dem "Emulation-Mode" und Modulen wie zum Beispiel "Evil" ohnehin die Möglichkeit die Tastaturnutzung komplett seinen eigenen Bedürfnissen anzupassen. Sowas hat letztendlich in einer Encyclopädie nichts verloren, oder muss anders formuliert werden.

  • Bisweilen ist zu hören, seine Struktur widerspreche der Unix-Philosophie, nach der ein Tool nur eine ganz bestimmte Aufgabe zu erfüllen hat.

Weil Emacs erstmal ein GNU und kein Unix Tool ist! Und die Unix Philosophie wie auch andere Programmier-Philosophien sind nur Paradigmen. Daraus die Qualität bzw. einen Nachteil bei Abweichung zu implizieren ist Quatsch. Dieser Nachruf Emacs hätte eine Designschwäche, da es sich nicht an "Write programs that do one thing and do it well." hält ist Hahnebüchen und kursiert so krmapfhaft im Netz, dass es einfach nicht totzukriegen ist. Viele verstehen diese Prinzipien als absolut, was jedoch nicht die Intention der Erfinder ist. Das sieht man schon daran, dass ich verlangen kann, dass eine Aufgabe darin besteht einen erweiterbaren Texteditor zu schreiben. Und was ist Emacs? Eben genau das, wie es ein und der selbe Wikipedia Artikel in seiner Einleitung beschreibt.

  • Leider wird in diesem Zusammenhang oft nicht gesagt, was unter einem Tool verstanden wird. Die Aufgabe des Emacs ist die Texterstellung und -editierung nicht nur in einer einzigen, genau definierten Situation, sondern in allen nur denkbaren.

Damit löst sich bis hier die Analyse über die Vor- und Nachteile wieder selbst in Luft auf. Hier wird genau das aufgegriffen was ich im letzten Punkt genauer spezifiziert habe. Daher sei einfach nochmal gesagt, dass die Unix Philosopien Richtlinien und keine Vorgaben sind, deren Nichteinhaltung irgendwelche Integrationsprobleme impliziert. Es steht außerdem nicht nur die Frage im Raum was ein Tool ist, bzw. welche Funktionalität oder Aufgabe als atomar betrachtet werden kann, sondern inwiefern diese Umgesetzt sind. Emacs kann man genauso als ein Kollektiv an Tools sehen die bedingt durch die gemeinsame Nutzung von Lisp zusammenarbeiten. Die Substitution gewisser Punkte in der Unix Philosophie ist nämlich nicht durch sich selbst ausgeschlossen.

  • Die größten Vorteile des Editors sind sein konsequent durchdachtes Konzept

Welches Konzept? Das ist ungenau.

  • seine gute Dokumentation

Ok.

  • Jede Funktionalität wird durch eine einzige Lisp-Funktion bereitgestellt, die eine genau definierte Aufgabe erfüllt.

Hier geht es nun vom Schwammigen ins Falsche über. Per Se ist es eben nicht jede Funktion, wenn ich noch die aus dem C Kern hinzuzähle, mit einer eLisp Schnittstelle geschmückt. Und hier kommen wieder Begriffe wie "Funktionalität" und "genau definiert Aufgabe" vor, die wieder genau zu gleichen Konsens wie oben führen. Was ist hier eine Funktionalität? Eine Lispfunktion, oder ein komplettes Modul? Im Ersteren Fall kann ich eine Lisp Funktion schreiben die mehrere genau definierte Aufgaben (was auch immer das heißen soll) erfüllt (Beispiel map über Funktionen) und im Letzteren sind das alles andere als genau definierte Aufgaben. Zumindest möchte ich sehen wie man zB das Org-Mode-Modul als solche beschreiben kann, ohne den Begriff "genau definiert" in die Länge zu strecken.

  • Diese Funktionalität ist von der Existenz einer Tastenbindung unabhängig.

Eine ziemlich sinnlose Aussage. Diese Funktionalität (und wieder: Was ist hier eine Funktionalität?) ist erstmal ein in eLisp geschriebener Code. Es tut überhaupt nichts zur Sache, ob ich da ein Key Binding dafür habe oder nicht. Und erst recht nicht in einer Vorteil, bzw. Nachteil Diskussion. Jede Funktion in irgendeiner Software ist in ihrer Existenz unabhängig von der (direkten) Ausführung durch irgendeinen Nutzer.

  • die vorhandene Funktionalität zu ändern. Die möglichen Anpassungen können somit erheblich tiefgreifender sein als es eine Skriptsprache erlaubt, mit der nur weitere Funktionalitäten den bereits vorhandenen hinzugefügt werden können.

Als erstes ist auch eLisp eine Scriptsprache, die sich auch zu Emacs-verdaubaren "Bytecode" übersetzen lässt. Und was heißt hier "erheblich tiefgreifender"? Und überhaupt ist diese Darstellung bzw. Aussage, dass man mit eLisp Funktionalitäten ändern kann, während Skriptsprachen (eLisp ist ebenfalls eine Skriptsprache!) hier nur "hinzufügen" können ziemlicher Schwachsinn. Es liegt nicht an der Natur von Lisp (ok ein bisschen da funktional und prozedural) und anderen Sprachen, sondern daran, dass Emacs nur im Kern C nutzt und möglichst viel in eLisp auslagert. Zudem werden so viele Sprachbindungen von C zu eLisp wie möglich gemacht, um eben diese Flexibilität zu gewährleisten. Und das ist alles manuelle Arbeit und liegt nicht etwa daran, dass Lisp verwendet wird. Genauso könnte ich theoretisch Emacs mit Python als Skriptsprache rausbringen und mit genügend Zeit die gleichen Möglichkeiten bereitstellen.

  • Da die Aufgaben der Texterstellung so vielfältig sind wie die Individualität der Autoren, darf nicht erwartet werden, dass ohne jede eigene Initiative für jede spezifische Frage eine Antwort bereits zur Verfügung steht. Dennoch ist die Zahl der fertigen Lösungen, die „out of the box“ abrufbar sind, derart überwältigend, dass ein Erlernen von Emacs Lisp zunächst nicht unbedingt erforderlich ist.

Das kann man wesentlich kürzer und weniger geschwollen fassen: Die große Anzahl an Emacs Modulen, auch die Dritter, deckt die meißten typischen Anforderungen an Texteditoren ab, sodass das Erstellen bzw. Bearbeiten von eLisp Code in der Regel nicht nötig ist.

  • leistungsfähigen Sprache aber sehr schnell aus

Mit "leistungsfähiger Sprache" wäre ich mal vorsichtig. Wenn hier der Begriff "Sprache" hergenommen wird, muss auch die komplette Lisp Familie in Betrachtung gezogen werden und da ist eLisp eher klein. Da müsste eher Konfigurationssprache stehen.

  • (wobei in diesem Zusammenhang auch ein Blick auf Scheme zu empfehlen ist, mit dem neue Funktionen für zukünftige Emacs-Versionen programmiert werden sollen).

Bitte was? Quelle? Ja es gibt Experimente, dabei handelt es sich aber um private Forks, die mit alternativen Interpretern arbeiten. Da wäre zum Beispiel Guile (Scheme) zu nennen, oder GCL (Common Lisp). Aber für einen geplanten Ersatz ist man da meines Wissens nach noch lange nicht bereit. Auf planetemacson ist ein Blogeintrag über einen Versuch mit CL der soweit ich weiß damit abschloss, dass eLisp für seine Zwecke komplett ausreichend ist. Und ich möchte mich hier nicht als eLisp Zealot darstellen. Über CL oder Scheme als Interpreter wäre ich ebenfalls sehr interessiert. Vor allem da deren Implementierungen wesentlich performanter laufen sollen.

  • Die vordefinierten Tastenbindungen erfordern für manche Benutzer, die mit anderen Editoren vertraut sind, eine gewisse Überwindung.

Wiederholung von oben. Und wie oben beschrieben auch nicht hier hineinpassend. Zumindest in dieser Form nicht. Vor allem das Wort Überwindung passt hier nicht. Klingt so als würden Neulinge von Emacs unter Brechreiz leiden. Der Begriff Einarbeitungsphase wäre hier passender.

  • Zwar kann der Emacs auch über Menüs mit der Maus bedient werden, aber eine erhebliche Steigerung der Produktivität, die weit über die meisten grafischen Editoren hinausgeht, erfordert den Einsatz von Tastaturkürzeln

Das hat eher etwas in einer Diskussion "Mousedriven vs Keyboarddriven" zu suchen aber nicht hier.

  • von denen die vordefinierten ebenfalls sehr gut durchdacht sind

Was jetzt? Sind die Tastenkürzel nun umständlich oder gut durchdacht? Und wer sagt, dass die gut durchdacht sind? Der Autor?

  • Sie können allerdings nicht jede individuelle Erwartung von dem, was der Einzelne als angenehm bezeichnet, zufriedenstellen. Entscheidend ist, dass sämtliche Belegungen beliebig geändert werden können und die Zahl der möglichen Tastenkombinationen nicht begrenzt ist.

Ja, und nun? Der Satz höhrt mitten in einer (mutmaßlich beabsichtigten) Aussage auf. Der Entscheidende Punkt wird aufgezählt und wie schneidet Emacs hier nun ab?

  • In Emacs wird eine Suche mit der Tastenkombination „C-s“ gestartet. Das zugehörige Steuerzeichen <CTRL>S wurde aber auch von vielen seriellen Terminals zur Datenflusssteuerung zum Rechner verschickt. Das führte in den 1980er Jahren dazu, dass eine der am häufigsten zum Emacs zu findenden Problem-Meldungen eine anscheinend selbsttätig angefangene Suche beschrieb.

In einer allgemeinen Pro- Kontra Analyse beim Emacs ist sowas Erbsenzählerei. Keybind Collissions sind sowas typisches, dass das hier eigentlich raus kann.


Die Aufzählung von Pro und Kontra lässt sich wesentlich kürzer und präziser fassen. Die Liste im Diskussionsabschnitt "Neutralität" ist nur teilweise brauchbar. Dort findet nämlich auch schon gewisser Vandalismus statt. Ich greife mal folgende Punkte auf, wobei ich in einzelnen Punkten Verbesserungsvorschläge hätte:

Vorteile:

  • Viele Erweiterungen, auch durch Dritte
  • Unterstützung für sehr viele Sprachen, zum Beispiel in Form von Syntax Highlighting
  • Umfangreiches Hilfe-System
  • Daemon-Mode (Anmerkung: Ist in der Tat etwas, was gegenüber anderen Editoren heraussticht)
  • Für sehr viele verschiedene Plattformen verfügbar
  • Aktive Community (Besser: Aktive Entwicklung und große Nutzerzahl, dh. großer Beitrag durch Dritte)

Nachteile:

  • Nicht einsteigerfreundlich (Besser: Relativ große Einarbeitungsphase, bedingt durch Komplexität)
  • Wird oft als überladen bezeichnet (Besser: Durch eLisp Interpreter und einer großen Anzahl mitgelieferter Module für einen Editor relativ umfangreich)
  • Standard-Tastenbelegung weicht ... (Besser: Quatsch. Es gibt genug Programme die die Emacs'schen Tastenkombis übernommen haben. Wer den Firefox nutzt soll doch einfach mal ins Menü schauen)
  • Zum Einstellen/Verändern/Erweitern vieler Dinge werden LISP-Kentnisse benötigt (Frage: Ein Nachteil?)

Letzten Endes ist noch die Frage ob man den Abschnitt "Vor- und Nachteile" nicht zu "Besonderheiten/Eigenschaften" umbenennt, da viele der obigen Punkte in der Liste und auch ein paar meiner Zerpflückung des bisherigen Abschnitts letzten Endes eher Standpunkte individueller Natur sind. Ich werde bei Zeit hier einen eigenen Text vorschlagen, warte jedoch bis dahin noch die Meinung Anderer ab. Nichtsdestotrotz gehört der Abschnitt "Vor- und Nachteile" dringend überarbeitet.

-- Kerobirum 17:06, 14. Feb. 2012 (CET)Beantworten

da gebe ich dir hundertprozentig Recht, so kann der Abschnitt nicht bleiben. Hoffe, du findest bald Zeit dazu... --Herbert Klaeren (Diskussion) 14:29, 13. Jul. 2012 (CEST)Beantworten


Warum nicht in Deutsch?

[Quelltext bearbeiten]

Anzuregen wäre auch, daß der deutschsprachige Wikipedia-Artikel etwas darüber aussagt, warum es auch nach Jahrzehnten noch keine deutschsprachige Version des emacs gibt. Hella, Mai 2013 (nicht signierter Beitrag von 79.206.204.191 (Diskussion) 18:59, 29. Mai 2013 (CEST))Beantworten

[Quelltext bearbeiten]

Das sind bei weitem zu viele Links - siehe WP:WEB :

Die goldene Regel der Wikipedia zum Thema Weblinks ist: Bitte sparsam und vom Feinsten. Nimm nicht irgendwelche Links zum Thema, sondern wähle das Beste und Sachbezogenste aus, was im Netz zu finden ist. Fünf externe Links sollten in der Regel zu einem Thema genügen (Belege und Einzelnachweise ausgenommen), im Zweifel lieber einer weniger.

--Anachron (Diskussion) 17:12, 12. Feb. 2014 (CET)Beantworten

Heutige Rolle

[Quelltext bearbeiten]

Obwohl Emacs in der Presse immer wieder als "aktivstes und populärstes" GNU-Projekt bezeichnet wird, ist davon meiner Meinung nach aktuell sehr wenig zu spüren. Vielleicht sollte man in den Artikel hinein schreiben, wie die aktuelle Rolle aussieht, und warum Emacs historisch so wichtig war für die Organisation GNU.

R.Stallman hat vor einigen Monaten den Wunsch geäußert, man solle Emacs in ein WYSIWYG-Tool umarbeiten, was nach Auskunft zumindest eines Reporters auf nicht wahrnehmbaren Applaus von Seiten der Zuhörer stieß.

Anekdotisch könnte man erwähnen, dass die Emacs-Variante MicroEmacs hauptsächlich deswegen entstand, weil damalige Computer nicht genug Speicher hatten, um das Original vollständig zu laden, das zu dem Zeitpunkt bereits weit über 10MB groß war. Scherzhaft wurde davon gesprochen, es handele sich nicht um einen Editor, sondern um ein Betriebssystem. --2A02:908:EB20:0:90C1:D4B8:B58B:924E 09:35, 16. Nov. 2014 (CET)Beantworten