Re: [Boost-docs] [quickbook] Reusing footnote

Subject: Re: [Boost-docs] [quickbook] Reusing footnote
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2010-12-29 17:08:22

> -----Original Message-----
> From: boost-docs-bounces_at_[hidden] [mailto:boost-docs-
> bounces_at_[hidden]] On Behalf Of Edward Diener
> Sent: Wednesday, December 29, 2010 2:48 PM
> To: boost-docs_at_[hidden]
> Subject: Re: [Boost-docs] [quickbook] Reusing footnote
> 
> On 12/29/2010 4:16 AM, Daniel James wrote:
> > On 29 December 2010 07:10, Edward Diener<eldiener_at_[hidden]>
> wrote:
> >>>
> >>> For a full native implementation, I'm not sure how to handle ids.
> >>> The normal quickbook id mechanism would be pretty confusing.
> >>
> >> Why not have footnote ids in Quickbook be syntactically like table
> >> ids ? So one could have '[footnote:myid The actual footnote]' and
> >> then later, to duplicate the same footnote '[footref
> quickbook.phrase.footnotes.myid]'.
> >> That would be cleaner than the anchor mechanism. Of course if phrase
> >> elements do not have ids like block elements it will not work, which
> >> is probably what you are telling me with your anchor proposed hack.
> >
> > That's pretty much what I meant by a native implementation. We can add
> > ids to any element, but doing so is a breaking change (although an
> > unlikely one, who'd start a footnote with ':'?) so they're normally
> > done with a version switch. I'm thinking about making the parser a bit
> > stricter about how it handles certain punctuation. Part of that could
> > forbid starting element contents with an unescaped ':', so that the id
> > syntax could be freely used anywhere in the future.
> 
> +1

Another +1 

Paul

PS I think that having implicit 'default' id was always a mistake,
(It makes guessing the section id tricky - something that you often need to
know).

As was indenting always causing going into source.  It looks prettier, but
it causes some hard to trace mistakes - I spent some unhappy time finding
that I had put a single space before [section ], so it was ignored, with a
puzzling report of an excess [endsect] :-(
It's too late to change, but future designers might take note.  I now make
all code sections explicit - and increasingly they are snippets of included
files anyway.