From: Ergus <spacibba@aol.com>
To: Alan Mackenzie <acm@muc.de>
Cc: 36678@debbugs.gnu.org
Subject: bug#36678: 27.0.50; imenu not working in C++ (maybe because of namespace)
Date: Wed, 31 Jul 2019 17:56:13 +0200 [thread overview]
Message-ID: <20190731155610.x33urisumbblyryu@Ergus> (raw)
In-Reply-To: <20190717163427.18177.qmail@mail.muc.de>
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).
>
next prev parent reply other threads:[~2019-07-31 15:56 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 [this message]
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
2019-08-03 11:27 ` Alan Mackenzie
2019-08-03 15:09 ` Paul Smith
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
[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
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=20190731155610.x33urisumbblyryu@Ergus \
--to=spacibba@aol.com \
--cc=36678@debbugs.gnu.org \
--cc=acm@muc.de \
/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.