On Jul 7, 2010, at 3:47 PM, mdipierro wrote:

> 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.

It's pretty common (and useful) in Wikipedia. And it needn't be literally the 
slug. As in Wikipedia,

[[link]]

would imply that 'link' is the text and slug(link) the slug for the URL. In 
Wikipedia, that's most commonly the space-to-underscore conversion, so

[[some link]]

becomes

<a href="some_link">some link</a>

I agree that coupling is an issue, but is the answer to make the wiki syntax 
worse? I think that the wiki should be a first-class user of its syntax. That 
is, it shouldn't be necessary to compromise its syntax just so markmin can be 
100% shared.

How about explicitly initializing markmin (at least optionally)? Give it a base 
address, that slugs could be appended to. Or subclass markwiki from markmin?

Or at the very least allow a shortcut.

[[name page:slug]]

could use the Wikipedia convention

[[name|slug]]

with [[name|]] implying [[name|name]]

Alternatively (see base addresses below), [[name page:slug]] could be 
abbreviated [[name :slug]], and [[name :]] would imply [[name page:name]] as 
above.


One more thing wrt the "base address" idea above. Suppose we were using the new 
wiki as the basis for a web2py reference wiki. One of the things that the wiki 
needs to do is to link to some external standard references. This is not an 
attempt at a real syntax--just something to give the general idea.

[[base:slice http://www.web2pyslices.com/main/slices/take_slice/%(slug)]]

and then:

[[Audit trail slice:35]]

...would do the obvious thing.

So we could have base addresses defined for slices, the manual, the Python 
reference pages, etc.

Side note: the base address definition format needn't be a command in wiki 
syntax; it could be an initialization call related to the plugin. In 
particular, we don't want to have to embed it in every page (though the 
*ability* to do so would be handy). Or every page could implicitly "include" a 
master page, if present.

> 
> 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.


Reply via email to