* CC Mode and GCC/CEDET integration for evaluating macros
@ 2015-05-01 17:03 Oleh Krehel
2015-05-01 18:11 ` Alan Mackenzie
0 siblings, 1 reply; 12+ messages in thread
From: Oleh Krehel @ 2015-05-01 17:03 UTC (permalink / raw
To: emacs-devel
Hi all,
I just went through the whole CC Mode manual, just to make sure that I'm
not being silly asking for an existing feature.
I'd like to be able to evaluate the current symbolic constant at point
with "C-x C-e" for C/C++. Moreover, I remember when I was using Visual
Studio 10 years ago, it had a feature of parsing the macros and graying
out #ifdef branches. I found a screenshot of this if it's not clear what
I mean: http://stackoverflow.com/questions/11610549/
I think it would be really cool to add both these features to CC Mode.
So I'd like to ask:
1. Is there any past progress towards these features?
2. How viable is it to implement them? Could they work for the most
common build systems?
3. Could / should they be implemented based on CEDET or GCC?
4. How hard would it be to actually do it all? Are there any predictable
roadblocks?
5. Would other people besides me find these features useful?
Oleh
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: CC Mode and GCC/CEDET integration for evaluating macros
2015-05-01 17:03 CC Mode and GCC/CEDET integration for evaluating macros Oleh Krehel
@ 2015-05-01 18:11 ` Alan Mackenzie
2015-05-01 18:23 ` Oleh Krehel
2015-05-02 8:57 ` martin rudalics
0 siblings, 2 replies; 12+ messages in thread
From: Alan Mackenzie @ 2015-05-01 18:11 UTC (permalink / raw
To: Oleh Krehel; +Cc: emacs-devel
Hello, Oleh.
I'm speaking here for CC Mode, not CEDET.
On Fri, May 01, 2015 at 07:03:05PM +0200, Oleh Krehel wrote:
> Hi all,
> I just went through the whole CC Mode manual, just to make sure that I'm
> not being silly asking for an existing feature.
> I'd like to be able to evaluate the current symbolic constant at point
> with "C-x C-e" for C/C++.
There's nothing like that in CC Mode. But there is c-macro-expand in
cmacexp.el which might have something like this, or be easily hackable to
something like this.
> Moreover, I remember when I was using Visual Studio 10 years ago, it
> had a feature of parsing the macros and graying out #ifdef branches. I
> found a screenshot of this if it's not clear what I mean:
> http://stackoverflow.com/questions/11610549/
There is hide-ifdef-mode in Emacs which does something similar - It makes
the "non-active" bits of #ifdef branches invisible rather than changing
their appearance. Doubtless it would be easy enough to add the "greying
out" facility as an option.
> I think it would be really cool to add both these features to CC Mode.
I'm not sure CC Mode would be the best place for these. hide-ifdef-mode
nd c-macro-expand already exist. I suggest you look at these first.
> So I'd like to ask:
> 1. Is there any past progress towards these features?
> 2. How viable is it to implement them? Could they work for the most
> common build systems?
> 3. Could / should they be implemented based on CEDET or GCC?
> 4. How hard would it be to actually do it all? Are there any predictable
> roadblocks?
> 5. Would other people besides me find these features useful?
> Oleh
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: CC Mode and GCC/CEDET integration for evaluating macros
2015-05-01 18:11 ` Alan Mackenzie
@ 2015-05-01 18:23 ` Oleh Krehel
2015-05-01 18:46 ` Eli Zaretskii
2015-05-02 8:57 ` martin rudalics
1 sibling, 1 reply; 12+ messages in thread
From: Oleh Krehel @ 2015-05-01 18:23 UTC (permalink / raw
To: Alan Mackenzie; +Cc: emacs-devel
Hello Alan,
Thanks for the response, I'm really glad I asked first before trying to
hack up something on my own.
Alan Mackenzie <acm@muc.de> writes:
> On Fri, May 01, 2015 at 07:03:05PM +0200, Oleh Krehel wrote:
>
>> Hi all,
>
>> I just went through the whole CC Mode manual, just to make sure that I'm
>> not being silly asking for an existing feature.
>
>> I'd like to be able to evaluate the current symbolic constant at point
>> with "C-x C-e" for C/C++.
>
> There's nothing like that in CC Mode. But there is c-macro-expand in
> cmacexp.el which might have something like this, or be easily hackable to
> something like this.
I tried c-macro-expand and it works well for macros defined within the
current file, and even for the standard stuff like __TIMESTAMP__. But
it doesn't work, for instance for HAVE_PWD_H in editfns.c. Do you know
if it could work? Is it just a matter of passing some include path to
the preprocessor call?
>> Moreover, I remember when I was using Visual Studio 10 years ago, it
>> had a feature of parsing the macros and graying out #ifdef branches. I
>> found a screenshot of this if it's not clear what I mean:
>> http://stackoverflow.com/questions/11610549/
>
> There is hide-ifdef-mode in Emacs which does something similar - It makes
> the "non-active" bits of #ifdef branches invisible rather than changing
> their appearance. Doubtless it would be easy enough to add the "greying
> out" facility as an option.
It appears that `hide-ifdefs' hides them unconditionally.
>> I think it would be really cool to add both these features to CC Mode.
>
> I'm not sure CC Mode would be the best place for these. hide-ifdef-mode
> nd c-macro-expand already exist. I suggest you look at these first.
The functions exist, sure. But for most users they are invisible /
unknown unless they are bound in a keymap. `c-mode-map' is pretty
visible and would be a great way to promote these features.
Oleh
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: CC Mode and GCC/CEDET integration for evaluating macros
2015-05-01 18:23 ` Oleh Krehel
@ 2015-05-01 18:46 ` Eli Zaretskii
2015-05-01 18:52 ` Oleh Krehel
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2015-05-01 18:46 UTC (permalink / raw
To: Oleh Krehel; +Cc: acm, emacs-devel
> From: Oleh Krehel <ohwoeowho@gmail.com>
> Date: Fri, 01 May 2015 20:23:32 +0200
> Cc: emacs-devel@gnu.org
>
> I tried c-macro-expand and it works well for macros defined within the
> current file, and even for the standard stuff like __TIMESTAMP__. But
> it doesn't work, for instance for HAVE_PWD_H in editfns.c. Do you know
> if it could work? Is it just a matter of passing some include path to
> the preprocessor call?
You need to pass it the same -I flags as used during the Emacs build,
see src/Makefile.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: CC Mode and GCC/CEDET integration for evaluating macros
2015-05-01 18:46 ` Eli Zaretskii
@ 2015-05-01 18:52 ` Oleh Krehel
2015-05-01 19:30 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Oleh Krehel @ 2015-05-01 18:52 UTC (permalink / raw
To: Eli Zaretskii; +Cc: acm, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Oleh Krehel <ohwoeowho@gmail.com>
>> Date: Fri, 01 May 2015 20:23:32 +0200
>> Cc: emacs-devel@gnu.org
>>
>> I tried c-macro-expand and it works well for macros defined within the
>> current file, and even for the standard stuff like __TIMESTAMP__. But
>> it doesn't work, for instance for HAVE_PWD_H in editfns.c. Do you know
>> if it could work? Is it just a matter of passing some include path to
>> the preprocessor call?
>
> You need to pass it the same -I flags as used during the Emacs build,
> see src/Makefile.
Thanks for the suggestion. I tried it and it didn't work. I've edited
src/Makefile.in to add:
echo_cflags:
echo "$(ALL_CFLAGS)"
Here are the flags that I obtained and passed to `c-macro-expand':
-Demacs -I. -I. -I../lib -I../lib -pthread -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/inclu
de/at-spi2-atk/2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/inc
lude/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/
harfbuzz -I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/libpng12 -I/usr/include/freet
ype2 -pthread -I/usr/include/librsvg-2.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.
0/include -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/cairo -I/usr/include/libpng12 -I/usr/include/pixm
an-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/libxml2 -I/usr/include/dbus-1.
0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64-l
inux-gnu/glib-2.0/include -pthread -I/usr/include/gconf/2 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-li
nux-gnu/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/i
nclude/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/freetype2 -I/usr/include
/freetype2 -I/usr/include/freetype2
Is there a working / better way to get these flags. I wouldn't want to
reconfigure just to get the flags.
Oleh
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: CC Mode and GCC/CEDET integration for evaluating macros
2015-05-01 18:52 ` Oleh Krehel
@ 2015-05-01 19:30 ` Eli Zaretskii
2015-05-01 19:42 ` Oleh Krehel
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2015-05-01 19:30 UTC (permalink / raw
To: Oleh Krehel; +Cc: acm, emacs-devel
> From: Oleh Krehel <ohwoeowho@gmail.com>
> Cc: acm@muc.de, emacs-devel@gnu.org
> Date: Fri, 01 May 2015 20:52:46 +0200
>
> > You need to pass it the same -I flags as used during the Emacs build,
> > see src/Makefile.
>
> Thanks for the suggestion. I tried it and it didn't work.
Sorry, I'm confused: what did you try, and how did it not work?
> Is there a working / better way to get these flags.
You could say "make -n fns.o -W fns.c", and process the output, I
guess. In any case, src/Makefile is the only place where these flags
are recorded, so you must somehow ask Make to display them.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: CC Mode and GCC/CEDET integration for evaluating macros
2015-05-01 19:30 ` Eli Zaretskii
@ 2015-05-01 19:42 ` Oleh Krehel
2015-05-02 8:27 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Oleh Krehel @ 2015-05-01 19:42 UTC (permalink / raw
To: Eli Zaretskii; +Cc: acm, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Oleh Krehel <ohwoeowho@gmail.com>
>> Cc: acm@muc.de, emacs-devel@gnu.org
>> Date: Fri, 01 May 2015 20:52:46 +0200
>>
>> > You need to pass it the same -I flags as used during the Emacs build,
>> > see src/Makefile.
>>
>> Thanks for the suggestion. I tried it and it didn't work.
>
> Sorry, I'm confused: what did you try, and how did it not work?
I did (setq c-macro-prompt-flag t), marked HAVE_PWD_H with a region,
called `c-macro-expand', entered that huge "-I" expression that I got from
make. Got this:
c-macro-expansion: Search failed: "
??? !!! ??? start of c-macro expansion ??? !!! ???"
Oleh
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: CC Mode and GCC/CEDET integration for evaluating macros
2015-05-01 19:42 ` Oleh Krehel
@ 2015-05-02 8:27 ` Eli Zaretskii
2015-05-02 9:07 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2015-05-02 8:27 UTC (permalink / raw
To: Oleh Krehel; +Cc: acm, emacs-devel
> From: Oleh Krehel <ohwoeowho@gmail.com>
> Cc: acm@muc.de, emacs-devel@gnu.org
> Date: Fri, 01 May 2015 21:42:27 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Oleh Krehel <ohwoeowho@gmail.com>
> >> Cc: acm@muc.de, emacs-devel@gnu.org
> >> Date: Fri, 01 May 2015 20:52:46 +0200
> >>
> >> > You need to pass it the same -I flags as used during the Emacs build,
> >> > see src/Makefile.
> >>
> >> Thanks for the suggestion. I tried it and it didn't work.
> >
> > Sorry, I'm confused: what did you try, and how did it not work?
>
> I did (setq c-macro-prompt-flag t), marked HAVE_PWD_H with a region,
> called `c-macro-expand', entered that huge "-I" expression that I got from
> make. Got this:
>
> c-macro-expansion: Search failed: "
> ??? !!! ??? start of c-macro expansion ??? !!! ???"
This generally means that cpp exited with some error, I think. (yes,
the error message could be improved.) I suggest to step with a
debugger through the relevant functions in cmacexp.el, it's possible
there's a bug there.
More to the point: I don't know what you mean, exactly, by "marked
HAVE_PWD_H with a region". For a C preprocessor to produce something
reasonable, the region you mark should be valid C, so you should at
least include everything to and including the matching #endif in the
region. If I do that, the command works for me, and produces a region
with the contents of <pwd.h> header, which means HAVE_PWD_H is defined
in my configuration.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: CC Mode and GCC/CEDET integration for evaluating macros
2015-05-01 18:11 ` Alan Mackenzie
2015-05-01 18:23 ` Oleh Krehel
@ 2015-05-02 8:57 ` martin rudalics
2015-05-02 12:00 ` Oleh Krehel
1 sibling, 1 reply; 12+ messages in thread
From: martin rudalics @ 2015-05-02 8:57 UTC (permalink / raw
To: Alan Mackenzie, Oleh Krehel; +Cc: emacs-devel
> There is hide-ifdef-mode in Emacs which does something similar - It makes
> the "non-active" bits of #ifdef branches invisible rather than changing
> their appearance. Doubtless it would be easy enough to add the "greying
> out" facility as an option.
See `hide-ifdef-shadow'.
martin
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: CC Mode and GCC/CEDET integration for evaluating macros
2015-05-02 8:27 ` Eli Zaretskii
@ 2015-05-02 9:07 ` Eli Zaretskii
0 siblings, 0 replies; 12+ messages in thread
From: Eli Zaretskii @ 2015-05-02 9:07 UTC (permalink / raw
To: ohwoeowho; +Cc: acm, emacs-devel
> Date: Sat, 02 May 2015 11:27:22 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: acm@muc.de, emacs-devel@gnu.org
>
> > c-macro-expansion: Search failed: "
> > ??? !!! ??? start of c-macro expansion ??? !!! ???"
>
> This generally means that cpp exited with some error, I think. (yes,
> the error message could be improved.) I suggest to step with a
> debugger through the relevant functions in cmacexp.el, it's possible
> there's a bug there.
In fact, there was indeed a bug in the code that handled abnormal exit
status of the preprocessor: it would bail out early without showing
the error messages emitted by the preprocessor, which are an important
clue as to what went wrong. For example, if you don't pass any
options to the preprocessor, it fails with this error message:
<stdin>:21:20: fatal error: config.h: No such file or directory
compilation terminated.
which clearly suggests that you need to pass at least the -I. switch.
I fixed this.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: CC Mode and GCC/CEDET integration for evaluating macros
2015-05-02 8:57 ` martin rudalics
@ 2015-05-02 12:00 ` Oleh Krehel
2015-05-03 16:45 ` martin rudalics
0 siblings, 1 reply; 12+ messages in thread
From: Oleh Krehel @ 2015-05-02 12:00 UTC (permalink / raw
To: martin rudalics; +Cc: Alan Mackenzie, emacs-devel
martin rudalics <rudalics@gmx.at> writes:
>> There is hide-ifdef-mode in Emacs which does something similar - It makes
>> the "non-active" bits of #ifdef branches invisible rather than changing
>> their appearance. Doubtless it would be easy enough to add the "greying
>> out" facility as an option.
>
> See `hide-ifdef-shadow'.
Thanks, it looks perfect. But it fails for this simple case (zero
includes, just from the top):
#define IN 1
#ifdef IN
double foo;
#endif
Here, "double foo;" gets the shadow. I called `hide-ifdefs'.
Oleh
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: CC Mode and GCC/CEDET integration for evaluating macros
2015-05-02 12:00 ` Oleh Krehel
@ 2015-05-03 16:45 ` martin rudalics
0 siblings, 0 replies; 12+ messages in thread
From: martin rudalics @ 2015-05-03 16:45 UTC (permalink / raw
To: Oleh Krehel; +Cc: Alan Mackenzie, emacs-devel
> But it fails for this simple case (zero
> includes, just from the top):
>
> #define IN 1
> #ifdef IN
> double foo;
> #endif
>
> Here, "double foo;" gets the shadow. I called `hide-ifdefs'.
Funny. It doesn't get shadowed here.
But I've never got around to make `hide-ifdef-mode' work reasonably with
the Emacs code base. I suppose that I'd have to set up some definitions
manually, then scan config.h and then scan the remaining header files in
the order they were processed by the compiler. So if you could come up
with a solution, this would be very much appreciated here.
BTW, `hide-ifdef-mode' fails on my current config.h file with the trace
below.
martin
Debugger entered--Lisp error: (error "Bad token in parenthesized expression: L")
signal(error ("Bad token in parenthesized expression: L"))
error("Bad token in parenthesized expression: %s" L)
hif-factor()
hif-muldiv-expr()
hif-math()
hif-logshift-expr()
hif-comp-expr()
hif-eq-expr()
hif-logand-expr()
hif-logxor-expr()
hif-logior-expr()
hif-and-expr()
hif-or-expr()
hif-expr()
hif-expr()
hif-exprlist()
hif-factor()
hif-muldiv-expr()
hif-math()
hif-logshift-expr()
hif-comp-expr()
hif-eq-expr()
hif-logand-expr()
hif-logxor-expr()
hif-logior-expr()
hif-and-expr()
hif-or-expr()
hif-expr()
hif-exprlist()
hif-factor()
hif-muldiv-expr()
hif-math()
hif-logshift-expr()
hif-comp-expr()
hif-eq-expr()
hif-logand-expr()
hif-logxor-expr()
hif-logior-expr()
hif-and-expr()
hif-or-expr()
hif-expr()
hif-exprlist()
hif-parse-exp((hif-lparen hif-lparen __GNUC__ hif-conditional hif-defined __GNUC_STDC_INLINE__ hif-and __GNUC_STDC_INLINE__ hif-colon hif-lparen 199901 L hif-less-equal __STDC_VERSION__ hif-and hif-not hif-defined __HP_cc hif-and hif-not hif-lparen hif-defined __SUNPRO_C hif-and __STDC__ hif-rparen hif-rparen hif-rparen hif-and hif-not hif-defined _GL_EXTERN_INLINE_STDHEADER_BUG hif-rparen))
hif-canonicalize("\\(^\\|
\\)[ ]*#[ ]*if\\(n?def\\)?[ ]+")
hif-possibly-hide(nil)
hide-ifdef-guts()
hif-recurse-on(1099 58650)
hif-possibly-hide(t)
hide-ifdef-guts()
hide-ifdefs()
hide-ifdef-mode(toggle)
funcall-interactively(hide-ifdef-mode toggle)
call-interactively(hide-ifdef-mode record nil)
command-execute(hide-ifdef-mode record)
execute-extended-command(nil "hide-ifdef-mode" "hide-ifdef-mode")
funcall-interactively(execute-extended-command nil "hide-ifdef-mode" "hide-ifdef-mode")
call-interactively(execute-extended-command nil nil)
command-execute(execute-extended-command)
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2015-05-03 16:45 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-05-01 17:03 CC Mode and GCC/CEDET integration for evaluating macros Oleh Krehel
2015-05-01 18:11 ` Alan Mackenzie
2015-05-01 18:23 ` Oleh Krehel
2015-05-01 18:46 ` Eli Zaretskii
2015-05-01 18:52 ` Oleh Krehel
2015-05-01 19:30 ` Eli Zaretskii
2015-05-01 19:42 ` Oleh Krehel
2015-05-02 8:27 ` Eli Zaretskii
2015-05-02 9:07 ` Eli Zaretskii
2015-05-02 8:57 ` martin rudalics
2015-05-02 12:00 ` Oleh Krehel
2015-05-03 16:45 ` martin rudalics
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.