In my experience, Emacs is excellent if you take the time to set it up to do as much as possible. Manage work with OrgMode, read email with any number of packages, edit code in one of the supported languages, send and receive messages. The less you have to leave the application, the more productive you are. There are 2 issues with this, the first is the sheer number of packages you need to install. Packages are a mixed blessing because they add so much, but if the person who wrote it stops working on it, you now need to take over or find something else. The second is the configuration. If you're willing to do all that work and keep it running, that's awesome.
> Packages are a mixed blessing because they add so much, but if the person who wrote it stops working on it, you now need to take over or find something else.
I know Spacemacs brings in a huge bunch, do they have any way to mitigate that?
I've been using Emacs for over 15 years now and I do almost all my work in it. The two things that I still haven't found good solutions for in emacs are available out of the box in almost every editor today:
1. Autocomplete of methods, classes, variables etc
2. Auto import statement organisation
Yes I am aware of JDEE for #2 and I am aware of emacswiki/autocomplete but none of those solutions are as smooth, well integrated or work well enough like they do in atom or visual studio.
If someone was to rethink the problem from the ground up and solve it in an elegant and efficient way my life would be complete.
Emacs features vary wildly in support from language to language - in Go, for instance, it's very easy to get both those working, while in Java it requires something more complicated such as eclim. company-mode is by far the best completion frontend, but the quality of the completions is dependent on how good the backend is, which varies a lot.
It basically takes the power of eclipse and runs it in a lightweight daemon, then ports most of the features (auto completion, refactoring, automatic imports, etc) directly to emacs.
I actually switched back to Rstudio, which has everything ESS has to offer (eg helm style autocomplete) plus much better autocomplete for tidy verse pipes.
I have not really used Rstudio, so I can't compare. I tried RStudio first, but then I was up and running with ESS effortlessly and have looked no further. Its the integration of Emacs with other development enviroments that keeps my life simple :-)
Could you clarify what you mean by "integration with other development environments"? I assume you're in data science -- could you describe how Emacs solve your need?
Also, am I correct in thinking that ESS company-mode autocomplete does not autocomplete data frame's variable names when using tidyverse's pipe?
Late response, but I moved to Emacs after being a very happy user of Rstudio for many many years.
Rstudio is a better editor for R. The problem is that it's a worse editor for everything else, and these days I write plenty of else, too. Being able to flip between different files, language shells, terminals, magit buffers, etc. effortlessly, makes putting up with worse autocomplete in R a pretty good deal for me. It does annoy me a little, but R is hardly a verbose language, and elisp is high-level enough that I have a shot at extending / changing the behavior if it really bothers me.
Is that a Java-specific thing? My experience with C++ is that ever since libclang became widely used, autocompletion works really well—but that's because libclang is so good. Is there an analog of libclang for Java?
What package are you using for your Emacs back end for completion? I've tried several and never really found them stable or even working in some cases. I write a couple thousand lines of C++ every week in emacs and I've actually become very productive without auto completion, so perhaps I'm not missing it anymore at all.
I use irony-mode (with its flycheck and company support) on OSX, and I think it works really well. It uses libclang as the backend, so for completion it's about as precise as a compiler can be.
I code in C so can't speak for C++, but I imagine it works well for that too: irony-mode as a backend and company-mode as frontend. It pretty much gives the Xcode auto-complete experience, and I think it works great!
Seconded this, this is my setup on both Windows and Linux and works for me across multi-million-line C and C++ codebases. It's quite finicky to get set up on Windows at first (or at least, it was for me last time I tried), but once you have irony-mode working with libclang, you don't need to think about it ever again, except for changing a couple compiler flags here and there.
My one complaint is that clang's MSVC mode is imperfect, and sometimes suggests some strange things (or produces some false negative/positive in syntax checking). But they've been getting much better lately and it's never caused me much pain.
e: also, second what a sibling said - combo this with flycheck-mode and you have yourself a full-blown C++ IDE in emacs ;)
I tried irony mode, but my autocomplete pop-ups would contain all kinds of nonsense, and I noticed at least two other issues on the irony mode github page that showed other people with the same experience as mine, on Mac. So I eventually gave up after not tracking down a resolution.
For #1, maybe company-mode can be of assistance? I haven't used it with Java (I never had to write enough of it to need Emacs), but I imagine it works.
I feel compelled to mention Spacemacs in response to some of the comments here. In terms of configuration required for reasonable productivity, Spacemacs is macOS, and a plain Emacs install is Arch Linux.
Spacemacs gives you sensible configuration and packages out of the box, whereas the Emacs tutorials I'd begun to read kept repeating, "These are the functions you'll want to use, but only you can decide what to bind them to". That made me lose interest really quick--I'd prefer to have a 95% solution and then adjust it, not reinvent a sensible configuration from nothing. Spacemacs gives you exactly that. If what I'm describing was a barrier for you in adopting Emacs, I'd encourage you to check it out.
And down the Xah Lee rabbit hole we go. If you have a question of the form "how do i <very complicated one-liner>", xah has almost certainly written a post about it.
I don't agree though, I started using emacs because of this one picture. There's way too much info out there if you're just starting to figure out what you want to use for coding.
So sexy maybe not the right word for this picture but I still love it.
Emacs itself isn't sexy; the sole reason I use emacs is the power and extensibility offered by emacs lisp. If vim used elisp instead of shudders vimscript, I would use it in a heartbeat.
Elisp (or even better, Guile) are definitely huge reasons to use emacs for me, but there are many, many other things I use it for instead of vim (which I also know, and have used for over 20 years).
org-mode and w3m (a web browser that can be integrated in to emacs) are my two biggest draws, but eventually I mean to get the mail client working, give the shell modes another try, and maybe get the irc and RSS clients going too. The sky's the limit with emacs, while vim does more closely stick to being just an editor.
All that said, I still use vim when I need it, such as for getting syntax highlighting of strace files, which last time I checked, emacs did not have a mode for. vim is also often much faster on large files.
A beginner would not want to break compatibility with every tutorial/instruction manual. They would be faced with decisions about the placement of shortcuts they're not even sure what they do. They definitely wouldn't have the perspective to create logical families of shortcuts.
So of course the solution is to suffer the bad shortcut placement in Emacs long enough to not need tutorials and fully understand what you're doing, then throw all the intuition you've gained out the window by remapping everything.
Oh, the beauty of emacs, the self-documenting editor...This is highlighted at the top of the built in tutorial if you change your keybindings:
>NOTICE: The main purpose of the Emacs tutorial is to teach you
the most important standard Emacs commands (key bindings).
However, your Emacs has been customized by changing some of
these basic editing commands, so it doesn't correspond to the
tutorial. We have inserted colored notices where the altered
commands have been introduced. [More]
[More] is a list of the default keybinding, the command, and how to access the command in "your" emacs.
The keybindings are also changed throughout the entire manual (C-h i) I believe.
Would it maybe be useful to have some framework for creating tutorials inside emacs? In that case, the tutorial could just check which shortcut(s) are defined for a given command, and update the tutorial text to reflect that.
Regarding extensibility, would it even be possible to embed Guile or ECL (or Lua or John Walker's ATLAST) into an existing editor? Perhaps not Vim, but maybe classic vi or nvi?
Vim has actually long had Scheme integration (in the form of plt-scheme and then racket). So you could actually script vim in Scheme. The problem is that virtually no one ever does.
Last I checked, almost all vim scripts were written in vimscript (with Python starting to make some headway). If any non-vimscript language is going to be the future of vim scripting, it's probably going to be python rather than Lisp or Scheme. So if you were going to start writing Scheme scripts in vim, you'd be pretty much the only one.
Compare that to emacs, where virtually the entire gigantic emacs ecosystem is written in Elisp. It's an Elisp ecosystem and community you'd be participating in were you to write in Elisp for emacs. Leveraging that enormous codebase and community is a huge win for emacs that you're not going to get in vim unless you program in vimscript or maybe to some extent in python.
So if you're interested in vimscript or maybe python, vim seems like a good choice, while those interested in Elisp or maybe Scheme would probably be much better off in emacs.
As for Lua, how many vim scripts are written in Lua? I would guess it's about as popular as Scheme is for vim, which is to say virtually not at all. In any case, it's not a Lisp, so I'm not sure how much interest there would be from the Lisp/Scheme communities in programming in it vs something like python, which seems to have more traction in the vim world. It would be a step up from vimscript, though, that's for sure. But, again, there is no Lua ecosystem for vim, so being the only one writing Lua scripts for vim is not hugely attractive for most people.
I've written a handful of Vim plugins before. I've generally tried to avoid writing Vimscript as much as possible why writing the bulk of my plugin logic in Python and then just exposing the bindings in Vimscript.
I've been a Vim user for quite some time. I've taken breaks and used Sublime, and most recently Atom. (with vim-mode-plus). A few years back I took a couple of months and dedicated myself to only using Emacs. I wanted to just prove to myself that I could do it. I have to say, it's one heck of an editor/environment/way-of-life. I can't see myself making the jump, but I can see why many make it. Just like Vim, it's an investment. You don't just get down to work easily. And the config files you start with (even if you start with some "make your life easy" packages) probably aren't the same ones you'll have in 5 years. It's meant to evolve. Who knows where Webstorm will be in 5 more years... I wish the best for everyone, cause competition in this area provides lots of innovation... but I am pretty certain Vim and Emacs will still exist.
I have used both, from Finseth's 'FINE'[1], to MicroEmacs (ue) to Gosling emacs. But I switched over to vi when I started using PC keyboards all the time because of that damn caps lock key. For a while I would keymap it back to control and spent extra for a keyboard that actually had a control key there, but eventually I gave up not being able to walk up to a vanilla / foreign install and effectively generate a text file from within an editor.
How can I contribute this sexy photo I took of RMS many years ago, in that fleeting moment between being asked a joke (to which his questioning smile replied "I don't know, why do you wrap gerbils in duct tape?") and hearing the punchline.
I'm surprised the article doesn't also mention the theme gallery here: https://pawelbx.github.io/emacs-theme-gallery/ I actually used it yesterday and am currently using the heroku theme(coming from zenburn for a few years).
Elisp was dynamic-scoping-only until version 24.1. That means elisp code written before that (i.e., 99.999% of emacs code that's not in C) as well as most of the code written after that, has essentially the feel of hacky cruft which will drown a modern programmer into an abyss of cognitive pain and headache when (s)he attempts to understand, modify, or debug it. (not unlike GOTO ridden spaghetti)
How many programmers have you come across that claim to use elisp as their primary programming language?
(to give you an idea, enough of emacs users/hackers are sick of elisp enough that emacs is now offered in two configurations: based on elisp or based on guile)
That's nonsense. Emacs Lisp has served well as programming language for 30 years. There is some really fantastic code written in Emacs Lisp. Dynamic Binding is a minor issue. People have been writing whole operating systems in dynamically bound Lisp and I'm not talking about GNU Emacs itself.
There is no GNU Emacs based on Guile in the sense that the Elisp code has been translated to Scheme. All there is is an Emacs based on the GNU Guile runtime. The code is still written in Emacs Lisp - it just runs on a different runtime.
> Guile-based Emacs is a branch of GNU Emacs that replaces Emacs’s own EmacsLisp engine with the Elisp compiler of Guile.
It's a different compiler. You can write stuff in Scheme, too. But who would do it, since then it would not be compatible with the main GNU Emacs editor...
Have you ever programmed with dynamic binding in Emacs Lisp or are you talking out of your ass? Because it's sort of obvious to me that the latter is the case here.
For 99.999% of cases in Emacs, there is no difference between dynamic and lexical binding regarding how code reads & feels.
Not to mention that Elisp was not dynamic-scoping-only (sic) until version 24.1, there exist lexical-let & friends.
Not to mention that guile-emacs is basically a hack at this point in time that very few ppl actually care about, the vast majority of Emacs users being very happy with Emacs Lisp.
Not to mention that even if guile-emacs becomes viable and more popular, it'll still be running Emacs Lisp on top of the Guile VM.
For someone that can't even get his facts straight you sure have a lot of strong opinions.
Anyone who is used to coding in a Lisp with closures will be handicapped by a lambda that is just code without an environment.
It only makes next to no difference if you're writing Fortran in Lisp: just block scoped functions with parameters and locals, but no expectation of function indirection that carries environments.
You know, even Wirth's Pascal lets you at least pass a functional argument downward, with its lexical environment ("downward funarg")!
Lambdas with no environment can sort of fake downward funarg, if nothing is dynamically shadowed on the way down. I.e. (some-function (lambda () x)) If nothing in the activation chain inside some-function binds x between here and the point where the lambda is called, then we're good: the x dynamically resolves to our x. If something binds x, we have a bug. Or worse; we don't have a bug: it's set up that way on purpose.
Hey at least Elisp wasn't ever as bad as Mock Lisp, the extension language in Gosling (aka UniPress aka Evil Software Hoarder) Emacs.
It had ultra-dynamic lazy scoping: It would defer evaluating the function parameters until they were actually needed by the callee (((or a function it called))), at which time it would evaluate the parameters in the CALLEE's scope.
James Gosling honestly copped to how terrible a language MockLisp was in the 1981 Unix Emacs release notes:
12.2. MLisp - Mock Lisp
Unix Emacs contains an interpreter for a language
that in many respects resembles Lisp. The primary
(some would say only) resemblance between Mock Lisp
and any real Lisp is the general syntax of a program,
which many feel is Lisp's weakest point. The
differences include such things as the lack of a
cons function and a rather peculiar method of
passing parameters.
"Rather peculiar" is an understatement. More info, links and code examples:
Editing in the Multi-Occur buffer can be just about ideal for coordinating name changes across multiple files. Unfortunately, it's keystroke-inefficient out of the box. The elisp fixes are here:
http://stackoverflow.com/questions/2641211/emacs-interactive...
You're just inviting the "decent text editor" joke, aren't you? ;-) But yes, if all you want is text editing I'm not sure what's better than Sublime. I've hard good things about VS Code lately, though.
I think the implied subtext of this site is "emacs is sexy, but its logo isn't. Here, download this alternate logo so you can feel ok about using it on a mac"
The page's domain and title are disappointing to me.
Using sexualized language can create an environment that is unduly hostile to women, even if this is not intended. Many of the biases against women that such language provokes are totally unconscious, so even if the intent is not harmful, it can be bad regardless.
The page's domain and title are disappointing to me.
Using sexualized language can create an environment that is unduly hostile to RMS, even if this is not intended. Many of the biases against RMS that such language provokes are totally unconscious, so even if the intent is not harmful, it can be bad regardless.
Oh, please. Sexiness does not have gender. Is being human acceptable anymore? Yes, do we sex and find things and people sexy, sometimes even text editors.
I believe he's implying that women have been and continue to be sexualized in a way and to an extent that men are not.
I'm fine with this particular example but I wholeheartedly agree with the comment. However me being fine with it isn't enough - everyone already takes me seriously. I haven't always seen that same courtesy extended to women engineers.
No it is not. It is incredibly bloated and inefficient due to the the number of keystrokes required to do simple stuff.
Eliza mode.
I've personally watched some incredibly talented researchers/engineers using emacs to perform every-day work; For a lot of the operations, it would have taken me 5 seconds in vi/vim, but took > 10 seconds for said (very brilliant) folk.
As in, some of these folk are world reknown and regularly cited in(and are reviewers of) ACM/IEEE computing related journals.
So no: Emacs is not sexy. Emacs is a fuster-cluck so complex as to be completely counter-productive.
I'd love to start using that super power tool with interchangeable heads from Black+Decker, but damn - it takes long time to recharge the batteries. I would rather stick to my knife and hand screwdriver. I'm so fast and efficient in using them.
