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)

[Ergus]

[-- Attachment #1: Type: text/plain, Size: 3398 bytes --]

--text follows this line--

In the example code (attachement) imenu does not recognizes the
functions. So it shows that there are not candidates when there are.


In GNU Emacs 27.0.50 (build 5, x86_64-pc-linux-gnu, GTK+ Version 3.24.10)
 of 2019-07-14 built on Ergus
Repository revision: 783eca57159065ea575622b74e1446853f31621a
Repository branch: master
System Description: Arch Linux

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
imenu-unavailable-error: imenu unavailable: "No items suitable for an index found in this buffer"
Making completion list...
funcall-interactively: End of buffer [18 times]

Configured using:
 'configure --prefix=/home/ergo/PhD/emacs/emacs.install_arch
 --with-mailutils --with-x-toolkit=gtk3 --with-xft --with-modules'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON
PDUMPER LCMS2 GMP

Important settings:
  value of $LC_CTYPE: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: C++//l

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec subr-x rfc822 mml mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs text-property-search time-date
seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils cl-seq imenu
cc-mode cc-fonts easymenu cc-guess cc-menus cc-cmds cc-styles cc-align
cc-engine cc-vars cc-defs cl-loaddefs cl-lib term/tmux term/xterm xterm
elec-pair tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 72274 9319)
 (symbols 48 8631 1)
 (strings 32 22019 1603)
 (string-bytes 1 830903)
 (vectors 16 10696)
 (vector-slots 8 112616 7942)
 (floats 8 25 573)
 (intervals 56 365 57)
 (buffers 992 13))

[-- Attachment #2: make_local_matrix.hpp --]
[-- Type: text/plain, Size: 788 bytes --]

#ifndef _make_local_matrix_hpp_
#define _make_local_matrix_hpp_

#include <vector>
#include <map>

#include <cassert>
#include <cstdio>

#include <fstream>


namespace miniFE {


	void get_recv_info_task(CSRMatrix *A, size_t id, size_t numboxes
	                        const size_t *nrows_array,
	                        size_t Annz, size_t Anrows)
	{

	}


	void get_send_info_task(CSRMatrix *A, size_t id,
		size_t numboxes,
		int *send_length_local)
	{
	}


	void set_send_info_task(CSRMatrix *A_array, size_t id,
	                        size_t numboxes,
	                        int nelements_to_send_local,
	                        int *elements_to_send_local)
	{
	}

	void make_local_matrix(CSRMatrix *A_array, singleton *sing, size_t numboxes)
	{
	}

}//namespace miniFE

#endif

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

[Alan Mackenzie]

Hello, Ergus.

In article <mailman.1463.1563222851.2688.bug-gnu-emacs@gnu.org> you wrote:
> [-- text/plain, encoding 7bit, charset: us-ascii, 91 lines --]

> --text follows this line--

> In the example code (attachement) imenu does not recognizes the
> functions. So it shows that there are not candidates when there are.

OK.  I'll look into this.

> In GNU Emacs 27.0.50 (build 5, x86_64-pc-linux-gnu, GTK+ Version 3.24.10)
> of 2019-07-14 built on Ergus
> Repository revision: 783eca57159065ea575622b74e1446853f31621a
> Repository branch: master
> System Description: Arch Linux

[ .... ]

> Major mode: C++//l

> Minor modes in effect:
>  tooltip-mode: t
>  global-eldoc-mode: t
>  electric-indent-mode: t
>  mouse-wheel-mode: t
>  tool-bar-mode: t
>  menu-bar-mode: t
>  file-name-shadow-mode: t
>  global-font-lock-mode: t
>  font-lock-mode: t
>  auto-composition-mode: t
>  auto-encryption-mode: t
>  auto-compression-mode: t
>  line-number-mode: t
>  transient-mark-mode: t
>  abbrev-mode: t

[ .... ]

> #ifndef _make_local_matrix_hpp_
> #define _make_local_matrix_hpp_

> #include <vector>
> #include <map>

> #include <cassert>
> #include <cstdio>

> #include <fstream>


> namespace miniFE {


>         void get_recv_info_task(CSRMatrix *A, size_t id, size_t numboxes
>                                 const size_t *nrows_array,
>                                 size_t Annz, size_t Anrows)
>         {

>         }


>         void get_send_info_task(CSRMatrix *A, size_t id,
>                 size_t numboxes,
>                 int *send_length_local)
>         {
>         }


>         void set_send_info_task(CSRMatrix *A_array, size_t id,
>                                 size_t numboxes,
>                                 int nelements_to_send_local,
>                                 int *elements_to_send_local)
>         {
>         }

>         void make_local_matrix(CSRMatrix *A_array, singleton *sing, size_t numboxes)
>         {
>         }

> }//namespace miniFE

> #endif

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Alan Mackenzie]

