Diskussion:Emacs

message: 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)
replies: text: 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)
replies: text:  Der letzte Link ist jetzt unter http://www.finseth.com/emacs.html zu finden. --H3xc0d3r (Diskussion) 16:19, 27. Apr. 2013 (CEST)

text: 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)
thread_title: Entwickler Stallman?

message: 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)
replies: text: 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)
thread_title: Vermisste Screenshots?

message: 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)
thread_title:  Emacs-Witze 

message: 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)
replies: text: 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)
thread_title:  Der erste Satz 

message: 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 (Diskussion • Beiträ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)
replies: text: English Tags like Image:... work on all Wiikpedias --Oms 20:36, 18. Jul. 2007 (CEST)
thread_title:  Emacs Wikipedia mode 

message: 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)
thread_title:  Kaffee-Anekdote 

message: 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)
replies: text: 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)
replies: text: Hm, ok, dann ziehe ich meine These erstmal zurück.--Briks 22:05, 13. Mär. 2007 (CET)

text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Mythos Emacs 

message: 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)
replies: text: 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)
thread_title:  Lemmaklärung *Emacs 

message: 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)
replies: text: Es gibt bereits die Artikel Puffer (Informatik) und Fenster (Computer). War das gemeint? --91.32.100.149 23:10, 8. Sep. 2009 (CEST)
replies: text:  Nein, wohl eher im Zusammenhang, was man bei Emacs darunter versteht, siehe auch die verlinkte Zeichnung. --Snuffels 23:40, 8. Sep. 2009 (CEST)
replies: text:  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)
replies: text:  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)
replies: text:  Und wie willst du das trennen?-- Tuxman 17:30, 9. Sep. 2009 (CEST)
replies: text:  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)
replies: text:  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)
replies: text:  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)

text:  @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)
replies: text:  Richtig, das steht aber bereits im Artikel.-- Tuxman 17:34, 10. Sep. 2009 (CEST)

text: 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)
thread_title:  Abschnitt "Terminologie"? 

message: 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)
replies: text:  Ja. Die Änderung war gut. :)-- Tuxman 07:54, 17. Feb. 2010 (CET)
thread_title:  Frühkindliche Prägungen 

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

message: Ich möchte erstmal zwei Dinge anmerken: 
# Ich bin langjähriger Vim- wie Emacs-Nutzer, womit ich meiner Meinung nach eine gewisse Objektivität gewährleisten kann.
# 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)
replies: text: 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)
thread_title:  Vor- und Nachteile entweder komplett überarbeiten oder entfernen 

message: 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)
thread_title: Warum nicht in Deutsch?

message: 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)
thread_title:  Weblinks überarbeiten 

message: 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)
thread_title:  Heutige Rolle