Talk:Editor war

From Wikipedia, the free encyclopedia

Articles for deletion This article was nominated for deletion on October 7, 2007. The result of the discussion was Keep.

Contents

[edit] Tone

The article implies that this is an ongoing heated debate instead of an old joke. In reality, this debate is relevant to the 80s-90s. If you don't believe me look at some of the dates on all of the articles referenced. The article needs a more 'historical' tone. Spayced 02:02, 10 November 2007 (UTC)

I disagree. If it were true that the debate was settled decades ago then there wouldn't be any difficulty in agreeing over a neutral description of the benefits of each editor. This article is a mess because it seems impossible for someone to contribute an impartial description of the reasons for the "Editor War", without writing something that draws fire from one the war's active combatants. (Me, I use both editors. I think the reason people have wars is that there is plenty to hate in each one; people get defensive and strike out at the opposition, rather than say 'yeah, my favourite editor sucks too, but it gets the job done'). 217.140.96.21 (talk) 16:42, 7 May 2008 (UTC)

[edit] Pros and Cons

Do we want to present the actual arguments here, or should this be done on the pages of the respective editors? --Anonymous

I think that it would be clearer to have the arguments on this page and a reference to the argument on the separate pages, especially if the argument have a "statement-rebuttal" form. --Anonymous


[edit] Pros and cons (2)

I removed this:

"*GNU EMACS can perform computations with some calendars, such as Mayan or Discordian, which are not supported by the vi-like editors."

Which was briskly reverted back in.

Ahem. I do not dispute the accuracy, but is anyone trying to convince me that being able to use the Discordian calendar is an advantage over vi? Isn't this ability simply granted by virtue of having elisp to customize the living daylights out of Emacs? If you're going down this road, you could list every individual elisp-application/customization of Emacs as an advantage; it's already covered. If you're going to do it with something as patently useless as a Mayan/Discordian calendar (no offense to the geeks who will no doubt claim the opposite) you're just making the argument look ridiculous. --82.92.119.11 23:34, 26 Jun 2005 (UTC)

If you're going down this road, you could list every individual elisp-application/customization of Emacs as an advantage; it's already covered.
Insufficiently so. It is one thing to mention that Emacs has at its core an easy-to-use Turing-complete programming language; it is quite another to make clear to the untutored reader what that really means. --maru 01:08, 27 Jun 2005 (UTC)
And what it really means is that you can use a Discordian calendar? Preposterous. But we obviously aren't going to reach an agreement over this, so I'm just going to leave it to others. --82.92.119.11 28 June 2005 07:33 (UTC)
Vims Scripting language is also turing-complete. However, The "Mayan Calendar" argument might be used to show that the editor wars are pretty useless since Vim and Emacs both implement all the important stuff. --134.100.104.127 11:40, 19 July 2005 (UTC)
But does any Vi editor have the "psychoanalyze-pinhead" command?? ;-) AnonMoos 16:55, 7 December 2005 (UTC)
people wake up. is it such a feature you choose your editor for (mayan calendar)? it should not be list of exotic things. if i, like KNOWLEDGE SEEKING person want to know something about Emacs i just have to know it can be extended into what i need (flexible and modifiable editor). vi is unix philosophy-complete (hehe touring complete is really what i need from an editor. sorry notepad *.^). i believe we should write stuff for PEOPLE. so i took a time and rewrote most of the bloated stuff. i am using vim so i am thinking about writing and i am liking it. i am not emacs hater i like the idea. they say linus torvalds use him anyway :) 84.16.123.194 (talk) 05:41, 22 January 2008 (UTC)

[edit] The part about dvorak

"Emacs is not qwerty-centric. Vi's "hjkl" movement keys lose their benefit when the user uses an alternative keyboard like Dvorak."

This is not 100% true --- I use dvorak with vim. While the 'hjkl' keys aren't _directly_ underneath my fingertips anymore, they're still miles closer than the four little arrow keys. In my opinion vim is easier with dvorak than with qwerty.

