support for "files/foo.txt" markup

[Randy]

I'm having trouble with "files/..." functionality.
1. Using "New Item" and naming it "files/foo"
creates "files_foo.txt" in the wiki, not under "files/...".
2. If I manually create "files/bar.txt" with markup and
link to it from another page, then files/bar.txt is
rendered as raw text (markup is ignored).
3. From the documentation, its unclear if links
within "files/test/foobar.txt" are relative to the
"wiki" or "files/test/".

I've tried numerous variations, such as
"wiki/files/foo", "wiki/files/foo.txt", "foo", etc.
I've tried manually inserting a metadata block at the top, ...

What I *really* like about WikklyText is that
it may allow me to edit pages with Vim (when
using the text store), where the links and pages
use names that I can following with Vim functionality,
i.e. "gf" (goto file under cursor). That, along with
Vim syntax highlights provide a useful approximation
to the Wiki experience, which helps when developing
content, especially when used with ctags to magically
link with C and Fortran source code.

-RLS

[Frank McIngvale]

On Sat, Sep 26, 2009 at 8:12 AM, Randy <Randy...@data-warp.com> wrote:

I'm having trouble with "files/..." functionality.
1. Using "New Item" and naming it "files/foo"
   creates "files_foo.txt" in the wiki, not under "files/...".
2. If I manually create "files/bar.txt" with markup and
   link to it from another page, then files/bar.txt is
   rendered as raw text (markup is ignored).
3. From the documentation, its unclear if links
   within "files/test/foobar.txt" are relative to the
   "wiki" or "files/test/".

Hi, I think this may be a two part question. First, the files/ area is meant strictly as a fileserving location. A convenient place to put images, file downloads, etc. All files are simply served as-is, they are not sent through the rendering engine at all. So if you create a file "files/foo/bar.txt" you would serve it via markup like this:  Download file [[here|files/foo/bar.txt]]. There is no support (at least yet) for creating "files/" content from within the wiki. Probably would be good to add a way to upload things directly there (added to my TODO).

If you are using textfiles to store your wiki content, all those .txt files live in the root directory of your wiki. WikklyText (like TiddlyWiki) has a flat namespace so there's no concept of folders as such. So you can name an item "/a/b/c" if you want to, but it will still live in the root directory, with a mangled name like "_a_b_c".
 
I'm not sure if that answers your issue -- I'm not a vim user so I'm not entirely clear on your usage case. If you could show me an example of what you're trying to accomplish it might make it clearer for me.

thanks,
frank

[Randy]

Thanks, that clarifies things a lot.
I'm new to the Wiki world, such as TiddlyWiki etc.
I keep forgetting that a flat namespace is the norm.

Vim is a text editor that is now burned into my brain
and muscle memory. The functionality that it provides
greatly increases my productivity as a programmer
and I'd like to leverage it for documentation.

Use case 1:

General documentation:
If the text contains something like
"blah blah files/foo.txt blah [[bar stuff|files/bar.txt]] blah"
then Vim allows you to position the cursor over any
phrase and open a file (goto) by that name with one keystroke
(or mouse click combination), i.e. Vim can treat essentially
any phrase as a hyper link, without any markup (which
is the simplest markup of all).

Vim can be configured
to do some simple name "mangling" such as ignore
certain leading and trailing characters (such as [, ], |).
Mangling " " (blank) into "_" is problematic for naked links,
i.e. it requires markup to delimit link bounds.
Mangling "/" into "_" is non-intuitive for me at least,
because my mental model is that of a path.
Using directories for a namespace is more intuitive.

Vim also supports "syntax highlight".
Its normally used to highlight source code language elements,
i.e. keywords in one color, strings in another, etc.
Wiki markup can be highlighted using syntax rules,
i.e. ''bold'', //italics//, headings, links, tables, etc.

When used together, "goto" file and markup highlights
provide a useful approximation to the Wiki experience.
This approximation helps when developing content,
i.e. when bouncing between pages to get it right.
While Vim is useful, its not polished enough for
presentation (like a browser), nor web accessible.

Use case 2:

Program documentation:
Wiki pages can be used for high level documentation
of source code (C, Fortran, ...). When used together,
Vim and ctags allow the pages to magically link
to the corresponding source code, i.e. if the page
mentions a macro or function name, one keystroke
will take you directly to its definition via the "ctags".

