Re: Why does refer(1) have no database field for "edition"?

[G. Branden Robinson]

At 2021-08-02T19:22:05+0200, Tadziu Hoffmann wrote:
> > > Why does refer(1) have no database field for "edition"?
> 
> > The lacuna isn't in refer(1), but in the macro packages using it.
> > Any %c, where c is an alphabetic character, can be used to create
> > a field refer(1) understands.  It is up to macro writers to work
> > out the the formatting and placement within a refer(1) citation or
> > bibliography entry.
[...]
> Sticking it onto the end of the title field is ugly, because
> one might like the title to be printed in italics, whereas the
> edition is "meta information" and should therefore perhaps be
> in the regular font.  Making the macro parse the content of a
> field to extract this kind of information is also unappealing,
> because that is the whole purpose of having different fields
> in the first place.

I just encountered this very problem in writing an "Examples" section
for refer(1), a page so dense it has a reputation for discouraging
people from picking up the tool.  Because I had the temerity to use an
editioned work for my example, I got rewarded with the edition in
italics (as well as the commas bracketing the title, which I think is a
solvable groff ms(7) bug).

> There is also no field for "type" (i.e., article, book, etc.), so
> refer has to infer this information from the presence/absence of other
> fields...

At a glance, the only free _capital_ letters are F, H, M, and U, if we
keep the existing preservation of X, Y, and Z for user extensions.

But I don't see anything calling strcasecmp() or {is,to}{upper,lower}()
in src/preproc/refer or any of the *bib utilities, so it seems we have
26 letters of space for expansion into lowercase.

It's the GNU thing to do!

Regards,
Branden

signature.asc
Description: PGP signature