It's more than just Evil mode (vi emulation). They have a pretty thoughtful way to organize libraries (layers) and a decent solution to the "how to I manage my Emacs config" problem.
This +1000. Flymake or Flycheck, Autocomplete or Company ? I was in the classic .emacs bankruptcy situation and even started using atom before cloning the Spacemacs repo in my .emacs.d
For those who do not want to understand the details (which in case of Emacs is silly - one miss so many aha moments) bbatsov's prelude is a piece of true craftsmanship.
Calling evil mode heresy is the same as saying "I wish fewer people used Emacs." Why continue the holy war? You've won many vimmers over... why marginalize us?
Actually, Spacemacs layer configuration uses the use-package add-on ( https://github.com/jwiegley/use-package ) , which helps greatly simplifies and organizes large .emacs config files (and also greatly improves emacs' startup time). use-package was written by John Wiegley, created of the Ledger CLI accounting software, and current maintainer of Emacs. Emacs integration of packages with Melpa gets only a small part of the way towards where Wiegley goes with use-package. . . .
That's a pretty lightweight Emacs config. Mine is based on emacs-starter-kit (technomancy's creation) and is much larger - https://github.com/metaperl/emacs
As someone who is a loyal Emacs user, would you recommend Spacemacs over regular old Emacs? Also is the migration process very difficult? I've got to say, it actually looks very nice and well polished.
As a vim user, I emphatically disagree. It seems to support most vim commands, but the ones it doesn't support of course become the most frustrating. As an example, I cannot use <space> for movement/direction because it consistently pops up some stupid menu, even in the middle if entering a command.
As a vim user, I'm also used to my editor starting up instantly. Spacemacs takes so long to load that it's laughable. And since GNU emacs is single-threaded, the whole UI is completely locked while it processes the massive amount of configuration needed to make spacemacs what it is. The only thing "better" about that is that it gives you an opportunity to take a coffee break. I'm reminded of the "code's compiling" XKCD: boss says, "hey! quit horsing around!", worker says "spacemacs is loading!" And this is with 8GB of RAM, 8 processor cores clocked at 3.2 GHz, and filesystem on an SSD drive.
And then you run into problems with many packages from MELPA. If some third-party package introduces its own keybindings, then you still wind up with odd emacs-style keybindings here and there, rather than Vim-style ones. Furthermore, Vim's leader key is backslash, not space, regardless of how you like to configure it.
So, what's "better" about it? The fact that it's got a "pretty" powerline statusline by default? The fact that it uses some dark colorscheme by default? That's not enough for me to abandon vim.
> Spacemacs takes so long to load that it's laughable.
Emacs is typically started once, and then you open files in the same instance. With vanilla emacs you can use `emacs --daemon` to start it as a server, and then use `emacsclient` to open files. That way it should open pretty much instantly. I'm not sure what Spacemacs calls those.
Yes, I'm aware. The thing is, I haven't had any issues with vanilla emacs's startup time in over a decade. That's probably because I don't load hundreds of packages I don't need in my init.el. Spacemacs, on the other hand...
EDIT: Furthermore, I really don't see how a Vim user is supposed to consider that an improvement. I can't picture someone saying, "I used to just run my editor when I needed it, and it started instantaneously. Now, it takes so long to start that I just leave it running all the time. It's so much better! Powerline! YEAH!!"
If people like Spacemacs, that's fine, I don't care. Use what you want. But I'm really getting sick of hearing that it's "a better Vim", because it's really, really not. In fact, it's so much not-Vim that whenever I use emacs, I prefer vanilla emacs, even though I've been using Vim for over a decade.
If you're an adherent of the holy church thinking of turning evil, then it will obviously take some relearning, but it's incredibly discoverable, making exensive use of hierarchical mnemonics and helm after each keypress to know what commands are available to you.
e.g. space-f-s is file->save, space-f-f is file->find, space-f-r is file->recent etc.
The modal mode is not mandatory. You can change a variable and have the classic Emacs keybindings + the advantages of spacemacs (sane configuration, beautiful look)
While I haven't run spacemacs in non-vim mode, it is there. Give it a try. It's all built into .emacs.d, so it's easy to try and drop if you want to. Just backup your .emacs.d first.
I just wanted to say thanks - I could never get into vanilla Emacs but after about an hour of playing around with Spacemacs I have to say it's amazing. It's incredible what a few convenience features (and of course, familiar keybindings) can do.
Even if you don't like Vi they added tho option to use the the default Emacs keybindings later as an option. I didn't catch with prelude or oh-my-emacs but Spacemacs is imho how Emacs should be shipped.
The installation does not work for me. I follow all the steps and then run '$ emacs' in the console and the old GNU emacs just pops up. Anyone got a clue what I'm doing wrong?
Edit: fixed it. It turns out that was an ~/.emacs file present which prevents Spacemacs from starting. If you did the cloning and $ emacs results in your standard GNU emacs, look for the file ~/.emacs and remove it.
Just to add, I highly recommend people to look at `:help 'clipboard`. There are several options available, and one or another might be better depending on what you're expecting, and on which platform you're on (e.g., there are notes about using the clipboard on X vs. Windows).
There is a hybrid mode that enables emacs commands (C-E, C-A, C-Y etc.) while in insert mode. Quite enjoyable, particularly when you're used to using emacs movement commands while editing text fields (thanks macOS).
The NEWS file usually gives more details about the changes and such. The NEWS file [0] can be found in the git repository. (C-h n if you are already running emacs.)
Also, this is the last release of Emacs for which RMS will be the maintainer. He's been the principal maintainer on and off since 1976, so he's probably earned a rest.
RMS hasn't been an actual maintainer since at least 2008. This release has been under the maintainership of John Wiegley, and several previous ones - under Stefan Monnier and Chong Yidong.
> Also, this is the last release of Emacs for which RMS will be the maintainer. He's been the principal maintainer on and off since 1976, so he's probably earned a rest.
'Emacs' is not a single line of editor which Stallman maintains. Emacs is a whole class of editors.
Well, considering that this is a Stallman maintained Emacs project, it's not misleading at all: if you know Emacs is a family of editors, than you know enough to know which of the Emacs he's talking about, and if you don't, than when you think "Emacs," you think GNU Emacs anyways.
Stallman hasn't maintained every Emacs, but he's maintained the definitive Emacs since '76, with some gaps here and there. When you think Emacs, you typically don't think THIEF, EINE, ZWEI, FINE, Edwin, Climacs, Hemlock, Efuns, Zile, QEmacs, Multics Emacs, Gosling Emacs, JOVE, JEmacs, Guile Emacs, or Ermacs.
You either think of GNU emacs and its derivitives, or the original EMACS. Both of which RMS maintained.
It's not a bad idea to give respect to other implementers, but when you maintained the most popular incarnation, twice over, you don't NEED that kind of specificity: people will know what you're talking about.
The Emacs from 76 and GNU Emacs are totally different programs.
> When you think Emacs, you typically don't think THIEF, EINE, ZWEI, FINE, Edwin, Climacs, Hemlock, Efuns, Zile, QEmacs, Multics Emacs, Gosling Emacs, JOVE, JEmacs, Guile Emacs, or Ermacs.
Talk about you.
When I think of Emacs, then I think of Aquamacs (a variant of GNU Emacs), Zmacs (which I have running on a real Lisp Machine and under emulation), Clozure CL's editor (which is a Hemlock variant) on my Mac and the LispWorks editor under OSX and Linux, which is also a Hemlock variant.
Actually the Emacs I use most, is the one in LispWorks. GNU Emacs comes second.
> To those familiar with Emacs development - is there a tendency to modernise the UI and generally make it an easier out-of-box experience?
The OOB GNU experience is rather lack-luster. There's a ton of thing Emacs can do, but with the default preferences it doesn't. Some of these missing or bad defaults really feel odd.
It seems the official GNU mantra is "if people aren't forced to look for things to customize, they wont really ever discover all the things Emacs can do for them".
Which is kinda true.
Basically, they want to encourage users to become "fully fluent Emacs-users", that is a person who can and will customize every part of the Emacs-experience. Which is a great goal! But the means used still puts a first-time novice user in a much more inferior-looking chair than he could have been put into.
The "solution" for this has often been Emacs starter-kits (like prelude), which provides lots of better defaults, not to mention a curated list of addons and packages, making the OOB experience much more friendly.
From here on it's probably all speculation, but a full starter-kit might leave the novice Emacs-user overwhelmed and incapable of customizing (he has no way to know what all the things the starter-kit sets or includes does, and why. He will not know what is Emacs and what comes from addons. Etc etc). IMO this can hurt the long-term prospect of the user actually becoming a fully fluent Emacs-user.
On the other-side, you have the GNU Stance where IMO they risk alienating people from becoming Emacs-users all together. And that's even worse.
I don't like to be all black and white and say "this side is the only way". There really should be a middle-ground somewhere, but it seems GNU is not willing to provide it. And that's really quite a shame.
As someone who recently picked up emacs (as in the past couple of years), I actually didn't find it that overwhelming. I'm not sure what "modernize" means in this sense, but other than trying to remember some fairly arcane key combos, it's a fairly straightforward system. Certainly no more difficult to grok that vim's modal system. If a user is new, start with the tutorial and get a feel for the navigation. Then I watched a few videos online to help me with more advanced stuff. After that point, Google was my friend if I needed to do something specific.
That said, I feel like emacs could update a few defaults and include a few packages to create less setup time. Like shipping an official starter package (dnf install emacs-starter) so people can choose what they want.
I haven't tried any of these so can't speak to the experience, but the idea is that a custom layer for various users can be built on top and distributed to desired users (so it's almost out-of-the-box).
Spacemacs is also a good example targeting VIM users.
I can't speak for emacs development, but spacemacs is all about usability. It really shines as a combination of the best of VIM and EMACS, however, you don't have to use the vim mode. I haven't tried it without though.
Emacs is a different paradigm in the editor world. The user interface reflects and is part of this paradigm, and don't expect it to change. It is an established interface, essentially an API, on which thousands of people built configuration and packages. Breaking it is breaking everybody's code. That said, improvements and fixes are certainly done and increasingly often so.
One thing that feels very old-fashioned about Emacs: the cursor acts like a hardware cursor on an old hardware terminal, even in the GUI version. Every modern GUI text editor lets you scroll away from the cursor without moving it. This is convenient if you want to quickly check something else in the file. Emacs will move the cursor so it's always on screen. It has no concept of scrolling without cursor movement.
The explanation for that behavior is that instead of a cursor, emacs has a mark and a point. If you want to view something else without losing your place, you can leave the mark behind and then jump back.
The main benefit of this is that you get to find the "something else" quickly using the full suite of normal search and movement commands. It's also nice that you can jump through the stack of past marks, not just one.
Instead of a mark and point, it could have a mark and modern cursor. This wouldn't lose any of that functionality and it would be less annoying for people used to modern software.
I don't know why you're being downvoted, it's a valid complaint.
I tried Emacs/Spacemacs and for example, there's no decent tabbed interface. I mean a real tabbed interface, at least as good as Vim's. The answers I got on this topic ranged from: "you're not going to need it" (how do you know what I need?) to "use this random package which kind of provides a limited subset of the tabbed interface UX" to "write it yourself" (...).
You don't need tabs in Emacs; use buffer instead. Helm has a really good interface to navigate open buffers. I usually have 30-50 buffers open in my emacs. Now how does vim handle that many buffers?
For what is worth, I have currently 755 buffers open on my emacs session. That's probably on the low side as I restarted my session recently (i.e. in the last 7 days). I usually have 8 buffers showing (vertical + horizontal split across two windows) at any one time. I don't even known how a tabbed interface would look like in this setup.
I use ido-switch-buffer instead of helm for quick switching. Should I switch to helm?
I prefer lazy-loading both packages and files, but still having
recently-worked-on files available for quick opening, since I
sometimes do restart Emacs :)
With the below form in my .emacs.d/init.el, I can restart Emacs and
the first time I do C-x b I get to pick from files I had opened in the
previous session:
(use-package ido
:init
(setq ido-use-virtual-buffers t) ; treat closed files as open buffers for C-x b
:config
(ido-mode 1)
(ido-everywhere 1)
(use-package recentf
:init
(setq recentf-auto-cleanup 7200 ; clean list on idle rather than startup
recentf-max-saved-items 2000)
:config
(recentf-mode 1)))
That is, ido-use-virtual-buffers will put closed buffers at the end of
the buffer list, while recentf makes that list of previously closed
buffers persistent across sessions.
Also, after opening vc-tracked files, I want subsequent find-file
calls to match on all non-ignored subdirectories of that repo, not
just the directory of the current file, so I use ffir to add tracked
subdirectories to ido's work directories:
(use-package find-file-in-repository
:ensure t
:config
(setq ffir-avoid-HOME-repository nil)
(defun ffir-repo-subdirectories ()
"Use ffir to put projects into ido-work-directories.
This makes useful files show up even if you haven't been to that
sub-folder yet."
;; TODO: compare emacs25 project-find-file
(interactive)
(let* ((repo-directory (expand-file-name
(ffir-locate-dominating-file
default-directory
(lambda (directory)
(ffir-directory-contains-which-file
ffir-repository-types directory)))))
(file-list (funcall (ffir-directory-contains-which-file
ffir-repository-types repo-directory)
repo-directory))
dir-list)
(mapc (lambda (p)
(add-to-list 'dir-list (file-name-directory (cdr p))))
file-list)
dir-list))
(defadvice ido-merge-work-directories (before advice-merge-repo-subdirs first nil activate)
(mapc (lambda (d) (add-to-list 'ido-work-directory-list d))
(ffir-repo-subdirectories))))
(ffir is a fairly small dependency for a vc-general
"list-non-ignored-files", though perhaps there's something built-in in
Emacs' vc.el I should be using instead)
There are multiple helm-like plugins for vim, which can be used to change buffers. Tabs, on the other hand, are used so that you can, for example, have a tab with a vertical split and buffers A and B, and another tab with just one big buffer, and so on.
> I tried Emacs/Spacemacs and for example, there's no decent tabbed interface. I mean a real tabbed interface, at least as good as Vim's.
It's been ages since I was a vi user, and I never used tabs. I took a look at http://vim.wikia.com/wiki/Using_tab_pages, and it sounds like tabs are just what emacs would call windows, which have been there for decades at this point. I'm guessing that's not it, so … what is?
Also, what is wrong with 'write it yourself'? You are presumably an intelligent human being; the whole point of free software is that you are free to do whatever you like with it. If there's a feature you want, implement it (or hire someone to do so)!
> I tried Emacs/Spacemacs and for example, there's no decent tabbed interface. I mean a real tabbed interface, at least as good as Vim's. The answers I got on this topic ranged from: "you're not going to need it" (how do you know what I need?) to "use this random package which kind of provides a limited subset of the tabbed interface UX" to "write it yourself" (...).
I'd like to offer a different explanation, which I think it much more truthful and reflects the Emacs way(tm).
In Emacs everything (and I mean everything) is represented by the same type of primitives: Buffers made out of text. Every interaction with such a text-buffer is represented as lisp-code implementing an Emacs mode.
This is the core of Emacs. Everything in Emacs must build on this. No exceptions. And that's incredibly powerful.
Because of these "limitations" it means everything (and I mean everything) in Emacs can be processed using the same primitives, the same functions and the same keys.
There's no magic buttons, or drop-down lists, or special UI elements exempt from this.
I can search/grep for text in any buffer. I can recursively grep for results in my grep-result buffer. I can navigate these search results, the same way I would navigate a code-document. I can enable spell-check in any mode I like (like Git commit-mode). Etc etc.
It also means that any customization I've done to any part of Emacs, I can apply to any third party extension as well. It means I can customize and interact with a extension which extends another extension. There's almost no limits to what you can do with these simple but powerful primitives.
And all that in a simple and uniform way. Everything at your finger-tips. Both as a Emacs-package developer and an Emacs-user.
Once you get used to it, it's really a captivating thing and everything else starts feeling wrong.
If you want to make a tabbed interface... How are you going to represent that using those primitives? How will that work?
How will you make sure you tab-line/row stays in place and is exempt from other rules which governs the current buffer and the Emacs mode it runs (not to mention the user-customized rules for this mode)?
I'm not saying it can't be done. I'm just saying it wouldn't be very Emacsy, and it's probably not a trivial thing to implement either. Especially when you consider that all your code also needs to work in a terminal. Emacs should be able to work 100% in a SSH session too, you know. At least for me, that's one of it's many selling points :)
So non-trivial and not very Emascy. That doesn't sound like anything which is going to get lots of developer-time. Neither core nor third-party.
Emacs has frames (aka "windows" for non-Emacs lingo) so there is no theoretical reason it couldn't have tabs. I understand the complaint about tabs. In Vim I have the opposite complaint: no frames.
Tabs can work in a terminal; Vim has them.
If I were an Emacs developer I wouldn't bother with tabs because we already have frames, but there's nothing non-Emacsy about tabs.
It could work well if tabs contained frames instead of buffers, i.e. as a sort of workspace management. I guess this could be done right now by using a tabbed window manager.
I actually think it could work well if you could choose one or the other. aquamacs outlines the paradigm that I would generally use (frames usually equal buffers, but a tab can contain two buffers in necessary, like you often do in org-mode). I'm glad emacs doesn't ship with a tab paradigm by default, but it's easy enough to add one if you need.
I typically open Emacs when I boot my laptop, and close it when I shut down (which happens only every few weeks); this is typical of a lot of Emacs users. In those few weeks, I open hundreds of buffers and I rarely close them: my buffer list contains all the TeX files from the paper I'm working on, the code files of a couple different projects, many one-off files, IRC buffers, twitter buffers, etc. Yet, switching to the buffer I want is easy, fast, and painless. Using ivy (helm or ido-flx are good too), I can quickly switch to any buffer by typing part of its name. This paradigm would be totally impossible (or at the very least, most impractical) if I had one tab-per-buffer.
I think if Vim or Visual Studio Code had a similar quick way of switching between buffers, people would be less reliant on tabs. As for Emacs, it seems like a waste of time and effort to implement a feature that most Emacs users would not use.
Tabs are an inefficient representation of Emacs buffers, as they are not mere views into files, and sometimes not even intended for the user to see. That said, there are packages out there if you really want them. Or you implement it. There are the facilities. But the default Emacs is an API for other packages, and plugging in tabs would have implications on most of the elisp out there.
Yet another option is not to use emacs if it does not fit your requirements and preferences.
So you mean GUI tabs I guess? How would one even begin to display hundreds of tabs on a screen? I hate that Firefox doesn't make it as easy to switch tabs as emacs makes it easy to switch buffers.
IIRC vim's tabs are just views into buffers - you don't need to have a tab per buffer at all. So you can switch between tabs, or between buffers in a tab etc.
IIRC it used to be impossible to display it in a split, it required a separate frame (that is, windowmanager-level window).
There were some dirty hacks to fix that, but led to more problems with window & buffer switch ordering (and layouts for things like ediff)
May all be fixed now, this was years ago when I last played with it, but haven't really found the need for it, instead of ibuffer-mode, ido-everywhere, and smex. (Probably helm too if I can ever be bothered to set it up properly)
The analogy would hold if Emacs would be used only for Lisp. But I see it recommended from time to time as the development environment for various non-Lisp programming languages.
And if you create artificial barriers to entry, don't expect many people to stick around to enjoy the supposed benefits at the end of the rainbow.
And my point was that I should be free to think in whatever I want. If the other bastion of go-your-own-way, Vim, has tabs, I'm pretty sure the Emacs could have them as well.
Especially since Emacs prides itself on being a jack of all trades, unlike the "limited" Sublime or Notepad++, for example.
Hmm, your tone indicates were this is likely to go.. but...
Emacs can have tabs and it can have goto next etc. What do you want? for them to override out of the box the default method of buffer and frame mgmt in emacs?
I've tried Emacs and I've tried several tab packages. None of them seemed to work properly, and I wasn't expecting much.
I just wanted a visual list of frames or whatever they're called, preferably at the top of the screen, preferably visible despite whatever mode I was in and preferably easily manageable through keyboard commands. For an exact example of what I wanted, just open GVim. You will notice that tabs are added on top of the existing Vim concepts, such as buffers, and you can easily use Vim/Gvim without actually using tabs. You can even disable the tabbar.
I couldn't get that without major hassle.
I don't really want anything from Emacs, I'm just pointing out that:
- Emacs is frequently aggressively promoted as some sort of holy grail of text editing
- people say that they are using an editor such as Sublime which does what they want
- Emacs folks then point out that Emacs can do whatever Sublime can and more
To which I'm just giving 1 data point of Emacs not being able to do what Sublime does out of the box. And "code it yourself" is not a valid reply since a flexible and robust tab management solution in the Emacs environment is not a trivial project.
In emacs frames are distinct windows on the display manager. Then you have buffers which usually are a file you are editing but also contain things like directories of files, list of buffers and messages from emacs. It's really easy to switch between buffers using a couple of key commands. Another command brings up the list of buffers which you can search with the same search command you use in a file. You can sort or filter the list. With all this you really don't need tabs cluttering up the screen.
> I just wanted a visual list of frames or whatever they're called, preferably at the top of the screen, preferably visible despite whatever mode I was in and preferably easily manageable through keyboard commands.
The list-buffers command provides exactly that: a list of buffers, easily manageable through keyboard commands. You can have a window containing that list at the top of every frame. I don't think that you'd end up actually wanting that, since in emacs it's common to have dozens or hundreds of buffers open, but you can if you like.
Again, I don't think you'd actually want to do that, but you can.
> To which I'm just giving 1 data point of Emacs not being able to do what Sublime does out of the box.
It is perfectly able to, being a Turing-complete text editor. But trying to do that doesn't make sense.
> And "code it yourself" is not a valid reply since a flexible and robust tab management solution in the Emacs environment is not a trivial project.
Neither was a text editor, neither was a Usenet client, neither was a web browser, neither was a git interface, neither was org-mode — and yet all those and more have been done.
Somewhy many conversations about emacs go like this:
A: emacs is awesome, you should use it.
B: I can't use it since it misses this one feature i like.
A: it is a stupid feature, but there are plugins doing half of what you like, and you can create another plugin.
B: it is too much work, i don't have time to do that.
A: people have created plugins that required even more work...
Emacs is a great editor, and for people who get used to its ui limitations, it is often the best editor, but for new users the ancient ui is a huge roadblock, and most users never will get past it.
Not implementing modern ui and not being interested in what new users like is a perfectly valid choice for emacs developers, but then saying emacs is great and not liking it is the users fault is illogical.
> for new users the ancient ui is a huge roadblock, and most users never will get past it.
Reading & writing is a huge roadblock, but most people do get past it — and the UI of emacs is far easier than learning to read & write.
> then saying emacs is great and not liking it is the users fault is illogical.
No, emacs is great and users should be humble enough to try to learn it, rather than arrogant enough to think they can do better. It's like a kid who says, 'I don't want to read; my parents can read to me.' That's no way to go through life — and neither is using an inferior computer interface.
The difference is the reward one gets after passing the roadblock. Without reading people can't do anything, without emacs most developers manage to work happily.
I do agree that emacs is great, but many aspects of its behavior are dictated by limitations of old machines and can be improved.
> Without reading people can't do anything, without emacs most developers manage to work happily.
Illiterate children are quite happy, too — they have no idea of the worlds which open up before them when they can read. They literally don't know what they are missing.
I hoped the meaning would be clear from context, but i see i should have been more careful in writing the comment.
Things that a human (who is living now) misses by not learning to read, far outnumber things a programmer misses by not learning emacs. There are very few jobs someone illiterate can perform. But non emacs user can do almost anything that emacs user does, almost as good.
So my argument that benefits from learning reading and learning emacs are not comparable, is not far from the truth.
Check out sr-speedbar. It is not exactly what you want because it represents the current directory of whatever file the current buffer is visiting, but in terms of a UI-ism it is very very close to what you want. You could probably modify it to bind to Ido-buffers instead of the current directory and essentially have exactly the functionality you want.
> And my point was that I should be free to think in whatever I want.
You are quite free to do that: go forth and freely implement your own tabs if the existing tab packages don't do what you want! Heck, you might even get the emacs dev team to include your package in the default elisp packages.
You don't have tasking authority for the emacs devs; it's puzzling that you seem to believe you ought to.
> On the other hand, I'm a bit tired of the holier-than-thou attitude of many Emacs (and many Vim users) on internet forums.
Well, think back to when you were a kid in school. Did the high-schoolers consider themselves better-educated than the first-graders? Almost certainly. Were they right? Indubitably.
vi & emacs are, simply, superior to the alternatives (albeit imperfect in themselves). It's a recasting of the Blub Paradox: someone using a moderately-powerful editor can see how it's better than Notepad or nano, but cannot see how emacs or vi is better than his own editor. From his perspective, users of better editors are self-congratulatory and delusional — the problem is that his perspective is wrong: there is an objective ranking of editors, and his is worse than theirs.
> In my case I voted with my feet already :)
In the long run, that's like being truant. Sure, it saves one some miserable hours in school, but those miserable hours buy one an education.
Life's too short to use Atom, Eclipse, SublimeText or TextMate.
The big change for this release is direct access to shared libraries. Traditionally, emacs has executed binaries directly for all its external interaction, using stdin and stdout for all communication. Now it will be able to call libraries and use their native APIs rather than just two text streams.
This had been long resisted on the grounds that this feature could be used to link emacs with non-free code.
From the ChangeLog:
** Emacs can now load shared/dynamic libraries (modules).
A dynamic Emacs module is a shared library that provides additional
functionality for use in Emacs Lisp programs, just like a package
written in Emacs Lisp would. The functions 'load', 'require',
'load-file', etc. were extended to load such modules, as they do with
Emacs Lisp packages. The new variable 'module-file-suffix' holds the
system-dependent value of the file-name extension ('.so' on Posix
hosts) of the module files.
> This had been long resisted on the grounds that this feature could be used to link emacs with non-free code.
The way to ensure that modules are GPL compatible is that they have to say that they are by exporting a symbol called "plugin_is_GPL_compatible"... and this is legally binding!
I'm curious what required this. I have to admit that the "distanced" approach of using stdin does a good job of forcing a logical boundary between existing tools and emacs. In particular, it makes debugging markedly easier, since you can usually see what the program was trying to do.
That said, I do agree that just wanting to avoid non-free linked code is not productive. That ship sadly sailed and emacs seems to be losing ground to products that don't have this concern.
I'm not following things as closely as I once did, but I think one of the main drivers was using gcc/clang for analysis, to e.g. make parse trees available inside emacs.
That makes sense. Though, it is a shame both of those don't just give a dump of the tree based on a flag. :( I am guessing there just isn't a good textual representation for some of these things?
I want something like a "couch to 5k" for emacs, does that exist? A daily exercise that I can do to go from "couch" (no emacs experience) to "5k" (proficient enough to get shit done with emacs and not miss Sublime Text).
I really recommend starting with spacemacs. Guide-key alone (https://github.com/kai2nenobu/guide-key) makes everything SO much more discoverable. Plus, their use of SPC as a universal prefix for useful commands is pretty nice.
There's a built-in tutorial, which you can access from the help menu or by typing "C-h t". There are a bunch of other built-in help facilities, you can get a list by typing "C-h ?".
http://spacemacs.org/
For those that haven't used it, it's a carefully designed and polished Emacs kit based around Evil mode (the vi emulation layer).