When editing C and Fortran source code, comments
can reference Wiki pages for general information.
Vim functionality can be used to follow these "links"
and "close the loop", without leaving the Vim world.

Use case 3:

Source code markup:
Within source code comments, Wiki style highlights
can be applied by Vim, i.e. ''bold'', //italics//, tables, etc.
These highlights can be limited to comments,
i.e. they don't mangle language syntax highlights.

Use case 4:

Doxygen-like functionality (new project idea).
Documentation within the source code could be extracted
and integrated with Wiki pages for presentation.
Comments and pages could share much of the same
markup conventions, which reduces the overall learning
curve and brain-cells load.

Back End Frustration:

Vim provides useful leverage, but only if the Wiki backend
is compatible. Wiki pages must be stored in text files,
not data bases.

Page revision implementation is tricky.
Some Wikis implement it with a directory and 1, 2, 3 names,
i.e. foo/1 first version, foo/2 for second.
This scheme makes it difficult to use Vim text links,
i.e. when the foo page is updated from version 1 to 2,
all simple-minded text links to foo/1 are broken.

Source repositories (subversion, etc.) can provide a more
comprehensive solution than simple 1, 2, 3-like schemes.
Repository versions can be integrated for pages and source
code, where as 1, 2, 3 schemes are not easily synchronized.

New project idea:

Glossary scheme.
Leverage the ctags concept for Wikis?

For example, create a ctags-like file for known "anchors"
within a Wiki for all pages. The anchors might be
specified with markup, i.e. the "GoodTimes" page has
<<anchor "GoodTime"|"good times"|"for a good time">>
for a good time call me at xxx.
Any page that contains one of the phrases (without any
additional markup) is a potential link to "GoodTimes".

This glossary-like scheme might reduce overall markup,
because there are inherently more links than anchors.

Hover-like mechanisms might provide a visual clue as
to which phrases in a page have a glossary entry.
Hovers might also provide disambiguation functionality,
i.e. follow the nearest phrase(s) to the "FastFood"
"Mature" or the "SelfHelp" section.

More Vim functionality:
Utl (Universal Text Links):
Since I live in Vim, I use the Utl plugin.
It provides a richer version of "goto file".
For example, "goto" http://foo.com/here will open the
browser and load the web page.

End-of-brain-dump...

I don't know enough about the wiki-web-browser world
to know if these ideas make sense, much less how
to implement them... perhaps somebody else can
follow up.

RLS


On Sep 26, 8:49 am, Frank McIngvale <fmcingv...@gmail.com> wrote:

[Frank McIngvale]

On Sat, Sep 26, 2009 at 11:14 AM, Randy <Randy...@data-warp.com> wrote:

Thanks, that clarifies things a lot.
I'm new to the Wiki world, such as TiddlyWiki etc.
I keep forgetting that a flat namespace is the norm.

My previous answer wasn't quite right, so let me try again -- this will help when discussing items below, I think:

To the wiki itself, "/a/b/foo.blah" is just a name, it doesn't imply anything about how the item is stored. On the backend, the wiki calls 'store("/a/b/foo.blah", item)' and the store itself (in this case wikklytext.store.wikStore_files) mangles the name for flat file storage.

However, there is no reason you couldn't have a directory-based store that would actually place the item into a directory "/a/b". In fact, it should be pretty simple to make such a store by starting with wikStore_files. Or if you just wanted a different name-mangling scheme that was more Vim-friendly you could create wikStore_files_my_version, etc.
 

Use case 1:

General documentation:
If the text contains something like
"blah blah files/foo.txt blah [[bar stuff|files/bar.txt]] blah"
then Vim allows you to position the cursor over any
phrase and open a file (goto) by that name with one keystroke
(or mouse click combination), i.e. Vim can treat essentially
any phrase as a hyper link, without any markup (which
is the simplest markup of all).

