Re: An exercise for the brain(-software) (bug #65474)

Well I clearly failed said exercise, because my brain has no idea what the hell it just read. On Thu, 4 Apr 2024 at 08:48, Bjarni Ingi Gislason wrote: > Give more people a chance to see, think and learn. > > The following is from the groff bug report #65474 > > spurious "warning: unbalanced

Re: The chat bots have come for groff users

dead. There is no future, only underwhelming AI gibberish and inevitable model collapse. On Wed, 28 Feb 2024 at 08:27, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > At 2024-02-28T07:30:37+1100, John Gardner wrote: > > > Terminals support only four font names: R, I,

Re: Macro package loading best practices

ng again. > > > > In the case of those of us who have specialized[2] -ms, it would make > > even more sense to use .mso instead of the command line “option.” > > Our modified package could source s.tmac at the outset. > > I don't have a response to this, except to n

Re: Macro package loading best practices

I tend to begin my documents with the following comment, designed to illustrate for the author what macro packages are used by the document, which preprocessors are needed, etc: .\" uses: -mpdfmark -man -rLL=80 tbl pic eqn I opt for a *descriptive* directive instead of a *prescriptive* one

Re: The chat bots have come for groff users

> > Terminals support only four font names: R, I, B, and BI; the *grotty*(1) > man page says more. Attempting to select any other font name will fail; > like much else in Unix, *roff font names are case-sensitive. *groff* > 1.23.0 started issuing diagnostics upon font selection failure in many

Re: Proposed: simplify `mso` request

Hi Branden, Wouldn't this conflict with behaviour documented in groff_tmac(5)? From the section *"Inclusion"* (emphasis mine): GNU troff offers an improved feature in the similar request “*mso* > *package-file-name*”, which searches the macro path for > *package-file-name*. Because its argument

Re: [TUHS] Re: Original print of V7 manual? / My own version of troff

s for the scan that Branden and I were referring to, I've uploaded a copy to Dropbox <https://www.dropbox.com/scl/fi/xdkq15am4zon6uosbk0m9/CSTR_54_1976.pdf?rlkey=edu8ftqj33klr6lpjcrjlpdxm=0> for you. Cheers, — John On Thu, 18 Jan 2024 at 18:00, Mychaela Falconia wrote: > John Gardner w

Re: Proposed: make \X read its argument in copy mode

> > This assumes you know both the desired font and the desired colour, which > might be defined at other places in the document and not under your control. Yeah, I know. I was trying to gauge how Groff's escape sequences might benefit an \X'…' sequence, and the PostScript I gave was a

Re: [TUHS] Re: Original print of V7 manual? / My own version of troff

> https://usenet.trashworldnews.com/?thread=614089 posted February 1988 > Perl Kit, Version 1.0, Copyright (c) 1987, Larry Wall Excuse my Roff,[1] but holy

Re: [TUHS] Re: Original print of V7 manual? / My own version of troff

, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > Hi John, > > At 2024-01-18T00:43:41+1100, John Gardner wrote: > > I'm a professional graphic designer with access to commercial typeface > > authoring software. Send me the highest-quality and most comprehensiv

Re: [TUHS] Re: Original print of V7 manual? / My own version of troff

ork. *John Gardner wrote yet another [cat2dit] but it's in JavaScript so not > maximally convenient for a Unix command line grognard.* Thanks for reminding me, Branden. :) I've yet to get V7 Unix working with the latest release of SimH, so that's kind of stalled my ability to develop somethin

Re: Proposed: make \X read its argument in copy mode

Hi Branden, So instead of: > \X'ps: \fB\s(12\m[red]big bold red text in my device command\fP' > > one would write: > \fB\s(12\m[red]\X'ps: big bold red text in my device command'\fP I believe you meant to provide an example more like this? \X'ps: exec 1.0 0 0 setrgbcolor /Times-Bold findfont

Re: missing -Tpdf (and the curious case of mandoc_roff(7))

Robinson < g.branden.robin...@gmail.com> wrote: > At 2023-07-30T09:35:28+1000, John Gardner wrote: > [I wrote:] > > > I wonder why mandoc didn't just call its roff(7) page mandoc(7), given > > > that it parallels groff(7) more than anything else. > > > > Strictl

Re: a morsel of groff 1.23.0 status

Bravo to everybody involved!! Seriously, I can't express just how good it feels to see a long-awaited release finally be published to the world. :) On Thu, 6 July 2023, 8:12 am G. Branden Robinson, < g.branden.robin...@gmail.com> wrote: > At 2023-07-05T23:31:54+0200, Bertrand Garrigues wrote: >

Re: notice: intent to diganose use of 'Df'

nds less like an imminent or planned removal. Apart from that, I wholeheartedly endorse making deprecation warnings more obvious and noticeable by users. On Thu, 29 Jun 2023 at 21:39, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > Hi John, > > At 2023-06-29T19:45:1

Re: notice: intent to kill off 'Df'

Hi Branden, Support for 'f' may disappear in the next release, producing an error > diagnostic regarding an unrecognized command. > This doesn't sit right with me. Removing an obsolete feature to encourage adoption of a newer one runs counter to Groff's normative handling of legacy features—a

Re: Mission statement and Knuth-Plass reconsidered

at 09:57, Deri wrote: > On Tuesday, 23 May 2023 23:49:05 BST John Gardner wrote: > > The embedded typeface (both in the original PDF and Deri's version) are > > encoded in Type 1 format. Given the constraints of that particular font > > format, it wouldn't surprise me if the conve

Re: A new ignoramus question about user-installed fonts

Hi Oliver, > message by GhostScript: Can't embed the complete font DFSongStd as it is > too large, embedding a subset > PostScript provides a dedicated resource-type for exactly this: a CID-keyed font (PLRM § 5.11

Re: pdfroff in groff 1.23.0.rc3 changes compared to 1.22.4

> > Yes. Though it contains device-dependent troff output. :-) > Aye, but most folks would find that less confusing than a format named after a fish … ;-) > The ‘dit’ suffix is probably what I've seen the most. > Same, although I personally prefer to

Re: pdfroff in groff 1.23.0.rc3 changes compared to 1.22.4

Hi Branden, > I know I will be mightily tempted to encourage others to adopt the > practice, in large part because "device-independent [gt]roff] output" is > far too long to type or speak repeatedly. I've always just called it "ditroff" (*"device-independent troff [output]"*), with *.dit and

[bug #63812] Discussion of conditional expressions in docs should mention `.if h`

Follow-up Comment #9, bug #63812 (project groff): [comment #8 comment #8:] > This would be a simple iterator. The string named "s" takes on the value of each item in string-expr from left to right. How is string-expr tokenised? Is its value treated like a whitespace-delimited list (following the

[bug #63812] Discussion of conditional expressions in docs should mention `.if h`

Follow-up Comment #7, bug #63812 (project groff): [comment #6 comment #6:] > Long stories short, I want a `for` request that will iterate over macros/strings/diversions Interesting. Does it resemble this

[bug #63812] Discussion of conditional expressions in docs should mention `.if h`

Follow-up Comment #5, bug #63812 (project groff): [comment #4 comment #4:] > Here's what I have at the moment. Looks good. One nanoscopic nitpick, which borders on bikeshedding: > and GNU @code{troff} may provide additional operators in the future. The projected likelihood of introducing such a

Re: [Optional] versus parameters

hn, > > I think I can speak to this. > > At 2023-02-22T16:24:33+1100, John Gardner wrote: > > What's the recommended convention for marking up *required* arguments? > > Square brackets indicate optional arguments more often than not, and > > something like this is ambiguous t

[Optional] versus parameters

What's the recommended convention for marking up *required* arguments? Square brackets indicate optional arguments more often than not, and something like this is ambiguous to readers: *upgrade* | *update* *package* This could be interpreted in two different ways (expressed using BNF): :=

Re: groff 1.23.0.rc3 available for testing

.4..1.23.0.rc3 > 14 Bertrand Garrigues > 14 Bjarni Ingi Gislason > 6 Colin Watson > 1 Cynthia A. E. Livingston > 1 Damian McGuckin > 30 Dave Kemper > 28 Deri James > 2 Dorai Sitaram > 1 Edmond Orignac > 1 Eri

Re: rc3: groff man pages truncated by mandoc(1)

Hi Branden, > If I could do something like the following: > > .if \n[.mandoc] .als MR IR > To determine if mandoc(1) is being used to format the current page, use .if \n(.f=0 This is what Mono.tmac

[bug #63768] want configurable URL format for man page hyperlinks

Follow-up Comment #18, bug #63768 (project groff): [comment #17 comment #17:] > Please review this patch. Works like a charm. However, the inline comments could use some rewording. Here's an amended patch: diff --git a/tmac/an.tmac b/tmac/an.tmac index 917739199..581374789 100644 ---

[bug #63768] want configurable URL format for man page hyperlinks

Follow-up Comment #16, bug #63768 (project groff): > I think you are, as I'm trying to avoid etching this register's name, or even its existence, in stone. Grouse, now we're on the same page. ;-) > It's just SSH access, to a machine in a build farm somewhere in Europe; I did not imagine that

Re: A version of fmt for troff files

> > https://en.roquesor.com/Downloads/fmtroff.c > Missed opportunity to call it "roffmt". ;-) Anyway, I fed the program a macro package with the -n switch passed, and it... basically mangled the entire file. I take it that fmtroff is only designed to format prose, rather than Roff code (macros,

[bug #63768] want configurable URL format for man page hyperlinks

Follow-up Comment #14, bug #63768 (project groff): [comment #13 comment #13:] > I wouldn't say "adamant"...but pretty resolved on letting groff > 1.23.0 gather some feedback on the feature. Do you mean feedback on the 'an*MR-URL-format' register? What if you end up having to ditch it? It

[bug #63812] Discussion of conditional expressions in docs should mention `.if h`

Follow-up Comment #3, bug #63812 (project groff): [comment #2 comment #2:] > That's documented because we _do_ support it. If we didn't, the 'v' would be treated as the opening delimiter of a formatted output comparison operation, just like other letters that aren't conditional operators. Ah

[bug #63812] Discussion of conditional expressions in docs should mention `.if h`

: None ___ Follow-up Comments: --- Date: Fri 17 Feb 2023 03:55:09 PM AEDT By: John Gardner Plan 9 (and by extension, plan9port and 9front <http://9front.org>) include a utility called htmlroff <https://

[bug #63768] want configurable URL format for man page hyperlinks

Follow-up Comment #12, bug #63768 (project groff): If you're adamant about keeping the current approach, then I recommend that you enumerate the supported URL formats in their order of priority: * man:grep(1) * x-man-page://1/grep * man:grep.1 * x-man-doc://1/grep Moreover, I'd begin counting

Re: macOS Terminal man page URL format

is why I suggested they be *un*set before running the tests. You may have misread what I wrote… ;-) — J On Thu, 16 Feb 2023 at 15:44, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > At 2023-02-16T15:34:57+1100, John Gardner wrote: > > > ...wait. Did you configure

Re: macOS Terminal man page URL format

ning the tests, which is How I'd Do It™. On Thu, 16 Feb 2023 at 15:30, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > Hi John, > > At 2023-02-16T15:09:06+1100, John Gardner wrote: > > Many thanks. All but one of the tests are passing now, which is the > >

Re: macOS Terminal man page URL format

uite 2022-06-07 foo(1) checking that SB macro uses correct input trap 'it' ...FAILED foo(1) General Commands Manual foo(1) B10R10 groff test suite 2022-06-07 foo(1) — John On Tue, 14 Feb 2023 at 13:59, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > Hi John, > > At

[bug #63768] want configurable URL format for man page hyperlinks

Follow-up Comment #11, bug #63768 (project groff): [comment #10 comment #10:] > I didn't want to over-engineer this feature, as I feel it is a band-aid. Then why support two highly obscure URL schemes (formats 2-3) that were only ever used by third-party software unaffiliated with Apple, none of

[bug #63768] want configurable URL format for man page hyperlinks

Follow-up Comment #9, bug #63768 (project groff): I still would've preferred a simpler and more supple solution, such as .ds1 man-scheme-format man:\\$1(\\$2)\" .ds1 man-scheme-format x-man-page://\\$2/\\$1\" \*[man-scheme-format printf 3] ... with the default value varying depending on

Re: [bug #63768] want configurable URL format for man page hyperlinks

ich produces working links in iTerm (Terminal.app doesn't support OSC 8 yet). Both links behave as expected when they're clicked. On Sat, 11 Feb 2023 at 11:48, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > Hi John, > > Savannah seems to be down so I'm replying dir

Re: "make check" failing on macOS (was: macOS Terminal man page URL format)

l.com> wrote: > Hi John, > > At 2023-02-11T10:19:08+1100, John Gardner wrote: > > Yes, it builds successfully now (macOS 12.6.3). I ran `make install` > > and the installed Groff seems to be working perfectly. > > Excellent! > > > However, when I ran `make check`

[bug #63768] want configurable URL format for man page hyperlinks

Follow-up Comment #6, bug #63768 (project groff): [comment #5 comment #5:] > Waiting on feedback from John. Refresh my memory: what do you need feedback on, again? ___ Reply to this item at:

Re: macOS Terminal man page URL format

register a different app, although the procedure appears complicated (and I've yet to read up on it myself: it's on my to-do list under *"Weaponise lsappinfo(8)"*). On Tue, 7 Feb 2023 at 08:03, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > Hi John, > > At 2023-02-07T07

Re: macOS Terminal man page URL format

3 at 06:55, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > Hi John, > > At 2023-02-07T06:26:22+1100, John Gardner wrote: > > Then how about a callback? It could be called with the relevant > > parameters, and authors can use plain ol' Roff to specify the &

Re: macOS Terminal man page URL format

6, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > Hi John, > > At 2023-02-06T18:53:10+1100, John Gardner wrote: > > While I *strongly* advocate for the man:name(section) syntax (because > > it essentially dates right back to the earliest man pages), it woul

[bug #63768] Configurable URL scheme for man page hyperlinks

Follow-up Comment #2, bug #63768 (project groff): > It really looks to me like macOS doesn't have its story straight here. Sorry, I probably could've expressed those scheme variants better: those are various other man-page URL schemes invented by authors over time: * Bwana is a standalone man

[bug #63768] Configurable URL scheme for man page hyperlinks

: None ___ Follow-up Comments: --- Date: Mon 06 Feb 2023 07:36:59 PM AEDT By: John Gardner On macOS, a non-standard URL scheme <https://github.com/donmccaughey/ManOpen/blob/04cfb7567a8dd6c9ed286ab6a3dd1a69183d259d/Documentat

Re: macOS Terminal man page URL format

> > And since it's specific to the macOS Terminal application It's indicative of a much larger issue — there's no formal, standardised scheme for man page URLs. I encountered many variants

[bug #63767] Build failure on macOS 12.6.3

mments: --- Date: Mon 06 Feb 2023 05:51:19 PM AEDT By: John Gardner I downloaded groff-1.23.0.rc2.tar.gz from GNU's alpha FTP site (https://alpha.gnu.org/gnu/groff/), but encountered an unfamiliar build failure pertaining to vasnprintf.c:

Re: groff 1.23.0.rc2 available for testing

> > The an (man) macro package can now produce clickable hyperlinks within > terminal emulators It might be worth clarifying for macOS users that the hyperlinks use a protocol incompatible with Apple's: “*man:printf(3)*” is used instead of “ *x-man-page://3/printf*” (the latter scheme is ancient

Re: .ab oddity

> > Something I recommend to all serious Unix users is to put the exit status > in the shell prompt. Alternatively, you can indicate a non-zero exit status by displaying a prompt symbol in a different colour than usual. This might be preferable for folks who prefer fixed-width and/or minimalist

Re: Inline TTY Pixel Rendering. (Was: groff 1.23.0.rc2 status report)

> > Sounds like it's up John Gardner's alley. :-) Actually, I think displaying multimedia within a character-based display is the second-wankiest thing people have managed to do with their terminal ( Browsh being the first). My own prejudices aside, this would be easy to

[bug #63527] [mdoc] .Nm duplicates parameters from supplementary calls in "NAME" section

Follow-up Comment #4, bug #63527 (project groff): Ie I had a dollar for every time I got those

[bug #63527] [mdoc] .Nm duplicates optional parameter in "NAME" section

ed Release: None ___ Follow-up Comments: --- Date: Thu 15 Dec 2022 10:06:18 AM AEDT By: John Gardner Using the latest build of Groff (94746cbd4), I'm seeing duplicate output in man pages whose _"NAME"_ secti

Re: Online Dictionaries. (Was: words (and commands) that I learnt...)

> > Wiktionary […] isn't too hard to edit once you've made one or two changes. > I know , don't worry. ;-) Wiktionary often gives translations, is multi-lingual, though they quite > rightly put English first :-), and isn't too hard to edit once you've

Re: Dynamic Paperlength for PS or PDF device

> > May as well be precise with 21c and 29.7c? Shit, did I really give A4 in Freedom Units™? My bad. I'm pinning this on sheet sleep deprivation and football fever. Staying up to 2:00am AEDT to watch the World Cup, then another at 6:00am—several times a week—has me running on fumes. I have 4.5

Re: words (and commands) that I learnt because of Branden

> > Actually, "horde" and "hoard" are homophones FFS, I keep getting those spellings mixed up. Thank you. :D On Sat, 10 Dec 2022 at 21:29, Robert Marks wrote: > Actually, "horde" and "hoard" are homophones, but one is a noun and the > other a verb: > "I use to horde definitions" > > Robert

Re: words (and commands) that I learnt because of Branden (was: preferred /proc//xxx style?)

> > Your emails are the reason I know and often use dict(1). Lol. Branden's e-mails are the reason I consult the Oxford English dictionary far more often than I'm comfortable admitting. Either I'm learning obscure words I know I'll never remember when I need them,[1] <#snarky-footnote-1> or

Re: Dynamic Paperlength for PS or PDF device

> > so here is my solution: > the last line of my groff script is: > ".tm \\n[nl]" > This shows me the page length in groff units. > For convenience I put it in a footer macro. Does this help…? .de *pagesize* \" $1 = width, $2 = height \\!x X papersize=\\$1,\\$2 .ll \\$2u-\\n(.o .pl \\$1 .. .

Re: Why isn't the device resolution exposed to the formatter?

> an *embolus* in my brain $ echo "embolus" >> ~/Words-that-Branden-taught-me.txt $ cat $_ inimical, inimicable: harmful; hostile sesquipedalian: having too many syllables irascible: easily pissed at shitty UX indefatigable: incapable of tiring out internecine: mutually destructive apodictic:

[bug #63377] [mdoc] .Nm emits warning instead of content

Follow-up Comment #4, bug #63377 (project groff): > Here's a patch. Works like a charm! $ groff -Tutf8 -mandoc -Wall `man -w NotificationCenter` NotificationCenter(8) System Manager’s Manual NotificationCenter(8) NAME NotificationCenter — Notification Center service for

[bug #63377] [mdoc] .Nm emits warning instead of content

: None ___ Follow-up Comments: --- Date: Thu 17 Nov 2022 09:44:57 PM AEDT By: John Gardner The '.Nm' macro has stopped working with recent builds of Groff: $ groff -Tutf8 -mandoc -Wall `man -w NotificationCenter` Usage: .Nm name .

Re: [groff] 15/39: [grog]: Drop relic code and comments.

> > Perl 5.6.1 is incredibly old (April 2001). I cannot find any evidence of > any current distribution supporting it. IIRC, declaring a program version is recommended practice, as future versions of Perl may have different defaults w.r.t opt-in behaviours like `use warnings` and `use strict`.

[bug #62860] [gropdf] trying to access URW fonts from wrong directory

Follow-up Comment #21, bug #62860 (project groff): [comment #20 comment #20:] > The file I am interested in seeing is /usr/local/share/groff/site-font/devpdf/download. As mentioned in [comment #17 comment #17], the `/usr/local/share/groff/site-font` directory doesn't exist. However, I only just

[bug #62860] [gropdf] trying to access URW fonts from wrong directory

Follow-up Comment #19, bug #62860 (project groff): [comment #18 comment #18:] > Please could you attach the file /usr/local/share/groff/site-fonts/download. I already did; see file #53823 ___ Reply to this item at:

[bug #62860] [gropdf] trying to access URW fonts from wrong directory

Follow-up Comment #17, bug #62860 (project groff): > Please check your copy of download in the site-font directory to see if it contains the stale paths. All of the paths referenced by `font/devpdf/download` point to font files. Also, concerning environment variables: the directory referenced

[bug #62860] [gropdf] trying to access URW fonts from wrong directory

Follow-up Comment #12, bug #62860 (project groff): Yes, the build now ends with: gropdf:contrib/mom/examples/typesetting.mom: fatal error: unable to open font '/usr/local/Cellar/ghostscript/9.56.1/share/ghostscript/9.56.1/Resource/Font/C059-Roman' for embedding GROFFdoc/meref.me GROFF

[bug #62860] [gropdf] trying to access URW fonts from wrong directory

Follow-up Comment #10, bug #62860 (project groff): Done. Attached are the files you requested (I forgot about the file-attachment feature…) (file #53823, file #53824, file #53825, file #53826) ___ Additional Item Attachment: File name:

[bug #62860] [gropdf] trying to access URW fonts from wrong directory

Follow-up Comment #8, bug #62860 (project groff): Neither the presence nor absence of `--with-urw-fonts-dir` had any bearing on the build. I've nonetheless uploaded logs from both build attempts: * Without option: https://gist.github.com/Alhadis/67fccae66e5e636e71fe68ee6991a2d6 * With

Re: groff 1.23.0.rc2 readiness

> > As you are the most active developer, would you consider taking over the > maintainership of groff? > Please, please, *please* let that be a "yes"… On Mon, 22 Aug 2022 at 07:14, Bertrand Garrigues via wrote: > Hi Branden, > > On Wed, May 25 2022 at 10:56:37 PM, "G. Branden Robinson" < >

[bug #62918] Wrong GhostScript version reported during build

Follow-up Comment #5, bug #62918 (project groff): [comment #4 comment #4:] > [this] needs to be looked into before 1.23.0 finalizes. @Branden: Is there anything else you need from me? ___ Reply to this item at:

[bug #55108] busgrap: New pre-processor for business charts

Follow-up Comment #5, bug #55108 (project groff): I know I'm bikeshedding, but the name _"business graphics"_ is vague enough to evoke _Corporate Memphis_ instead of anything chart-related. Wouldn't _"chart"_ be a more self-documenting umbrella name? "Chart" and "graph" are confusable terms, but

[bug #62918] Wrong GhostScript version reported during build

: None ___ Follow-up Comments: --- Date: Fri 19 Aug 2022 09:45:45 PM AEST By: John Gardner Whilst building Groff from the latest upstream changes (macOS Monterey 12.5.1): gropdf:contrib/mom/examples/typesetting.mom:

Re: One Page Dungeon Layout in groff?

This is what pic(1) is for: # Long version $ pic < dungeon.roff | troff -Tpdf | gropdf > map.pdf # Concise version (recommended) $ groff -p -Tpdf dungeon.roff > map.pdf If you're new to pic(1), there's a browser-friendly (albeit limited)

Re: Is it possible to detect `grotty -i` at runtime?

f(1) open at the same time. groffy(1), if you will. Apologies for the retarded e-mail. This hasn't been one of my finer moments. — J On Fri, 22 Jul 2022 at 11:09, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > Hi John, > > At 2022-07-22T07:29:48+1000, John Gardne

Is it possible to detect `grotty -i` at runtime?

I'm looking for a way to harden my .UL (underline) macro against grotty(1) v1.23's new -i switch, which causes italicised text to be rendered with actual italics (in TTYs that support SGR 3, at

Re: Warn on semantic newlines

> > AI is a bane of formatting. It's getting better. Though I still prefer smart practices and dumb programs,

Re: [TUHS, groff] 1981 edition of AT Nroff/Troff User's Manual

> > Since PDF didn't exist in 1981, the document is either a scan or the > result of a recent *roff run on ancient source. > It's most definitely a scan. Magnifying the pages reveals dust, surface details (grain and creases), and shadow falloff around the holes and edges. Each page is also titled

Re: Zero Width Space

> > What about "input escape" Copy+pasta from my earlier post to a concurrent discussion in another thread: s/input escape/control suppressor/gi s/input escape/command suppressor/gi (This discussion appears to have been split

Re: groff man(7) `B` macro behavior with `\c`, and input traps

> > And to allude to an another conversation we are currently having, > including those that contain nothing but "\&", but *not* those that are > completely empty, which would make you think that "\&" is a "zero-width > non-breaking space" or a "zero-width non-printing character" rather than >

Re: Setting up repository for user macrosets

> > I was recently thinking of creating one of those "awesome lists" for *roff > resources. I have quite a few tagged bookmarks to go through.. Naming it awesome-roff and tagging it with the awesome-list or awesome

Re: groff 1.23.0.rc2 readiness

; I've given in and taken to calling it "ditroff" informally, even though I know damn well that it's a misappropriation. > . > On Sat, 28 May 2022 at 08:51, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > Hi Johm, > > At 2022-05-27T11:04:52+1000, John Gardner wro

Re: groff 1.23.0.rc2 readiness

y. If you still decide to go ahead: Don't say I didn't warn you. On Fri, 27 May 2022 at 01:23, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > Hi John, > > At 2022-05-27T00:38:31+1000, John Gardner wrote: > > Please consider #62494 <https://savannah.gnu.org/bugs/?62

Re: groff 1.23.0.rc2 readiness

Hi Branden, I'm running out of things I can think of to do before RC2. > Please consider #62494 ASAP. Otherwise, it's going to piss a lot of users off. Regards, — J On Thu, 26 May 2022 at 13:56, G. Branden Robinson < g.branden.robin...@gmail.com> wrote:

Re: A Modern Typesetting Language. (Was: .TQ to replace .PD 0)

Hi Ralph, Or at best, gives it through some clunky ‘treat it as a string’ mechanism. > How is that clunky? Text is text. It's opaque, honest, and universal. The foundation of the Unix Philosophy… you know this as well as I do. ;-) One could look at shoehorning evermore complexity through to the

Re: .TQ to replace .PD 0

Hi Ralph, > Support of modern font technologies and of course languages which aren't left-to-right. Agreed. But for everything else you've mentioned: it's just a matter of writing another PDF postprocessor (or some other adapter for a particular format). Postprocessors are where the real beauty

[bug #62494] [grotty] Remap ~ and ^ to their ASCII equivalents

Follow-up Comment #2, bug #62494 (project groff): [comment #1 comment #1:] > It also puts additional stress on manual page writers, who are often programmers with no particular interest in typesetting That argument also goes both ways: programmers with an interest in typesetting should know

[bug #62494] [grotty] Remap ~ and ^ to their ASCII equivalents

Additional Item Attachment, bug #62494 (project groff): File name: glyph-comparison.png Size:20 KB ___ Reply to this item at:

[bug #62494] [grotty] Remap ~ and ^ to their ASCII equivalents

: None ___ Follow-up Comments: --- Date: Sat 21 May 2022 03:34:14 AM AEST By: John Gardner In Groff 1.22.4, tildes and carets are respectively rendered in man pages as ~ <https://graphemica.com/%7E>

[bug #62357] [build] tests using "locale charmap" skipped on macOS

Follow-up Comment #16, bug #62357 (project groff): [comment #15 comment #15:] > Please try the attached patch and let me know if the test passes after applying it. That seemed to do the trick! I've attached the build log. (BTW, I remembered I still had a /usr/local/share/groff from a previous

[bug #62357] [build] tests using "locale charmap" skipped on macOS

Follow-up Comment #14, bug #62357 (project groff): [comment #11 comment #11:] > The problem is a divergence between Linux 'od -c' output and macOS (BSD?) 'od -c' output. Except I haven't heard any complaints from Ingo, so this may be a true macOS-ism. This might make your life easier:

[bug #62357] [build] tests using "locale charmap" skipped on macOS

Follow-up Comment #10, bug #62357 (project groff): Strange, I'm not seeing a "./build" directory after building. Instead, each of the executables are merely dumped into the checkout's root directory. Here's the output of `git status --ignored` in case it helps to elucidate which build directories

[bug #62357] [build] tests using "locale charmap" skipped on macOS

Follow-up Comment #6, bug #62357 (project groff): [comment #5 comment #5:] > What does the command "locale charmap" produce on your system? "UTF-8". Running `locale` without arguments gives: LANG="en_AU.UTF-8" LC_COLLATE="en_AU.UTF-8" LC_CTYPE="en_AU.UTF-8" LC_MESSAGES="en_AU.UTF-8"

[bug #62357] [build] Test suite failure on macOS

Follow-up Comment #3, bug #62357 (project groff): Sorry for the slow response, I haven't been very good at getting onto the computer later. I reran the tests without a LANG environment variable set. Strangely, none of them failed; a few were skipped instead: # TOTAL: 115 # PASS: 108 # SKIP:

[bug #62357] [build] Test suite failure on macOS

Follow-up Comment #4, bug #62357 (project groff): > getting onto the computer later. *lately, not later. (How does one edit comments on this site?) ___ Reply to this item at:

Re: traveling for a few days

at 20:15, Bertrand Garrigues < bertrand.garrig...@laposte.net> wrote: > Hi John, > > On Sun, Apr 24 2022 at 04:39:57 AM, John Gardner > wrote: > > On macOS, Groff builds and installs perfectly from a fresh checkout > (currently using > > f55d8f41). > > >

[bug #62357] [build] Test suite failure on macOS

URL: Summary: [build] Test suite failure on macOS Project: GNU troff Submitted by: alhadis Submitted on: Mon 25 Apr 2022 12:08:08 AM AEST Category: Device - others/general

Re: traveling for a few days

On macOS, Groff builds and installs perfectly from a fresh checkout (currently using f55d8f41). However, running `make check` produced 6 failing tests: FAIL: src/devices/grotty/tests/basic_latin_glyphs_map_correctly.sh > XFAIL: src/roff/groff/tests/string_case_xform_unicode_escape.sh > XFAIL

[bug #62233] [doc] Stop referring to Roff as a group of languages

Follow-up Comment #5, bug #62233 (project groff): I've no idea why Savannah ate 90% of that comment... How the hell do you post a multiline comment on this thing? ___ Reply to this item at:

[bug #62233] [doc] Stop referring to Roff as a group of languages

Follow-up Comment #4, bug #62233 (project groff): Let's be practical. Users know Roff when they see it: a backslash-laden markup language punctuated by directives that begin with a full-stop or apostrophe at the very beginning of a line, often with terse, cryptic-looking names. This description

  1   2   3   4   >