Just an anecdote about the older site. I was in a comp sci class at school a year ago. My classmate next to me asked what editor I use because it was a Beginning C++ class, and I said emacs. He went to the website which looked incredibly outdated to the expectations of new programmers, and just felt uncomfortable giving it a try. He opted for an editor with a more modern website.
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!
Personally it has never mattered to me how many people adopt Emacs because it has enough users to ensure development forever. 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.
Emacs is emblematic of the community aspect of software development that rms usually brings up when talking about free software, and I think it's a subtle notion that separates Emacs from a typical "open source" project. Projects that are as they say "Open Source" tend to be commercially oriented more than community oriented.
Whether or not Emacs is a large or small community does not really matter to me, the software is pretty much stable enough that the future is bright even if everyone on the developer mailing list dropped dead.
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.
Today I had to use non emacs windows editors for an hour. All of them a subset of what I'd like. I grabbed a copy of emacs for windows build. My blood pressure lowered as I saw the splash screen. Freedom and extensibility. It's impossible to fully appreciate right away. But having an appealing website is always good.
>the learning curve of emacs that isn't exactly beginner-friendly
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.
Talk about judging a book by its cover. Did he say anything specific about the source of his discomfort? If I'm looking for a text editor, I'm not sure how it matters whether or not its web site is full of images, fonts and colorful reactive javascript modern HTML. All I need is a download link.
I'm not sure the new design is a good thing because using Emacs is like entering another world. If newbies have the impression that it's just another editor like all the others with fancy websites they will be quickly disappointed. On the other hand, if they are looking for something that challenges their understanding of what an editor, or software for that matter, should be then they may be motivated to overcome more hurdles such as an archaic homepage.
>He went to the website which looked incredibly outdated to the expectations of new programmers, and just felt uncomfortable giving it a try. He opted for an editor with a more modern website.
Sounds like a personal problem to me, I love most of the GNU projects' pages. Simple, readable, low-bandwidth, to the point.
As someone semi-new to using emacs, (I knew basic keybindings but never bothered to set up init files, etc.) coming from the IDE world, my biggest complaint was the amount of things I had to do to get vanilla emacs to behave in a civilized way, even using the GUI version. I spent hours scouring peoples emacs files on GitHub to try and find all the things that looked "obvious in retrospect" and settings that looked silly to have turned off by default (e.g. commands that act on regions should act on lines when no region is selected). Then my second biggest complaint was the analysis paralysis of all the plugins. I'm starting to get a stable emacs file, after a few months, but there's still several pieces of functionality I miss from my IDEs that I chunk out time every now and then to research and add. I think having a "if you're coming from IDEs you may want to install X Y Z" page would be helpful, as well as package download rankings so that people can find the popular projects (e.g. helm, use-package). It should also be prominently encouraged to use something like guru-mode where it disables the arrow keys to force you to use ctrl and meta as your movement keys.
There are historical reasons for pretty much all default settings. For example, you said:
"e.g. commands that act on regions should act on lines when no region is selected"
This is because traditionally Emacs never had the concept of "no region selected". The way it Emacs works is that it has two markers: "point" (which is just the cursor) and "mark" which is another position somewhere in the buffer. You can set the position to mark to that of point by pressing C-SPC. In fully traditional mode, the position of mark nor the selection is ever actually displayed in the buffer. If you press C-x C-x, the locations of point and mark are swapped, allowing you to quickly jump to mark and then back again.
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[1] 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.
Footnotes:
[1] I used the word "complicated" to mean "needs more keypresses".
The obvious point is that everyone disagrees about "settings that look silly to have turned off by default".
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.
Looks nice, but having a 1.1MB webpage with 7 different fonts seems somewhat wrong to me... We should start thinking about mobile clients who have to pay these MB.
It would be nice, if they will merge patches [1] for truecolor (16M colors) support in their console incarnation of emacs. Both Vim [2] and Neovim [3] already did this. Since most terminal emulators now support this mode [4], that will improve syntax highlighting and theme customizing to a new level.
I switched back to emacs last month after 10 years in ides, vim and sublime and my hands still remember the key combinations. It's nice, like going back to an old favorite pair of shoes.
Also good to see the changes like the elpa/melpa stuff.
It looks real snazzy and nice. But I always liked that the GNU project did not try to look like the latest fad out of SV. Their low-fi HTML4 approach meant they could be browsed in anything and still be perfectly readable.
Another piece of "marketing" collateral that can help popularize Emacs is a "tour of Emacs" video. Awhile back, I watched Russ Cox's "Tour of Acme" video and became an Acme convert as a result.
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.
My thoughts exactly. Personally, that's why I can't justify spending all that time trying to figure out a text editor when I could be, I don't know, working.
They also have a good project [1] of migrating Emacs codebase and plugins support on Guile - partly by adding Elisp support in Guile, partly by rewriting Emacs itself.
There is lots of IDE vs emacs discussion in this subject.
I have been using primarily (IntelliJ+IdeaVim) and sometimes (Emacs+evil) for the last few years.
If I want to write big, complex change in a codebase in Java/Scala/Python/Javascript I would use IntelliJ. Yet IntelliJ doesn't work well in many corner cases, like very big codebases, projects in C/C++ or languages not officially supported by Jetbrains, cross language projects (even with IJ Ultimate), remote editing or just quickly opening some github repo without spending time on any project setup. And extra emacs packages like magit and org-mode are irreplaceable.
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!"
I haven't had to java in a long time, but for C++ I find ymcd (based off vim's YouCompleteMe) well worth a little effort to set up. Get the daemon at https://github.com/Valloric/ycmd and emacs package at https://github.com/abingham/emacs-ycmd It gives "intelligent" completion and code navigation, just like you'd expect from IDE's. For the per-project setup, I typically just copy-paste the config file from another project and perhaps tweak some include paths in it.
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.
A lot of text editors have a 1% of emacs power but a great web site and a great interface. This help them to shine in the IDE/Editors jungle. So, this new interface, will help emacs (from a "marketing" point of view).
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).
Does anyone know of a fun and engaging way to learn emacs, like VIM Adventures? I sit and stare at a list of emacs hotkeys any time I want to give it a shot and my eyes glaze over.
I'm not sure it's worth learning the emacs key bindings for text editing if you already know vim. Just turn on evil mode and use that. I could be totally wrong here but I haven't seen any real defenders of emacs key bindings. seems to me that people are used to them and they do the trick, but vim is considered more powerful for pure text editing. Using emacs is still great for a host of other reasons though.
It's interesting that they used jquery (MIT licensed) for the web page, and also interesting given RMS's dislike of the use of Javascript. http://www.gnu.org/philosophy/javascript-trap.en.html. MIT is GPL compatible, admittedly, so his main concerns about Javascript probably don't really apply here.
I use it as my primary editor. Works pretty much out of the box, unless you need image support, in which case you have to download dozens of different dlls for each image type.
[+] [-] justinsingh|10 years ago|reply
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!
[+] [-] maplant|10 years ago|reply
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.
[+] [-] flatline|10 years ago|reply
[+] [-] agumonkey|10 years ago|reply
[+] [-] smonff|10 years ago|reply
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.
[+] [-] ryandrake|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] reedlaw|10 years ago|reply
[+] [-] wcummings|10 years ago|reply
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
[+] [-] AckSyn|10 years ago|reply
All kidding aside though, it seriously is. It's not a bad piece of software.
[+] [-] _asummers|10 years ago|reply
Also you can pry Magit from my cold, dead hands.
[+] [-] lokedhs|10 years ago|reply
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[1] 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.
Footnotes: [1] I used the word "complicated" to mean "needs more keypresses".
[+] [-] rkangel|10 years ago|reply
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.
[+] [-] michaelhoffman|10 years ago|reply
[+] [-] catern|10 years ago|reply
[+] [-] ZenoArrow|10 years ago|reply
http://spacemacs.org/
[+] [-] indigo747|10 years ago|reply
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...
[+] [-] theunamedguy|10 years ago|reply
[+] [-] Faaak|10 years ago|reply
[+] [-] xvilka|10 years ago|reply
[1] http://emacs.1067599.n5.nabble.com/RFC-Add-tty-True-Color-su...
[2] https://github.com/vim/vim/commit/8a633e3427b47286869aa4b96f...
[3] https://github.com/neovim/neovim/commit/8dd415e887923f99ab5d...
[4] https://gist.github.com/XVilka/8346728
[+] [-] jimjimjim|10 years ago|reply
[+] [-] satysin|10 years ago|reply
[+] [-] bitwize|10 years ago|reply
[+] [-] oneeyedpigeon|10 years ago|reply
[+] [-] masolino|10 years ago|reply
[+] [-] ktamura|10 years ago|reply
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.
[+] [-] rpgmaker|10 years ago|reply
[+] [-] sotojuan|10 years ago|reply
[1] https://www.gnu.org/software/guile/
[+] [-] xvilka|10 years ago|reply
[1] https://www.emacswiki.org/emacs/GuileEmacs
[+] [-] nanory|10 years ago|reply
[+] [-] alain_gilbert|10 years ago|reply
[+] [-] pwelch|10 years ago|reply
[+] [-] terda12|10 years ago|reply
[+] [-] kozikow|10 years ago|reply
If I want to write big, complex change in a codebase in Java/Scala/Python/Javascript I would use IntelliJ. Yet IntelliJ doesn't work well in many corner cases, like very big codebases, projects in C/C++ or languages not officially supported by Jetbrains, cross language projects (even with IJ Ultimate), remote editing or just quickly opening some github repo without spending time on any project setup. And extra emacs packages like magit and org-mode are irreplaceable.
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!"
[+] [-] unhammer|10 years ago|reply
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.
[+] [-] benkuykendall|10 years ago|reply
http://i.imgur.com/5mLJdXb.jpg
[+] [-] bitfox|10 years ago|reply
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).
[+] [-] apatters|10 years ago|reply
[+] [-] rashkov|10 years ago|reply
[+] [-] joshumax|10 years ago|reply
resists urge to make emacs joke about this
[+] [-] chris_wot|10 years ago|reply
[+] [-] benbristow|10 years ago|reply
Joking aside, looks really nice!
[+] [-] rvern|10 years ago|reply
[1]: https://gnu.org/software/guile/
[2]: https://gnu.org/software/octave/
[3]: https://gnu.org/software/guix/
[4]: https://gnu.org/software/grub/
[+] [-] Twirrim|10 years ago|reply
[+] [-] rekado|10 years ago|reply
[+] [-] typon|10 years ago|reply
[+] [-] tetheno|10 years ago|reply
http://www.gnu.org/software/guile/
[+] [-] eulji|10 years ago|reply
[+] [-] groovy2shoes|10 years ago|reply
[+] [-] Grue3|10 years ago|reply