[pmwiki-devel] Update Re: Using "!#anchor heading" markup

[Petko Yotov]

On 30/05/2026 04:45, John Rankin wrote:
> 1. [[##visibleAnchor]] now uses TrackAnchors function to detect
> duplicate ids. If it finds one, it displays � instead of § (the
> characters are user-configurable). This revealed a conflict with
> SectionEdit's use of MarkupToUnstyled, which I have fixed.
> 
> 2. For consistency, the recipe now tests $SeenAnchor for [[#anchor]]
> and !!#anchor to display a � for a duplicate, before giving control
> back to pmwiki to process the markup. Telling a writer when ##anchors
> are duplicates but not #anchors felt wrong (by Philosophy 1).

> 3. !!##anchor heading produces a visible anchor, again for
> consistency.

The core "!!#anchor..." produces:
   <h2 id="anchor">...</h2>

not:
   <h2><a id="anchor"></a>...</h2>

so in !!#anchor there is no actual anchor tag. I guess you can have a 
markup rule that rewrites !!##anchor into !![[##anchor]] for it to be 
made visible.

> 5. Is there a case for making duplicate anchor ids visible as part of
> the pmwiki core?

Currently, !!#anchor does not check for duplicates, maybe it should, but 
should we also do something about all possible elements with an 
identifier like:

   (:input id=something:) planned (:input#something.className:)
   (:div id=something:)   planned (:div#something.className:)
   (:details id=something:)
   %list id=something%

What if a writer adds to a page [[#wikitext]] when the skin already 
defines <div id="wikitext">? At some point we might want say PmWiki is 
not an HTML standards validator and leave the responsibility with the 
writers. A recipe may use output buffering and htmltidy to remove 
duplicate ids when this is required.

If there are duplicate identifiers, which one should win? The different 
markups are processed in order one after another, even if in the page 
!!#anchor is before [[#anchor]], the engine will see the latter first.

If both are in the page and both are rendered, a link to Page#anchor 
will focus the one that is earlier in the page.

If both are in the page, using (:include Page#anchor:) will include from 
[[#anchor]] not from !!#anchor because of the order of 
$TextSectionAnchorPatterns.

I would not render a character for a removed anchor with duplicate 
identifiers, because recipes and pagelists can include parts of multiple 
pages that are wrapped in the same anchors:

   (:include {=$FullName}#start#end:)
   (:b3-list:)

If duplicate anchors are replaced with �, these will appear as new weird 
characters in pagelists that worked fine before.

> 6. Should I be separating out visible and duplicate anchor markup
> processing into its own separate recipe?

If someone needs visible anchors but prefers one of the several other 
table-of-contents recipes, it may be good to split them.

> Should such a recipe be an optional part of the pmwiki core?

If visible anchors are popular, we can consider adding them to the core. 
I know of a single wiki that is using these extensively.

The core already matches [[##anchor]] as well as !!#anchor for inclusion 
of sections in (:include Page#anchor:).

> 4. (:toc anchors=visible:) makes all anchors in the toc headings
> visible (overriding any !![[#anchor]] markup); a new option (:toc
> anchors=!visible:) hides all anchors (overriding any !![[##anchor]]
> markup), except for any duplicate ids; (:toc:) processes anchors as
> written.


> PS Simon, I'll update your site once nitram has confirmed that all is
> well.
> 
> On 10/04/2026 3:30 pm, Simon wrote:
> 
>> thank you so much.
>> I will follow this up with the recipe's author, who probably has
>> seen this.
>>