Stack Exchange for Emacs
github.com
github.com
http://emacs.stackexchange.com/
(After first seeing the title, I assumed that's what this post was about!)
"GNU Emacs is an extensible, customizable text editor—and more. At its core is an interpreter for Emacs Lisp, a dialect of the Lisp programming language with extensions to support text editing."
Text editing is a subset of Emacs and Emacs Lisp, not the other way around.
I know. But it was written as just a text editor—but an extensible one, and so it has grown to be a lot more. Which is really pretty awesome.
No it's not. It is really a big REPL optimized for text processing. You compare Emacs to the like of Python, not just some random editor. Unlike other editors that have an optional extension language, if you remove Emacs Lisp, effective you remove Emacs. Even file opening is written in Emacs Lisp.
Yes, of course emacs is a big REPL optimised text processing. But it's optimised for text processing because…it started out as a text editor.
The whole point of what I wrote is that emacs started out as a simple text editor (yes, I'm aware that its origin was as text editing macros for TECO) and due to its extensibility it can and has become so much more.
Really, I think you got way too hung up on the word 'just.'
We both love emacs. We both love having a fully-extensible text editing environment.
I just wanted to clarify in case someone read your comments and have a wrong impression that Emacs is a text editor like Vim. Nothing more, nothing less.
That post is the fifth most popular thing on my blog, all from search-hits looking for how to count words in Emacs.
The difference is that sos-mode is made for getting answers quickly and being able to copy/paste any code snippets. The output buffer of answers uses org-mode so it's easy to tag the list.
A full-blown stackexchange mode may be good if you're answering questions or looking for a lot of answers but I don't see that happening a lot. Most users are anonymous (sos-mode doesn't require login) and just want to get some answer.
Today I feel it has missed its boat with good looking and user friendly stuff available like Sublime Text, Atom, Eclipse and even cloud IDEs.
I cant help but to laugh quietly to addons like this.
I want to jump to any file at any time regardless of where I am in the project instantly, can Sublime do it? And even if a project has 30-40k files, it must be fast and make me jump instantly. See the demos in this guide for details: http://tuhdo.github.io/helm-projectile.html
Atom has a limit of 2MB text file which is worse than Vim in the 90s.
https://www.youtube.com/channel/UCsON_8vogp4nCQFTnfu43kA
(Other languages also have nice modes for context-aware completion (and more), like Haskell's ghc-mod and Rust's racer, which is incomplete but is already very nice)
[1] - http://emacsrocks.com/
Yes, Sublime handles that smoothly. Do a linux tree clone, enter the directory, run "subl .", then ctrl+p (or cmd+p) and start typing whatever. It fuzzy-completes your typing and immediately displays your selection as a preview in the background as well.
Video here: https://www.dropbox.com/s/wjc9k8ocwiukq5t/sublime-linux.mov?...
(note the percentage in the footer, it was indexing in background the files for code completion and other stuff, since I had just cloned it, but the file jumping still works smoothly).
I skimmed through your other videos, and I didn't instantly see anything that I couldn't do with a recent editor as well.
How about other thing? Like switch between source and header files without configuring anything? Or Jump to any file I see instantly, even without full filepath and you only have just a name and without typing the filename? http://tuhdo.github.io/static/helm-projectile/helm-projectil...
Can it do powerful automatic indentation: https://github.com/Bruce-Connor/aggressive-indent-mode. It does not only indent the current line, but the whole Semantic context around your cursor. Demos inside the homepage.
Beautiful compile output: http://tuhdo.github.io/static/c-ide/compilation-compile.gif
Open man page for symbol at cursor: http://tuhdo.github.io/static/part3/helm-man-woman.gif
Emacs can save any arbitrary window layout and restore it later. You can even have workspace in Emacs, each can store a set of window layouts (i.e. one for debugging, one for reading doc, one for just source code...), can be saved as a bookmark and later restore in future session. In Emacs, you can bookmark everything, even a git commit.
Yes (ctrl+alt+up).
> Or Jump to any file I see instantly, even without full file path > and you only have just a name and without typing the filename?
I'm not sure I understand. I mentioned fuzzy completion before, the way it works is that it matches even subparts of the paths and/or filename, with the only requisite of preserving left to right. For instance if I type "bmx25" I can find boot-related imx25 files, because it will match the "b" from the boot path, and then "mx25" from the filename (even a few directories down the path).
> Can it do powerful automatic indentation:
I never saw such a plugin; generically speaking, plugins can do stuff on keypresses (in a separate thread of course to avoid blocking), for instance you can configure the linters to run at each keypress, at each save, every Nth seconds, after N idle millesconds, etc.
So it depends whether you want to compare the richness of the ecosystem or the core capabilities of the editor.
> Beautiful compile output:
I honestly don't know; it doesn't that by default, though there might be some plugin to that effect; when I use compiled languages, I prefer a linter-like approach to showing compilation errors, so I don't use this kind of plugins in my own environment.
> Open man page for symbol at cursor
yes, this is supported, though I personally switched to Dash (http://kapeli.com/dash) recently, which is similar but much more powerful than just man, as it allows to cache and index documentation from dozens of programming environment and frameworks, taking care of the different formats, etc. So for instance with the same shortcut I can get the help for a POSIX function from its man page, or a Boost class method from their official documentation, and everything is blazingly fast because of local cache and index, so my computer doesn't need to go to boost.org to show that page.
> Emacs can save any arbitrary window layout and restore it later.
You can do that in Sublime, but you need to define a project (which, in its most basic form, is just a "save project" command after having opened a directory); at that point, you have a shortcut to switch between projects with fuzzy completion, and each project keeps the full workspace, ALSO including unsaved modifications to files (which sounds crazy but I love it) as it means that you can do it without even thinking once.
---
Generally speaking, I don't think there's a world of difference. I find vim harder to replicate in its more advanced features, with its approach to command combinations which is totally different from anything else; but emacs introduced to the world the concept an extendible editor based on complicated, targeted commands (which is the one in widespread usage today), so I think that any sufficiently advanced editor can get very close to emacs in most features.
Obviously emacs has many years of history and contributors that created a vast ecosystem, but there might also be some ecosystem bias given its legacy (e.g.: I think it's safe to assert that most web programmers don't use emacs, so I think it's normal to expect Sublime or Atom support for web programming to be generically more advanced).
In fact, I don't think Emacs have a specific paradigm that is hard to replicate, as it's the contrary (what used to be special in Emacs 20 years ago as become the default for all editors nowadays). We can battle on the last advanced feature in one specific workflow, but I think the discussion then becomes anecdoctal or at least very niche-related.
If look at Atom for instance, they introduced a concept where the editor window is not simply line-based, but they can open graphical windows within it, which is a paradigm shift which might introduce unique features, very hard to replicate. See for instance their nested CSS editing feature, which is very nice because it helps my brain limit the context switching a lot.
Does it work in the source as large as the linux kernel that shows you every possible files? i.e I have a file named `fpu.c`, I want all `fpu.h` in Linux. And Emacs does not work with only C/C++, but work for any languages that users define two lists of pairs of file extensions to switch to. i.e. you can switch between Gemfile <-> Gemfile.lock, .h <-> .js...
> I'm not sure I understand. I mentioned fuzzy completion before, the way it works is that it matches even subparts of the paths and/or filename, with the only requisite of preserving left to right. For instance if I type "bmx25" I can find boot-related imx25 files, because it will match the "b" from the boot path, and then "mx25" from the filename (even a few directories down the path).
No. I mean that in an ASCII text file, with only the filename (no path information), you press a key binding, it automatically jumps to that fine. For example, I have a file "Document/test.txt". In "src/feature1/test.c", it only mentions "test.txt". I want that when cursor is on "test.txt", and if that file is the only file in my project, I jump to it instantly; otherwise, it gives me a list of potential candidates. And this must work in any file, even plain ASCII text file.
If the text at point is a directory path, I expect with a single key stroke, my editor returns all files that contain that path.
> So it depends whether you want to compare the richness of the ecosystem or the core capabilities of the editor.
Both. After all, Emacs is a Lisp interpreter at its core. It's a computing environment more than a text editor; text editing is just a subset of it. That's why it is so easy to write tools for Emacs, despite a much lesser user base than other editors. Emacs has many hidden things that I can never find in other editors. For example, it has an advanced calculator and mathematical tool roughly based on the HP-28/48 : http://www.gnu.org/software/emacs/manual/html_mono/calc.html
> I honestly don't know; it doesn't that by default, though there might be some plugin to that effect; when I use compiled languages, I prefer a linter-like approach to showing compilation errors, so I don't use this kind of plugins in my own environment
Emacs supports coloring compile output by default, built-in. Emacs also has a syntax check plugin for wide array of languages, called flycheck: https://github.com/flycheck/flycheck (see the homepage for a simple demo).
And here is GDB inside Emacs: tuhdo.github.io/static/c-ide/gdb-many-windows.gif
Every change you make to a value, all other panes update as well, when relevant. You can also have an integrated memory debugger inside Emacs. You can even do remote debugging with Emacs.
> yes, this is supported, though I personally switched to Dash (http://kapeli.com/dash) recently, which is similar but much more powerful than just man, as it allows to cache and index documentation from dozens of programming environment and frameworks, taking care of the different formats, etc. So for instance with the same shortcut I can get the help for a POSIX function from its man page, or a Boost class method from their official documentation, and everything is blazingly fast because of local cache and index, so my computer doesn't need to go to boost.org to show that page.
Emacs has support for Dash as well, and you can view it inside Emacs: https://github.com/areina/helm-dash
> You can do that in Sublime, but you need to define a project (which, in its most basic form, is just a "save project" command after having opened a directory); at that point, you have a shortcut to switch between projects with fuzzy completion, and each project keeps the full workspace, ALSO including unsaved modifications to files (which sounds crazy but I love it) as it means that you can do it without even thinking once.
Emacs can do that as well. You can switch between projects, and Emacs remembers window layout of each project you are working on with Projectile: https://github.com/bbatsov/projectile. You can see more Projectile demos in my guide (demos at top): http://tuhdo.github.io/helm-projectile.html
What I said is very different. You think each Emacs window is like a perspective in Eclipse. Each window layout can have different purposes: it can be a layout of 4 smaller code buffers, or it can be a debug view, or it can hold many documentation panes... You can arrange arbitrary window layouts, save and restore in future sessions. You can group many window layouts (or "perspectives") inside a workspace, and you can also have many workspaces like that. Each workspace can be a project, each has many different layouts for different purposes.
> Generally speaking, I don't think there's a world of difference. I find vim harder to replicate in its more advanced features, with its approach to command combinations which is totally different from anything else; but emacs introduced to the world the concept an extendible editor based on complicated, targeted commands (which is the one in widespread usage today), so I think that any sufficiently advanced editor can get very close to emacs in most features.
Vim is now a proper subset of Emacs. Evil is the best Vim emulator out there, said Vimmers who switched to Emacs. See Spacemacs: https://github.com/syl20bnr/spacemacs
> If look at Atom for instance, they introduced a concept where the editor window is not simply line-based, but they can open graphical windows within it, which is a paradigm shift which might introduce unique features, very hard to replicate. See for instance their nested CSS editing feature, which is very nice because it helps my brain limit the context switching a lot.
Yet Atom cannot work in terminal, which is essential for working remotely. Emacs can live to this day because it has 30 years of accumulating vast amount of different uses cases. Someday someone will add such capacities to Emacs, when it is really needed. For now, graphic is cute but it mostly satisfies web development. If I have 10 or 20 local VMs (with only terminal), it would be crazy without Emacs to manage all of them effortlessly.
Morevoer, even if Emacs is a LISP machine, it doesn't give it any super-power that can't be replicated in other editors; I mean, it of course gives it flexibility to use it as a mail reader, that's true, but within the editor itself, there's nothing game-changing. I showed features that are either very close, or a bit worse, or a bit better, made with an editor which is not a LISP machine. I think we can agree that anything that you mentioned can be implemented in Sublime as a plugin; if it's not there out of the box, point taken that the ecosystem is more mature, but it doesn't show an inherent gap that can't be filled, it only shows where development effort is being focused on. For Sublime, surely it's not C/C++.
Emacs is also a fine PDF reader. I can search text in the PDF file with highlighting and a table of content side by side. All can be controlled with the keyboard: https://tuhdo.github.io/static/emacs-read-pdf.gif. I never use Evince again.
I don't think that inlining feature really help much. Generally, if you want to access a css element in Emacs, you jump in, edit and jump back in an instant to see your result.
See also web-mode: http://web-mode.org
Well, that's true, and Atom deserves recognition for replicating it...
However, it's not particularly suited to quick server admin stuff. If you're using emacs as its intended, you'll have a lot of packages to load on startup, making it sluggish for ad-hoc editing with sudo (precluduing use of emacsclient). Emacs -q or mg would be faster. Personally, I'm fond of joe for this purpose - more functionality than mg while far smaller an install than emacs.
It looks to me like you're probably unaware that an Emacs not running as root can edit files owned by root. The way it goes about it (in a word, TRAMP) is a little complicated under the hood, but (at least for files residing on the same machine as the Emacs process) reliable.
Specifically, both C-x C-f /sudo::/etc/hosts and `emacsclient /sudo::/etc/hosts` work.
function semacs() {
emacsclient -t -a "" "/sudo::$(realpath $@)"
}It just happens that there are people out there, like me, that want more out of their software and really enjoy tweaking and improving our editor. For us, there's emacs :).
Yes, but you wouldn't have that many excellent extensions without Emacs being a great Elisp IDE. I recently compared PyCharm (I had to purchase it for work) with Emacs and the number of plugins for the former is negligible in comparison. I think that this is because writing extensions/plugins for PyCharm is so much harder than for Emacs: no scratch, no built-in API docs, no full blown book on scripting (like Elisp info), no macro->defun ability, no defadvice, no find-function/find-library and so on and on and on...
Of course, the other reason may be the fact that Emacs has 30 years worth of code written for it :) but I think without matching Emacs extensibility features no editor will ever come close to it in terms of extensions. LightTable looks promising in this regard, so does Atom, but other than these all editors/IDEs look like they don't treat extensibility seriously. Which is why I'm still using Emacs as my primary workspace.
> Did you know that there is a really powerful PDF
You mean with DocView mode? Yes, I knew it (and it's built-in, not 3rd party). I also knew about Calc (http://nullprogram.com/blog/2009/06/23/), about Calendar, about proced, about dired and wdired, about VC, about ediff and emerge, about ctags/etags, about artist-mode, about rmail and gnus, about TRAMP and eshell and ansi-term...
Do you know how I learned about all of them? I just opened this page: https://www.gnu.org/software/emacs/manual/html_mono/emacs.ht... and started reading. You know, cover to cover, as I'd do with any good book. Of course, along the way I switched to reading it inside Emacs, and I skipped some parts I decided I'm very unlikely to ever use, but I can assure you that it's all there. Perhaps a need for such a book is an Emacs failure in itself (because the interface is not discoverable by itself?), but at least it is there. I know of no other editor (Vim comes close in terms of docs coverage, but it's less neatly structured and harder to read cover-to-cover) which is that well documented.
Once you have that "everything is text" realisation, there are two ways to make the most of it. One is to have an editor that's easily called from other places (e.g., vim) and the other is to have an editor that can be integrated into everything (e.g., emacs).
I started using emacs over a decade ago, and it keeps growing and changing to best suit my workflow. And yes, that includes reading mail.
(just kidding. I don't like SE but I'm sure this is a great tool for people who do like SE.)