For example, the yyp command (copy a line and paste it below) might be considered easier since 'y' and 'p' are right next to each other on dvorak, but on qwerty are farther apart.

Just because something was not designed for dvorak doesn't mean it won't work. As I recall, qwerty was designed to slow people down, but lots of people are really fast at it.

Bryan 17:55, 8 September 2006 (UTC)

The studies performed by Dvorak showing his layout is best were fairly shoddy and obviously biased. In fact, there is no evidence that the Dvorak layout is faster.

[edit] Advantages of what over what are acceptable for inclusion?

The article does mention the clones of vi and Emacs, but does it at the end (in the "current state" section). This is, IMHO, too late, because a user (like me) who knows well Vim but not Vi will be tempted to say "Get the facts right!". So:

  • it should be properly explained early in the beginning that there are really two kinds of editor feature comparisons: "Vi vs Emacs" and "Vim vs Emacs"
  • it should be explained which of the two feature comparisons is done in the article (or, better, do both). Or, state that this is just a list of frequently used arguments - but then remove items that are not used as an argument today.

This is important because otherwise the page may be misinterpreted. E.g., let's discuss support for editing non-English text. The article states that this possibility is an advantage of Emacs, while this is true only partially. In 8-bit locales under Linux, both nvi, Vim, and Emacs work well. In UTF-8 based locales, nvi fails, vim configured without --enable-multibyte switch fails, vim with this switch works, Emacs works.

Because the subject is flame-prone, I won't edit the article without first discussing this change here. Alexander Patrakov 08:54, 18 September 2006 (UTC) (Vim user)

This article is mostly about the historical claims. The section at the bottom could probably do with having a little more added about Vim now that Vim is attempting to assimilate the world (it's the default vi on OS X, gack), but this is best kept out of the main article body. Chris Cunningham 12:06, 19 September 2006 (UTC)
i took a liberty to change it. flame or water lots of stuff here look like some non-touchable holy relics ;) 84.16.123.194 (talk) 05:44, 22 January 2008 (UTC)

It says "PostScript output from plain text files." for Emacs. How's that a benefit? Vim has it too... (:hardcopy >file). Removing it. 84.191.254.114 (talk) 14:43, 3 February 2008 (UTC)

Can vim print faces to file though? ps-spool-buffer-with-faces? Silly rabbit (talk) 14:49, 3 February 2008 (UTC)

[edit] Emacs includes vi is misleading

It is true that Emacs includes a mode emulating vi. However, that does not make Emacs act like vi for a vi or Vim user. Vim scripting is probably not going to work in this mode. Also, the fact that Vim starts very quickly cannot be replicated in Emacs by introducing a mode. Therefore, I consider this kind of argument incorrect. -- Daniel Polansky, an XEmacs user.

Is that "XEmacs user", or "ex-(Emacs user)" :) --Chinasaur
It makes Emacs act very close to vi for a vi user. But not vim, for a vim user. It is a vi emulator, not a vim emulator.--Per Abrahamsen 17:53, 7 December 2005 (UTC)
That counts as a feature but not an advantage... To my bigoted view that sounds like Emacs is admitting defeat to Vi -- Le

[edit] "All The Standard UNIX Commands" in vi

Under advantages of vi, we find:

"vi blends naturally with the Unix environment and you can use all the standard Unix commands that you are already familiar with, or on all sections of your edit buffer".

Emacs can do this as well. Want to run a shell command? M-! Want to run a shell command and insert the output into the buffer? C-u M-! Want to run a shell command on a section of the edit buffer (region)? M-| And finally, passing the region to a shell command and replacing with output: C-u M-|

[edit] Cleanup: tone

I've tagged this article as needing tone cleanup. Mainly the problem as I see it is that the second half of the article is a list of percieved benefits; the article doesn't explain their importance as it relates to the editor war (which is itself a conflict I think deserves some recognition). Why are details of the features of the browsers important? —donhalcon╤ 17:28, 7 March 2006 (UTC)

