Emacs is sexy
emacs.sexy
emacs.sexy
I know Spacemacs brings in a huge bunch, do they have any way to mitigate that?
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.
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 ;)
https://github.com/emacs-lsp/lsp-java
Microsoft's Language Server Protocol might be just the thing that takes Emacs sexiness to an entirely different level.
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.
Perhaps I'm missing some killer ESS features?
Also, am I correct in thinking that ESS company-mode autocomplete does not autocomplete data frame's variable names when using tidyverse's pipe?
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.
Hope I don't have to explain that in the log to anyone - "No really, it's a text editor..."
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.
So sexy maybe not the right word for this picture but I still love it.
https://www.metafetish.com/2010/08/02/deldo-sex-toy-control-...
It's well worth freeze framing and reading the text in the list of all the different programming languages that Emacs supports.
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.
I really hate the key combos though.
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.
>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.
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?
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.
Just my two cents.
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.
[1] Fine Is Not EMACS
http://donhopkins.com/home/catalog/images/jsol-rms-gerbil-li...
I'll add pawelbx's gallery on the next update. Thanks!
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)
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:
https://archive.org/stream/bitsavers_cmuGosling_4195808/Gosl...
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.
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.
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.
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.
From https://www.emacswiki.org/emacs/GuileEmacs
> 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...
My favorite editors are still nano and notepad.exe
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.
More info here: http://geekfeminism.wikia.com/wiki/Sexualized_environment
Wording in this comment borrowed from here: https://github.com/alecthomas/voluptuous/issues/287
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.
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.
More info here: https://www.gnu.org/philosophy/philosophy.html
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.