So are you talking Vim opening the file directly, or launching a browser to open it? The reason I ask is, as noted above, if you have a wiki item "MyFunctionDocs", you don't know *in general* where that item is physically stored. But in the textfiles case, it would be stored in "MyFunctionDocs.txt" (in the root of you wiki folder) and the link would look like [[mydocs|MyFunctionDocs]]. So the ".txt" doesn't appear in the link (unless you are serving from "files/" but I'm assuming you are talking about wiki items now).

Vim can be configured
to do some simple name "mangling" such as ignore
certain leading and trailing characters (such as [, ], |).
Mangling " " (blank) into "_" is problematic for naked links,
i.e. it requires markup to delimit link bounds.
Mangling "/" into "_" is non-intuitive for me at least,
because my mental model is that of a path.
Using directories for a namespace is more intuitive.

See above -- does that help any?
 

Vim also supports "syntax highlight".
Its normally used to highlight source code language elements,
i.e. keywords in one color, strings in another, etc.
Wiki markup can be highlighted using syntax rules,
i.e. ''bold'', //italics//, headings, links, tables, etc.

When used together, "goto" file and markup highlights
provide a useful approximation to the Wiki experience.
This approximation helps when developing content,
i.e. when bouncing between pages to get it right.
While Vim is useful, its not polished enough for
presentation (like a browser), nor web accessible.

Depending on the answer above, this sounds like just a matter of making Vim realize that [[a link|MyItem]] means to browse to http://whatever/blah/MyItem. Is that right?
 

Use case 2:

When editing C and Fortran source code, comments
can reference Wiki pages for general information.
Vim functionality can be used to follow these "links"
and "close the loop", without leaving the Vim world.

Like above, to me this sounds like just making Vim understand the wiki link syntax?
 

Use case 4:

Doxygen-like functionality (new project idea).
Documentation within the source code could be extracted
and integrated with Wiki pages for presentation.
Comments and pages could share much of the same
markup conventions, which reduces the overall learning
curve and brain-cells load.

I guess I should go ahead and put this out, but I have a plugin that will extract TiddlyWiki/WikklyText style markup from Python source code and render it. Here is an example:

http://boodebr.org/pages/boodebr/boodebr.sql2.html

It doesn't have a lot of nice things like autolinks between modules, etc. but it does the basic job when you don't want to write the same comments in the source AND on a website.

If you look in the mailing list archives, there was another plugin posted that uses pygments to do Python syntax highlighting with wiki items. One of these may be what you are looking for? Or at least give a starting point.

Back End Frustration:

Vim provides useful leverage, but only if the Wiki backend
is compatible.  Wiki pages must be stored in text files,
not data bases.

Page revision implementation is tricky.
Some Wikis implement it with a directory and 1, 2, 3 names,
i.e. foo/1 first version, foo/2 for second.
This scheme makes it difficult to use Vim text links,
i.e. when the foo page is updated from version 1 to 2,
all simple-minded text links to foo/1 are broken.

Like above, you might be able to come up with a more Vim-friendly mangling scheme that does what you want. Right now WikklyText doesn't handle revisions. I'm not sure if it's better to handle this as a new store type, ie. a store that pushes changes to svn/git/etc., or to implement it as middleware between the wiki and the backend.

Glossary scheme.
Leverage the ctags concept for Wikis?

For example, create a ctags-like file for known "anchors"
within a Wiki for all pages.  The anchors might be
specified with markup, i.e. the "GoodTimes" page has
<<anchor "GoodTime"|"good times"|"for a good time">>
for a good time call me at xxx.
Any page that contains one of the phrases (without any
additional markup) is a potential link to "GoodTimes".

This should be possible -- the <<anchor>> macro would need to know what page it was being rendered for, but that's easy to put into the WSGI environment. For the second part you'd need a hook that received the (post-rendered) XML and compare plaintext phrases vs. the "tags" file entries. This is supported at the low-level but not yet through wiki plugins. I'll make a "think about this" note in my TODO on these since I think they would be generally useful.

Utl (Universal Text Links):
Since I live in Vim, I use the Utl plugin.
It provides a richer version of "goto file".
For example, "goto" http://foo.com/here will open the
browser and load the web page.

Does that have hooks where you could make it recognize [[link|Name]] style links? Or if Utl lets you define your own schemes, maybe something like [[link|wiki://Name]] would work? (You could then have an URL resolver on the wiki side that knew that wiki://Name maps to Name.)

Any of that sound helpful? :-)

frank

[Randy]

Yes, your comments are helpful.

Several of the Vim suggestions you made
already exist and work reasonably well.

See below for details...

On Sep 26, 1:18 pm, Frank McIngvale <fmcingv...@gmail.com> wrote:

> On Sat, Sep 26, 2009 at 11:14 AM, Randy <RandyTid...@data-warp.com> wrote:
>
> > Thanks, that clarifies things a lot.
> > I'm new to the Wiki world, such as TiddlyWiki etc.
> > I keep forgetting that a flat namespace is the norm.
>
> My previous answer wasn't quite right, so let me try again -- this will help
> when discussing items below, I think:
>
> To the wiki itself, "/a/b/foo.blah" is just a name, it doesn't imply
> anything about how the item is stored. On the backend, the wiki calls
> 'store("/a/b/foo.blah", item)' and the store itself (in this case
> wikklytext.store.wikStore_files) mangles the name for flat file storage.

Yes, I understand now.

If the name mangling rules used by the Wiki were
explicitly documented, then Vim mangling rules
could be implemented to match them.
Right now I have to do it by guess and by gosh,
then hope that the abstraction doesn't change in
the future. Documenting the rules would make it
an official part of the interface, which you may
dislike but would allow interfacing at that level.

>
> However, there is no reason you couldn't have a directory-based store that
> would actually place the item into a directory "/a/b". In fact, it should be
> pretty simple to make such a store by starting with wikStore_files. Or if
> you just wanted a different name-mangling scheme that was more Vim-friendly
> you could create wikStore_files_my_version, etc.
>

Yes, that would be the right way to do it and I hope it happens.
I doubt I'll get it done because I know so little about Python, Web
standards,
and related issues... also because this effort falls way outside the
bounds
of the project that I'm supposed to be working on.

> > Use case 1:
>
> > General documentation:
> > If the text contains something like
> > "blah blah files/foo.txt blah [[bar stuff|files/bar.txt]] blah"
> > then Vim allows you to position the cursor over any
> > phrase and open a file (goto) by that name with one keystroke
> > (or mouse click combination), i.e. Vim can treat essentially
> > any phrase as a hyper link, without any markup (which
> > is the simplest markup of all).
>
> So are you talking Vim opening the file directly, or launching a browser to
> open it? The reason I ask is, as noted above, if you have a wiki item
> "MyFunctionDocs", you don't know *in general* where that item is physically
> stored. But in the textfiles case, it would be stored in
> "MyFunctionDocs.txt" (in the root of you wiki folder) and the link would
> look like [[mydocs|MyFunctionDocs]]. So the ".txt" doesn't appear in the
> link (unless you are serving from "files/" but I'm assuming you are talking
> about wiki items now).

Yes, I execute Vim directly from the command line.
I would use Mozilla only for QC before publishing the pages.
Nearly all of my time would continue to be within the Vim environment.

I already have a couple hundred pages of documentation for my
project and estimate that its only 10% documented.
The C and Fortran source will be about 2X documentation size.
Using Vim I can easily refactor code and documentation in hundreds
(or thousands) of files all with just a few keystroks,
i.e. with one command I can change a function name from foo
to bar, add boiler plate changes and

Using Vim on the wiki pages requires that the backend
text store be well defined (not abstracted and hidden).

>
> > Vim can be configured
> > to do some simple name "mangling" such as ignore
> > certain leading and trailing characters (such as [, ], |).
> > Mangling " " (blank) into "_" is problematic for naked links,
> > i.e. it requires markup to delimit link bounds.
> > Mangling "/" into "_" is non-intuitive for me at least,
> > because my mental model is that of a path.
> > Using directories for a namespace is more intuitive.
>
> See above -- does that help any?
>
>
>
> > Vim also supports "syntax highlight".
> > Its normally used to highlight source code language elements,
> > i.e. keywords in one color, strings in another, etc.
> > Wiki markup can be highlighted using syntax rules,
> > i.e. ''bold'', //italics//, headings, links, tables, etc.
>
> > When used together, "goto" file and markup highlights
> > provide a useful approximation to the Wiki experience.
> > This approximation helps when developing content,
> > i.e. when bouncing between pages to get it right.
> > While Vim is useful, its not polished enough for
> > presentation (like a browser), nor web accessible.
>
> Depending on the answer above, this sounds like just a matter of making Vim
> realize that [[a link|MyItem]] means to browse tohttp://whatever/blah/MyItem. Is that right?
>

Yes, I'm already using Vim to do this.

If the Vim cursor is bounded by "|MyItem]", then with one keystroke
it will open the file named "MyItem" in Vim for editing.
The configuration can be adjusted to look for "MyItem.txt" or
search in directories relative to the file containing the cursor.
I need to understand the Wiki name mangling to do this...

If the Vim cursor is bounded by http://whatever then the
Vim Utl plugin will start Mozilla using this URL.

>
> > Use case 2:
>
> > When editing C and Fortran source code, comments
> > can reference Wiki pages for general information.
> > Vim functionality can be used to follow these "links"
> > and "close the loop", without leaving the Vim world.
>
> Like above, to me this sounds like just making Vim understand the wiki link
> syntax?
>
> > Use case 4:
>
> > Doxygen-like functionality (new project idea).
> > Documentation within the source code could be extracted
> > and integrated with Wiki pages for presentation.
> > Comments and pages could share much of the same
> > markup conventions, which reduces the overall learning
> > curve and brain-cells load.
>
> I guess I should go ahead and put this out, but I have a plugin that will
> extract TiddlyWiki/WikklyText style markup from Python source code and
> render it. Here is an example:
>
> http://boodebr.org/pages/boodebr/boodebr.sql2.html

That sounds useful for Python development.

I want to do something similar for C and Fortran (and ... ?).
The "NaturalDocs" is another system that tries to document
code using a very simple conventions for comments.
Its philosophy is similar in spirit to Wiki markup.

Python is supported by ctags, along with dozens of other languages.
I haven't used it with Python, but its essential for my C
productivity.
Are you familiar with ctags?

>
> It doesn't have a lot of nice things like autolinks between modules, etc.
> but it does the basic job when you don't want to write the same comments in
> the source AND on a website.
>

Yes, exactly !!!
I'm trying to minimize duplication too.

> If you look in the mailing list archives, there was another plugin posted
> that uses pygments to do Python syntax highlighting with wiki items. One of
> these may be what you are looking for? Or at least give a starting point.
>

Vim syntax files already support several dozen languages.
Pygments (and others) will highlight preformatted blocks for browsers.

This is beyond my skill level, but I suspect it could be implemented
as:
1) create a tags file by scanning all pages, remembering the anchor
names,
page names and positions within pages.
2) read the global tags file when the first page is loaded.
3) use the tag info to control hover displays and link following.

