bug#36678: 27.0.50; imenu not working in C++ (maybe because of namespace)

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 02 Aug 2019 22:25:27 -0400
> Cc: acm@muc.de, spacibba@aol.com, 36678@debbugs.gnu.org
> 
>   >   And of course there are LSP servers for many languages
>   > which can all be used with the same LSP client.  Since the servers are
>   > external (ccls is based on clang)
> 
> That is not a moral issue but it is something we don't want to support.
> Let's make GNU Emacs do a better job of this.

It is unreasonable to expect Emacs to be able to do a job as good as
the language servers, because that requires to have experts on board
that can implement similar capabilities in Emacs's own code, for the
plethora of languages that we want to and do support in Emacs major
modes.  I counted at least 2 dozen programming-language we support in
lisp/progmodes/, at least a dozen of them major programming languages
that are actively used today to develop and maintain very large
software systems.  We will never be able to have the expertise about
all of these languages nor resources to track their development in a
timely fashion.  Doing that entirely in Emacs Lisp is already
inadequate for several languages, so we will have to go to C, where we
have even less expertise and manpower.

Therefore, supporting language servers should be an important trend in
Emacs development, one of the trends that will ensure its relevance
and vitality in the very near future, let alone in the long run.

We should definitely want to support that.  Whether that server is
installed on the end-user's machine or not is a separate issue, but we
will simply be unable to support modern IDE features without having an
LSP client.  Support for editing programs is the main feature of
Emacs, so we cannot fall back too much in that department.

I see your point about outsourcing some work to an external server,
but I think in this case we have no other way but to support such
servers, because there's no practical alternative.

P.S. Such issues should not be discussed in a bug report.