Differences between revisions 19 and 53 (spanning 34 versions)
Revision 19 as of 2003-09-20 07:26:17
Size: 9333
Editor: h24-70-69-26
Comment:
Revision 53 as of 2013-04-20 11:12:02
Size: 5925
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
EMACS and vi used to be the most popular families of text editors. There are several implementations of each. = Emacs vs. Vi =
Line 3: Line 3:
The user interface of EMACS is mostly modeless. The user interface of
vi traditionally has a '''command mode''' and an '''insert mode'''. Each
character has a different meaning depending on which mode '''vi''' is in.
Commands in EMACS are traditionally given by modifier keys like {{{Ctrl}}},
{{{Alt}}} and so on.
Both of these editors support many fundamental virtues of text editors such as extensive syntax highlighting, collapsible functions, spell checking, macros, undo-redo, multiple document editing, and a large support community. They are both free, Open Source, mature and well developed pieces of software. But...while both [[EmacsEditor|Emacs]] and [[Vim|Vim]] are considered powerful text editors, both capable of providing many of the same feature lists for general editing commands, the primary difference between these editors is the fundamental philosophy behind their design, and more to the point, the types of workflow that they were originally designed to handle. A search online for "philosecurity ninja or pirate" will produce a fun read on Vi creator Bill Joy and Emacs creator Richard Stallman. Because of the major design differences between these editors, emac/xemac extensions to emulate vi and vim are readily available online. For those more interested in personal versatility and combining the best attributes of both editors, there is information provided at the bottom of this wiki under the heading "More Tips".
Line 9: Line 5:
In earlier times EMACS became ''famous'' for its size and memory consumption
(EMACS = Eight Megabytes And Constantly Swapping ;) ). With today's computers this
is no longer a problem.
At first, Vi (and its popular variant [[Vim|Vim]]) were considered mere small text editors built for speed with their focus on editing text quickly, but as they've matured have become considered to be on par with emacs/xemacs. Ultimately, these editors may have different pros and cons depending primarily on your style and workflow needs. For instance, "Vi" and [[Vim|Vim]] starts much faster than [[EmacsEditor|Emacs]] and their usual workflow assumes that you often will both enter through and exit from them alone. [[Vim|Vim]] has matured to using a tabbed interface which can be used to edit multiple files very quickly, while [[EmacsEditor|Emacs]] are based more on the assumption that you'll be working in one spot for a more extended period of time.
Line 13: Line 7:
Good Python language support is available for both editors, and modern implementations such as GnuEmacs and ViImproved are extensible in Python. Historically, among sysadmins, ''vi''/''vim'' has tended to be the preferred software, while ''emacs''/''xemacs'' has tended to be favored more by programmers. This is not very surprising when you compare the typical editing needs of sysadmins v/s programmers to the relative merits of the two different editors. For a VERY detailed explanation of why this has been the case and the pros and cons of each editor, visit [[http://devopsanywhere.blogspot.com/2011/11/emacs-for-sysadmins.html|Emacs for Sysadmins]]
Line 15: Line 9:
Which editor suits your personal needs better is a matter of taste.
Since both are OpenSource, free and mature, try both and choose one. :)
Commonly, systems administrators are working on many different machines, in varying states of installation, configuration and repair. They are making relatively quick edits to many different files. An editor with a quick load time, blazing keyboard efficiency (with the right expertise) and few library or other dependencies is essential. Preferably it will be the editor that virtually every version of UNIX includes by default. It is even, occasionally, handy that the editor be able to fall back on an old fashioned line editing mode when even the terminal emulation subsystem is non-functional.
Line 18: Line 11:
It should be noted that one can have the BestOfBothWorlds by running ViperMode in EMACS. Simply run meta-x "viper-mode", and blammo, you get vi keybindings. EMACS is a wonderful operating sytem. Now it has a decent editor... :)
Line 20: Line 12:
----
'''Discussion:'''
Programmers, on the other hand, tend to work extensively on large complex sets of related files. However they tend to have all of them located on one single machine (usually checked out of a version control system ''en masse''). For programmers the overhead of starting a larger, slower, more complex editor is amortized over their usage. They may have the same instance of the editor up for weeks or months at a time, closing and opening buffers as necessary. Having an editor support a full programming language internally is important to many programmers, as they need IDE (integrated development environment) features and tools like ''ediff'' and ''emerge'' (for comparing and merging different versions of a file, for example).
Line 23: Line 14:
Emacs has evolved into an application framework. I see many simple applications turning into application frameworks: Emacs, Netbeans, Mozilla! When I see this happen I think those project must have really lacked strategic management...
Line 25: Line 15:
Software makers need to realize the importance of management and strategic management. If you are going to make software that you want to see being used and improving after 5+ years, you need to sit down and read about strategic management, set a vision for your project, a mission, objectives and goals.
Else you will start by building a text editor and end up with one of the worst application frameworks available. Emacs is just another software project that lacked a clear good and sound vision and mission. And that is why I think we should all use Vim, because Vim knows what it is (mission), and what it wants to be (vision).
Of course this generalization can fail us. Many programmers started as, or spent stints as systems administrators and developed a preference for ''vi'' over ''emacs.'' A modern version of ''vim'' can support almost any of the features one would expect of ''emacs.'' (''including'' a full programming language [python] available for use in vim, but it tends to be less integrated and feel less natural for programming editing than Elisp). In contrast, many people feel uncomfortable with ''vi's'' notorious "modal" paradigm. They never become accustomed to "command" vs. "insert" or "replace" modes and often consider the very notion to be atavistic.
Line 28: Line 17:
  Emacs was pretty much always ''intended'' to be an applications framework. Its macro language is a full-featured programming language (Lisp), so you can build anything with it. It's also far more customizable than vi and clones, and has features that make it a full-fledged IDE. You can extend it with Lisp and now with Python (see pymacs).
