suggestions for more "semantic tags" in the wiki parser

[felix winkelmann]

• allow {{<syntax>}} as alias to {{<macro>}}

• allow {{<setter>}} (for a SRFI-17 setter procedure)

[Jim Ursetto]

Yes please. I have been waiting for this moment forever.

Another interesting tag might be <class> for coops.

In the manual there are a few other tags such as [import specifier] and [module]. I think [module] can be omitted semantically because these show up in chicken-doc and really in the manual as separate nodes anyway. [import specifier] can probably be usurped by <syntax> and then "only", "rename" etc. would show up as nodes.

It would also be interesting to make foreign types such as "scheme-object" and "integer32" light up.

It is not clear to me whether C functions, such as the ones in man/4/Embedding, should be marked up semantically. It could be useful, especially if it were used to document the core in general, if that ever happens.

[felix winkelmann]

I think it would also be good to get rid of the <scheme> tag.

[sjamaan]

We never implemented the <scheme> tag in svnwiki-sxml, so no need to get rid of it :)

I also removed it from the wiki-syntax documentation file now.

[sjamaan]

It looks like there's already support for the following types, by the way:

• procedure
• macro
• read
• parameter
• record
• string
• class
• method
• constant
• setter (just added this one)

I haven't tested these, but the code that handles these things is quite generic so these should "just work".

One word of warning though: I'm against making syntax and macro both possible. If it is handled the same way as the other things, an identifier search on the wiki would not find things marked up as "macro" when searching for "syntax: foo" and vice versa. We could add special treatment to svnwiki-sxml to translate syntax to macro internally, but that's just ugly IMHO.

I've added "setter" to the list in svnwiki-sxml.

[Jim Ursetto]

I forgot I added support for class etc. before. We just couldn't use them.

I am okay with modifying svnwiki-sxml to translate syntax to macro, unless these two should have different semantic meanings. There are already plenty of ugly hacks in that code for svnwiki anyway.

Actually I have always thought that "syntax" would be a better tag than "macro" anyway. But svnwiki only supports "macro", so that is what I used. If anything, I'd rather alias macro to syntax.

[sjamaan]

You say "There are already plenty of ugly hacks in that code for svnwiki anyway."

I'd rather work on reducing those hacks now we aren't restricted by compatibility with svnwiki, than adding more of those.

[sjamaan]

I'll let you decide on how (and if) to handle "syntax", Jim.

[Jim Ursetto]

Felix, to confirm, you want syntax and macro to be identical, i.e. no semantic difference?

My plan would be to use syntax as the primary tag and, when macro is read by the svnwiki-sxml parser, store it as syntax internally. All wiki, chicken-doc and chickadee pages will render it as syntax.

Sound ok?

[felix winkelmann]

Replying to zbigniew:

Felix, to confirm, you want syntax and macro to be identical, i.e. no semantic difference?

That was the idea, yes.

My plan would be to use syntax as the primary tag and, when macro is read by the svnwiki-sxml parser, store it as syntax internally. All wiki, chicken-doc and chickadee pages will render it as syntax.

Sound ok?

Sounds very ok.

[Jim Ursetto]

Implemented in svnwiki-sxml 0.2.7, but won't be active until restart of qwiki.

You need to pull the latest chicken-doc because it did not understand syntax tags in sxml. To avoid this problem in the future it now accepts arbitrary tags.

Updating chicken-doc-admin is not required but it did get a lot faster in the last week. See r19490 and r19682.

[Jim Ursetto]

Sorry, the directive to pull chicken-doc was meant for Felix or anyone using chicken-doc with svnwiki-sxml 0.2.7 (including those that d/l the repo tarball from the website). It has nothing to do with qwiki. :)

[sjamaan]

OK, updated. I don't want to reinstall the wiki though (currently the only way to reinitialize the search database), so the search function will be accepting mixed macro: and syntax: searches until all pages which have a <macro> have been touched (so the db is updated). I don't think this is that much of a problem since nobody searches specifically for syntax anyway. (an unspecified identifier search will return both macro and syntax entries)

If this is too obnoxious, let me know and I can do a reinstall or come up with a script to reindex.