Short description
Example of a page internal link which refers to a header of a page: http://ooowiki.de/ZeichnungInTextdokumentEinf%C3%BCgen#head-443e77d5200f72870982716f06bd38ace7643206
That is very long. And the link does not "speak" to the user.
Solution
Example for a pattern for short and "speaking" links to the headers of a page:http://borumat.de/php-tipps-und-skripte#autotoc-ziel The pattern ensures, that each id for headers is unique for a document.
The pattern is part of a description of a PHP script to generate a table of content for a single page. If this is helpful, I do not know. I'm not a programmer. I had just the idea for this script. I mentioned the script just to suggest a pattern, not because I think the script could be useful for the moinmoin engine.
Please contact me, if my feature request isn't clear enough. -- Andreas Borutta borumat@gmx.de
- The problem of those links is that they have to use unique ids. Look at the moinmoin code doing this. If you still have a nice idea how to do that after looking at it, let us know.
Of course I know, that ids have to be unique for one document. The pattern I suggested in http://borumat.de/php-tipps-und-skripte#autotoc-ziel for headers ensures, that an each id for headers is unique for a document. The legibility of the ids is IMHO good - and - the ids are very short. Because I could not program, it makes no sense when I look at the moinmoin code.
Not a solution at all, but why do not use the -tag? Normally you do not link headers in a document that much so it's not so much work. Another advantage: The Page and Headlines can be changed but the Anchor can still be the same without changing the link.
You should use the Anchor() macro.
Although I understand you want to clean up old MoinMoin issues, you however can't close a feature request by pointing to the workaround for the problem. That would actually lead the sense of a feature request ad absurdum. -- MartinBayer 2008-03-18 22:53:27
Why is the workaround not satisfying? a) You need to edit both, the target and the linking page while b) we don't have deep links only from within the wiki, but also from outside, and c) might have editing restrictions on one or all pages (ACL).
However, something like this is already implemented, unfortunately not on MoinMoin, but on http://wiki.python.de. I wonder whether the extension they use is stable enough for being implemented into the MoinMoin core code. Or is it just the patch published on the site mentioned below, ../NicerHeadingIds? In that case, this feature request should not be closed until the patch has been rejected (for what good reason ever), or has been implemented into MoinMoin.
Ok, let me elaborate:
- this is impossible to implement exactly as you wish due to issues with Include() and unique IDs
there has to be an algorithm that determines a unique ID, it used to be a simple sha1sum, now it is much nicer (e.g. if the heading is == Abc Def == then the ID will be #AbcDef), for example http://linuxwireless.org/en/users/Drivers/b43#features
- this only works for ascii because IDs cannot contain non-ascii characters
- as soon as you have non-ascii characters, the ID isn't simple any more and you need to use the anchor macro
- therefore, the whole issue is led ad absurdum as soon as you use non-ascii languages
- regardless of all this, you want predictable IDs!
-- JohannesBerg 2008-03-19 00:26:04
I'm not sure you really understand what I meant with reductio ad absurdum, however, I'm afraid you are yet again confusing abstract concepts (features, or features to be) with concrete implementations. Otherwise you wouldn't say that something is impossible because there is this or that issue standing in the way: dependencies that complicate an implementation are the reason why Feature Requests exist in the first place. IOW, the complexity of a possible implementation is never a reason for closing a Feature Request. And, speaking of bizarre things, I really don't see what sense it makes telling me why the patch on ../NicerHeadingIds can not be implemented into the main branch, but solving this issue as “implemented” at the same time. So, let's come back to what this issue is all about:
Headings should be auto-converted into anchors in order to make deep-links to a chapter on a wiki page possible from both, inside and outside the wiki. The anchor should be the text of the heading literally in order to make these links both, human-readable and persistent even when a chapter is moved on the page (or an other chapter removed). There is no need to determine now whether two or more identical headings should result or not into two or more identical anchors (from which only the first would work). It is sufficient for now to state that a feature as described in this request has been demanded from our users, is welcome from the usability's point of view, and a shortage in MoinMoin's competition with other wiki engines (do I really have to mention that this has been implemented in MediaWiki for ages?).
So, please don't close this issue again unless you are willing to decide that MoinMoin should become ignorant about usability, its users, and its competitors—or, of course, a working implementation is in the main branch. -- MartinBayer 2008-03-19 21:07:22I don't know how I can be any clearer: This feature is implemented in 1.7 (as you can see from the example I gave) and (for release technical reasons) rejected for 1.6. ../NicerHeadingIds is about a bit of an improvement and can stand on its own without this feature request. Please do not reopen this issue unless you wish that I completely ignore you in the future (as I'm already doing on other feature requests.) -- JohannesBerg 2008-03-19 21:41:50
Related Issue(s): FeatureRequests/NicerHeadingIds FeatureRequests/LinkWikiNameHeadings
CategoryFeatureRejected (1.6) CategoryFeatureImplemented (1.7)