> How about other thing? Like switch between source and header files without configuring anything?
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.
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.
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.
> 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.
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.
I agree that Emacs has many nice features that come with 30 years of development, but I also thing that those features have a bias towards older paradigms/languages of programming, and thus the advantages reduce a lot and/or there are deficiencies if you move into newer technology stacks.
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++.
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.