Emacs doesn't come with everything built-in. But when you extend Emacs, you usually do it entirely in Emacs with Elisp. Emacs libraries rarely call external tools - they usually implement the tools inside Emacs.
I don't think I misunderstood the parent. The parent heavily implies that Emacs' semantic mode simply works out of the box.
I have no idea if that's the case, but if it's not, there is no functional difference between that and any other editor, where you need to install a separate plugin.
Sublime itself can be extended with Python. To me, that's a better solution than a proprietary (albeit Lisp-based) language.
Whether those plugins "call external tools" or not is of little importance, although relying, in a modular fashion, on pre-existing software is more Unixy.
I'm sure Emacs' tag system is powerful, but personally, I would rather have something like SublimeClang, which is built on a high-quality, highly maintained C/C++ compiler toolchain that retain type information and so on, than some kind of tag system based on a superficial parser designed purely for code inference.
You did indeed misunderstand my post. I was not arguing about the relative merits of clang vs some-other-tool.
I was simply saying that Emacs can open a C++ file and have all tags and completions right there, no setup required. No external application required either. That is the power of Emacs and that is a power not available to Sublime Text (unless you write your own C++ parser in Python).
You see, clang is an awesome tool and I'm sure its integration in Sublime Text is very good. But by its design it can not look for headers in appropriate locations without someone explicitly telling it to do so. Also it can not parse partially erroneous code. Both these actions are just not sensible actions for a compiler.
And that is why no external tool can ever provide the integration and practicability of a tool purposely built just for parsing code for Emacs in the same way cscope can not match the integration of Visual Studio's C# parser in Visual Studio.
I am not arguing the merits of Clang versus some other tool, either.
I am arguing against the claim that a monolithic app like Emacs that bundles a specific tool is somehow qualitatively superior to any other tool which does not bundle a specific tool.
> But by its design it can not look for headers in appropriate locations
I think that's a perfectly valid design. I would rather want to spend 10 seconds adding a path to my project's config file than spend an eternity with just ctags. :-)
> Also it can not parse partially erroneous code.
Of course it can. Clang recovers from partially invalid code just fine.
For example, if I do something like "typedef enum { a, b, 3 } foo bar;" (constituting two syntax errors), it will still correctly autocomplete "foo" as well as its values, even though the type is strictly incomplete.
Emacs is anything but monolothic. I think that is what our argument boils down to.
Emacs is a Lisp virtual machine and someone happens to have implemented da rather splendid text editor in it. Claiming that Emacs is monolithic is about as meaningful as calling the assorted programs that make up a Unix environment monolithic.
Emacs doesn't come with everything built-in. But when you extend Emacs, you usually do it entirely in Emacs with Elisp. Emacs libraries rarely call external tools - they usually implement the tools inside Emacs.