[giovannibajo1]

> 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

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.

[tuhdo]

Emacs also has that preview feature when you move the highlighter to a selection. However, I feel it annoying because screen keeps changing while I narrow to a file or a set of files, and luckily it is off by default.

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.

[giovannibajo1]

> 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.

[tuhdo]

If you want image display, there Emacs has it eons ago, and people write plug-ins for it, like this one: https://github.com/josteink/wsd-mode

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.

[giovannibajo1]

No, I don't want image display. I want to replicate Atom's inlining editing features. Did you look into that? This is one example: https://discuss.atom.io/t/expand-css-rules-inline-html/12437

[tuhdo]

i think skewer-mode is close enough: https://github.com/skeeto/skewer-mode for live editing.

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

[klibertp]

> is a paradigm shift [...] very hard to replicate

Well, that's true, and Atom deserves recognition for replicating it...

http://www.emacswiki.org/emacs/EmacsXWidgets

[giovannibajo1]

Well, that's the basic technological point, then you need the commands to make it useful for writing code at production speed, and not just a gimmick.

[klibertp]

Yes, I was being obviously unfair here, sorry for this.

[tuhdo]

> Yes (ctrl+alt+up).

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.

[giovannibajo1]

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++.