The name of the article is 'editor war', not 'comparison of Vi and Emacs'. It shouldn't be a list of pros and cons, but rather a list of common arguments used by both sides of the discussion. This should stop the article from becoming a manifestation of the editor war.--Verithrax 03:13, 25 May 2006 (UTC)
I've tidied up the more obvious examples of informal tone. I'm removing the warning. Chris Cunningham 12:41, 11 July 2006 (UTC)

[edit] What about joe?

Emacs and vi are not the only popular editors. There is a significant "joe" (Joe's Own Editor) camp for those who dislike vi (and believe it to be a glorified version of ed/edlin), and may have cut their teeth on non-unix style text editors such as the IDE's of Borland's Turbo C or Pasal, or MicroPro's WordStar editor under CP/M or MS-DOS. --Thoric 16:19, 1 June 2006 (UTC)

There are zillions of text editors out there, the comp.sources.unix moderator at one point refused to post new editors for that reason.
The Editor War refers to a clash between two of those, that happened to be the most popular with the early Usenet crowd.
WordStar would be a word-processor, not a text editor.--Per Abrahamsen 18:03, 1 June 2006 (UTC)
Actually, this article would do well to have a flat statement like: While the "editor war" between emacs and vi remains relevant for many older users, most new users will look at either in complete disgust or horror and will continue to search for "a proper editor" which is easier to use by default. Menus and common hotkey combinations are common arguments for avoiding those two editors, even though they both could be customised to become friendlier. Common alternates include nano/pico, joe and a small handful of others (very small). Many users will reach for GUI editors whenever possible, most of which are much more "sane" in the eyes of these users. -- Sy / (talk) 13:41, 14 June 2006 (UTC)
I don't think that this is a good idea. This is about vi vs emacs, not about text editors in general. --Apyule 14:48, 14 June 2006 (UTC)
Actually the article's name is Editor wars, not vi vs emacs. I believe a reference to other editors wouldn't hurt, although it would seem important to note that the canonical example of editor wars is indeed emacs vs vi (which would lead nicely into the rest of the article as it is now). I would not, however, agree with the example given by Sy above. "complete disgust or horror" does not seem like the sort of term we should be using on an enciclopedic article (and is subjective to begin with), "easier to use" is subjective, and I'm not at all convinced that emacs and vi are only relevant for older users. Capi 03:42, 15 June 2006 (UTC)
I have to agree here; I'm a young guy, and I am interested in both editors (haven't made a choice yet) because I think they are both going to be more powerful than most of what else is out there in the long run. I think many people especially in the development community agree. 128.113.147.60

[edit] Eclipse vs NetBeans?

Can't it be said that a modern parallel is found in the Eclipse vs NetBeans debates? Wouter Lievens 07:46, 7 June 2006 (UTC)


[edit] Modes

I swore I wouldn't get involved in this, but here goes. Under "Benefits of vi-like editors", the last point notes that vi is modal. I think this point should be removed since it is, in fact, a disadvantage. Modes are widely considered to be poor human interface design. I don't have references handy at the moment, but as a rule, modal interfaces introduce significant confusion and errors. At the very least, I think the assertion that modes are "very useful if one gets used to it" needs a citation. -- Captaindan 16:23, 27 July 2006 (UTC)

