|
Size: 9333
Comment:
|
Size: 4805
Comment: wiki restore 2013-01-23
|
| 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. | |
| Line 3: | Line 2: |
| 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. |
= Emacs vs. Vi = |
| Line 9: | Line 4: |
| 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. |
|
| Line 13: | Line 5: |
| Good Python language support is available for both editors, and modern implementations such as GnuEmacs and ViImproved are extensible in Python. | [[EmacsEditor|Emacs]] and [[Vim|Vim]] both are powered text editors with mostly same feature list for general editing commands but quite different in phylosophy and forkflow behind them. |
| Line 15: | Line 7: |
| Which editor suits your personal needs better is a matter of taste. Since both are OpenSource, free and mature, try both and choose one. :) |
|
| Line 18: | Line 8: |
| 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... :) | Previously Vi (and its popular variant [[Vim|Vim]]) is tend to be a small text editor which does a few things, mostly relating to editing text, but today it more closely to Emacs. It starts mutch faster than [[EmacsEditor|Emacs]] and its usual workflow assume that you often enter to and exit from [[Vim|Vim]]. Today [[Vim|Vim]] have tabbed interface for simultaneously editing of several files. Emacs assume long session into it by using buffer interface for multiplies files (some people report than they live in Emacs for the years, reloading it for upgrades). |
| Line 20: | Line 10: |
| ---- '''Discussion:''' |
|
| Line 23: | Line 11: |
| 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... | [[EmacsEditor|Emacs]] is a large text editor which does quite a lot of things (including vi emulation), not all of which are related to editing text. If you find yourself interested in an application which does many things, but may require more learning to explore its potential, then you might find this editor to be of interest to you. |
| Line 25: | Line 13: |
| 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). |
|
| Line 28: | Line 14: |
| 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)'' |
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 software. Try them both and choose the one that best suits you. |
| Line 32: | Line 16: |
| 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. | |
| Line 34: | Line 17: |
| 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'' |
Among technically inclined UNIX/Linux users ''vi''/''vim'' tends to be preferred more by sysadmins while ''emacs''/''xemacs'' tends to be favored by programmers (quotation needed). Comparing the typical usage patterns of these classes of users to the relative merits of the two editors this should not be surprising. |
| Line 38: | Line 19: |
| 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 20: |
| Remember this famous quote: "Plans are nothing; Planning is everything." -Dwight D. Eisenhower | 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 42: | Line 22: |
| 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. | |
| Line 44: | Line 23: |
| 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. |
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 47: | Line 25: |
| Ask "12 years from now, where would we want to be?" and make that your mission. | |
| Line 49: | Line 26: |
| 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? | 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 anyway it less integrated and natural for programming editing than Elisp). |
| Line 51: | Line 28: |
| 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. |
|
| Line 55: | Line 29: |
| 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. | Conversely many people are 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 57: | Line 31: |
| 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. | |
| Line 59: | Line 32: |
| 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. | Some tips: |
| Line 61: | Line 34: |
| 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! | |
| Line 63: | Line 35: |
| 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. | * In emacs and xemacs one can access the vi keybindings using 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). * 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 little more than a pastime for those who have already made up their minds. |
| Line 67: | Line 46: |
| 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
Emacs and Vim both are powered text editors with mostly same feature list for general editing commands but quite different in phylosophy and forkflow behind them.
Previously Vi (and its popular variant Vim) is tend to be a small text editor which does a few things, mostly relating to editing text, but today it more closely to Emacs. It starts mutch faster than Emacs and its usual workflow assume that you often enter to and exit from Vim. Today Vim have tabbed interface for simultaneously editing of several files. Emacs assume long session into it by using buffer interface for multiplies files (some people report than they live in Emacs for the years, reloading it for upgrades).
Emacs is a large text editor which does quite a lot of things (including vi emulation), not all of which are related to editing text. If you find yourself interested in an application which does many things, but may require more learning to explore its potential, then you might find this editor to be of interest to you.
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 software. Try them both and choose the one that best suits you.
Among technically inclined UNIX/Linux users vi/vim tends to be preferred more by sysadmins while emacs/xemacs tends to be favored by programmers (quotation needed). Comparing the typical usage patterns of these classes of users to the relative merits of the two editors this should not be surprising.
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 anyway it less integrated and natural for programming editing than Elisp).
Conversely many people are 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.
Some tips:
In emacs and xemacs one can access the vi keybindings using 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).
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 little more than a pastime for those who have already made up their minds.