Opened 9 years ago

# [Patch] Add support for tags in source file

Reported by: Owned by: anton.deguet@… Chris Heller normal IncludeSourcePartialPlugin normal 0.11

### Description

Instead of using line number to extract the snippet of code, it would be nice to use some special tags to identify the starting and end lines of the code to be inserted. For example one could do:

  unsigned int var;
// @TracWikiIncludeSourcePartialBegin(example1)
for (var = 0; var != 10; var++)
someFuntion(var)
}
// @TracWikiIncludeSourcePartialEnd(example1)


Then in the wiki page, one would use:

  [[IncludeSource(trunk/proj/file.cpp, snippet=example1, rev=1200)]]


This way, the code snippet could be moved within the file or grow but the wiki would still insert the right code.

### comment:1 Changed 9 years ago by Chris Heller

Status: new → assigned

Your example is good because it keeps the IncludeSource macro syntax straightforward, but having a specific syntax inside the source code being included doesn't seem like a good thing to require.

Maybe instead of requiring a special syntax within the source code, the start and end could be defined as regular expressions. I wouldn't want the macro syntax itself to get too complex though.

### comment:2 Changed 9 years ago by Jeff Hammel

I dislike adding tags to source files just for 3rd-party documentation purposes, if avoidable. A better (though harder) solution would be to allow language dependent includes. E.g. for python to include the FooBar class:

[[IncludeSource(trunk/proj/file.cpp,class=FooBar)]]


### comment:3 Changed 9 years ago by anonymous

I second the regular expression. That would still support the example syntax it would also support more complex things, for example a specific class, or function, or even a family of functions (say, all the custom exceptions in a file)

That said, I also know regular expressions are becoming a lost art form, so we might need quite a few examples, or add in some "shortcuts" for typical cases.

Such as support RE plus the @IPSExample1, class CLASSNAME def METHODNAME etc.

I would suggest the additional support be plugins to the plugin :d So native support Regular expressions, or pass to plugin chain (either explicit plugin, or by file extension?)

the nice thing about that is, one could do double duty with code markup with a tool such as doxygen and this, assuming a plugin2 (plugin to a plugin) was created :) if you liked code doc tools, if not, you could still link to specific lines, or an RE

So I think I proposed a trinary behavior: current, regular expression, or pass to plugin2 I know, it's more work. but I like to use the wiki for code reviews, and this just makes it better!

btw, thanks for the great plugin

### comment:4 Changed 9 years ago by tekknokrat

Also second support for regex. We are monitoring configuration files in trac environment and this way I can get rid of the bunch of comments typically in a default configuration file.

Just wondering how to match a specific section in a typical trac.ini with regex. Is something like this possible?

[[IncludeSource(trunk/proj/file.cpp,/^$IniSection$,^$.*$],regex=true)]]


This should define a start and an end line matched via regex. The last param is for compatibility reasons for the numbering.

Last edited 12 months ago by Ryan J Ollos (previous) (diff)

### comment:5 Changed 8 years ago by anonymous

example for attached patch:

[[IncludeSource(trunk/proj/file.cpp, start="function callMe", end="; // end function")]]

Last edited 19 months ago by Ryan J Ollos (previous) (diff)

### Changed 8 years ago by anonymous

Keeping it simple is a good idea. Please find attached a diff that allows to use plain text in start/end and searches for the first occurence of the start text in the source and the first occurence of end in a line below start to get line numbers. Though this is not a regex, it still allows to be used with any source code language.

### comment:6 Changed 8 years ago by anonymous

Summary: Add support for tags in source file → [Patch] Add support for tags in source file

### comment:7 Changed 19 months ago by Massimo

Some years later, are there any plans to integrate that into the plugin? However I would prefer the RegEx approach for being able to adapt to old code without adding magic comments.

It is often interesting to include the usage() part of code into wiki pages in order to keep it up to date.

Last edited 19 months ago by Ryan J Ollos (previous) (diff)

### comment:8 Changed 19 months ago by Ryan J Ollos

Last edited 19 months ago by Ryan J Ollos (previous) (diff)