Hello again, Ergus.

In article <mailman.1463.1563222851.2688.bug-gnu-emacs@gnu.org> you wrote:
> [-- text/plain, encoding 7bit, charset: us-ascii, 91 lines --]

> --text follows this line--

> In the example code (attachement) imenu does not recognizes the
> functions. So it shows that there are not candidates when there are.

[ .... ]

> Major mode: C++//l

The problem is that the function names are not at column zero.  If they
were, they'd get recognised properly.  If CC Mode's imenu were to
recognise indented functions there'd be too many false positives.

This problem has actually come up before (on 2016-11-25, in a post to the
CC Mode list by Jens Kjerrström), and I then hacked up three defuns which
would search for functions functionally rather than by regexp.  This
wasn't wholly satisfactory since (i) this searching was slow; and (ii) if
there were two functions of the same name (e.g., in different
namespaces), imenu would only find the first one in the buffer.

If you are interested, I could send you this hack, which is not all that
big.  Maybe you could play around with it and make it work well.

Maybe it would be possible to bring this approach up to a usable part of
CC Mode - possibly solving (ii) by constructing a hierarchical menu, but
problem (i) would remain.  In any case this would be a substantial
enhancement rather than a simple bug fix.

[ .... ]

> [-- text/plain, encoding 7bit, charset: us-ascii, 45 lines, name: make_local_matrix.hpp --]

> #ifndef _make_local_matrix_hpp_
> #define _make_local_matrix_hpp_

> #include <vector>
> #include <map>

> #include <cassert>
> #include <cstdio>

> #include <fstream>


> namespace miniFE {


>         void get_recv_info_task(CSRMatrix *A, size_t id, size_t numboxes
>                                 const size_t *nrows_array,
>                                 size_t Annz, size_t Anrows)
>         {

>         }


>         void get_send_info_task(CSRMatrix *A, size_t id,
>                 size_t numboxes,
>                 int *send_length_local)
>         {
>         }


>         void set_send_info_task(CSRMatrix *A_array, size_t id,
>                                 size_t numboxes,
>                                 int nelements_to_send_local,
>                                 int *elements_to_send_local)
>         {
>         }

>         void make_local_matrix(CSRMatrix *A_array, singleton *sing, size_t numboxes)
>         {
>         }

> }//namespace miniFE

> #endif

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Ergus]

Hi Alan:

Sorry for the long delay replying this.

I have been thinking on this for a while because this issue affects me
constantly as I use most of the time C++ now.

Maybe this is a stupid suggestion, but I was thinking that if the issue
is performance (for ii) we could add a special function to implement the
expensive part for the functional search in C and use the C regexps.

Maybe it could be restrictive somehow, but if this solves a problem,
could be good enough and important for C++-mode. Because namespace use
is becoming more and more extended in C++ with the new standards. And
the most common indentations are the 

Probably:

1) For example it could do a first filtration for the buffer in a C
function using C regexp (with fake positives) and then filter again in
the Lisp side?

2) Or, we could just iterate the file by lines in C and then modify the
regex for the next line conditionally (which is cheaper than in
Lisp). This could create a list in C that we can then use in the Lisp
side more efficiently.

In case we figure out a nice method for that. Does it makes sense?



On Wed, Jul 17, 2019 at 04:34:27PM -0000, Alan Mackenzie wrote:
>Hello again, Ergus.
>
>In article <mailman.1463.1563222851.2688.bug-gnu-emacs@gnu.org> you wrote:
>> [-- text/plain, encoding 7bit, charset: us-ascii, 91 lines --]
>
>> --text follows this line--
>
>> In the example code (attachement) imenu does not recognizes the
>> functions. So it shows that there are not candidates when there are.
>
>[ .... ]
>
>> Major mode: C++//l
>
>The problem is that the function names are not at column zero.  If they
>were, they'd get recognised properly.  If CC Mode's imenu were to
>recognise indented functions there'd be too many false positives.
>
>This problem has actually come up before (on 2016-11-25, in a post to the
>CC Mode list by Jens Kjerrstr?m), and I then hacked up three defuns which
>would search for functions functionally rather than by regexp.  This
>wasn't wholly satisfactory since (i) this searching was slow; and (ii) if
>there were two functions of the same name (e.g., in different
>namespaces), imenu would only find the first one in the buffer.
>
>If you are interested, I could send you this hack, which is not all that
>big.  Maybe you could play around with it and make it work well.
>
>Maybe it would be possible to bring this approach up to a usable part of
>CC Mode - possibly solving (ii) by constructing a hierarchical menu, but
>problem (i) would remain.  In any case this would be a substantial
>enhancement rather than a simple bug fix.
>
>[ .... ]
>
>> [-- text/plain, encoding 7bit, charset: us-ascii, 45 lines, name: make_local_matrix.hpp --]
>
>> #ifndef _make_local_matrix_hpp_
>> #define _make_local_matrix_hpp_
>
>> #include <vector>
>> #include <map>
>
>> #include <cassert>
>> #include <cstdio>
>
>> #include <fstream>
>
>
>> namespace miniFE {
>
>
>>         void get_recv_info_task(CSRMatrix *A, size_t id, size_t numboxes
>>                                 const size_t *nrows_array,
>>                                 size_t Annz, size_t Anrows)
>>         {
>
>>         }
>
>
>>         void get_send_info_task(CSRMatrix *A, size_t id,
>>                 size_t numboxes,
>>                 int *send_length_local)
>>         {
>>         }
>
>
>>         void set_send_info_task(CSRMatrix *A_array, size_t id,
>>                                 size_t numboxes,
>>                                 int nelements_to_send_local,
>>                                 int *elements_to_send_local)
>>         {
>>         }
>
>>         void make_local_matrix(CSRMatrix *A_array, singleton *sing, size_t numboxes)
>>         {
>>         }
>
>> }//namespace miniFE
>
>> #endif
>
>-- 
>Alan Mackenzie (Nuremberg, Germany).
>

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

