</pre>
---
+----
> A few quick notes about it:
>> Thus tagging [[patch]]. --[[intrigeri]]
>>
>>> Joey, please consider merging my `meta` branch. --[[intrigeri]]
+
+So, looking at your meta branch: --[[Joey]]
+
+* Inter-page dependencies. If page A links to page B, and page B currently
+ has no title, then A will display the link as "B". Now page B is modified
+ and a title is added. Nothing updates "A".
+ The added overhead of rebuilding every page that links to B when B is
+ changed (as the `postscan` hook of the po plugin does) is IMHO a killer.
+ That could be hundreds or thousands of pages, making interactive editing
+ way slow. This is probably the main reason I had not attempted this whole
+ thing myself. IMHO this calls for some kind of intellegent dependency
+ handler that can detect when B's title has changed and only rebuild pages
+ that link to B in that case.
+* Looks like some plugins that use `pagetitle` to format it for display
+ were not changed to use `nicepagetitle` (for example, rename).
+ But most of those callers intend to display the page name
+ as a title, but including the parent directories in the path. (Ie,
+ "renaming foo/page title to bar/page title" --
+ you want to know it's moved from foo to bar.) `nicepagetitle` does not
+ allow doing that since it always takes the `basename`.
+* I don't like the name `nicepagetitle`. It's not very descriptive, is it?
+ And it seems very confusing to choose whether to use the "nice" or original
+ version. My hope is that adding a second function is unnecessary.
+ As I understand it, you added a new function for two reasons:
+ 1) It needs the full page name, not basename.
+ 2) `titlepage(pagetitle($page))` reversability.
+
+ 1) If you look at all the callers
+ Of `pagetitle` most of them pass a complete page name, not just the
+ basename. In most cases `pagetitle` is used to display the full name
+ of the page, including any subdirectory it's in. So why not just make
+ it consitently be given the full name of the page, with another argument
+ specifying if we want to get back just the base name.
+
+ 2) I can't find any code that actually uses the reversability like that.
+ The value passed to `titlepage` always comes from some external
+ source. Unless I missed one.
+* The use of `File::Spec->rel2abs` is a bit scary.
+* Does it really make sense to call `pagetitle` on the meta title
+ in meta's `nicepagetitle`? What if the meta title is something like
+ "foo_bar" -- that would be changed to "foo bar".
+* parentlinks is changed to use `nicepagetitle(bestlink($page, $path))`.
+ Won't `bestlink` return "" if the parent page in question does not exist?
+* `backlinks()` is changed to add an additional `title` field
+ to the hash returned, but AFAICS this is not used in the template.
+* Shouldn't `Render.pm` use nicepagetitle when getting the title for the
+ page template? Then meta would not need to override the title in the
+ `pagetemplate` hook. (Although this would eliminate handling of
+ `title_overridden` -- but that is little used and would not catch
+ all the other ways titles can be overridden with this patch anyway.)
+
+> I'm not a reviewer or anything, but can I chime in on changes to pagetitle?
+> I don't think having meta-titles in wikilinks and the parentlinks path by
+> default is necessarily a good thing. I don't consider the meta-title of a page
+> as used in `<title>` to be the same thing as the short title you
+> want in those contexts - IMO, the meta-title is the "formal" title of the page,
+> enough to identify it with no other context, and frequently too long to be used
+> as a link title or a parentlink, whereas the parentlinks title in particular
+> should be some abbreviated form that's enough to identify it in context.
+> [tbm](http://www.cyrius.com/) expressed a similar opinion when I was discussing
+> ikiwiki with him at the weekend.
+>
+> It's a matter of taste whether wikilinks are "like a parentlink" or "like a
+> `<title>`"; I could be persuaded either way on that one.
+>
+> An example from my site: [this page](http://www.pseudorandom.co.uk/2004/debian/ipsec/)
+> is the parent of [this page](http://www.pseudorandom.co.uk/2004/debian/ipsec/wifi/)
+> with a title too long to use in the latter's parentlinks; I think the titles of
+> both those pages are too long to use as wikilink text too. Similarly, tbm's page
+> about [Debian on Orion devices from Buffalo](http://www.cyrius.com/debian/orion/buffalo/)
+> can simply be called "Buffalo" in context.
+>
+> Having a `\[[!meta abbrev="..."]]` that took precedence over title
+> in parentlinks and possibly wikilinks might be a good way to fix this? Or if your
+> preference goes the other way, perhaps a `\[[!meta longtitle=""]]` could take
+> precedence when generating the `<title>` and the title that comes after the
+> parentlinks. --[[smcv]]
+
+>> I think you've convinced me. (I had always had some doubt in my mind as
+>> to whether using titles in all these other places would make sense.)
+>>
+>> Instead of meta abbrev, you could have a meta pagename that
+>> overrides the page name displayed everywhere (in turn overridden by
+>> meta title iff the page's title is being displayed). But is this complexity
+>> needed? We have meta redir, so if you want to change the name of a page,
+>> you can just rename it, and put in a stub redirection page so links
+>> still work.
+>>
+>> This leaves the [[plugins/contrib/po]] plugin, which really does need
+>> a way to change the displayed page name everywhere, and at least a
+>> subset of the changes in the meta branch are needed to support that.
+>>
+>> (This would also get around my concern about inter-page dependency
+>> handling, since po contains a workaround for that, and it's probably
+>> acceptable to use potentially slow methods to handle this case.)
+>> --[[Joey]]