+ >>>> I'm afraid this is not the case in the ikiwiki I have. It might be the effect of some kind of interaction of
+ >>>> this with the next patch, but apparently I need both to ensure that the proper title is being used (see also
+ >>>> below for further details).
+
+* the (new) third patch passes uses the included rather than the including page for the URL. This is
+ actually a forgotten piece from my previous patch (now upstream) to base the feed name on the
+ included rather than the including page, and it's only relevant for nested inline pages.
+
+ > I have a vague memory of considering doing this before, and not,
+ > because there is actually no guarantee that the inlined page (that
+ > itself contains an inline) will generate an url. It could be excluded;
+ > it could be an internal page; it could use a conditional to omit the
+ > inline when not inlined.
+ >
+ > Also, I think that `destpage` gets set wrong. And I think that
+ > `get_inline_content` is called with the source page, rather than the
+ > destpage, and so could generate urls that don't work on the destpage.
+ >
+ > All in all, this is an edge case, and currently seems to work ok, so
+ > why change it? --[[Joey]]
+
+ >> Because it does not work ok for me. I have a number of directories `dir1/`, `dir2/`, `dir3/`
+ >> each with a corresponding `dir1.mdwn`, `dir2.mdwn`, `dir3.mdwn` etc that is basically just
+ >> an inline instruction. Then my index.mdwn inlines `dir[123]`. Without these two patches, the
+ >> `dir[123]` feeds get the wrong title.
+
+* the (new) fourth patch introduces a `feedtitle` parameter to override the feed title. I opted for
+ not squashing it with the second patch to allow you to scrap this but still get the other, in case
+ you're not too happy about having a plethora of parameters
+
+ > This seems clearly a good idea, since there is already a "description"
+ > parameter. But, by analogy with that parameter, it should just be
+ > called "title". --[[Joey]]
+
+ >> I'll rework the patch to that effect.
+
+* a fifth patch introduces an `id` parameter to allow setting the HTML id attribute in the
+ blogpost/feedlinks template. Since we replace their id with a class (first patch), this brings
+ back the possibility for direct CSS customization and JavaScript manipulation based on id.
+
+ > That sort of makes sense, but it somehow seems wrong that "id" should
+ > apply to only cruft at the top of the inline, and not the entire div
+ > generated for it. --[[Joey]]
+
+ >> Good point. I'll look into a way to move the id to the `inlinepage` div, although I guess
+ >> that falling back to `id`ing the `feedlink` div in the feedonly case would be ok.
+
+* 30a4de2aa3ab29dd9397c2edd91676e80bc06feb "urlto: prevent // when {url} ends with /"
+
+ > The `url` in the setup file should not end in a slash. Probably more
+ > things get ugly doubled slashes if someone does that. --[[Joey]]
+
+ >> I was not aware of this. Did I miss it or is it just not documented?
+
+* 57a9b5c4affda9e855f09a64747e5225d6254079 "inline: use urlto instead of manually building the RSS url"
+
+ > Well, that seems ok. 3 parameter urlto should give us an absolute url.
+ >
+ > But we have to be careful and verify that it will always produce
+ > exactly the same url as before. Changing the feed url unnecessarily
+ > can probably flood aggregators or something... --[[Joey]]
+
+ >> AFAICS, the feed url would not change (unless the previous patch is also applied and the wiki url ends with a slash)
+
+
+-----
+
+* the first patch simply replaces the id attribute in the default template for feedlinks with a class attribute by the same name. This is necessary in pages with multiple inlines to guarantee correctness
+
+ > Ok, but blogform.tmpl has the same problem. And either change can need
+ > CSS changes. (blogform in particular is used in style.css as an id.)
+ > So this needs more documentation and associated work. --[[Joey]]
+
+ >> I didn't include blogform in the change because the case of two
+ >> blog post forms in the same page is probably extremely rare. But
+ >> then again I remember doing having them in one of my ikiwiki
+ >> draftings, so I rewrote the patch to include blogform. I had
+ >> checked the distributed CSS for #feedlinks references, without
+ >> finding any. The new patch does include CSS changes for the
+ >> \#blogform -> .blogform change. I have no idea on where to document
+ >> this change though.
+
+ >>> Picked. NEWSed. --[[Joey]]
+
+