From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Paul Smith Newsgroups: gmane.emacs.bugs Subject: bug#36678: 27.0.50; imenu not working in C++ (maybe because of namespace) Date: Sat, 03 Aug 2019 11:09:29 -0400 Organization: GNU's Not UNIX! Message-ID: <6bd84b972db36b359b7151755b90eb87d56e61a1.camel@gnu.org> References: <20190717163427.18177.qmail@mail.muc.de> <20190731155610.x33urisumbblyryu@Ergus> <20190802193315.GC11966@ACM> <20190803112734.GA5573@ACM> Reply-To: psmith@gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="85067"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Evolution 3.32.1-2 Cc: Ergus , 36678@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Aug 03 17:10:13 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1htvfh-000M0J-47 for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Aug 2019 17:10:13 +0200 Original-Received: from localhost ([::1]:40524 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1htvff-0001bc-Bl for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Aug 2019 11:10:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55705) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1htvfa-0001bN-7u for bug-gnu-emacs@gnu.org; Sat, 03 Aug 2019 11:10:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1htvfZ-0000q9-13 for bug-gnu-emacs@gnu.org; Sat, 03 Aug 2019 11:10:06 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50945) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1htvfX-0000oB-39; Sat, 03 Aug 2019 11:10:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1htvfW-0007Jh-Rt; Sat, 03 Aug 2019 11:10:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Smith Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Sat, 03 Aug 2019 15:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36678 X-GNU-PR-Package: emacs,cc-mode Original-Received: via spool by 36678-submit@debbugs.gnu.org id=B36678.156484497728086 (code B ref 36678); Sat, 03 Aug 2019 15:10:02 +0000 Original-Received: (at 36678) by debbugs.gnu.org; 3 Aug 2019 15:09:37 +0000 Original-Received: from localhost ([127.0.0.1]:59766 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1htvf7-0007Iw-1L for submit@debbugs.gnu.org; Sat, 03 Aug 2019 11:09:37 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:43210) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1htvf5-0007Ih-Sx for 36678@debbugs.gnu.org; Sat, 03 Aug 2019 11:09:36 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58563) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1htvf0-0000ZG-JQ; Sat, 03 Aug 2019 11:09:30 -0400 Original-Received: from pool-98-118-0-140.bstnma.fios.verizon.net ([98.118.0.140]:35694 helo=homebase.home) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1htvf0-0000iu-BJ; Sat, 03 Aug 2019 11:09:30 -0400 In-Reply-To: <20190803112734.GA5573@ACM> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:164466 Archived-At: 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!