Being modal is clearly a perceived advantage to vi proponents - as Emacs not being modal is a perceived advantage to Emacs proponents. I could sit here and say that Emacs not being modal is, in fact, a disadvantage. Or its being "a Swiss-Army knife". I could easily say that's just being bloated and poor design. But I would clearly not be NPOV and would be inserting bias, which is what your proposal would be doing. vi proponents have their perceived advantages, emacs proponents have their own perceived advantages. The whole point of the article is that neither side agrees (otherwise there would be only one editor). Capi 01:59, 28 July 2006 (UTC)
I misunderstood the purpose of the "Benefits of ____" sections. I was under the impression that they were lists of legitimate benefits (let's ignore for the moment whether modality is a "legitimate" benefit), but now I see language indicating that they are lists of perceived benefits. At this point I don't really care what happens to the article but it might be worthwhile to make the purpose of these sections more evident. -- Captaindan 20:54, 2 August 2006 (UTC)
I went ahead and fixed the section titles to reflect this. Benwing 00:53, 3 August 2006 (UTC)
BTW the Wikipedia page on Mode (computer interface) notes that modes are generally considered bad. Benwing 00:55, 3 August 2006 (UTC)
haha, "'It is no accident that swearing is denoted by #&%!#$&,' writes my colleague, Dr. James Winter; it is 'what a typewriter used to do when you typed numbers when the Caps Lock was engaged'." That's very funny. However, this is why a vi user will commonly hit escape (or control-[) before typing, to make sure they are in command mode. and without modes i can think of no way to move around using one finger at a time without leaving the home row. and i really like that feature. having to do C-n in emacs just annoys me, and i don't want to move my hands to the arrows... 128.113.147.60 04:55, 17 October 2006 (UTC)
Now the fact that vi is modal isn't even mentioned in the Differences section (it's first mention is in the Humor section, which doesn't seem right). Also, the fact that Emacs uses a lot of modifier keys isn't mentioned until the Humor section. To me, this is these are significant differences, and should be near the top of the Differences list. Actually, I don't think the Differences section is all that good, because most of the points are written to sound like similarities rather than differences. Adw2000 (talk) 14:04, 6 May 2008 (UTC)

[edit] Keeping the article on track

I've removed a lot of the crosstalk which is inevitably generated in editor wars arguments by vim users. The Emacs benefits section still needs to be condensed and written in a more formal style, so don't think I'm picking on vi (which I use myself). Chris Cunningham 12:42, 3 August 2006 (UTC)

[edit] Emacs = must commonly GUI?

vi is normally used inside of a text-mode console, whereas Emacs is most commonly run as a GUI application.

This line should be removed. Emacs is a text-mode console and you need an extension to run it in GUI mode.

Yes, but most people run it using said extension. (I realise we're getting into the terriritory of "most vi users are really using vim", but I only see people running emacs inside a terminal on rare occasions these days.) Chris Cunningham 15:47, 6 September 2006 (UTC)
That is not true. I am in an institute that employ 300 computer scientists and bioinformaticians, and the use is even. Personally I often use both at the same time (e.g. the GUI on my local machine and the text-mode in ssf connection or as an editor for my email client). Nicolas Le Novere 09:59, 13 April 2007 (UTC)
Since somewhere in the Emacs 18 series (20 years ago!), X support has been part of the standard distribution. It is not an "extension". It is possible to build Emacs without X support. But it is also possible to build it without termcap support. Both will be included by a default build, if the libraries are available.--Per Abrahamsen 15:59, 6 September 2006 (UTC)

[edit] Sample post from the Church of Emacs

This doesn't add anything to the article, it isn't sourced and it looks to be very recent judging by the things it references. I don't see the point in this staying. Chris Cunningham 14:44, 2 November 2006 (UTC)

I entirely agree. Not point at all in this particular article. It makes us look like lunatic and our editors some games. Besides it induces the idea that "vi" users are not free software supporters, while Vim at least is entirely GPL-compliant.

[edit] On the lighter side

... there is a recent entry from User friendly about beating them both. --22:38, 7 January 2007 (UTC)

[edit] "supposed" should be "claimed"

I don't think either side of the editor war, or the observers, are supposing any of these benefits - I see plenty of claiming that these benefits apply to either editor. I'll change the section titles from "supposed" to "claimed". Gronky 11:51, 5 February 2007 (UTC)

yes but it would be then "what people think" rather than "what is objective more/less". people usually think x an y while those two are differrent (lets suppose that) 84.16.123.194 (talk) 07:43, 24 January 2008 (UTC)

[edit] "Steep" learning curve

the popular misapprehension that a "steep" learning curve means that something is hard to learn. In fact, a "steep" learning curve implies that something gets easier quickly.

However, popular and accepted usage dictates that a steep curve is one which is difficult to climb. Or at least one which is daunting due to its apparent steepness. --JamesTheNumberless 15:14, 13 February 2007 (UTC)
I've usually seen "learning curve" expressed as knowledge and experience required vs. utility. A steep one means you have to study a lot to get any better. - 209.130.150.117 05:04, 4 March 2007 (UTC)

[edit] Unicode support

The reason why I am currently shifting more and more from emacs toward vim is the native support of UTF-8. This should be one of the positive points in Vi. —The preceding unsigned comment was added by Lenov (talk • contribs) 10:05, 13 April 2007 (UTC).

[edit] customisation

Typically most vim users customise their editor more than emacs so they don't have to keep hitting the esc-key all the time. I've marked it citation needed, i'm sure some people will argue here. —The preceding unsigned comment was added by 86.155.174.85 (talk) 12:25, 26 April 2007 (UTC).

The statement vi users generally do not customize their editor much, as opposed to advanced Emacs users who would not feel comfortable if their heavily customized profile were not available to them. seems more like a rant than fact and it is backed by only a citation that express one user's personal experience. I think it should be deleted or backed up by a source as few would regard it as common knowledge or something. Pink18 09:43, 30 August 2007 (UTC)

[edit] My contribution to the war

All text editor sucx, except NoTextEditor. NoTextEditor rulezzz. Let everybody know that! Said: Rursus ☺ ★ 12:45, 6 August 2007 (UTC)

[edit] Wow what a bunch of losers

It's a bit surprising to think that there are actually basement dwellers who argue over crappy terminal text editors over the internet.

--RucasHost 12:22, 9 August 2007 (UTC)

Almost as surprising as basement dwellers who go out of their way to troll discussions in which they clearly have no interest. jsnx 01:04, 11 August 2007 (UTC)

[edit] religious fanaticism

"The community has a tradition of treating their favored piece of software with a reverence bordering on religious fanaticism"­­—ehm, excuse me? I am going to remove this un-backed claim because it simply does not fit in an encyclopedia. If somebody could provide a citation for this, great. In the mean time...--bb 20:01, 22 September 2007 (UTC)

[edit] Broken link

The link to http://www.dina.kvl.dk/~abraham/religion/vi-tutorial.html doesn't work. Should I just remove it, or does anyone know of a working replacement URL? (Interestingly, the hostname resolves, but to an IP that either isn't in use at all or is used by a stealth-firewalled machine that isn't a Web server.) —Preceding unsigned comment added by 76.64.154.160 (talk) 19:41, 29 September 2007 (UTC)

seem to work now Xchmelmilos (talk) 13:37, 13 March 2008 (UTC)

[edit] Misleading Title

The title "Editor war" is too vague and inaccurate for this. It gives the impression that the article is about broad range of text editors on various computers. There are others worthy of addition such as TextMate, but I suspect that would trigger a whole new range of flame war and unresolved issues, never mind over-complicating the article.

I like the article itself, however. It is good to attempt a unifying information vault for both, while allowing both sides to have potentially an equal input - and this is a good start. So I am against deleting it, but it should be kept under a different title. I think it is too much of a hard work at this point in time to keep the name and expand the content - as if there weren't enough content to write as it is already for 2 editors!

Thus, I recommend a title change. Ultimately this article is about Vim vs Emac and the title should reflect that without ambiguity.

My suggestion is as follows on the narrow-downs. First, it is about Vi and Emac. Second, there are common denominators - they are freeware. As Wiki itself is a generalized encyclopedia with no specificity of platforms or prior knowledge, I suggest that those key points are included, or at least suggested in the title to avoid disambiguation.

Either that or just name it for what it is i.e. "Freeware Editor War: Emac vs Vi" (editor name in alphabetical order). Jgrey (talk) 10:23, 9 December 2007 (UTC)

A name does not need to be a description, the editor war is the name of a specific editor war, much like the reign of terror is the name of a specific reign of terror. A disambiguation page might be on order though.
You are right that a name does not "NEED" to be a description. However it does help if the title not only reflects the issue but further specifies what is actually defined in the article. For instance, every war that has taken place in the world can come under the title "War", be it World War 2, VHS vs Beta video format war ,or a random small war that has taken place centuries ago. And that would work, in theory, but that would be highly unhelpful. Obviously that is an exaggeration of the point in this particular case, but nevertheless, a rethink on the title can further improve the accessibility of this article. Jgrey (talk) 01:43, 16 February 2008 (UTC)
And it is Emacs vs vi, an eMac is an Apple brand computer. vi was not free software (nor freeware, whatever that is) at the time, but the later vim is. --Per Abrahamsen (talk) 15:22, 10 December 2007 (UTC)
Thank you PA for further clarification. I would back that as the new title for the article, or some variation of it. As it stands this article could be a war between 2 tabloid newspapers. Jgrey (talk) 01:47, 16 February 2008 (UTC)
"Emacs vs vi rivalry" seems the most descriptive wording to me, but the "editor war" redirect should be kept since that is how the rivalry is usually refered to. --Gronky (talk) 00:48, 2 March 2008 (UTC)

[edit] Bias

This article seems to be a little biased towards Emacs. --66.68.89.209 (talk) 01:06, 16 December 2007 (UTC)

this is totally true. i almost started to believe that emascs has a different fonts size(s) and can teach me how to cook. i reduced comparison bloat on both sides. it was simply list of cool-features of emacs. 84.16.123.194 (talk) 05:51, 22 January 2008 (UTC)
Now it's biased to vi. I'm a bit to lazy to fix it, not knowing anything bout this. The bias is small and not obvious, but is there.66.75.127.77 (talk) 08:21, 13 March 2008 (UTC)
At least something is biased to vi ;) This balancing from dark to light side (whatever one identifies as such) may be a good thing as far as it converges to grey side;) Anyway i seem rather a lack of structure. I mean vi is MODAL and emacs is NON-MODAL and have everything(at least beginning/intro) turn around it. Good would be some tables - i am not sure exactly how to doo it. Xchmelmilos (talk) 13:34, 13 March 2008 (UTC)

