I checked in a fix for this problem.
Header_guard was inheriting the :c environment, so I added the :c parameter to that template.
On 03/27/2013 03:59 AM, Bukuli Norbert wrote:
I have found another issue which slightly connect to this one.<mailto:email@example.com>>
works perfetly, as I wrote it in my previous letter, however
throws a warning message:
Warning: macro "FILENAME_SYMBOL" was not found in the dictionary.
And creates the following in the header file:
Can anybody confirm this behaviour?
Thank you in advance!
2013/3/27 Bukuli Norbert <firstname.lastname@example.org<mailto:email@example.com>>
it works perfectly!
2013/3/27 Eric M. Ludlam <firstname.lastname@example.org/home/zappo/cedet/trunk/etc/__srecode/cpp.srt
I was able to reproduce the problem.
When I examined what was going on, I discovered this when I ran
-- SRecode Global map --
which means that templates recently removed from cpp.srt and
moved to c.srt is getting ignored due to the version of cpp.srt
that comes with Emacs, giving you this unexpected duality.
My load path for srecode looks like this:
"/usr/share/emacs/23.3/etc/__srecode" "/home/zappo/.srecode/")<mailto:email@example.com <mailto:firstname.lastname@example.org>>__>
I updated this load script and checked it in so if you get a new
version from bzr, this should be fixed.
On 03/26/2013 08:21 AM, Bukuli Norbert wrote:
What is the concept, shall this style of header guards work
both with C
and C++ mode?
If I visit a new file, my_header.hpp (in this case c++-mode
is active in
the buffer), and insert file:empty with SRecorder, then I
get the following:
/** my_header.hpp ---
#define my_header_hpp 1
#endif // my_header_hpp
However if I open a new file my_header.h (c-mode), and do
thing, I get this:
/** my_header.hpp ---
#define MY_HEADER_H 1
#endif // MY_HEADER_H
Is this the desired behaviour? I use cedet from bzr, with
2013/1/18 Eric M. Ludlam <email@example.com
On 01/15/2013 01:41 PM, Lluís wrote:
Eric M Ludlam writes:
I agree with the typical use being all
uppercase for for C
code macros, such as:
#define MYHEADER_H 1
I wonder if it is instead better to tweak the
upcase on a
per-usecase basis (see patch), or always for
I'm curious what other C / C++ developers
think. Is a
same-case symbol of the
I've never got to need it, but you never know; so
I'd go for
your patch (note
that my patch also contains a fix on the symbol
Ok, I'll check in a mix of the two then after running
the unit tests.
BTW, I don't really use srecode very much, but I'm
implement the following header guard pattern (which
I use very
* take the file path relative to the project root
* eliminate uninformative prefix directories (e.g.,
I'd go into srecode/cpp.el and add a new dictionary
entry for the :c
argument, perhaps PROJECT_FILENAME_SYMBOL, and
calculate it. EDE
can tell you the file name with file-relative-name against
(ede-toplevel-project default-directory) and the
* replace the directory separator with "__"
* replace symbols by "_"
Your new code snippet would do some of that.
Probably in the use of the new dictionary entry.
So, for example, "foo/bar.h" would be "FOO__BAR_H".
This concept seems useful. The attached patch adds a
called :project that could be used to add a variable
similar to what
you asked for.
I tried it out, and it seems to work ok.
Master HTML5, CSS3, ASP.NET <http://ASP.NET>
<http://ASP.NET>, MVC, AJAX,
Knockout.js, Web API and
much more. Get web development skills now with
350+ hours of step-by-step video tutorials by Microsoft
SALE $99.99 this month only -- learn more at:
Cedet-devel mailing list