So with the new website, which looks good, maybe emacs will seem more accessible and worth giving a try to new programmers who cross paths with it. At the same time, maybe that sense of accessibility is misleading given the learning curve of emacs that isn't exactly beginner-friendly. Nonetheless, I like the site!
I don't mean to complain about "open source" software nor do I claim that the way that Emacs is being developed is better than any other. What I mean to say is that Emacs is an old application and I found it on its old crusty website, decided to dedicate a bunch of time on learning macros, because that's simply the kind of person I am. Whether or not Emacs had a great website would not be the factor that swayed me, and frankly I'm not in the business of trying to sway people as an Emacs fan. Use what you want. I know I'm getting the best development environment for me, because I know me, and I've made Emacs mine.
I know for a fact that if the Emacs developers weren't
doing a bang up job, which they are, then I would
immediately allocate some of my time to help.
This in turn leads to all kinds of changes to appear more fashionable and appealing to the masses.
Frankly i think thats a fools errand. Seems to me that when it comes to fashionable in relation to computing, we are dealing with a Giffen Good (or perhaps even a Veblen Good). Meaning that to be a fashionable computing platform, it has to be an expensive one.
But in the process you end up with something similar to New Public Management for FOSS projects. Trying to evangelize and drum up attention as if they were pitching a for profit product, much like NPM tries to put market forces into public services.
Of course Emacs can get away with it, but this sets a good example of what a nice, simple website can look like for your project.
Don't spend too much time on the website, of course (the core project is what's important), but first impressions affect adoption, right?
This was already true back when I started using Emacs in my teens. Now that I'm middle-aged myself...
VS, Eclipse, and IntellijIDEA very likely won't.
And I say that as someone who doesn't use Emacs much -- I'd learned it at one point and used it pretty heavily for a job, with a very nice set of modes for a proprietary software tool I was using at the time, but made the critical career error of working for an idiot boss who didn't believe any software other than what the vendor provided was necessary on corporate servers.
So yes, I use vim.
But I've learned ... at least a dozen editors and development environments which are either dead or proprietary and not availa ble to me. Time which I could have devoted to learning persistent tools and extending them.
That's among the strongest arguments in favour of using Free Software tools generally, from a technical PoV. Your knowledge tends to remain relevant far, far longer.
VS was first released in 1997; Eclipse in 2001; and IntelliJ in 2001 as well. I wouldn't take that bet.
> VS, Eclipse, and IntellijIDEA very likely won't.
Why do you think so ?
Intellij and Eclipse are both open source. I suspect they will be around as well. The companies supporting them may go out of business, but there are enough users for it at the moment that someone will be able to keep maintaining it or build new businesses around it.
I'm actually thinking of picking up Emacs again as a preferred option to a browser.
Eclipse and Intellij may be open source (and I'm sufficiently unfamiliar with them that I'd blown that fact, thanks for the correction), but they're far narrower in scope. That itself tends to be a strike against. Even broadly-used tools -- say, Perl -- can be, pardon the term, eclipsed by others.
Mind to: learning multiple ways isn't a Bad Thing. But being highly mindful of what tends to survive and what doesn't is itself useful.
Emacs dates from glass TTYs, and has survived to mobile devices. I've seen enough of other tools to note the quirks of their own tech origins and how this has or hasn't limited them over the years.
So: consider mine a somewhat informed, somewhat uninformed opinion. Though I'd still strongly recommend Emacs as a durable, extensible, and exceedingly useful skill.
They do if those tips&tricks include basic editing functions, which is what you're talking about if you're comparing it to vi/emacs.
In fact, reading email and RSS/ATOM in Gnus is also a tip/trick, since it was originally written (in 1987) for Usenet.
I'm not at all saying that others should use Emacs for their email. I'm pointing out that Emacs customisation can involve far more than "basic editing functions", and that these customisations can continue working for decades.
The POV presented in that comment is basically a sales pitch. It's too standardized and common not to be (it pops up in most of these threads).
Leigh Van Valen's Law of Extinction, related to the Red Queen Hypothesis.
I don't know how well this translates to areas such as software, but it does give me pause.
Well, I hope they won't. But I'm sure their many common UI conventions will. Those conventions are shared between hundreds of thousands of apps already.
In 20 or 40 years, the Emacs UI will still rule only in a single program (and if we're unlucky maybe a few other tools still, like the readline library!).
As for vi, I'm sure some people will still be installing vi plugins everywhere to get 1/10th as smooth an experience as everyone else, and telling themselves they're more productive for it. Already these UI conventions developed for a line editor have outlived much of the generation that has ever used a line editor, so I'm sure it can go on for another 40 years!
Things I wish I knew about emacs earlier in life:
Emacs benifit plan volume 1:
* You will finally love the ui/ux for `info` pages
* macros (save and repeat a sequence of commands, commands can be applied to anything)
* registers (save locations in buffers, save text for later pasting)
* Frames (M-x speedbar for starters)
* modes (which to use and how to configure?!)
* built in documentation is awesome!
* what does this sequence of buttons do is only a `Ctr-h k <sequence of buttons>` away
* Mostly solid remote editing (tramp mode is no match for rsync on large files, luckily, RMS and friend have afforded us our freedom and we can configure this to our liking.)
* Freedom (as already identified by many people here but not by the word 'Freedom'. Also Freedom causes longevity. I have no source on this)
* Why is Freedom not number one on my silly list? If this were ORG mode I could bump it up to the top quickly.
* Excellent (multi-language (multi-language)) support. This is a recursive joke and the base case for me at least is English Bash. Emacs is language agnostic and language aware
* You will never have to write a 'throw-away' shell script ever again because emacs macros are that good. Still like shell scripting, incorporate shell commands in your macro.
* Carpel tunnel syndrom (cts) is a real thing, but, IMO, poor posture is more likely to give you health problems than cts. In reality, with Ctrl-R reverse search and Ctrl-S forward search, you can basically cycle through every command you have ever typed.
* Default key bindings in bash are emacs based and I actually enjoy the emacs bindings more than the vi ones despite spending lots of time in vim
Last reason: It's fun to play with a "real time display editor" and realize that emacs is an endless journey on the road to freedom in your ability to manipulate computation, however it may be expressed in years to come.
Also, use sticky keys (https://en.wikipedia.org/wiki/Sticky_keys)
I use all software with sticky keys enabled and I can't go back to a state without sticky keys. I wonder why others also don't use it. Stick with it for two or three full days and I am certain that you will love not having to press shift to capitalise text or how easy it is to press the Ctrl keyboard shortcuts in general. Not to talk about how easy it makes Emacs usage.
For exampe, to paste the URLs above, I pressed Shift with my left pinky and pressed Insert with right pinky one after the other, easier than contorting (it feels so now, after using sticky keys for some time, earlier it was okay) hand to press Ctrl-V. Also, to open and close brackets is real easy, tap Shift then press 9.
>I recommend trying out sticky keys if your OS supports it, because your hands really feels better. It takes a while to switch mindset e.g. from M-x to M x (pressing one after the other), but it’s worth it. No less effective and less stress in the hands. - https://www.emacswiki.org/emacs/StickyModifiers
In Windows I place the sticky key icon in taskbar where I can see it instead of placing it inside the tray so that I can see the state of keys so as to avoid any confusion.
Also, Sticky keys are system-wide as it is an OS provided feature. It makes life very easy, for example, to select text, just click where you want to start selecting and go to end of your selection, tap shift and click mouse, selected. I wish more people give it a chance.
Lisp systems are dynamic, you can extend/modify them on the fly. It's a bit ugly but for a personal experience it beats Eclipse plugins by far. Most IDEs are fixed and complicated to modify. The way they understand UI and UX are also often subpar (magit is way more effective than most IDE versionning interfaces I've seen).
Emacs ain't perfect (~fragile shell integration, old culture => weird defaults), but its value offset its warts.
ps: Oh, and I forgot, you also have a symbolic calculator. Always handy.
And because all of the modes share that emacs feel (except for the vi-emulation, I guess), that knowledge is transferable across every language you work on, instead of learning a new (possibly proprietary) IDE for each new language.
But suppose you're working with some random language that nobody's ever heard of. It's some tool-, product- or site-specific thing. If you're very lucky, there's some ropey Scintilla-based text edit widget that lets you work with one file at a time. If you're not, there's quite literally fuck all. When you search on Google, there's 0 useful results (until you get to page 9, and there's 1 single post from somebody, on some random forum for general blarney, ranting about how they're doing some contract work and using this stupid language and it's terrible because there's no tools and they're stuck using notepad and their life sucks).
If you've got an IDE, now you're sort of stuck. Maybe you can find a language it supports that's a bit like, and then you've got syntax highlighting - sort of - and autoindent - maybe. But you have to do code browsing by grep, effectively, and you've got 0 in the way of code completion.
With emacs on the other hand you can relatively easily code up some language-specific support for syntax highlighting (takes 5 minutes) and autoindent (5 minutes for something basic, maybe 1-2 hours if you want to get fancy). Add some imenu regexps (5 minutes) and you've got code browsing from within a file. Put your imenu regexps into Exuberant Ctags (15 minutes), and you've got cross-file code browsing. Code completion... well... yeah... it's not perfect, but if you squint a bit, dabbrev (2 minutes if you need to tweak your syntax categories) is fine.
I've never failed to turn a time/effort/hassle profit from doing this.
But Emacs (and Vim) offer you superior text editing, if you can be bothered to learn it. Semantic navigation, convenient incremental search, semantic editing, keyboard macros, etc. etd. - you can do much more in fewer keystrokes, which is important in keeping yourself in the flow. In Emacs, you get all the benefits of highly optimized keyboard navigation and editing for every task you'd like to do - writing code, managing files, inserting simple and complex code templates, managing projects, complex work with Git repositories, etc. - and it's all consistent - you can do the same regex incremental search in e.g. your commit logs as you do in your source files.
My overall personal impression about Emacs is that it's the most efficient environment optimized for anything text-related out there (especially if you switch to vim keybindings for text editing and navigation, which are arguably smarter).
"Semantic navigation", "incremental search", "semantic editing", "keyboard macros", "optimized keyboard navigation", "inserting simple and complex code templates", "managing projects", "complex work with Git repositories", "regex incremental search"
C-h f : find help for functions
C-h v : find help for variables
C-h k : Get help for a key-combination
If you have helm mode installed it's often very easy to find the functions you are looking for.
Among other things, I'm current developing some code for an Atmel chip. The environment for this is Atmel Studio (VisualStudio based), which has excellent Intellisense based autocomplete/navigation etc.. The thing is, I keep finding myself using emacs. Apart from the obvious 'force of habit' reasons for this, I think there are two factors:
1) Even with the autocomplete I still code faster in emacs. The various features like being able to load up multiple files at once on split windows, better facilities for swapping code around (I could go on) mean that it just goes faster. I still use the IDE for bits and pieces - it's particularly convenient for when I'm using unfamiliar parts ofthe hardware libraries - but I keep going back to emacs.
2) Developing for the Atmel is only ONE of the devices I'm targeting at the moment. I've got another ARM device (using Keil), a whole host of Python bits and pieces, a Windows GUI app. Being able to write the code for all of these in one place is unmatchable. Particularly as they interrelate and share code. It even helps the style look the same (where appropriate). A well configured emacs gives you a great development environment for anything.
So should your text editor (and/or it's companion programs)
> and provides superior auto-completion.
See above. Superior is a bold claim, superior out of the box for "strongly" supported languages, perhaps? (Eg: one way of working with java in vim is to use eclipse for extracting some information about a project)
Personally I'm more familiar with vim, than with Emacs -- arguably the main difference is that Emacs has one standard and sane scripting language (lisp), while vim doesn't (I'm very happy a lot of masochists work tirelessly to provide vim plugins for everything I need (and a great deal I don't) -- but I think it's hard to argue that vimscript is a "good" language. And having other bindings (eg: ruby, python) is a bit of a mixed blessing)).
But what they have in common, is a strong focus on making it easy to automate transformation of text. Any kind of text. With any kind of automation, via commands. As such they empower a continued process of improving the process of writing and editing.
I like Moolenaar's (vim's creator) short text and expanded talk on 7 habits of effective text editing:
"7 Habits For Effective Text Editing 2.0":
"Seven habits of effective text editing":
I often feel that modern IDEs with typical "modern" languages, tend to trap you in a certain way of working that is "with" the IDE, that tend to be counter-productive if that "one true (editing) process" doesn't fit. And they tend to provide only something like 70% of the benefit of a true IDE, like a Smalltalk System coupled with a Object Database, or something simpler like a complete Forth system.
For better or worse, all current popular programming systems (that I'm aware of) has the hopeless abstraction of program text organized in file system files in folders (often coupled with half-integrated resource files, be they xml-layout, binary images, fonts or other stuff).
So no IDE can be effective, because the central abstraction remains only half-structured text, and you can only get that far with strapping semantic analysis on top. So as long as you're (forced to) working with text, programs that enable text editing and transformation will have an edge.
I don't think there's a wall between the two: you might want to use something like , or vim-mode in IDEA or something -- but if you want one effective tool to work with: Documentation, a handful of mark-up languages, a data language (like SQL), and a handful of programming languages (eg: assembler, C/C++, python), patch-files and perhaps writing email -- then I think text editors are going to be a good investment.
I do think that text editors (for writing code) is a kind of local maxima - but if we want to stick with traditional files and file systems (probably a terrible idea), they do help facilitate tools that have somewhat loose coupling (between editing, debugging, high-lighting, re-factoring, formatting) and I think that helps keep systems portable (you can take a similar set of C++ files and preform a similar set of transformation (with completely different tools) on Linux and Windows and end up with (different) binaries that preform a similar function.
Another great video that I think demonstrates text editing as different from "just" an IDE, is Russ Cox' short intro on ACME:
"A Tour of the Acme Editor":
In short, I suppose text editors are a superior user interface for interacting with text-like structures in general. The relative benefit for programmers depends a bit on what kind of system you work with: I'd prefer a simple, less verbose language, like Kotlin coupled with a plain editor, to an IDE coupled with more traditional Java (esp: Java 5) -- I firmly believe auto-generated code is a dark pattern: if it can be automated, it should be moved to a run-time or a library so that it can be maintained in one place, rather than leaving dead and possible buggy code in dark corners of a large code-base.
But then there's everything else.
If I have boilerplate that I need to set up, building a yasnippet template is a piece of cake. If I need syntax highlighting, it's almost guaranteed that someone has gone down that road and has a mode already set up. If I need to migrate to a new machine, I pull in my .emacs from my git repo.
Little things that might be a challenge - like opening a file over SSH or needing kerberos authentication in order to edit a file - are challenges that have long since been dealt with.
There were two videos that brought me back to Emacs after years of using other editors - one was about python development in Emacs when I was looking for a python IDE, the other was a video about org-mode.
It took me two weeks of forcing myself to use Emacs before the muscle memory came back and I started preferring Emacs over vi again.
I wouldn't be too concerned about whether or not you should migrate to it. Use what you know. When you have a need for the power of emacs, you can safely ignore it the first five or ten times it pops up.
Eventually, you'll wander into a video how-to like I did and turn to the dark side. Or not.
I've noticed that a lot of people who use IDEs can't use anything else. Want to build an Android app? There are people who can not build an Android app without eclipse.
After learning Vim I was able to use it just like an IDE and I felt like I had a better understanding of how the projects I was building actually work.
Any advantage gained from the interface are small enough that they're not worth introducing another mental mode for. Any time you sit down at a keyboard and have to mentally remap ("copy works differently here", "shortcuts are different here", "that thing you do all the time must be done in a very different way here"), it's mental capacity out the window. When you do a task, you want your interface to be as similar as possible to the interfaces you're used to when doing related tasks.
Emacs could have become the common, core interface for working on a computer (unlike vi, I'd say) - but it didn't. The common user access standards that you're used to in VS, Eclipse and IDEA did. Spend your time mastering those instead, it will give far more transferable and valuable skills.
That's true, which is why I use only Linux, only StumpWM, only emacs. Using anything else slows me down and gets in my way.
> The common user access standards that you're used to in VS, Eclipse and IDEA did. Spend your time mastering those instead, it will give far more transferable and valuable skills.
There's nothing to master, because the languages those tools offer aren't expressive enough to require any mastering. They're two steps above pointing and grunting, while emacs is poetry.
I started to learn emacs in 2006 after a friend show it to me in it's no-window version in a OS X Teminal. We were at the time art students and most of us didn't have programing education. Some people were playing a bit of advanced flash or Max (proprietary Pure Data sound processing), but most of us were doing performing art, sculpture, sound or painting.
Honestly, I have been so motivated by what I discovered, that, the learning curve hasn't been so bad. The folkloric keyboard shortcuts were easy to memorize and the software never failed me. I stopped using Text Edit and the horrible .rtf format and I learned that plaintext was surely more appropriate to write poetry. And wait what is it? Markdown?
I started to open mp3s in text mode and grep into videos. It was really exciting. It was possible to open incredibly huge files in text mode, and the computer was still usable. Wait... Why common browsers slow the machine down when you try to open Gmail then?
I discovered a land of wonder full of funny animals, meaningful laws texts (I mean GNU license) and documentation to read until the end of your life.
In 2008 I ordered GNU Emacs Manual 16th edition with a tee shirt, the reference card is still on my desk.
This piece of software is usable, accessible, documented, and it is still possible to use it 30 years after it's creation. Let's be honest: what is the aim of having a fast-learning-curve if you learn tools that you won't use in 2 years. If the tool is a bit hard to learn but we'll designed, it maybe worth the effort.
Sounds like a personal problem to me, I love most of the GNU projects' pages. Simple, readable, low-bandwidth, to the point.
https://web.archive.org/web/20160101125451/https://www.gnu.o... for ex
All kidding aside though, it seriously is. It's not a bad piece of software.
A download link is less useful if you want to find out about an editor vs just trying it (especially with Emacs when you first open the program, the killer features are not immediately apparent).
The old site showed a change log, which seems much for like a site for current users than a site for new users.
It often tells quite a lot about how involved the developers are, what direction the project is heading to, or how mature it is overall.
Also you can pry Magit from my cold, dead hands.
"e.g. commands that act on regions should act on lines when no region is selected"
The way Emacs was (and is) designed to work is that all region-based commands simply apply their function on the characters between point and mark. Since there isn't any "selection" as such, talking about what commands do without the selection simply does not make sense.
Now, in (what I consider to be) a misguided appeal to users of "windows style" editors, Emacs introduced the concept of "active regions". The underlying concept of having a point and mark is still there, but there is now also a flag indicating whether a region is "active" or not. Commands can look at this flag to perform different operations whether or not this is the case. Since several years, active regions has been enabled by default in Emacs.
The problem when having active regions enabled is that in many cases the user has to reactivate the region before performing some operations, making many region-based operations much more complicated to use.
I seem to have become to the go-to person for Emacs support at my workplace, and I have seen a lot of new users being confused about regions in Emacs. Instead of adding even more Elisp code to try to coerce the application into behaving more like Notepad, I typically recommend them to turn off active regions and learn Emacs the way it was meant to be used. It's certainly different from most other editors, but the behaviour makes a lot more sense once you pick it up.
 I used the word "complicated" to mean "needs more keypresses".
Don't you see it as a problem? Anyone new coming has to go through all the history to get an understanding of why things work the way they work. Other software evolve over time and follow practices that result in better UX.
A lot of modern software uses the 'opinionated' approach. The designers come up with their preferred way of using the software product, and build the user experience around that. This gives great results a lot of the time - you get a consistent and unsurprising experience and you can build a very intuitive experience. To pick a silly example of this, Google Chrome tries very hard to prevent the expansion of extra 'settings'. That way everyone is using the browser in the same way (this has security benefits too).
Emacs goes completely the other way. It gives you the tools to tweak absolutely every aspect of your usage, and while it may have some defaults it isn't really opinionated about which is right. It's been said many times - emacs isn't a text editor, it's a platform on which developers can build their own ideal text editor.
That isn't to say that there aren't some silly things in the defaults, but the emacs developers appear to continue to actively tweak the defaults in the direction of being ever more sensible.
My point was that it wasn't the ONLY approach. It appears to be the best one for mass market consumer products, but developers do so many different things in so many different ways that a different approach might be more appropriate. Based on emacs' enduring popularity with a large chunk of users, it would appear that a lot of people agree.
I use ace-jump-mode for almost all of my movement. I can go straight to where I want to with a fraction of the effort.
The previous site https://web.archive.org/web/20150522051725/http://www.gnu.or...
The new site on the 20th of April https://web.archive.org/web/20160420170002/http://www.gnu.or...
BTW, the website looks really nice. Kudos!
EMACS is from the 1970s, GNU Emacs 1980s...
I'm all for lean sites but emacs' site is one of those where I just don't care. Emacs users are sitting in front of a workstation and if they don't have a proper internet connection, they just install it from their unix distribution's CD/DVD.
And it is also kind of adequate to have a bloated website... anyone remembers the joke to name a kernel "emacs" so that it says "LILO booting emacs..." at startup? ;)
Or, more appropriate when explaining why it's not a good fit for touchscreens:
Esc Meta Alt Control Shift
Looking at the source for <http://www.gnu.org/software/emacs/fira.css>, I can't help but wonder if mobile^W OS vendors could make the Web faster for their users if they'd just bundle every single popular free (beer and/or speech) font with their OSs and keep the fonts up-to-date.
Of course, you should be sending along far-future Expires and Cache-Control headers, but this'll still be slower than local() accessing fonts that're bundled with the OS when someone visits a new site.
... what can be said now about the relative sizes of GNU emacs and its own WWW page? (-:
I clicked the link, came back, and read this commend. Doesn't mean much, but it would have helped if the site was a tad smaller.
Its manual page (herewith a slightly outdated version) calls out the ISO/IEC 8613-6 parameter separator problem in its section on differences from real terminals and documented standards.
But don't complain, better submit a patch. Or help ironing out the one linked above, it's unfinished.
If I hadn't then why would I say so?
But what use is there to complain to them? None of them sound to be anywhere close to the Emacs development.
I just think the graphical Emacs provides the most comfortable environment. It displays images (and thus also PDF files or a graphical browser widget), doesn't swallow the Alt key by default, has prettier colours, and you still get to edit remote files with TRAMP.
This doesn't mean that Emacs in a terminal should not be improved. I sometimes use it when I ssh into my workstation from a machine that doesn't have Emacs installed.
Me too. He often asks for corrections in light of these types of oversights (at least, it looks like an oversight to me).
Fedora, i.e. Red Hat, is very distinct from Debian. A Debian software package is not guaranteed to work on Fedora, nor is a Red Hat package guaranteed to work in Debian. Both try to be semi-compatible with each other, but that does not make them identical.
A common name used in the past is "Unix" or "Unix compatible", but then what is not Unix compatible today? We could be talking about Linux compatible, but then, the vast majority of programs will work on BSD kernel as well as Linux kernels, while having stronger compatibility demands on distribution-specific technology. Maybe "systemd" or "systemd compatible" should be the new OS name?
If you tell me the distribution of your OS, it will tell me enough information to make or identify compatible software. What property is more important than that in a name?
I'm still surprised at how few there are.
This explains why many are not considered free, though the summary could simply be "the Linux kernel contains non-free blobs" and "they haven't promised not to allow non-free in their package repo's"
2) I look into a lot of videos about Emacs.
3) I've noticed that, recently, many of these videos and screenshots are by people using OS X.
4) Someone wondered about an OS X video on the Emacs site.
5) I pointed out #3.
Yes Unix is not Linux, but I see OSX widely used at hackathons and conferences because of its underpinnings.
Obviously the use case in point doesn't come under that though. :)
Yes, it's pedantic, but this GNU we are speaking about.
In the end, an editor is a productivity tool, and the best way to evaluate it is seeing it in action as part of a workflow: video is an excellent format to capture and share this with newcomers.
Given the emacs flexibility I was able to configure Emacs to implement majority of IntelliJ keybindings. There usually is an equivalent emacs function of package for IntelliJ behavior, e.g. M-x and IntelliJ "Find Action". Emacs helm works a lot like fuzzy matching in IntelliJ. Sometimes I only implement the "similar" behaviour, e.g. "Show usages" vs "Grep for text at point in current project" in IJ. I will be writing a blog post about it at kozikow.wordpress.com, but if you are interested now now I can send you my .emacs.d.
In this setup I can just setup "fast, always works and easy to set up, but not too powerful" code navigation using ctags/ggtags, grep/ag and projectile in emacs and avoid packages like EDT, eclim-emacs or Jedi that are more powerful, but sometimes require custom per repository setup, or are slow. I usually have both emacs and IJ opened and switch between the two. I have a keybinding in both editors for "open current file in the other editor" (emacsclient + external tool in IJ).
So in the spirit of motto of Spacemacs - "The best editor is neither Emacs nor Vim nor IntelliJ, it's Emacs and Vim and IntelliJ!"
Apparantly ycmd can do C#, Rust, Go, JS etc. as well now. I like this way of putting such "IDE features" (meaning the programming language-specific features) into editor-agnostic deamons; that way good completion/navigation is available to all editors. The same idea is behind eclim (as you mentioned) for Java and merlin for OCaml.
The idea is at least as old as SLIME, which has been the defacto common lisp mode for Emacs for ages. When I was using it nearly fifteen years back it was easily the most comfortable development environment I had used in any language.
Personally, I think that Emacs is one of the best editors. Not so simple to use (you may think if you are going to start without a tutorial), but, definely... very strong and personalizable.
I prefer to not compare with IDEs. The advantages of IDEs is that they have a particular UI and a set of tools focused for a particular language/development tool. This will allow you to have an initial set of features. Ready to use. Without spending your time to work on personalization. You may think to IDEs as editors with a restricted set of features (compared with emacs).
resists urge to make emacs joke about this
Duh. Don't know how I could have missed that.
But who needs Apache? Just M-x package-install elnode, and you've got yourself a web server.
Joking aside, looks really nice!
I've discovered [evil](https://www.emacswiki.org/emacs/Evil) a few days ago and I'm in love.
However, watching people try to use vim without wanting to, or taking the time to learn it, just made everyone less efficient, and even more painful to watch.
If you want to learn emacs, then do it. But do it because you want to, or have a need to.
Other than that, emacs has first class plugins for pretty much anything, is easy to extend, and your config and extensions are easy to back up or move to another machine, and can be expected to still work.
If you are ever in a situation where you are working on a remote system over SSH (possibly with low bandwidth) you will appreciate it. Also your terminal is in emacs mode by default, so all your shortcuts work there as well. Finally if you are an OSX user all of your _text fields_ understand emacs shortcuts as well :).
Note: I tried Sublime for approximately one year and don't use it anymore.
(Obviously this has nothing to do with agreeing/disagreeing with his views.)
> people like you
This comment breaks the HN guidelines by being personally abusive. Please comment civilly and substantively, or not at all.
We detached this subthread from https://news.ycombinator.com/item?id=11656193 and marked it off-topic.
We detached this comment from https://news.ycombinator.com/item?id=11656415 and marked it off-topic.
I don't want to live in a world where I can't like formal verification and modern website design