[Alan Mackenzie]

Hello, Ergus.

On Wed, Jul 31, 2019 at 17:56:13 +0200, Ergus wrote:
> Hi Alan:

> Sorry for the long delay replying this.

No problem!

> I have been thinking on this for a while because this issue affects me
> constantly as I use most of the time C++ now.

I've actually spent some time on this.  What I now have is the ability of
imenu to find functions, even when they are not at column zero, and to
record the enclosing namespace/class/etc. of these functions.  On M-x
imenu <tab>, which lists all found functions (more or less), the
namespace/class bit only gets displayed as needed to distinguish from
other functions of the same name.

The above is a bit of an exaggeration: it is not yet clean or robust
code, and hasn't been tested much, but does sort of work on the files
I've tried it on.

What is still missing is a scanning of a function's parameters, needed to
distinguish, say, a constructor with two parameters from the same with
none.  This is still looking a bit tricky.

> Maybe this is a stupid suggestion, but I was thinking that if the issue
> is performance (for ii) we could add a special function to implement the
> expensive part for the functional search in C and use the C regexps.

At the moment, the scanning of these C++ files is taking a small number
of seconds on my (pretty fast) Ryzen machine.  This is slow for imenu.

I can't honestly see how we might use a C function to speed all this up.
Currently, my new code is just using (c-beginning-of-defun -1) to find
the next function, thus avoiding the need to write reams of syntactical
analysis code, but not being fast.

> Maybe it could be restrictive somehow, but if this solves a problem,
> could be good enough and important for C++-mode. Because namespace use
> is becoming more and more extended in C++ with the new standards. And
> the most common indentations are the 

> Probably:

> 1) For example it could do a first filtration for the buffer in a C
> function using C regexp (with fake positives) and then filter again in
> the Lisp side?

> 2) Or, we could just iterate the file by lines in C and then modify the
> regex for the next line conditionally (which is cheaper than in
> Lisp). This could create a list in C that we can then use in the Lisp
> side more efficiently.

All this might be workable, I just don't know.  But it would probably
make sense to write it in Lisp first, and only then optimise it with C if
it really is too slow.

> In case we figure out a nice method for that. Does it makes sense?

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Paul Smith]

I certainly don't want to discourage anyone from pursuing new features
and capabilities if they want to.

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.