>
> Utl (Universal Text Links):
>
> > Since I live in Vim, I use the Utl plugin.
> > It provides a richer version of "goto file".

> > For example, "goto"http://foo.com/herewill open the

> > browser and load the web page.
>
> Does that have hooks where you could make it recognize [[link|Name]] style
> links? Or if Utl lets you define your own schemes, maybe something like
> [[link|wiki://Name]] would work? (You could then have an URL resolver on the
> wiki side that knew that wiki://Name maps to Name.)

Yes, Utl already does this.

[Frank McIngvale]

On Sat, Sep 26, 2009 at 3:35 PM, Randy <Randy...@data-warp.com> wrote:

On Sep 26, 1:18 pm, Frank McIngvale <fmcingv...@gmail.com> wrote:

> On Sat, Sep 26, 2009 at 11:14 AM, Randy <RandyTid...@data-warp.com> wrote:
>

If the name mangling rules used by the Wiki were
explicitly documented, then Vim mangling rules
could be implemented to match them.
Right now I have to do it by guess and by gosh,
then hope that the abstraction doesn't change in
the future.  Documenting the rules would make it
an official part of the interface, which you may
dislike but would allow interfacing at that level.

Not at all, I consider that to be part of the public interface and I don't break public interfaces if at all possible. The function is wikklytext.store.wikStore:makeFSname(), which I can summarize here:
-------------------------------------
convert unicode -> ascii, replacing bad chars
replace \/*?<>| with _
" -> '
: -> -
\n -> _
\r -> _
-------------------------------------

Now ... the twist on this is that the mangling is used when SAVING the item. When loading, the <Name> tag inside the file is used. So "/a/b/c" gets saved as "_a_b_c" but the real name is saved in <Name>. This leads to the weird result that it would be perfectly legitimate for item "Foo" to be saved in file "Bar.txt", as long as <Name> is Foo. WikklyText NEVER does this -- "Foo" will always be saved in "Foo.txt", but the code allows for it in case some third-party code changed the wiki.

And not to belabor the point, but if you KNOW you are going to use a filesystem where all characters are allowed in filenames, you could make a non-mangling store. The above scheme was chosen for cross-platform use.

Using Vim on the wiki pages requires that the backend
text store be well defined (not abstracted and hidden).

In general yes, you don't want to assume anything about the storage system, however, text files are a special case in that:
   * they are meant to be edited by hand
   * their metadata can be missing entirely and they'll still work
   * they are the best format for auto-generating or reading the wiki content across languages, without worrying about formats or Python particulars.

In short, it sounds like you are using textfiles exactly as they were meant to be used, so don't worry about things breaking there.

>
> Depending on the answer above, this sounds like just a matter of making Vim

> realize that [[a link|MyItem]] means to browse tohttp://whatever/blah/MyItem. Is that right?
>
Yes, I'm already using Vim to do this.

If the Vim cursor is bounded by "|MyItem]", then with one keystroke
it will open the file named "MyItem" in Vim for editing.
The configuration can be adjusted to look for "MyItem.txt" or
search in directories relative to the file containing the cursor.
I need to understand the Wiki name mangling to do this...

Let me know if there is anything else I can do on this. WikklyText is meant to be a "programmer's wiki" so I'm interested in these kinds of projects.
 

> I guess I should go ahead and put this out, but I have a plugin that will
> extract TiddlyWiki/WikklyText style markup from Python source code and
> render it. Here is an example:
>
> http://boodebr.org/pages/boodebr/boodebr.sql2.html

>
That sounds useful for Python development.

I want to do something similar for C and Fortran (and ... ?).
The "NaturalDocs" is another system that tries to document
code using a very simple conventions for comments.
Its philosophy is similar in spirit to Wiki markup.

I think it would make a good starting point for other projects ... I need to tar it up and put it out sometime :-)

 

Python is supported by ctags, along with dozens of other languages.
I haven't used it with Python, but its essential for my C
productivity.
Are you familiar with ctags?

Not too much. I need to see if I can get the plugin working for jedit.

> > For example, create a ctags-like file for known "anchors"
> > within a Wiki for all pages.  The anchors might be
> > specified with markup, i.e. the "GoodTimes" page has
> > <<anchor "GoodTime"|"good times"|"for a good time">>
> > for a good time call me at xxx.
> > Any page that contains one of the phrases (without any
> > additional markup) is a potential link to "GoodTimes".
>
> This should be possible -- the <<anchor>> macro would need to know what page
> it was being rendered for, but that's easy to put into the WSGI environment.
> For the second part you'd need a hook that received the (post-rendered) XML
> and compare plaintext phrases vs. the "tags" file entries. This is supported
> at the low-level but not yet through wiki plugins. I'll make a "think about
> this" note in my TODO on these since I think they would be generally useful.

This is beyond my skill level, but I suspect it could be implemented
as:
1) create a tags file by scanning all pages, remembering the anchor
names,
page names and positions within pages.
2) read the global tags file when the first page is loaded.
3) use the tag info to control hover displays and link following.

The more I think about this, what you're proposing sounds like a "micro-tagging" concept, where in addition to applying tags to the page as a whole, you're also tagging individual bits within the page (specifically at the anchor level). I need to google and see if any other wikis have tried that. That could be pretty cool.

frank

[Randy]

If I remember correctly, ctags is flexible and extensible.

The ctags application can be extended for new languages,
were the "anchor notation" represents a new mini-language.
The ctags file format is flexible and is hopefully suitable
as-is for anchor information.

The ctags maintainer has probably thought
about some of these issues too (generic glossary support
AKA micro-tagging of Wiki text). He may have valuable
insight to share.

He might be willing to implement support in ctag for an
"anchor notation" because this mini-language is trivial
compared to parsing C, Java, Python, etc.
This would reduce the problem to using the ctags
within a Wiki context... your area of expertise.

I'll send the ctags maintainer a note and reference
this Google Group.

On Sep 26, 5:58 pm, Frank McIngvale <fmcingv...@gmail.com> wrote:

[Frank McIngvale]

On Sat, Sep 26, 2009 at 8:47 PM, Randy <Randy...@data-warp.com> wrote:

The ctags maintainer has probably thought
about some of these issues too (generic glossary support
AKA micro-tagging of Wiki text).  He may have valuable
insight to share.

He might be willing to implement support in ctag for an
"anchor notation" because this mini-language is trivial
compared to parsing C, Java, Python, etc.
This would reduce the problem to using the ctags
within a Wiki context... your area of expertise.

I'll send the ctags maintainer a note and reference
this Google Group.

Sounds like a good idea -- thanks!

frank