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