[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#36678: 27.0.50; imenu not working in C++ (maybe because of namespace
bug#36678: 27.0.50; imenu not working in C++ (maybe because of namespace)
Sat, 03 Aug 2019 11:09:29 -0400
On Sat, 2019-08-03 at 11:27 +0000, Alan Mackenzie wrote:
> Hello, Paul.
> > However, my personal opinion is that it's likely not the most
> > productive use of time. IMHO cc-mode should continue to focus on
> > formatting (which is clearly no small task, but which it's very good
> > at!) and not attempt to also get involved with indexing.
> CC Mode has had imenu type indexing right from its inception. What is
> changing is the increasing complexity of function definitions, in
> particular, the slow demise of the convention of function names being in
> column zero.
Yes. Languages are getting more complicated, and so more advanced
methods of parsing them are needed!!
Implementing (efficient) parsers in elisp is becoming not just more of
a burden, but more unrealistic.
I'm not suggesting that cc-mode stop trying to parse code completely
and start relying on an LSP server to work.
What I'm suggesting is that we may consider it OK for cc-mode to make
simplifying assumptions about the structure of the code it uses to
provide some basic indexing capability for imenu (such as, functions
start in column 1). And then suggest that for users who have more
complex requirements (for example their code cannot meet these
simplifying assumptions) that they should investigate more
sophisticated setups based on LSP (or whatever they like).
Rather than spending lots and lots of resources trying to reimplement
those sophisticated setups in elisp.
> > The future (again IMO) for indexing and code introspection is in LSP:
> > there are very good LSP servers for C++ that are free ....
> Free as in speech (not beer)? (Just checking.)
They are free software, yes. They may not be copyleft.
> > .... (I use ccls personally) and there are also very good LSP clients
> > for Emacs (I use lsp-mode). 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 ....
> External to what? External to Emacs, or external to the machine running
> Emacs? If the latter, that would restrict full Emacs functionality to
> networked machines, which would be a big negative, possibly a decisive
External to the editor (in this case Emacs).
See my reply to RMS... I should have provided links in my original
email. Sorry about that.
> This makes it controversial, since clang isn't free software in the
> copyleft sense of the term.
Well, LSP is a protocol. There could be copyleft-licensed servers out
there: I haven't looked hard. All the LSP servers for C/C++ I'm aware
of use clang's parser on their backends.
I've never heard anyone suggest that not only do we only accept free
software, we only accept the subset of that software that is copyleft.
I do understand that the origins and aims of clang in particular may be
less than pure. It would be good if an LSP server based on GCC was
created now that it allows integration directly with its parser but so
far as I know no one has done that work. I don't know how feasible it
is based on the interfaces GCC provides.
> > .... they are very fast and can do much, MUCH more than imenu-type
> > indexing.
> Could you please give some idea of what you mean by "much more"?
Since they completely index the source code, they provide not just jump
to definition, but they show all users of an element, they provide
accurate auto-completion, they understand the language structure so
they don't just do text matching but _contextual_ matching so they
won't offer completions that are not valid, etc. It also gives docs
for methods and members in via hover popups, and other things.
You can find out more by looking at some LSP clients for Emacs:
The latter has some animated GIFs showing LSP clients in action.