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

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

[Douglas McIlroy]

Another issue I have run into is recursion, when a reference includes
another reference. This comes up in various forms:
     Also published as ...
     Errata available at ...
     Summarized [or reviewed] in ...
     Preprint available at ...
Often such a reference takes the form of a URL or a page in a journal
or in a proceedings. This can be most succinctly placed in situ --
formatted consistently with other references. If the reference
identifies an alternate mode of publication, it may lack %A or %T
fields.

Partial proposal. a %O field may contain a reference, with no further
recursion, The contained reference will be formatted in line in the %O
text unless references are accumulated and the  contained reference is
not unique.

Doug

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

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 2403 bytes --]

So many groff discussions get re-routed to TUHS thanks to Doug's MUA. :)

At 2021-08-02T19:38:42-0400, Douglas McIlroy wrote:
> Another issue I have run into is recursion, when a reference includes
> another reference. This comes up in various forms:
>      Also published as ...
>      Errata available at ...
>      Summarized [or reviewed] in ...
>      Preprint available at ...
> Often such a reference takes the form of a URL or a page in a journal
> or in a proceedings. This can be most succinctly placed in situ --
> formatted consistently with other references. If the reference
> identifies an alternate mode of publication, it may lack %A or %T
> fields.
> 
> Partial proposal. a %O field may contain a reference, with no further
> recursion, The contained reference will be formatted in line in the %O
> text unless references are accumulated and the  contained reference is
> not unique.

This would tighten the existing semantics of %O, would it not?  Maybe
that's not a problem, since it's already defined as a dumping ground[1].

So if I understand you and the GNU refer(1) manual correctly, %O would
be parsed for a pair of brackets[2] containing keywords only (no
fields), and if that resolved to a single reference, the label for that
reference would be interpolated.  That of itself would be sufficient to
halt the recursion.

Here's an example of what this sort of thing looks like today, _without_
adding this feature to %O[3].

$ cat EXPERIMENTS/my-db-file-for-doug
%A Daniel P.\& Friedman
%A Matthias Felleisen
%C Cambridge, Massachusetts
%D 1996
%I The MIT Press
%T The Little Schemer, Fourth Edition
%O Reviewed in [posterior analytics 36]
$ REFER=EXPERIMENTS/my-db-file-for-doug ./build/test-groff -R -Tutf8 \
 -ms EXPERIMENTS/scheme.ms | cat -s

Read the book[1] on your  summer  vacation.   Commentary  is
available.*

───────────
  [1] Daniel  P.  Friedman  and Matthias Felleisen, The
Little Schemer, Fourth Edition,  The  MIT  Press,  Cam‐
bridge,  Massachusetts  (1996).  Reviewed in [posterior
analytics 36].
  * Space reserved for penetrating insight.


Regards,
Branden

[1] "Other information.  This is usually printed at the end of the
    reference."
[2] could be anything non-keywordy, but brackets seem like a good choice
[3] ...and a nickel goes into the "cat -v swear jar".

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]