I do not have a strong opposition and I see the advantages in terms of notation but I have two problems:
The page:slug notation is handled by plugin_wiki, not by markmin. markmin just treats url, #anchor, url#anchor, page:slug all in the same way. plugin_wiki replaces the page:.. with /app/plugin_wiki/ page/.... after markmin has done its job. This decoupling was intentional to allow markmin to work without web2py and without plugin_wiki conventions. Your first suggestion would introduce coupling. Moreover it would provide a shortcut that encourage users to display the slug as text of the link. I am not convinced this is a good idea. Massimo On 7 Lug, 17:24, Jonathan Lundell <jlund...@pobox.com> wrote: > On Jul 7, 2010, at 3:14 PM, mdipierro wrote: > > > > > Right now you can do links with > > > url > > [[name url]] > > [[name #anchor]] > > [[name url#anchor]] > > [[name page:slug]] > > > and define an anchor with > > > [[anchor]] > > > If I understand your suggestions: > > 1) also allow > > [[url]] > > [[url#anchor]] > > [[#anchor]] > > [[page:slug]] > > to allow un-named links. Q: how can a link not have a name? > > In your notation, I was thinking: > > [[slug]] would imply [[slug page:slug]] > > 'slug' would be used verbatim as the name, and with slug-encoding as the slug. > > A link would always have a name; it would just be implicit. That's the > Mediawiki convention, though they use a vertical bar to separate an optional > name from the slug. > > > > > 2) use [[=anchor]] to define an anchor to avoid conflict with 1. > > > if we do 1, we must do 2 but I would prefer [[!anchor]] then. > > Sure. > > Or [name:anchor], which corresponds to the html that it generates.