I checked in a fix for this problem.
Header_guard was inheriting the :c environment, so I added the :c
parameter to that template.
Eric
On 03/27/2013 03:59 AM, Bukuli Norbert wrote:
> I have found another issue which slightly connect to this one.
>
> (srecode-insert "file:empty")
> works perfetly, as I wrote it in my previous letter, however
>
> (srecode-insert "file:header_guard")
> throws a warning message:
> Warning: macro "FILENAME_SYMBOL" was not found in the dictionary.
> And creates the following in the header file:
> #ifndef
> #define 1
>
>
> #endif //
>
> Can anybody confirm this behaviour?
> Thank you in advance!
>
>
>
> 2013/3/27 Bukuli Norbert <bukuli.norbert@...
> <mailto:bukuli.norbert@...>>
>
> Hello Eric,
>
> it works perfectly!
> Thank you!
>
>
> 2013/3/27 Eric M. Ludlam <eric@...
> <mailto:eric@...>>
>
> Hi Bukuli,
>
> I was able to reproduce the problem.
>
> When I examined what was going on, I discovered this when I ran
> srecode-get-maps:
>
> -- SRecode Global map --
> Mode Filename
> ------ ------------------
> c++-mode
> /home/zappo/cedet/trunk/etc/__srecode/cpp.srt
> c-mode /home/zappo/cedet/trunk/etc/__srecode/c.srt
> default
> /usr/share/emacs/23.3/etc/__srecode/default.srt
> c++-mode /usr/share/emacs/23.3/etc/__srecode/cpp.srt
>
> 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:
>
> ("/home/zappo/cedet/trunk/etc/__srecode"
> "/usr/share/emacs/23.3/etc/__srecode" "/home/zappo/.srecode/")
>
> I updated this load script and checked it in so if you get a new
> version from bzr, this should be fixed.
>
> Good Luck
> Eric
>
>
> On 03/26/2013 08:21 AM, Bukuli Norbert wrote:
>
> Hello!
>
> 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 ---
> ... */
> #ifndef 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
> the same
> thing, I get this:
> /** my_header.hpp ---
> ... */
> #ifndef MY_HEADER_H
> #define MY_HEADER_H 1
>
>
> #endif // MY_HEADER_H
>
> Is this the desired behaviour? I use cedet from bzr, with
> emacs 24.2.1
>
> Thank You!
>
>
>
>
> 2013/1/18 Eric M. Ludlam <eric@...
> <mailto:eric@...>
> <mailto:eric@... <mailto:eric@...>>__>
>
>
> On 01/15/2013 01:41 PM, Lluís wrote:
>
> Eric M Ludlam writes:
>
> Hi Lluis,
>
>
> I agree with the typical use being all
> uppercase for for C
> code macros, such as:
>
>
> #ifdef MYHEADER_H
> #define MYHEADER_H 1
> ...
>
>
> #endif
>
>
> I wonder if it is instead better to tweak the
> template to
> upcase on a
> per-usecase basis (see patch), or always for
> that symbol.
>
>
> I'm curious what other C / C++ developers
> think. Is a
> same-case symbol of the
> filename useful?
>
>
> 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
> generation).
>
>
> 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
> curious how
> would you
> implement the following header guard pattern (which
> I use very
> often):
>
> * take the file path relative to the project root
> * eliminate uninformative prefix directories (e.g.,
> "src/" or
> "include/")
>
>
> 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
> current file.
>
>
> * replace the directory separator with "__"
> * replace symbols by "_"
>
>
> Your new code snippet would do some of that.
>
> * upcase
>
>
> 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
> new argument
> 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.
>
> Eric
>
>
> ------------------------------__------------------------------__------------------
> 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
> LearnDevNow -
> 350+ hours of step-by-step video tutorials by Microsoft
> MVPs and
> experts.
> SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore___122812
> <http://p.sf.net/sfu/learnmore_122812>
> _________________________________________________
> Cedet-devel mailing list
> Cedet-devel@...
> <mailto:Cedet-devel@...>
> <mailto:Cedet-devel@...
> <mailto:Cedet-devel@...>>
>
> https://lists.sourceforge.net/__lists/listinfo/cedet-devel
> <https://lists.sourceforge.net/lists/listinfo/cedet-devel>
>
>
>
>
> --
> Best regards,
> Norbert Bukuli
>
>
>
>
> --
> Üdvözlettel:
> Bukuli Norbert
>
>
>
>
> --
> Üdvözlettel:
> Bukuli Norbert
|