----
''Emacs is just another software project that lacked a clear good and sound vision and mission and that is why I think we should all use Vim, because Vim knows what it is (mission), and what it wants to be (vision)''
Line 32: Line 18:
You seem to make a number of different points: you claim that a vision/mission is needed for a software project to be used and improved after 5+ years. Python doesn't have a real mission/vision. It's still in use, after 12 years. According to you Emacs doesn't have a mission either. It's still being used and improved after ca. 25 years. Helpful Tips:
Line 34: Line 20:
I'm not sure if Emacs is one of the worst application frameworks available, I've never developed any substantial programs, but I like it for (extensive) customization. Why do you claim Emacs is a bad application framework?
----
''Python doesn't have a real mission/vision''
 * With emacs/xemacs one can access the vi keybindings use the command: '''M-x viper''' (That's [Alt]+[x]viper[Enter] or [Esc][x]viper[Enter] --- either should work, but the latter will work on terminals/keyboards that don't have an [Alt] key).
 * To emulate vim features such as visual selection and text objects, the extensible vi layer "[[http://emacswiki.org/emacs/Evil|Evil]]" is available on emacswiki.org.
 * In ''vim'' use the ''ex''-mode command ''':syntax on''' to enable syntax highlighting (which is often configured to be off by default).
 * To learn the basics of ''vim'' very quickly run the command ''vimtutor'' (it's a set of macro files that run in ''vim'' and teach one how to use it).
 * To learn the rudiments of ''emacs'' use: '''C-h, t''' (from inside the editor of course). (That's [Ctrl]+[h] and then [t]). This will start the tutorial system that's written in emacs' "elisp" version of the Lisp programming language.
Line 38: Line 26:
Then it should. Maybe that would help the developers understand more where Python wants to go, what it wants to be. Visions, missions and goals should not be too rigid; they can change over time and from time to time.
Line 40: Line 27:
Remember this famous quote: "Plans are nothing; Planning is everything." -Dwight D. Eisenhower Ultimately the choice of a text editor is a highly personal one, so flame wars on the topic of vi vs. emacs are very common and often considered rather frivolous, but what's important is that you find what works best for you. Try them for yourself, and perhaps take Bryan Berry's advice to heart, "Using vi is like being in a relationship, you are involved. Using Emacs is like a marriage, you are committed, in large part because there is so much to learn."
Line 42: Line 29:
The motive behind having a Vision and Mission, is to provide a basis for the planning of the projects and a basis to decide on goals and objectives. The vision is sometimes viewed as the project/organization dream and the mission is the project purpose or reason to exist, objectives and goals are more specific and more short term.

Planning for a project is serious issues. Don't think "hey, after 12 years without a mission we are still here! so why do we need one?"
Yes, lucky we are! others are not.

Ask "12 years from now, where would we want to be?" and make that your mission.

I think Guido Van Rossum always has a vision and a mission, but he never explicitly said it, like when he says he wants python to be used in education, or to be the best programming languages for education. This implies his vision, and according to python, explicit is better then implicit! So why not make a vision statement?

All those statements should not be taken lightly they can be used to construct a vision and a mission
and most developers interested in improving python should have em in mind! And I think most of them already do, they just don't know what to call it!
I see lots of programming problems being solved are technical issues, when all they need is few lessons from the management schools. And many projects fail.

You could be right, a good product sells itself! You won't be the only one who believes so. A few planning statements definitely won't slow the progress of any project.

As for Emacs, maybe I used the wrong word to describe it, I should have used application platform! Have you seen any application that uses Emacs, ERC for example? What advantages does it have?! Nothing. Apps done for Gnome/Kde look better, feel better, and it's easier to switch between apps on Gnome/KDE.

I read somewhere a really nice comment on Emacs vs Vim: most ppl who uses Emacs don't use the shortcuts or the overwhelming features. In vim you would use and learn most of it features, probably because they're easier to reach for. {{{zz}}} is my friend! {{{:set linebreak}}}, {{{:set nu}}}... I won't even try to look how those can be done in Emacs, they are too easy to do in Vim. I can open x-chat, k-mail, Vim, Eclipse...all in Kde and switch between em using Alt-Tab. I don't need them in my text editor.

Where is Emacs after 25 years? Well, it definitly doesn't look like 25 worth of work! Is it because it didn't have a Vision and a Mission? No... because I bet RMS had something in mind he never explictly said, and not one was able to discuss that with him, because no one can read your mind!

So I am not saying a Vision or a Mission as an end, but a mean to a better end! I hope my vision is clearer this time.
Line 67: Line 32:
I find a statement of vision very helpful. I imagine that I can feel the difference between a project with a single, direct, explicit, forceful vision and one that rather evolved over time, with individual components shaped by people with different visions. Vision-based software seems like forceful prose: self-consistent, cleanly structured, and without needless duplication of parts. It seems to have been built by a single person. [http://www.perforce.com/ Perforce] is software with a vision. Emacs clearly evolved. Python is somewhere in-between.

Python is intended to be a powerful, dynamic, easy-to-use, real-world programming language. That's the team's vision for it since at least 1994 or so, possibly earlier. And it is explicit.

There's also a "near-sighted vision" for the design of Python's individual features, within the larger far-sighted vision of being a programming language. Type {{{import this}}} sometime.

(By the way: I use Emacs, not vi, mainly because I learned Emacs first.)

----

Hello, may i interrupt you two?

"I read somewhere a really nice comment on Emacs vs Vim: most ppl who uses Emacs don't use the shortcuts or the overwhelming features."

The same can be said of Vi, though it is a pretty powerful and featureful app, most people tend to use just a few navigation and edition commands. That's because a) most people don't have the time/desire to learn all the features; b) if the standard basic commands get the job done, that's it for most people. Why do you think many people on M$ Windoze are used to build complex webpages with just the poor cut-and-paste commands from the very featureless Notepad - even though much powerfull editors are available for the platform to increase productivity, such as GNU Emacs itself?

Anyway, Emacs is my favorite software of all time by a large margin. I think the fact that it is actually a Lisp VM says very clearly its main goal: to be a platform in itself. But you're wrong to guess it doesn't have a mission or vision, when it clearly has one: it's still pretty focused on being a tool for text editing. All activity going on inside Emacs involves text editing one way or another, be it programming, making apointments in a calendar, answering email or even chatting with a virtual psycologist.

As for myself, being a lover of the software and spending most of my computing time on it, i'm a pretty heavy user of many of its advanced modes, key-combos and even learned a good deal of ELisp to better customize it. I can tell i wouldn't be half as productive or happy without Emacs.

----

The one real advantage I've ever found of one over the other is that vi is on every Unix system, almost regardless of how minimalist or old the install. Then again, that's really just a reason to be familiar with it, not to make it your primary editor. Unless, of course, like me, you learned on such a minimal system that you couldn't afford the space of Emacs.
[[CategoryEditors|CategoryEditors]]

Emacs vs. Vi

Both of these editors support many fundamental virtues of text editors such as extensive syntax highlighting, collapsible functions, spell checking, macros, undo-redo, multiple document editing, and a large support community. They are both free, Open Source, mature and well developed pieces of software. But...while both Emacs and Vim are considered powerful text editors, both capable of providing many of the same feature lists for general editing commands, the primary difference between these editors is the fundamental philosophy behind their design, and more to the point, the types of workflow that they were originally designed to handle. A search online for "philosecurity ninja or pirate" will produce a fun read on Vi creator Bill Joy and Emacs creator Richard Stallman. Because of the major design differences between these editors, emac/xemac extensions to emulate vi and vim are readily available online. For those more interested in personal versatility and combining the best attributes of both editors, there is information provided at the bottom of this wiki under the heading "More Tips".

At first, Vi (and its popular variant Vim) were considered mere small text editors built for speed with their focus on editing text quickly, but as they've matured have become considered to be on par with emacs/xemacs. Ultimately, these editors may have different pros and cons depending primarily on your style and workflow needs. For instance, "Vi" and Vim starts much faster than Emacs and their usual workflow assumes that you often will both enter through and exit from them alone. Vim has matured to using a tabbed interface which can be used to edit multiple files very quickly, while Emacs are based more on the assumption that you'll be working in one spot for a more extended period of time.

Historically, among sysadmins, vi/vim has tended to be the preferred software, while emacs/xemacs has tended to be favored more by programmers. This is not very surprising when you compare the typical editing needs of sysadmins v/s programmers to the relative merits of the two different editors. For a VERY detailed explanation of why this has been the case and the pros and cons of each editor, visit Emacs for Sysadmins

Commonly, systems administrators are working on many different machines, in varying states of installation, configuration and repair. They are making relatively quick edits to many different files. An editor with a quick load time, blazing keyboard efficiency (with the right expertise) and few library or other dependencies is essential. Preferably it will be the editor that virtually every version of UNIX includes by default. It is even, occasionally, handy that the editor be able to fall back on an old fashioned line editing mode when even the terminal emulation subsystem is non-functional.

Programmers, on the other hand, tend to work extensively on large complex sets of related files. However they tend to have all of them located on one single machine (usually checked out of a version control system en masse). For programmers the overhead of starting a larger, slower, more complex editor is amortized over their usage. They may have the same instance of the editor up for weeks or months at a time, closing and opening buffers as necessary. Having an editor support a full programming language internally is important to many programmers, as they need IDE (integrated development environment) features and tools like ediff and emerge (for comparing and merging different versions of a file, for example).

Of course this generalization can fail us. Many programmers started as, or spent stints as systems administrators and developed a preference for vi over emacs. A modern version of vim can support almost any of the features one would expect of emacs. (including a full programming language [python] available for use in vim, but it tends to be less integrated and feel less natural for programming editing than Elisp). In contrast, many people feel uncomfortable with vi's notorious "modal" paradigm. They never become accustomed to "command" vs. "insert" or "replace" modes and often consider the very notion to be atavistic.

Helpful Tips:

  • With emacs/xemacs one can access the vi keybindings use the command: M-x viper (That's [Alt]+[x]viper[Enter] or [Esc][x]viper[Enter] --- either should work, but the latter will work on terminals/keyboards that don't have an [Alt] key).

  • To emulate vim features such as visual selection and text objects, the extensible vi layer "Evil" is available on emacswiki.org.

  • In vim use the ex-mode command :syntax on to enable syntax highlighting (which is often configured to be off by default).

  • To learn the basics of vim very quickly run the command vimtutor (it's a set of macro files that run in vim and teach one how to use it).

  • To learn the rudiments of emacs use: C-h, t (from inside the editor of course). (That's [Ctrl]+[h] and then [t]). This will start the tutorial system that's written in emacs' "elisp" version of the Lisp programming language.

Ultimately the choice of a text editor is a highly personal one, so flame wars on the topic of vi vs. emacs are very common and often considered rather frivolous, but what's important is that you find what works best for you. Try them for yourself, and perhaps take Bryan Berry's advice to heart, "Using vi is like being in a relationship, you are involved. Using Emacs is like a marriage, you are committed, in large part because there is so much to learn."


CategoryEditors

EmacsVsVi (last edited 2013-04-20 11:12:02 by Neurosearcher)

Unable to edit the page? See the FrontPage for instructions.