Slashdot Mirror
Comparison: Linux Text Editors
jrepin writes: Mayank Sharma of Linux Voices tests and compares five text editors for Linux, none of which are named Emacs or Vim. The contenders are Gedit, Kate, Sublime Text, UltraEdit, and jEdit. Why use a fancy text editor? Sharma says, "They can highlight syntax and auto-indent code just as effortlessly as they can spellcheck documents. You can use them to record macros and manage code snippets just as easily as you can copy/paste plain text. Some simple text editors even exceed their design goals thanks to plugins that infuse them with capabilities to rival text-centric apps from other genres. They can take on the duties of a source code editor and even an Integrated Development Environment."
It may not have been wise for me to spend years training vi into my muscle memory, but it's done now, and I'm not especially interested in giving up that advantage.
You can do all of this in Emacs and Nano. No need for some shiny new text editor...
none of which are named Emacs or Vim
What's there to compare? Everything else is just Notepad.
When you're SSHd into a *BSD based firewall in China, you can't just bring up some fancy autocompleting GUI editor. You'll get vi (not vim!) and like it.
I want to delete my account but Slashdot doesn't allow it.
nano is fine for starting out....but realistically, vim or go home.
I used to use gedit on Linux a lot a few years ago. I then used OS X for a few years, but I recently moved back to Linux. One of the first things I did after getting Linux installed was try to edit some files using gedit. And my first reaction was: JESUS FUCKING CHRIST, WHAT IN THE FUCKING HELL DID THEY DO TO GEDIT'S UI?!
It used to have a good, traditional UI. There were useful menus and a toolbar, and it all worked very well. But now, JESUS FUCKING CHRIST, it looks stupid as all hell. There are no menus any longer, and the toolbar has been castrated into having like 4 buttons. The icons are pathetic, and don't indicate what the button actually does. Whoever the hell reworked the UI managed to break what was once a very usable text editor. Now it's rubbish.
It's like they took the idiotic UI design of Chrome and brought it over to gedit. And now gedit is useless to me! So I've moved on to Kate. At least the KDE crew hasn't gone completely fucking stupid like the GNOME dipshits apparently have.
Why the fuck did they have to ruin gedit's UI?
Have you seen Gedit lately? Its new user interface is even less usable that vi's is: https://en.wikipedia.org/wiki/Gedit#mediaviewer/File:Gedit_3.11.92.png
The Gnome designers just keep making Gnome's user interface worse and worse to use. I guess that's why so few people use Gnome these days!
Where's geany? It's much better than gedit.
Video of some good progressive thrash music
vi or nothing. Not vim, not gvim, nvi or anything else. No A, B, C or D. :-)
Sorry if this is stating the obvious, but if you're a programmer who does lots of editing on a few machines, then pick the editor that best fits the job.
However, as an admin, I have long ago standardized on VI for the simple reason that it's included by default on every single *nix variant out there. (At least, in my experience.)
My cunning strategy breaks down with Windows, though. Notepad is so nasty to use that I find myself installing textpad or cygwin on the machines where I do most of my work.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
( obligatory, credit to: https://www.gnu.org/fun/jokes/... )
When I log into my Xenix system with my 110 baud teletype, both vi and Emacs are just too damn slow. They print useless messages like, ‘C-h for help’ and ‘“foo” File is read only’. So I use the editor that doesn't waste my VALUABLE time.
Ed, man! !man ed
ED(1) Unix Programmer's Manual ED(1)
NAME
ed - text editor
SYNOPSIS
ed [ - ] [ -x ] [ name ]
DESCRIPTION
Ed is the standard text editor.
---
Computer Scientists love ed, not just because it comes first alphabetically, but because it's the standard. Everyone else loves ed because it's ED!
“Ed is the standard text editor.”
And ed doesn't waste space on my Timex Sinclair. Just look:
-rwxr-xr-x 1 root 24 Oct 29 1929 /bin/ed /usr/ucb/vi /usr/bin/emacs
-rwxr-xr-t 4 root 1310720 Jan 1 1970
-rwxr-xr-x 1 root 5.89824e37 Oct 22 1990
Of course, on the system I administrate, vi is symlinked to ed. Emacs has been replaced by a shell script which 1) Generates a syslog message at level LOG_EMERG; 2) reduces the user's disk quota by 100K; and 3) RUNS ED!!!!!!
“Ed is the standard text editor.”
Let's look at a typical novice's session with the mighty ed:
golem$ ed
?
help
?
?
?
quit
?
exit
?
bye
?
hello?
?
eat flaming death
?
^C
?
^C
?
^D
?
---
Note the consistent user interface and error reportage. Ed is generous enough to flag errors, yet prudent enough not to overwhelm the novice with verbosity.
“Ed is the standard text editor.”
Ed, the greatest WYGIWYG editor of all.
ED IS THE TRUE PATH TO NIRVANA! ED HAS BEEN THE CHOICE OF EDUCATED AND IGNORANT ALIKE FOR CENTURIES! ED WILL NOT CORRUPT YOUR PRECIOUS BODILY FLUIDS!! ED IS THE STANDARD TEXT EDITOR! ED MAKES THE SUN SHINE AND THE BIRDS SING AND THE GRASS GREEN!!
When I use an editor, I don't want eight extra KILOBYTES of worthless help screens and cursor positioning code! I just want an EDitor!! Not a “viitor”. Not a “emacsitor”. Those aren't even WORDS!!!! ED! ED! ED IS THE STANDARD!!!
TEXT EDITOR.
When IBM, in its ever-present omnipotence, needed to base their “edlin” on a Unix standard, did they mimic vi? No. Emacs? Surely you jest. They chose the most karmic editor of all. The standard.
Ed is for those who can remember what they are working on. If you are an idiot, you should use Emacs. If you are an Emacs, you should not be vi. If you use ED, you are on THE PATH TO REDEMPTION. THE SO-CALLED “VISUAL” EDITORS HAVE BEEN PLACED HERE BY ED TO TEMPT THE FAITHLESS. DO NOT GIVE IN!!! THE MIGHTY ED HAS SPOKEN!!!
BeauHD. Worst editor since kdawson.
Don't all of these text editors require a GUI? I prefer something which can work with a serial/telnet/(basic ssh) console, without all the unnecessary overhead of a GUI. I like joe (which can reasonably emulate emacs/pico, if you want), but can deal with vi if I have to.
"National Security is the chief cause of national insecurity." - Celine's First Law
i would like some text editors reviews as well, like nano, joe and others
Open Source Java Web Forum with LDAP authentication
That's why I use Sublime Text. It has a 'vi' mode that works very well. (Well, it does the most common functions, but if you're a grand-master vi wizard you'll easily find things it doesn't do.)
That was the primary reason I allowed myself to try it. 'come for the 'vi' stay for everything else.' The good news is that it's a top-notch editor even without vi. The 'overview' slider on the right side is brilliant. There's a vibrant 'plugin community', and it's very customizable. Also it's multi-platform so I'm using exactly the same Editor on my Windows box at work as well as my Gnome sessions at home.
(I still use vi in my terminals.)
--Welcome to the Realm of the Hawke--
http://xkcd.com/378/
Even if you don't personally engage in editor wars, it's pretty funny. I'm afraid that the number of Slashdot articles best answered by an XKCD cartoon has remained surprisingly consistent.
Given that most of the tools in the mentioned article require a GUI to work from, and many of them are destabilized by their use of Java, I'm afraid that the article will remain aimed at GUI and web developers, not "real programmers". We who do real systems recovery or kernel level code development will continue to use "vi" for small tasks, "emacs" when we need full integration with source control systems or more powerful indentation..
I'm generally using BBedit from my Mac. SFTP is my friend.
Besides, who wants all the extra kruft that goes along with Gedit or Kate on a server? In that case it's not the editor I'm objecting to - it's the 100 other required packages that go along with it.
#DeleteChrome
Why do you think that it may not have been wise for you to do that? I did it and I think it's worthy.
Yeah, right, dat steep learning curve. I've wasted years using UltraEdit, because I was told that vim was too hard. One friday afternoon I fired up vimtutor, and it took me the following weekend to learn vim enough to do my work as good as with UltraEdit. From that moment on, I've spent years honing my vim skills, following a very slow but rewarding learning curve.
I've been editing (plain)text for living for the last 15 years, and I doubt I'd ever get as dedicated, thorough and precise in my work without vim. All those self-proclaimed no-learning-curve, get-the-job-done editors are inferior, and one should use them only if they actually need to do some ad-hoc work, which they actually don't even want to do.
Pick a proper tool for your job, not a toy.
So there!
http://xkcd.com/378/
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
I still use nedit, thought it hasn't had any decent upgrade in years. Nonmodal (modal is why I don't like vi/vim), simple, easy to hack regex based syntax highlighting (though that can be tripped up sometimes - I'm looking at you Perl), simple enough to get out of your way (I'm looking at you emacs), and fast with no lag (I'm looking at you jEdit).
Mayank Sharma of Linux Voices tests and compares five text editors for Linux, none of which are named Emacs or Vim.
Real men don their asbestos suit and compare the most useful and popular text editors as well. What's next, are we replacing car analogies with analogies to tunnel boring machines (so that we can compare something no one knows to something else no one knows)?
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
I like Nano more than Vi when SSH'ing. Just seems easier and does all that I need it to do.
Where's Jed? Why isn't anyone mentioning Jed? It's got Emacs bindings, it's really light-weight, and available by a simple apt-get.
Where's Jed? Why isn't anyone mentioning Jed? It's got Emacs bindings, it's really light-weight, works on command-line, and is available by a simple apt-get.
If you think any of these editors is "fancier" than VIM, you probably shouldn't be posting about text editors on the internet.
"Emacs is a great operating system, if only it had a decent text editor!"
All --
None of the Gooey Editors mentioned are much good on remote terminal sessions.
Learn the basics for vi and you'll always be able to fix a remote host via a text-only console session,
Second place goes to emacs in my list because it's not available by default on all flavors of *NIX.
Otherwise, JED, JOE, NANO, PICO, etc are out there for the taking.
-- kh
No Emacs? What the fuck is this shit!? No one gets anything of value done in Linux without Emacs!
I have a few text files on my Windows box with :wq scattered around in random locations.
-- Will program for bandwidth
My students hated that I made them learn vi. Why? Because if the graphics subsystem failed, or they had to go to single user mode, they had vi.
If they made it through my class alive, they could use whatever they wanted.
My mom says I'm cool.
Seems like they knocked it because of the Java and it wasn't Fedora/RPM friendly. But I've been through all of these and the plugin capabilities put jEdit on top IMO. With a little customization, it easier becomes the most powerful of the lot. The other editors are just Notepad clones by comparison.
As a kid I grew up on Wordstar (running on CP/M, on an Osborne 1) and as such joe (http://joe-editor.sourceforge.net/), which is more or less a command-compatible workalike to Wordstar, suits me perfectly. While it is still available and updated reasonably regularly, it is getting harder to find / install easily for modern *nix systems. I love joe, though, I don't even have to think to use it.
There are assorted plugins to integrate vim and other vi-like editors with web browsers. So I might be using vim keystrokes to write this. Alternatively, a vim plugin can also call lynx. I'm not sure why you'd want to do the latter. The former might be handy if just avoid accidentally ending your posts like this. :wq
Emacs bindings and light weight, eh? Maybe nobody who cares about light weight is accustomed to emacs and vice versa.
My personal favorite is 'le' simply because its the only one I've found that doesn't obsess over whitespace. It isn't that way by default, you have to configure it from its 'exact' mode which is like most editors into 'text' mode, but at least it has the option unlike most editors. When in 'text' mode, when you push the right arrow while at the end of a line, the cursor just continues to go to the right, and doesn't do anything retarded like go down to the beginning of the next line.
Honestly, why nearly every editor does that, I have no idea. Just drives me fucking insane when I press the right arrow and the cursor goes to the left of the screen, or when I use the up/down arrows and the cursor completely disappears from anywhere I might look for it because the next line is longer/shorter than the previous one and so the editor has decided the cursor should now be at some other column. I don't care where spaces are or are not in the file. Indeed, I'd prefer the editor strip the file of all spaces not used for indentation when it saves, because spaces just don't fucking matter. Same with tabs, don't use them, just indent with spaces.
I wish I could find a GUI editor that works the same way, but aside from the author of 'le', everyone seems to think that where spaces are or are not in a text file is so critically important that anyone editing the file shouldn't be permitted the luxury of just putting the cursor where they want letters to be and typing them there, but instead they must be forced to add the spaces manually and only then be permitted to type what they want.
While everyone (who doesn't live under the rock that is vi/emacs) is sucking Sublime's dick these days, I'll say one thing -- at least jEdit has a free (S)FTP plugin. You have to pay $90 dollars to have Sublime and a shitty SFTP plugin. That's not even a frugal ass whore.
Vim, GCC and GDB, the best software development system on the market.
pff no one mentions teh grand daddy - TECO
where line noise is an executable!
So, - here's the bottom line. Almost nobody here agrees with the OP premise :-)
/usr/bin/vim
Personally I use vim and emacs, they can do everything those editors can, and much more.
Once you get over the learning curve, which I did, there is no reason to try the less capable editors.
Gedit is so slow to start that it has been used as a strawman as to "why X is bad" instead of the more accurate "why is this new gnome stuff so much slower than the old gnome stuff?"
Just like political cartoons and a pile of three panel strips. It's what they do.
Newbs. Now it's like Rock Paper Scissors Lizard Spock for text editors.
I've been trying to like Atom.io lately. The latest Ubuntu packages have been pretty good in terms of memory and speed compared to the initial release, and seems to be becoming more interesting.
While my editors of choice are Kate (or the embedded kate-part in Krusader, same thing), and Geany, I've been wondering if anyone else is taking a shine to Atom. Any feedback or opinions?
(Yes, I am aware that using webkit is bloated as all hell, but if it ultimately manages to put more features I like than the others, I am not having second thoughts on using it.)
Now I use its clone mbedit (http://www.braun-home.net/michael/mbedit/index.htm) on Linux, Windows, and even MACs.
Lots of text editors are garbage. Notepad++ looks amateurish, or do you think that any professional program would name one of its tabs "MISC."? Sublime Text is not any better as it does not have proper configuration dialogues at all (a proper graphical program should have). Vim and Emacs have some cool features but the keybindings are unnecessarily unintuitive. If those two didn't have the hacker legacy and they were invented today, no one would use them. I surely am an angry man. :D
There is emacs. There is vi, for when some fool didn't install emacs. There is ex, for when the terminal is messed up. And there is ed, because it is the standard text editor.
Anything else is either redundant, or is a word processor with a text-only output.
Or taken a lot longer to sort it out and then move on to FreeBSD.
Joe seems very intuitive to me and has just enough power as a text editor to give you free range of config files and basic scripting or even a couple hundred lines of Perl. I've always found vi impossible; the command/editing modes never made sense yet Joe seemed to work "like normal."
I made an honest effort to master emacs, but it always seemed like effort and I always went back to Joe when I needed to get something done.
I actually went trolling recently for a win32 text mode version of joe (which I swear I used to have) but couldn't find one.
Emacs
They finally sorted this out!
I wonder whether anyone has an editor with really good auto-completion suggestions.
For example, in HTML, I might type:
Alternatively, in PHP, I might type: forea
and the editor should offer me: foreach ($key => $val){
It should also be able to show the documentation for the functions within a tooltip, do inline syntax lint checking, and support refactoring.
So far, I would also mention "Brackets" and Github's "Atom" editors as worth looking at.
I combine vim's ability to apply a command to a range of text with unix utilities like sort or awk or even perl. This piping ability makes vim a true member of the Unix toolset.
Happens to me far too often on my Windows VM's, LibreOffice windows and even on the Chromebook that I use to type this message on (on normal Linux machines I have Firefox w/ VI plugin).
Okay, y'all can stop mentioning how vi and emacs do everything these do plus come preinstalled on Linux systems. From the article:
Two of most popular and powerful plain text editors are Emacs and Vim. However, we didn’t include them in this group test for a couple of reasons. Firstly, if you are using either, congratulations: you don’t need to switch. Secondly, both of these have a steep learning curve, especially to the GUI-oriented desktop generation who have access to alternatives that are much more inviting.
This is for people moving to a text editor from Word.
Functionality comes at a price. Complexity introduces bugs by necessity, reduces performance and increases memory footprint.
Below some given threshold, adding complexity is fine. The reduction in wasted time/money exceeds the increase in overheads. Above that threshold, the reverse is true.
As with all systems, for any given variable, the plot of efficiency vs complexity follows the standard S curve. Memorize this curve, it will save you much grief. The aggregate will be more complex because the variables have inter-dependencies and unique characteristics. You need to resolve to orthogonal components if you want to do anything useful.
Since nobody can be bothered to do that much maths, it becomes a simple question - do you get anything out of using them?
For me, the answer is usually no. There are no editors out there that handle more than a small fraction of the languages I use. Several critical languages use specialized formatting rules and it is a syntax error to not follow them. It would be nice to actually have an editor remember the rules for me, but formatting editors prettify code. The notion of languages having rules is beyond them.
Most code editors I've used also insist on adding truly ugly dummy code. And by "ugly", I mean I would demote a first year student by a year for writing such crap.
Maintainer convenience is not a factor I allow in mitigation. NetBeans and Eclipse score poorly. Eclipse doubly so, as I've seen it suffer seizures when updating purportedly compatible extensions. If I can write code faster by chiselling it into rock than typing it into an editor, the editor's coding isn't being written for the benefit of users. If portability and compatibility are claimed, I expect that claim to be true or rescinded. Transactions, including updates, should be bulletproof - which may include rollbacks for the irretrievably mangled.
Good code isn't the problem. Good code is never a problem. Finding good coders IS a problem, finding good coders who can work together is almost impossible. (Ergo, Linux is the byproduct of alien experiments on the brains of Linus Torvalds and Alan Cox, coinciding with a freak quantum entanglement with Dread Cthulhu in a parallel universe.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I was thinking something similar. I've been using vi for a bit over 20 years now and in that time I've got pretty efficient with it. Now these new editors might be better for new users, but there's no way I'm going to give up the efficiency I get from using a tool that I've spent so long mastering.
Incidentally I tried the vi bindings for visual studio the other day and found them incredibly frustrating. Basic things work, so you can say run
":s/a/b/" but slightly more advanced commands don't work, so you can't run ":23d 4". The problem with that is you never know which commands are supported so end up typing instructions only to have it thrown back at you. You're better off with no bindings at all.
You do know the reason ed is so small is that it's hardlinked to vi, and vi reads $0 to know it should enter ed emulation mode. A real ed binary is small, but not that small.
That said, I agree with you - ed is a pretty nice editor and it's saved me on more than one occasion (generally after I've screwed up my terminal emulation).
Oh, and there's a small bug in your interaction with ed above. An EOF will terminate the session rather than generate an error, at least all the variants I've used support this instead of q.
scite/notepad++: scintilla based, leightweight
vi: for editing system files (i like the fact that it usually takes 2 keystrokes to do harm.
the editor integrated in eclipse in order to edit java and xml
formerly i used emacs when doing development, but now i prefer full IDEs
Have gnu, will travel.
It is mentioned clearly why they didn't include vim and emacs. One of the reasons is stupid (both of these have a steep learning curve), but the other and primary reason is sound. You don't need to switch however great the 5 tested editors turn out to be.
So Vim and emacs were declared winners before the race started. I see that you are not a fan of paralympics, but paralympics are somewhat entertaining and instructive.
Bingo Dictionary - Pragmatist, n. A myopic idealist.
They should have tested interactivity of the editors. Though in synthetic test environment that would have been probably an impossible task.
I'm still using the VIM (terminal version, occasionally the GUI gvim-athena) because this is the only combination which doesn't have the delays.
Few years back I have tried the Kate/Kdevelop, Gedit and Eclipse, and they still had the same thing in common: occasionally GUI would freeze for couple hundred milliseconds, typed text at first goes nowhere and then suddenly pops in the editor window.(*)
It's probably not a big deal for a mouse person. But for a keyboard person (or a touch-typist), when there is no visible indication of something happening, the delays are simply too irritating.
VIM (in xterm) still remain my champion of text editing. Yes, xterm, because the "modern" terminals, especially with tabs open, not only prone to the same GUI delays, but they also prone to losing the focus (like in: you switch back to the terminal, start typing but nothing happens, click with the mouse inside the terminal window and start typing again - and lo and behold it finally works).
(*) Disabling the "composing" window managers helps greatly, but doesn't eliminate the delays completely.
All hope abandon ye who enter here.
Now I use vim because I prefer an editor that works in a terminal but I used to work with JEdit and it's much better than shown in the review. I didn't have any problem folding code or any other coding task, and it install flawlessly in Debian using the installer or thru the package manager.
I have good memories from the GNU Emacs editor. :-)
M-x create-world
And none of them scrolls as smoothly as CygnusEd on my 14 MHz (sic!) Amiga 1200.
Sometimes I get a feeling that somewhere something went horribly wrong... :(
After all, ed is the standard text editor.
Wordpad running under WINE?
New gedit is completely unusable. I abandoned GNOME years ago in favour of XFCE, but I kept using gedit when I needed an editor with a GUI.
Now even that is useless, and I've switched to kate. Maybe I should give geany a shot...
--Coder
It used to be that the editor wars were vi vs. emacs. Now we've evolved to the point where it's the text-based editors (vi and emacs lumped into the same camp) vs. the graphical-based ones (sublime and all the rest).
I've never used Sublime, but a few people in my office use it, and I'll admit, it looks pretty neat. If I was editing files exclusively on my desktop, it might well be what I would use (and I say that after 30-odd years as a die-hard emacs user). But, the biggest problem I see with Sublime (and I'm assuming the same for rest of the graphical editors) is that it doesn't work and play well in a cloud environment.
We do all our work on servers in a hosting provider. My desktop is just for reading mail, browsing, and hosting terminals windows. And maybe, as I get dragged kicking and screaming into gmail, that list might get reduced to just "browsing and terminal windows". All the files I want to edit are remote. I've got my terminal program configured so one click gets me a shell connection on a remote machine, then I run emacs (in text mode, i.e. -nw). All my files are there.
I watch my office mates who use Sublime struggle with moving files back and forth. Drag a file down from the server to their desktop. Edit it in sublime. Push it back up to the server. There's some kind of integration which takes much of the drudgery out of that, but it's still pretty clunky. Even if you used something like sshfs to mount your remote directory, it's still a lot slower (I'll often grep 100's of source files to find a function name; that would be deathly over sshfs).
Yes, you could run the sublime app on the remote machine, talking to the X11 server on your desktop, but that's pretty horrible in its own way. It does solve the problem of getting the editor close to the files, but U/I performance sucks over most real-life networks.
I will admit that the idea of customizing/extending my editor using elisp is just frightening. A cool idea 35 years ago, but at this point, it's absurd. I'm glad that there are still a few lovable fanatics out there continuing to maintain the language bindings I use, but it's clear that's at an evolutionary dead end.. The fact that Sublime uses Python is one of the things that makes it attractive.
Comment removed based on user account deletion
I've never understood why this war continues. Emacs and Vim unequivocally have a GUI. Status bars, split window, auto complete drop downs. Yet if you even talk about improving them the pitchforks come out.
It seems like they're so firmly wedded to the idea GUI=mouse that they can't even think straight.
Who uses a text editor that runs in graphics mode? I still have some old VT-220's that I actually use. Plus I often have various tools installed on a system other than my laptop (when you target ~10 different microcontroller architectures this can be a problem). I think one of the most appealing things of vi, emacs, joe, and nano is they don't require a graphics mode and work well over a low bandwidth SSH connection.
It's also nice to run a text editor in real full screen mode. There is little wasted screen real estate and I can actually use a decent font size. I think when most programmers are coding they are engrossed in the code -- so why litter the screen with something that isn't code?
I thought only I did that! :)
Yeah, there's no such thing better than VIM. Then again I have years of specialized configs for it and honestly I don't want to get new muscle memory.
<happiness>beer</happiness>
Is there a Linux text editor for the console that has an interface similar to MS-DOS Edit?
It really helps in those situations where you're trapped in the shell trying to fix xorg.conf, among other times.
MS-DOS Edit does pretty much all I could want from an editor, runs on thin air, and it has common GUI elements like the status bar, scroll bars and the menu bar which helps me greatly. (I suffer from option amnesia, and a general lack of giving a shit about learning the not-shown shortcuts of other editors.)
My wife is a software engineer and uses sublime exclusively. I am an academic, and have used only emacs for the past 20 years. Guess which of us makes more money...
Hear Hear,
I generally use vi myself, though I've actually forgotten some of the fancier stuff. I even have some muscle memory for emacs which I acquired because I had an Atari 500 ST back in the 1980s. Having cut my teeth on old glass teletypes (Uniscopes, Hazeltines, and even genuine VT-100s with the gold keys pad) I needed a basic term window and text editor for my Atari. The best text editor for the Atari that I could find on Usenet in the old binaries groups was 'Micro-Emacs', a very stripped down version of emacs, but in using it, my fingers learned CTR-E to go to the end of a line, CTRL X 2 to split a screen, etc. It's because of that that I still use emacs sometimes for very basic stuff. (I always install the -nox version). Heh, back in the 80s, I knew if I was on a fast computer at work if I could use emacs and it was responsive, which made Micro-Emacs, running on my Atari so well, all that much more impressive.
In theory, theory and practice are the same; in practice they're different. (Yogi Berra & A. Einstein)
I have yet to see anyone comment on this...
One advantage of so-called stone-age editors like Emacs and VI is that they don't clutter the screen with useless junk like toolbars, menus, project side panels, etc. I've got Emacs setup on each machine I use such that each pane, running 2 across or 3 across, almost exactly fits the width of the code based on the maximum line length called out in the coding standard we follow (giving a few characters of margin). I want as much code on the screen as possible in as large a font as is reasonable (to reduce eye strain). I also remove as much clutter vertically so that I get as many lines of code on the screen as possible.
I definitely do not want my editor to clutter my screen with menu bars, tool bars, scroll bars, project side panels, cute little multi-line consoles, big status bars, etc. that take valuable space away from the actual code window. I use my editor 8 hours every day, if not more. I know the editor's commands. I use my editor to write code, I want to see the code, not screen wasting cruft.
Some GUI editors, such as JEdit, let you remove some of the clutter; however, I have yet to see any GUI editor let you remove all of the clutter to the extent possible (or default) with Emacs or VI.
I can't believe this.
SlickEdit is the only editor that's both fully-functional (at least half as useful as emacs) and GUI-centric (learning not required). In fact it's the only one of the old powerful editors which get renewed into 21st century.
There are tagging support for dozens of languages, command help for mainframe assembly (!), semantic highlighting / symbol coloring, red-mark on non-existing functions/classes, c/java/xml formatting, and replace-in-files with two-pane diff preview which is extremely useful when you perform replace on dozens of files with multi-line regex.
It also loads faster than emacs, BTW.
After Archbang came out with the light iso with nothing installed, I found my self look ing for new options. I like the file tree in the editor that some of these options offer. Small sizes install too. Tea , Medit , Juffed
Nano.
It shows text, programmers "should be" able to edit text. Job done. Why overcomplicate it?
Remember, use it or lose it.
Well, we already have the Church of Emacs, I guess we might was well start the Church of Linus.
Our motto shall be "Despite his arrogance and occasional seemingly childish outbursts, in the end you will find that he was right".
Emacs is a great operating system, it just needs a good text editor.