public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
To: newlib@sourceware.org
Subject: Re: [PATCH 0/1] newlib/libc/time/tzset_r.c(_tzset_unlocked_r): add POSIX <> quoted abbrs
Date: Fri, 18 Feb 2022 22:31:16 -0700	[thread overview]
Message-ID: <db618bb6-3a29-9f2d-899e-c4e1c807d2e5@SystematicSw.ab.ca> (raw)
In-Reply-To: <d9d3b708-74ff-f87f-06df-0be63cc9fd88@dronecode.org.uk>

On 2022-02-18 07:16, Jon Turney wrote:
> On 18/02/2022 03:43, Brian Inglis wrote:
>> On 2022-02-17 05:11, Corinna Vinschen wrote:
>>> On Feb 16 12:18, Brian Inglis wrote:
>>>> On 2022-02-16 01:55, Corinna Vinschen wrote:
>>>>> On Feb 15 22:38, Brian Inglis wrote:
>>>>>> I am inclined to use if defined in order:
>>>>>> *    limits.h TZNAME_MAX
>>>>>> *    unistd.h sysconf(_SC_TZNAME_MAX) if available
>>>>>> *    limits.h _POSIX_TZNAME_MAX
>>>>>> *    6!
>>>>>
>>>>> I'd replace 6 with #error
>>>>
>>>> That's probably for the best - I'll look at adding that to a v2 
>>>> patch set
>>>> including doc update.
>>>>
>>>> What is required to remake newlib libc info and man pages?
>>>
>>> make info / make man?
>>
>> Thanks for the kick!
>> I finally found those targets under build64/newlib/Makefile and got 
>> errors: it looks like python {lxml,ply} need to be manually upgraded 
>> to python39-{lxml,ply} for these to work!
>>
>> Both the updated tzset info and man pages now look awful with a 
>> screenful of run on text!
> 
> That's odd since I would think the viewer should wrap appropriately.

There are now nested lists of fields and definitions which were indeed 
wrapped: into a single run on paragraph with no indentation or breaks, 
so it looks like the makedocbook docs mostly don't apply here!

>> As far as I can see, I can only use blank lines and angle brackets for 
>> formatting, so I will add a whole bunch more of those, retry if they 
>> will now build as part of Cygwin, and see if I can get them to look 
>> much better.
>>
>> If anyone has any pointers to the embedded lib doc header semantic 
>> formatting conventions I would be grateful for those.
> 
> Yeah, this should be described in the documentation section of the 
> 'HOWTO' file, but isn't.
> 
> Briefly:
> 
> '<<' and '>>' mark up function names and code
> '<[' and ']>' mark up formal parameter and variable names
> 
> There are formatting instructions for bullet points, preformatted 
> monospaced text and tables, which are probably best understood by 
> looking at an existing example.

I did get bullet lists working with "*- " prefix which marked with "- " 
but not "*", "* ", "**", "** "!
I used <[...]> and blank lines extensively to provide emphasis which 
mostly works in man pages, but as info pages convert those to uppercase, 
could not distinguish from uppercase literals, so I had to add the 
convention that those are indicated by apostrophe single quotes 'X' in 
both formats, although unnecessary in man pages, while in man format two 
adjacent variable names are concatenated, which I could not separate 
without inserting a visible character, which would be more confusing! ;^<

> In theory, you can also use any texinfo markup, but if you use anything 
> outside the very limited subset currently used and understood by 
> makedocbook.
> 
> Unfortunately, makedocbook relies on the prototypes being marked-up in 
> quite an exact way in order to be able to massage them into the very 
> detailed content model of a docbook funcsynopsis.

I'll browse the other functions to see if I can find more example 
markup, but those constructs look more like what I would expect in guile 
or m4 scripts than makedocbook, which seems natively to be closer to 
restructured text or markdown: I prefer the latter over the former!

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

      reply	other threads:[~2022-02-19  5:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-15 21:57 [PATCH] " Brian Inglis
2022-02-15 22:04 ` [PATCH 0/1] " Brian Inglis
2022-02-16  5:38   ` Brian Inglis
2022-02-16  8:55     ` Corinna Vinschen
2022-02-16 19:18       ` Brian Inglis
2022-02-17 12:11         ` Corinna Vinschen
2022-02-18  3:43           ` Brian Inglis
2022-02-18 14:16             ` Jon Turney
2022-02-19  5:31               ` Brian Inglis [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=db618bb6-3a29-9f2d-899e-c4e1c807d2e5@SystematicSw.ab.ca \
    --to=brian.inglis@systematicsw.ab.ca \
    --cc=newlib@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).