The future (again IMO) for indexing and code introspection is in LSP:
there are very good LSP servers for C++ that are free (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 (ccls is based on clang) they are very fast and can do much,
MUCH more than imenu-type indexing.  I honestly can't imagine working
on a larger codebase without it, anymore.

I don't personally use imenu but a quick search shows that there are
integrations of imenu and lsp-mode available.

Just my $0.02!!

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The future (again IMO) for indexing and code introspection is in LSP:
  > there are very good LSP servers for C++ that are free (I use ccls
  > personally) and there are also very good LSP clients for Emacs (I use
  > lsp-mode).

Using a server to do your ocmputing job is bad for your freedom
(unless it's your own server).  We call it Service as a Software Substitute
(https://gnu.org/philosophy/who-does-that-server-really-serve.html).

Since you don't control the code running someone else's service.  it
is never "free" the way a program can be free.  It's not a solution,
it's a problem.

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

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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.

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

[Paul Smith]

On Fri, 2019-08-02 at 22:25 -0400, Richard Stallman wrote:
>   > The future (again IMO) for indexing and code introspection is in LSP:
>   > there are very good LSP servers for C++ that are free (I use ccls
>   > personally) and there are also very good LSP clients for Emacs (I use
>   > lsp-mode).
> 
> Using a server to do your ocmputing job is bad for your freedom
> (unless it's your own server).

Sorry, I guess I should have provided more details.  When I say
"server" I mean in the traditional sense, of a background process
running on your local system.  I don't mean "service", as in Internet
service.

LSP stands for "Language Server Protocol" and is a public protocol
(invented and driven by Microsoft, but a public effort).

The goal is to split the work of indexing source code and the work of
editing source code into two parts, and LSP is the protocol between
those two parts.  The protocol is language agnostic, so if you have a
client that speaks LSP, that same client can work for ANY language for
which you have an LSP server.  There are (free) LSP servers available
for most popular languages.

More info here: https://langserver.org/

An Internet service would be quite untenable since the server is used
to index your source code, and virtually no one would be interested in
uploading all of their source code to some third party for indexing.
Plus it's indexing your particular code so it would have to support
uploading every individual developers workspace, and uploading every
change to that workspace, etc.

There are many free software LSP server implementations.  The one I
mentioned, ccls, supports C and C++ and is licensed via Apache 2.0:

https://github.com/MaskRay/ccls

Of course the Emacs client implementations are all free software
(available on ELPA etc.)

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Sorry, I guess I should have provided more details.  When I say
  > "server" I mean in the traditional sense, of a background process
  > running on your local system.  I don't mean "service", as in Internet
  > service.

That makes a big moral difference.
There is nothing wrong about running free software in a daemon process.

However, the word "server" is traditionally used for programs to be
contacted over the network.  For the programs that run in the
background and are contacted from the same machine, the usual term is
"daemon".



-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Alan Mackenzie]

Hello, Paul.

On Fri, Aug 02, 2019 at 15:56:59 -0400, Paul Smith wrote:
> I certainly don't want to discourage anyone from pursuing new features
> and capabilities if they want to.

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

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

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

> .... (ccls is based on clang) ....

This makes it controversial, since clang isn't free software in the
copyleft sense of the term.

> .... 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"?

> I honestly can't imagine working on a larger codebase without it,
> anymore.

Does the server you're using run on your own machine?  (I'm guessing
yes.)

> I don't personally use imenu but a quick search shows that there are
> integrations of imenu and lsp-mode available.

> Just my $0.02!!

Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Paul Smith]

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!

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

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

That is the approach I have used since the start.

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

Instead of giving up, let's design additional simplifying conventions.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Paul Smith]

On Sat, 2019-08-03 at 23:01 -0400, Richard Stallman wrote:
>   > 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).
> 
> Instead of giving up, let's design additional simplifying conventions.

Simplifying conventions are only workable if they are used throughout
the codebase.  If you have a one-man development team that's fine but 
convincing a larger team to adjust their coding conventions to support
one editor is generally not feasible.

In any event as Eli mentioned this bug report is probably not the place
to have this discussion: I'm happy to move it to an FSF discussion list
if we want to have a deeper conversation.

And again I don't want to discourage anyone from working on what they
find enjoyable.  If cc-mode can be taught to handle namespaces
reasonably so much the better.  But if not, there are good (free
software) options available for Emacs so that's OK too.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Simplifying conventions are only workable if they are used throughout
  > the codebase.  If you have a one-man development team that's fine but 
  > convincing a larger team to adjust their coding conventions to support
  > one editor is generally not feasible.

You could say the same about our old conventions, such as open-paren
in column zero and function name in column zero.  Projects of all sizes
adopted them because they were helpful.

I therefore urge Emacs developers to work on improvements along these
lines.  If not everyone uses them, that's not our problem.


-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

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

Why is that happening?  Is there a practical benefit, or is it just
a matter of fashion, or what?

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Alan Mackenzie]

Hello, Richard.

On Sat, Aug 03, 2019 at 22:56:19 -0400, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

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

> Why is that happening?  Is there a practical benefit, or is it just
> a matter of fashion, or what?

In C++, it's largely the namespace, which is being used ever more.

Instead of writing

    namespace foo {
    int bar (int baz)
    {
        .....
    }
    .....
    }

, people are indenting within the namespace, something like

    namespace foo {
        int bar (int baz)
	{
	    ....
	}
	....
    }

.  Not all the time, but a lot of the time, possibly most of the time.
This indentation inside a namespace seems like a natural way to format a
program, and people are going to carry on doing it.

The issue is how we best deal with this.

> -- 
> Dr Richard Stallman
> President, Free Software Foundation (https://gnu.org, https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > This indentation inside a namespace seems like a natural way to format a
  > program, and people are going to carry on doing it.

I think they are making a bad decision, and we should spread awareness
of the practical reasons not to do that.

Of course, if we can make Emacs handle that kind of indentation
better, it is good to do so.  If we can do so with no slowdown, that's
ideal.  But educating users to follow indentation conventions is much
better than nothing.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)