Fwiw, a few years back i created a patch which caused generated wiki links to always emit wiki/x rather than name=x, but it was pointed out to me that wiki/x doesn't work when x contains a slash, which is a valid wiki page name character. Thus the portable approach is to use name=x. :/
----- stephan Sent from a mobile device, possibly left-handed from bed. Please excuse brevity, typos, and top-posting. On Wed, Jul 4, 2018, 22:54 Andy Goth <andrew.m.g...@gmail.com> wrote: > To create a link in the Markdown wiki, the syntax is [like this](url). > That's all well and good, but what precisely does url need to be for one > page to link to another? In writing embedded documentation, I've gotten > used to relative paths, so in order to link /doc/trunk/doc/foo.md to > /doc/trunk/doc/bar.md, I write (bar.md). > > However, with the wiki, there's an issue. Most (if not all) of the > links into the wiki use the ...?name=page syntax rather than the > theoretically equivalent .../page syntax. This throws off relative > paths entirely. Relative links between wiki pages will be different > depending on which "equivalent" syntax was used to access the wiki. > > Suppose wiki page foo wants to link to wiki page bar. If foo was > accessed as wiki?name=foo, then it must link to (wiki?name=bar) or > (wiki/bar). But if foo was accessed as wiki/foo, it must link to (bar), > which it what I hoped would work all along. > > To make intra-wiki links work regardless of which syntax is used to > access the wiki, it appears it's necessary to use "absolute" (actually > relative to the project root) paths: (/wiki?name=bar) or (/wiki/bar). > This is not something I've had to deal with (yet?) when doing embedded > documentation. > > My preference would be for Fossil to never send the name query parameter > to the user. If a name query parameter is received from the user, I > think maybe Fossil should not call the webpage function (other than > confirming that one exists) and instead immediately send a 301 Moved > Permanently back to the user to rewrite the URL to use /. > > Or maybe I'm missing something fundamental here. > > There's one other style of relative link I'll mention: (?name=bar). > This replaces the name query parameter. I don't think this would work > very well if linked from /wiki/foo. Also it gets even weirder when > clicking a link in the preview shown by wikiedit, since it takes the > user to the editor for the target page. But this last would still occur > should we replace all ?name= with /. To avoid that, the link would have > to be either (/wiki/bar) or (../wiki/bar), though of course that last > one combines the worst of all worlds. > > For now, I'll make sure all my wiki links are to /wiki/whatever. > > Note: I'm talking about Fossil version 83e3445f67 (2.1), since that's > what Chiselapp uses. > > -- > Andy Goth | <andrew.m.goth/at/gmail/dot/com> > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
