Hi Branden, On 1/4/23 17:05, G. Branden Robinson wrote:
Hi Alex, At 2023-01-04T13:34:59+0100, Alejandro Colomar wrote:v2: * No longer migrates `PP` macros to `P`. * No longer migrates ASCII "arrow" `->` to troff special character.I'd like this change, if you can apply it globally. But we'll leave it for a separate patch set.Yes. I already chased it down. "Globally" affects 2 pages. There is more elaborate ASCII art in sched(7). That can be made relatively pretty with Unicode arrow characters; the four orthogonal single-stemmed arrows even happen to have portable special character identifiers going back to 1976 AT&T troff. But I'm not sure about chewing that one off. Using special character escape sequences would make the source looked weirder and misaligned. There's a way around that (the `tr` request) but that's a fairly chunky breach of the "no *roff requests in man page sources) rule that Ingo Schwarze and I try to hold to. Still, it's worth thinking about whether you'd like to have pic(1) diagrams in the Linux man-pages, with ASCII/Unicode-art fallbacks for terminal devices.
I don't know. Can you show source code and formatted output of some examples, so I can compare?
This more or less corresponds to what we call srcfix (although some might qualify as ffix; the ones you called imprecise).[...]This more or less corresponds to what we call tfix.[...]This more or less corresponds to what we call wfix. wfix can englobe tfix normally.[...]This more or less corresponds to what we call ffix. It might be good to break such changes in two or three separate categories, although sometimes one needs the other, and it's simpler to just apply one patch that does all of them.I will recast my characterizations in the commit messages. I used to know the above categories, but they bit-rotted in my brain due to my feverish rush to get groff 1.23 ready. Context switches are expensive in meatspace, too... Do you continue to practice Michael's indifference to Git's first-line "limit" to commit messages?
Yes. While I try to make subjects short, as anyone else, I don't have any strict rules about it. If the number of files being modified is a bit large, it's easy to go past the 80-col, and I'm fine with that.
However, Michael and I used some abbreviations, such as "Many pages: ...", or "Various pages: ...", and similar, when there were a large amount of pages but the change was a global fix and the page names were completely irrelevant. We used "various" for a smallish number of pages over 10 or so. "Many" was more for things like 500 pages.
I have some pending patches that look like
this.
commit ab218d9f02bcfb9d6c7c127ed90c9a8c34cd8ba5
Author: G. Branden Robinson <g.branden.robinson@xxxxxxxxx>
Date: Wed Jan 4 02:31:37 2023 -0600
adjtimex.2, eventfd.2, mmap2.2, perf_event_open.2, quotactl.2, shmget.2, times.2, drand48.3, ldexp.3, random.3, tgamma.3, proc.5, mount_namespaces.7, random.7, sched.7, tcp.7, udplite.7, units.7, unix.7, utf-8.7: srcfix
You could use "Various pages: srcfix" here.BTW, another thing I noticed you practice is writing a trailing '.' in the subject line. I don't have any strong preference there, but followed the practice of not writing it, as Michael did. It has the advantage of having one more byte for the subject.
I guess you prefer language consistency.
Use correct *roff special character for hat/caret/circumflex accent.
Signed-off-by: G. Branden Robinson <g.branden.robinson@xxxxxxxxx>
Regards,
Branden
Cheers, Alex -- <http://www.alejandro-colomar.es/>
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
