all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Paul Smith <psmith@gnu.org>
To: Alan Mackenzie <acm@muc.de>
Cc: Ergus <spacibba@aol.com>, 36678@debbugs.gnu.org
Subject: bug#36678: 27.0.50; imenu not working in C++ (maybe because of namespace)
Date: Sat, 03 Aug 2019 11:09:29 -0400	[thread overview]
Message-ID: <6bd84b972db36b359b7151755b90eb87d56e61a1.camel@gnu.org> (raw)
In-Reply-To: <20190803112734.GA5573@ACM>

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

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:

https://github.com/emacs-lsp/lsp-mode
https://github.com/joaotavora/eglot

The latter has some animated GIFs showing LSP clients in action.

Cheers!






  reply	other threads:[~2019-08-03 15:09 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-15 20:33 bug#36678: 27.0.50; imenu not working in C++ (maybe because of namespace) Ergus
     [not found] ` <mailman.1463.1563222851.2688.bug-gnu-emacs@gnu.org>
2019-07-17 14:39   ` Alan Mackenzie
2019-07-17 16:34   ` Alan Mackenzie
2019-07-31 15:56     ` Ergus
2019-08-02 19:33       ` Alan Mackenzie
     [not found]       ` <20190802193315.GC11966@ACM>
2019-08-02 19:56         ` Paul Smith
2019-08-03  2:25           ` Richard Stallman
     [not found]           ` <E1htjjb-0002eO-Fo@fencepost.gnu.org>
2019-08-03  7:20             ` Eli Zaretskii
2019-08-03 14:43             ` Paul Smith
2019-08-05  2:24               ` Richard Stallman
2019-08-03 11:27           ` Alan Mackenzie
2019-08-03 15:09             ` Paul Smith [this message]
2019-08-04  3:01               ` Richard Stallman
2019-08-04 13:56                 ` Paul Smith
2019-08-05  2:25                   ` Richard Stallman
2019-08-04  2:56             ` Richard Stallman
2019-08-04  8:51               ` Alan Mackenzie
2019-08-05  2:26                 ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6bd84b972db36b359b7151755b90eb87d56e61a1.camel@gnu.org \
    --to=psmith@gnu.org \
    --cc=36678@debbugs.gnu.org \
    --cc=acm@muc.de \
    --cc=spacibba@aol.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.