What is the benefit for an existing CS student to switch to Emacs who is already comfortable with using IDEs like Visual Studio, Eclipse or IntellijIDEA?
In 20 or 40 years, emacs will still exist, as will the hooks and tools you've integrated and built up to support it.
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.
>In 20 or 40 years, emacs will still exist, as will the hooks and tools you've integrated and built up to support it.
> 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.
Emacs is a very general and fundamental tool. It's "do one thing well" is "organise textual interactions, via lisp". And that ranges from editing to shell to numerous programming environments to email to web....
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.
There is a difference between brand/product name and product itself. As @dredmorbius mentioned in a sibling comment, IDEs by definition do not "do one thing well" - various tools are integrated with varying degrees of tightness. Take old VS project, old Eclipse workspace and they have to be first converted to a new format. How can one be sure that there is 1:1 mapping between old and new formats?
Having worked on VS6 does not guarantee that old tips&tricks will be valid in VS2016 or VS2030. Imagine if they decided to switch from VC to clang - it is integral part of VS and cannot be dismissed. Even though I'm not emacs user I'm pretty confident that overwhelming majority of what I learn today about the tool will be valid 20 years later.
My "tips and tricks" include how to read email and RSS/ATOM feeds in Emacs, which I do using Gnus.
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.
Point is, if you use emacs and vi, you're stuck doing basic editing functions in a different way than the rest of the world. We see vi users adapt to this by trying to cram vi plugins into everything, and emacs users by trying to cram everything into emacs.
After witnessing many of these discussions, it's just FUD. Just because Emacs is older doesn't mean that IntelliJ or Eclipse aren't likely to follow you until retirement. Java hit critical mass a long time ago and both IDEs have mass adoption and are also OSS, as you mentioned.
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).
There is an interesting rule from biological evolution of rates of extinction with species age that I'd thought of in relation to this. Essentially: they're constant. That is, a species is as likely ro go extinct when old as young: there is no increased survival probability with age.
Leigh Van Valen's Law of Extinction, related to the Red Queen Hypothesis.
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!
Disclaimer: I have only used vim and emacs, so I really don't know what an IDE can do.
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.
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.
Yes they are nice. I always become indecisive when it comes to assigning keys with keychord.
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.
In a job setting, don't. Integration is more important at first. Emacs is a way of life. You got a lisp, with beautiful libraries (binary parser, ~bnf parsers, hashtables, trees) that allow you to parse, interact, render data as you see fit at the tip of your fingers.
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.
There's a subtle benefit that I haven't seen any of the other comments describe: the UI is made up of text, and I don't mean that in some curmudgeonly "things were better back in the day" way. I mean that all of the commands you use for navigating and manipulating text, moving between frames and windows and so on all use one consistent interface. With magit, I can be editing a file, hit Ctrl-C, g, then do some git manipulations and switch back to my work with a much smaller mental context switch.
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.
Completely agree. I often got frustrated that the "modern" featureful IDEs don't allow me to incremental/regexp search in drop-down menu items nor to use set-mark-command + kill-ring-save keystrokes within dialog messages.
If you're working with something else than C#, Java or the like (i.e. languages that benefit hugely from features offered by IDEs (or that require IDEs to write in them and stay sane - if you're not feeling charitable)), then yes - benefits of speed, flexibility and efficiency. That's without even bringing up the topic of org-mode... :).
Can you give me some example of efficiency? I've always thought IDEs are more efficient, i.e. intellij IDEA indexes everything and provides superior auto-completion.
For your ordinary average everyday normal well-supported language, stick with the IDE.
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.
Too much clicking in the IDE, though I guess this complaint goes more towards Eclipse than IDEA :).
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).
I'm using emacs for a year now but I'm reallt bad at it, I wish there was a text like your comment with the words linked to specific webpages or videos which explain how to install everything you need for that word and show how to use it. I would link:
"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"
You're probably right about the autocompletion. I've never been able to get it to work particularly well in emacs (although I'm probably due another attempt). If you're focused on a particular target with a good IDE (i.e. Visual Studio, something by IntelliJ and probably nothing else) then they can be a good tool to use.
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[1])
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:
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 [1], 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:
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.
The benefit is customization to your needs to make your unique workflow faster. There is a reason people spend tweaking their ".emacs.d" configurations - it just makes them so much faster. For example, I use a light theme in office because I have a glossy monitor and I prefer a dark theme otherwise, so I wrote a few lines of elisp to choose the light/dark theme based on the time of day and day of week. Try doing that in other editors / IDEs / etc. :) Of course, I'm quoting a trivial example here, but this is a glimpse to what is possible.
I'm an emacs evangelist and I'll use Eclipse or IntelliJ for Java. I have half a mind to just use a windows VM for visual studio because I think it's a great Python IDE.
But then there's everything else.
I've looked a great deal for a decent javascript IDE and I have yet to find one outside of Emacs. For a lot of languages I end up using in short spurts, I appreciate having a text editor that can do what I need it to do, and can do it consistently regardless of what I throw at it.
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.
For me, when I use an IDE I feel like I'm learning/using the IDE, not the language it self. I found that I was somewhat dependent on the IDE. Then I switched to vim and started learning how to actually build projects from the ground up.
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.
No genuine ones. There are some extremely few ones, but they're all related to "some people use emacs and it's good for you to fit in with them" (for instance, I recall a proof assistant some years ago which was painful to use without the associated emacs mode).
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.
> 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.
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.