[edit] Grammar / Sentence Structure

Article has many nuances in grammar and sentence structure, notably missing words in sentences, that mark it as written by a foreign editor with a good, but not excellent, command of the language. Examples: "This creates path in decision tree"; "Emacs issues same thing, nevertheless its commands are a combination executed immediately, which leaves user but with a choice whether use a command or not." Glacialfury (talk) 20:56, 1 March 2008 (UTC)

I noticed this also. Apparently, much of it comes from 84.16.123.194 (see Bias above). I would try to fix it, but I have no idea what this person is trying to say. :-( 71.255.111.251 (talk) 01:40, 9 March 2008 (UTC)
it is not put the best way from him ;) he is trying to say that you (usually) choose count of repeats, command and movement. and each one of those decisions are branches. you can omit count of repeats for example ... feel free to improve it. anyway i apologize for my messy english;) ca1 (talk) 08:13, 26 April 2008 (UTC)

[edit] Actual Differences?

The Differences section states:

  • vi editing retains, or keeps, each permutation of typed keys. This creates a path in the decision tree which unambiguously identifies any command.
  • Emacs does the same thing. Its commands are a combination of typed keys executed immediately, which leaves the user with the choice of whether or not to use a command.

First off, I don't fully understand what the first part means. Is this referring to the vi behavior of stringing several keys together to form a command? e.g. diw to remove a word, y2f} to copy everything until the second curly brace? If so, it should be made MUCH clearer.

Second... "vi does this; Emacs does the same thing". How is this a difference? Max (talk) 15:18, 12 May 2008 (UTC)