[emacs-wiki-discuss] Re: Questions about sectionalize and tags markup

[Peter K . Lee]

The following message is a courtesy copy of an article
that has been posted to gmane.emacs.wiki.general as well.


,----[ Michael Olson (20 Jan 2006) writes: ]

> address@hidden (Andrew J. Korty) writes:
>
>> While porting planner-authz.el to muse (sorry I didn't mention
>> sooner I was working on it, Michael :-), I was hoping to take
>> advantage of the sectionalize code, but I ran into a couple of
>> problems.
>>
>> First, sectionalize seems to run too early -- before any of the
>> markup or tag rules.  So if you have something that looks like,
>> say, a section heading in the middle of an <example> section, it
>> will get marked up incorrectly.  It happens a lot with snippets
>> from ERC, which I'll often wrap in <example> tags.  By default, ERC
>> begins action lines with *s, so they look like section headings.
>>
>> Can anyone think why sectionalize shouldn't be run from a regexp
>> rule?  That way, we could mark text wrapped in <example> tags as
>> read-only (probably a good idea, if we don't already) so it won't
>> get matched.
>
> Is this still an issue with the 3.40 release?  I remember that Peter
> K. Lee tweaked planner-publish a bit just before the release.

Yes, sectionalize still runs as part of :before style.  So, it does
not respect <example> type tags that are marked read-only.

The reason sectionalize hasn't run from a regexp rule is that no
matter how you look at it, it needed to run *before* the regexp rule
that marked up the tags.  

The reason is that sectionalize marks up sections with <section> tags,
handling certain sections (i.e. * Tasks, * Notes) as <tasks>, and
<notes> tags.

So, when the regexp rule ran that marked up the TAGS, it THEN took
care of the <example> tag sections, and by that point, it would be too
late.

I think what we can do is to have 2 stages of tag processing, one with
"pre-processor" like tags, where (<example>, <literal>, <code>,
<lisp>, <include>, etc.)  type of tags get processed, and the second
stage of tag processing, where the rest of tags would get marked up
(where custom * Tasks, * Notes regexps for planner would markup those
sections with <tasks> like tags, and get processed with a similar tag
processing routine).

>> Second, muse-publish-markup-tag doesn't seem to understand nested
>> tags of the same name, which sectionalize produces a lot of.  I can
>> think of two ways around this.  Preferably, we'd make
>> muse-publish-markup-tag able to grok nested tags.  Or as a quick
>> fix, we could have sectionalize name each tag differently
>> (<section1>, <section2>, etc.).
>
> I think that some of the nested tags were renamed in the
> aforementioned changes to work around this.
>
> One issue with recognizing nested tags of the same name is that
> example/QuickStart.muse uses constructs like
> =<literal><literal></literal>= in order to get the text "<literal>"
> printed correctly in monospace.  This would be something we'd have
> to take into consideration.

I'm not exactly sure how we can address this.  :)

-Peter