Thread: [Codestriker-user] Syntax highlight (patch included)
Brought to you by:
sits
Menu
▾
▴
codestriker-user
|
From: Nikita B. <el...@gm...> - 2007-06-22 16:57:44
Attachments:
codestriker-1.9.3_hl.diff
|
Hello, all! Syntax highlight is probably the most needed feature of Codestriker as it helps code readability dramatically. Here is my implementation of syntax highlight using Syntax::Hightligh::Engine::Kate engine (thanks to Kannan Goundan for pointing to it). I've used to redesign Codestriker::Http::Render.pm internal workflow a little but in my day-to-day work It works just like before. The only thing I haven't check in real life is LXR linking but I'm quite sure it works too. Codestriker is great thing to help collaborative work, great thanks to all the team! -- Nikita V. Borodikhin, System Administrator NIKB-RIPN BNV7-RIPE Registered Linux user #256562 with the Linux Counter |
|
From: David S. <si...@us...> - 2007-06-24 22:58:40
|
Hi Nikita, > Syntax highlight is probably the most needed feature of Codestriker as > it helps code readability dramatically. Here is my implementation of > syntax highlight using Syntax::Hightligh::Engine::Kate engine (thanks > to Kannan Goundan for pointing to it). Many thanks for your submission. I actually tried using Syntax::Hightlight::Engine::Kate when it first came out, and found it to be very slow. It would take something like 30 seconds to parse a small java file, so I decided against using it. What is the performance of it like now? Hopefully it has been fixed. > I've used to redesign Codestriker::Http::Render.pm internal workflow a > little but in my day-to-day work It works just like before. The only > thing I haven't check in real life is LXR linking but I'm quite sure > it works too. Please check it out LXR linking if you can - it will save me the trouble. Also, once you have finish it, please submit your patch into the patches list: http://sourceforge.net/tracker/?group_id=41136&atid=429862. Many thanks for your contribution! I'll give it a try later on - it would be great to have the code highlighted. Cheers, David |
|
From: Nikita B. <el...@gm...> - 2007-06-25 11:28:51
|
Hello, David. On 6/25/07, David Sitsky <si...@us...> wrote: > Many thanks for your submission. I actually tried using > Syntax::Hightlight::Engine::Kate when it first came out, and found it > to be very slow. It would take something like 30 seconds to parse a > small java file, so I decided against using it. What is the > performance of it like now? Hopefully it has been fixed. If Kate engine is used to highlight text line-by-line as in my code, it process SQLite 3.3.17 amalgamation (2.1Mb, 41218 SLOCs reported by sloccount) in about 5 minutes. I think this speed is acceptable because: 1. Codestriker can't handle such a big files reliable (it creates Subversion topic that consists of the same amalgamation more than about 5 minutes) 2. I believe that reviewing such files isn't the common practice. However if highlighting of our code would be too slow I'll consider to make alternative highlighting using webc++ external highlighter. > > I've used to redesign Codestriker::Http::Render.pm internal workflow a > > little but in my day-to-day work It works just like before. The only > > thing I haven't check in real life is LXR linking but I'm quite sure > > it works too. > > Please check it out LXR linking if you can - it will save me the > trouble. Also, once you have finish it, please submit your patch into > the patches list: > http://sourceforge.net/tracker/?group_id=41136&atid=429862. Hm... I've never touched LXR and don't think I'll have a time to until autumn, sorry. But a quick test to check which identifiers are passed to lxr_ident shows the same set for our projects except: 1. identifiers that start with underscore (I've added that to LXR code as this is common for local C variables) 2. some tab issues related to /^(\s| ){0,10}\*/ regexp (this is bacause of tab expansion now happens _after_ identifier search) 3. some spaces, as I've used to remove $token =~ s/(\s| )//g; code from identifier search code to leave positions untouched. > Many thanks for your contribution! I'll give it a try later on - it > would be great to have the code highlighted. Patch posted to maillist was broken a little (it was not the final version), sorry. Fixed patch uploaded: http://sourceforge.net/tracker/index.php?func=detail&aid=1742781&group_id=41136&atid=429862 -- Nikita V. Borodikhin, System Administrator NIKB-RIPN BNV7-RIPE Registered Linux user #256562 with the Linux Counter |
|
From: David S. <dav...@gm...> - 2007-06-25 11:32:26
|
> If Kate engine is used to highlight text line-by-line as in my code, > it process SQLite 3.3.17 amalgamation (2.1Mb, 41218 SLOCs reported by > sloccount) in about 5 minutes. > I think this speed is acceptable because: > 1. Codestriker can't handle such a big files reliable (it creates > Subversion topic that consists of the same amalgamation more than > about 5 minutes) > 2. I believe that reviewing such files isn't the common practice. > > However if highlighting of our code would be too slow I'll consider to > make alternative highlighting using webc++ external highlighter. Can you do a comparison between Kate and webc++ on something a little smaller? Say something with roughly 1000 SLOCs. I'd be curious to see what the difference is. If it is huge, perhaps going the webc++ or enscript route might be better. Cheers, David |
|
From: Nikita B. <el...@gm...> - 2007-06-25 13:17:47
|
On 6/25/07, David Sitsky <dav...@gm...> wrote: > Can you do a comparison between Kate and webc++ on something a little > smaller? Say something with roughly 1000 SLOCs. I'd be curious to > see what the difference is. File src/sqliteInt.h from sqlite-3.3.17 distribution (86K, 1075 SLOCs). Kate engine used standalone (not within Codestriker): 9.6 sec real time Web C Plus Plus 0.8.2 (pipe mode): 2.0 real time It seems the speed difference is nonlinear function of size because sqlite3 amalgamation was processed by webc++ at 16 seconds (>300 Kate's seconds). > If it is huge, perhaps going the webc++ or enscript route might be better. I can't decide if more speed is really needed for my tasks. Quicker is better but Kate's speed is enough for now. I don't think Enscipt is the good for Codestriker because Enscript uses visual formatting (b, i, font color="xxx" tags) instead of semantic (span class="comment"). Codestriker should parse highlighted data as it should place LXR links but enscripted data is harder to parse than webcpp'ed. Speed of enscripting is roughly the same as speed of webc++'ing. -- Nikita V. Borodikhin, System Administrator NIKB-RIPN BNV7-RIPE Registered Linux user #256562 with the Linux Counter |
|
From: David S. <dav...@gm...> - 2007-06-25 23:34:02
|
Hi Nikita, > It seems the speed difference is nonlinear function of size because > sqlite3 amalgamation was processed by webc++ at 16 seconds (>300 > Kate's seconds). Wa.... this was my memory with Kate. In my opinion, this doesn't really make it very practical for the types of reviews I do. > I don't think Enscipt is the good for Codestriker because Enscript > uses visual formatting (b, i, font color="xxx" tags) instead of > semantic (span class="comment"). Codestriker should parse highlighted Agreed. Cheers, David |
|
From: Nikita B. <el...@gm...> - 2007-06-25 16:52:19
|
Hello, David! On 6/25/07, David Sitsky <dav...@gm...> wrote: > Can you do a comparison between Kate and webc++ on something a little > smaller? Say something with roughly 1000 SLOCs. I'd be curious to > see what the difference is. I have an idea about using external program to do syntax highlight. Probably we should not stuck to only one (webcpp or other) but provide generic layer for use external highlighters. I think, we could use any one that: * builds css-formatted code by using <span class="style"> and closes tags correctly; * don't add any symbols other than escaped standard one (lt, gt, amp); * can behave as line filter (get text from stdin and output it to stdout). To add such highlighter support we need is to provide its description: * program name and command line template; * correspondence between file externsions and program's language names; * description of header we should strip out from highlighter output; * correspondence between program's styles and our styles. In my Debian there are some tools that meet these requirements: * highlight: http://www.andre-simon.de/doku/highlight/en/highlight.html * GNU source-hightlight: http://www.gnu.org/software/src-highlite/source-highlight.html * Web C Plus Plus: http://webcpp.sourceforge.net To allow usage of pure Perl highlighter (Kate engine) it seems to be a good idea to name styles after its standard ones. -- Nikita V. Borodikhin, System Administrator NIKB-RIPN BNV7-RIPE Registered Linux user #256562 with the Linux Counter |
|
From: David S. <dav...@gm...> - 2007-06-25 23:35:22
|
Hi Nikita, > Probably we should not stuck to only one (webcpp or other) but provide > generic layer for use external highlighters. I think, we could use any > one that: > * builds css-formatted code by using <span class="style"> and closes > tags correctly; > * don't add any symbols other than escaped standard one (lt, gt, amp); > * can behave as line filter (get text from stdin and output it to stdout). Sounds like an excellent idea. > To add such highlighter support we need is to provide its description: > * program name and command line template; > * correspondence between file externsions and program's language names; > * description of header we should strip out from highlighter output; > * correspondence between program's styles and our styles. > > In my Debian there are some tools that meet these requirements: > * highlight: http://www.andre-simon.de/doku/highlight/en/highlight.html > * GNU source-hightlight: > http://www.gnu.org/software/src-highlite/source-highlight.html > * Web C Plus Plus: http://webcpp.sourceforge.net > > To allow usage of pure Perl highlighter (Kate engine) it seems to be a > good idea to name styles after its standard ones. Agreed! Thanks for looking into this, you'll make a lot of people happy! Cheers, David |
Thanks for helping keep SourceForge clean.
X