Patrice Dumas writes:
> Here it is:
> https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=2f185696654b41dd43d1904f66fc4c9ed0ae73ca
yay. Thank you.
> > (*) ... would like the <h5>s to go away ... have the
> > number/mark be inlined into the first paragraph ... give
> > each footnote its own <div> ...
>
> If you are ready to share the code, it could be interesting to
> have it in a maintained init file if it gives a result more
> similar with other formats.
I don't think it will be doing anything really surprising:
Texinfo::Config::texinfo_register_formatting_function(
format_single_comment => sub {
my $self = shift;
my ($id, $href, $mark, $text) = @_;
my ($pre, $post) = $text =~ m{\A\s*(<p\b.*?>)?(.*)\z}saai;
return '<div class="footnote-text">' . $pre
. qq{<sup><a id="$id" href="$href">$mark</a></sup>}
. ' ' . $post . "</div>\n";
}
);
modulo various not-totally-resolved questions, e.g., what to do
about footnote text NOT starting with <p> and other pathological
cases (none of my footnotes have this particular problem, so the
probable answer is, "Don't do that"), what <div> class name plays
best with everything else in CSS Land, and whether <sup> really
is a good idea here (vs. <span class="footnote-mark">$mark</span>
vs. leaving it as ($mark))...
... so I'm guessing what should go in a public init file example
may well need to be a bit different. But this is where I am at
the moment.
> > Now, as it happens, what I want to do is indeed possible in
> > 7.1 with a custom 'format_footnotes_sequence' handler.
> >
> > However, ... using THAT handler first requires re-parsing
> > the footnotes back out of a previously formatted string, ...
>
> I do not understand why you need to do that if you customize
> the format_footnotes_sequence handler.
> [... copy-paste the existing default 'format_footnotes_sequence'
> handler and edit it...]
The reason for NOT doing it that way is I'd then miss out on
whatever happens (bugfixes, enhancements) with that default
handler in the future. And seeing the extent of the changes
between 6.7, 6.8, 7.0, 7.1, it's clear that whole section of code
is under rather active development, making it more likely there
will be further changes...
... which I'll inevitably have to track (yay, life on the bleeding
edge), but the less I have to track, the better.
> There is a trade-off between complexity and ease of customization.
> Given a full cover of customization (which is the case in 7.1), in
> general, the less customization format_* customization functions the
> better, but it can be counterbalances by usability.
> ...
> if we did the same for all the formatting, we would have to add a
> lot of format_* functions.
Understood. I'll try not to open any floodgates. :-)
> I'll add the change.
Again, thanks, and also for the quick response.
> That's what is needed for Perl, but in the master for the
> upcoming release, there is a parallel C implementation for
> speed that needs about the same changes (in tp/Texinfo/XS/.
Um, yeah ... *that* I probably would NOT have gotten right the
first time (suffice it to say, it's been one of my life goals to
learn as little as possible about XS).
--
Roger Crew
w...@wrog.net (c...@cs.stanford.edu)
