Thread: [CEDET-devel] [PATCH] srt: Upcase and (re)normalize FILENAME_SYMBOL
Brought to you by:
zappo
From: Lluís <xs...@gm...> - 2013-01-11 18:48:44
Attachments:
filename-symbol.patch
|
When producing the value for 'FILENAME_SYMBOL', replaces all characters in [^a-zA-Z0-9_] with '_'. It also upcases the value, as that is the common approach when used as a header guard. |
From: Eric M. L. <er...@si...> - 2013-01-15 02:31:06
Attachments:
c.srt.diff
|
On 01/11/2013 01:48 PM, Lluís wrote: > When producing the value for 'FILENAME_SYMBOL', replaces all characters in > [^a-zA-Z0-9_] with '_'. > > It also upcases the value, as that is the common approach when used as a header > guard. 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? Eric |
From: Lluís <xs...@gm...> - 2013-01-15 18:41:24
|
Eric M Ludlam writes: > On 01/11/2013 01:48 PM, Lluís wrote: >> When producing the value for 'FILENAME_SYMBOL', replaces all characters in >> [^a-zA-Z0-9_] with '_'. >> >> It also upcases the value, as that is the common approach when used as a header >> guard. > 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). 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/") * replace the directory separator with "__" * replace symbols by "_" * upcase So, for example, "foo/bar.h" would be "FOO__BAR_H". Thanks, Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth |
From: Eric M. L. <er...@si...> - 2013-01-18 02:54:41
Attachments:
srecode.args.el.patch
|
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 |
From: Bukuli N. <buk...@gm...> - 2013-03-26 12:21:48
|
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 <er...@si...> > 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, 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 > _______________________________________________ > Cedet-devel mailing list > Ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-devel > > -- Best regards, Norbert Bukuli |
From: Eric M. L. <er...@si...> - 2013-03-27 01:06:26
|
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 <er...@si... > <mailto:er...@si...>> > > 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>, 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 > _______________________________________________ > Cedet-devel mailing list > Ced...@li... > <mailto:Ced...@li...> > https://lists.sourceforge.net/lists/listinfo/cedet-devel > > > > > -- > Best regards, > Norbert Bukuli |
From: Bukuli N. <buk...@gm...> - 2013-03-27 07:13:53
|
Hello Eric, it works perfectly! Thank you! 2013/3/27 Eric M. Ludlam <er...@si...> > 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 <er...@si... >> <mailto:er...@si...>**> >> >> >> 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>, 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 >> Ced...@li...urceforge.**net<Ced...@li...> >> <mailto:Cedet-devel@lists.**sourceforge.net<Ced...@li...> >> > >> >> https://lists.sourceforge.net/**lists/listinfo/cedet-devel<https://lists.sourceforge.net/lists/listinfo/cedet-devel> >> >> >> >> >> -- >> Best regards, >> Norbert Bukuli >> > -- Üdvözlettel: Bukuli Norbert |
From: Bukuli N. <buk...@gm...> - 2013-03-27 07:59:14
|
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 <buk...@gm...> > Hello Eric, > > it works perfectly! > Thank you! > > > 2013/3/27 Eric M. Ludlam <er...@si...> > > 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 <er...@si... >>> <mailto:er...@si...>**> >>> >>> >>> 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>, 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 >>> Ced...@li...urceforge.**net<Ced...@li...> >>> <mailto:Cedet-devel@lists.**sourceforge.net<Ced...@li...> >>> > >>> >>> 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 |
From: Eric M. L. <er...@si...> - 2013-03-27 11:45:47
|
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 <buk...@gm... > <mailto:buk...@gm...>> > > Hello Eric, > > it works perfectly! > Thank you! > > > 2013/3/27 Eric M. Ludlam <er...@si... > <mailto:er...@si...>> > > 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 <er...@si... > <mailto:er...@si...> > <mailto:er...@si... <mailto:er...@si...>>__> > > > 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 > Ced...@li...urceforge.__net > <mailto:Ced...@li...> > <mailto:Cedet-devel@lists.__sourceforge.net > <mailto:Ced...@li...>> > > 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 |
From: Bukuli N. <buk...@gm...> - 2013-03-27 12:15:39
|
Perfect. Thank you! 2013/3/27 Eric M. Ludlam <er...@si...> > 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 <buk...@gm... >> <mailto:bukuli.norbert@gmail.**com <buk...@gm...>>> >> >> >> Hello Eric, >> >> it works perfectly! >> Thank you! >> >> >> 2013/3/27 Eric M. Ludlam <er...@si... >> <mailto:er...@si...>**> >> >> >> 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 <er...@si... >> <mailto:er...@si...> >> <mailto:er...@si... <mailto:er...@si...>* >> *>__> >> >> >> >> 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> >> <http://p.sf.net/sfu/**learnmore_122812<http://p.sf.net/sfu/learnmore_122812> >> > >> ______________________________**___________________ >> Cedet-devel mailing list >> Ced...@li...urceforge.**__net >> <mailto:Cedet-devel@lists.**sourceforge.net<Ced...@li...> >> > >> <mailto:Cedet-devel@lists.__so**urceforge.net<http://sourceforge.net> >> <mailto:Cedet-devel@lists.**sourceforge.net<Ced...@li...> >> >> >> >> https://lists.sourceforge.net/**__lists/listinfo/cedet-devel<https://lists.sourceforge.net/__lists/listinfo/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 >> > -- Üdvözlettel: Bukuli Norbert |