Emacs 25.1 RC1
lists.gnu.org
lists.gnu.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).
Pretty simple and doesn't rely on heresy such as evil mode.
But one thing that's annoying the hell out of me is window/buffer management. It really confuses me when plugins 'eat' a buffer to display something.
Spacemacs is, as the tagline says, FOCUSED ON EVIL.
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.
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.
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.
It takes some getting used to, but I could never go back :)
It does support a non-evil mode, and asks which way you want the first time you run it.
Since there is no good in VIM (besides being pre-installed on every *nix platform), you know what that equation leads to... just emacs.
edit typo
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.
I also believe Neovim (and possibly normal vim, I'm not sure), automatically does `:set paste` and `:set nopaste` when you use the terminal paste.
[0] http://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS?h=e...
'Emacs' is not a single line of editor which Stallman maintains. Emacs is a whole class of editors.
A) A family of editors
B) Editor MACroS, a collection of TECO extensions written by various members of the MIT AI lab, and maintained by RMS.
C) GNU Emacs, a powerful text editor that was based on EMACS that is written in a combination of C and its own dialect of Lisp.
In this case, it's obvious that they mean B or C, or both. RMS isn't quite crazy enough to seriously claim he wrote every Emacs. Yet. ;)
In short, it's obvious what they meant, stop being such a pedant.
Give the proper respect to the other Emacs authors/maintainers.
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.
I know, but there were both definitive in their time.
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.
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.
For instance,
or CUA-mode.
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.
The UI feels pretty modern to me; it's when I use every other app that I feel crippled. That's not hyperbole, but fact.
It'd be wonderful if Firefox gave me the full set of emacs keybindings (not just a few) and a decent language to extend it.
It'd be wonderful if desktop environments let me converse with the computer via my keyboard, rather than pointing and grunting like an infant.
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.
I suggest to try the conkeror web browser: http://conkeror.org/
Conkeror is configured entirely in JavaScript, though, not LISP.
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 use ido-switch-buffer instead of helm for quick switching. Should I switch to helm?
1790 buffers 20295782 1774 files, 1 processWith 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)))
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))))
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?
Does https://github.com/krisajenkins/evil-tabs not solve your problem?
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'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.
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 can be done, it's just that there's no interest in the community or from the developers.
I can understand that, on the other hand such things make sure that a large number of people won't ever enter the Emacs community, for good or bad.
If you don't believe me about the popularity of the tabbed interface, I present:
- the addition of tabs to Vim
- the #1 feature request for Visual Studio Code, now implemented, tabs
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.
Yet another option is not to use emacs if it does not fit your requirements and preferences.
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)
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.
Especially since Emacs prides itself on being a jack of all trades, unlike the "limited" Sublime or Notepad++, for example.
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 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.
Anyway, different philosophies, both successful.
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.
If you'd prefer a look like you're used to, there's https://www.emacswiki.org/emacs/TabBarMode
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.
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.
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.
I do agree that emacs is great, but many aspects of its behavior are dictated by limitations of old machines and can be improved.
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.
So too for people not using a powerful editor.
People could do lots of things before written language was developed, so I'm pretty sure that's far from the truth.
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.
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.
You're probably right, I shouldn't have been ranting.
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.
In my case I voted with my feet already :)
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.
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.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!
Like Lawrence Lessig said, "code is law".
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.