Stack Exchange for Emacs

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.

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.

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.