Re: Groff macro to make .UR and .UE links clickable in PDF?

Steve's list left out one other URL-handling strategy: omit them altogether if they aren't needed: *HTML:* https://tools.ietf.org/html/rfc6455;>RFC 6455 https://adobe.com/content/dam/acom/en/devnet/actionscript/articles/PLRM.pdf#page=144;>PostScript Language Reference Manual, page 130 *Text:*

Why are Groff's macro packages not PDF-aware by default?

When preparing PDF output, Groff will automatically load PDF-specific macro packages (such as pdfmark.tmac). I'm wondering why man(7), mdoc(7) and friends aren't leveraging PDF features like outlines and clickable links. For example, headings and subheadings should logically generate an outline

Re: documentation of hyphenation

Why are we using Info, again? Was it because of GNU policy? Or is there a more compelling reason as to why we're maintaining two different versions of the same documentation? On Sun, 14 Jun 2020 5:42 am Doug McIlroy wrote: > groff(7) doesn't tell what the hyphenation modes are. > It directs you

Re: [groff] 01/01: preconv: Support Emacs coding tags at file ends.

> A non-Unix text editor which liked to do things its way, e.g. the > three-byte ‘foo’ is a text file. Putting how to read a file at the end > of that file is such a daft idea when placed in a Unix context; it's > alien and should not be encouraged. That's an oversimplification. And Vim does

Re: Potential enhancements to install-font.sh from https://www.schaffter.ca/mom/bin/install-font.sh

> You don't even have to learn the details of the escape codes with their > inscrutable syntax an unmemorizable numerical codes. I'm sorry, \x1B[4;1mwhat?\x1B[24;21m On Thu, 30 Apr 2020 at 07:55, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > At 2020-04-29T17:04:31-0400, James K.

Re: Proposed: drop groffer (was: contrib/groffer/roff2.1.man)

> Does anyone object to just deleting groffer? Terminate with extreme prejudice. IMHO, anything that can be achieved with an alias or shell one-liner really doesn't warrant its own executable. On Tue, 21 Apr 2020 at 22:32, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > Hi Ingo! >

Re: [PATCH] new .cp register; was: Possible regression with `groff -C`

, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > Hi, John! > > First, let me address your lingering point. > > At 2020-04-12T13:34:04+1000, John Gardner wrote: > > Wouldn't it be simpler to inline the contents of unicode.tmac? Only > > two other macro pa

Re: Pop quiz: How do YOU .do?

Wouldn't it be cool if we could just .nr _C \n(.C . .\" Rename the `cp` request to something inane .rn cp ^GC \" Here, ^G means U+0007 . .de cp . ie'+1'\\$1' .nr _C \\n(_C+1 \" +1: Begin new level . el \{ .ie '-1'\\$1' .nr _C \\n(_C-1 \" -1: End current level . el

Re: What is the difference between GNU groff and Mac OS X groff

mac groff". > groff is GNU roff, by definition. > Mac just ships with an ancient version of that. > > > > On 4/12/20, John Gardner wrote: > > > Use Homebrew <https://brew.sh/> to install the latest version of > Groff: > > > > > > $ brew ins

Re: What is the difference between GNU groff and Mac OS X groff

Use Homebrew to install the latest version of Groff: $ brew install groff For a full-blown setup: $ brew install groff ghostscript grap less $ brew tap alhadis/troff $ brew install alhadis/troff/man-db dformat > so if you care about up-to-date software, use a different

Re: Possible regression with `groff -C`

> At 2020-04-12T12:40:38+1000, John Gardner wrote: > > > Any lurking experts have any suggestions? > > > > From a glance, it looks like the `.C` register is being set twice: once > by > > the calling tty.tmac, and again by unicode.tmac. If I comment out a few >

Re: Possible regression with `groff -C`

] .char ` \[oq] .char ' \[cq] .\" .cp \n[_C] ... it suddenly works. On Sun, 12 Apr 2020 at 11:52, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > At 2020-04-12T11:12:32+1000, John Gardner wrote: > > After building Groff from master, I noticed one of Roff.js's r

Possible regression with `groff -C`

After building Groff from master, I noticed one of Roff.js's regression tests failed when asserting compatibility mode: *Command:* printf '.ds FOO BAR\n\\*[FOO]' | groff -C -Tutf8 | head -n1 *Expected output:* FOO] *Actual output:* BAR This only started happening since I installed a

Re: weird \s

I agree with Tadziu. Along with .cc and .c2, the .ec request opens up a world of creative (ab)uses that reward clever thinking. On Sat, 4 Apr 2020 at 03:25, Tadziu Hoffmann wrote: > > > In that light, inventing .ec was a terrible language design > > mistake that should never have been

Re: eqn sqrt and pdf?

wrote: > hello John and thanks for helping, > > On Fri, Feb 21, 2020 at 08:47:18PM +1100, John Gardner wrote: > > Even without seeing the PDF output, I'd say you have one or more fonts > > missing from your installation path. Do you have GhostScript installed? > > $ a

Re: eqn sqrt and pdf?

Hi Marc, Even without seeing the PDF output, I'd say you have one or more fonts missing from your installation path. Do you have GhostScript installed? Also, you can debug formatted output by calling groff with its -Z switch. You should see something like this: $ eqn -Tpdf | groff -Tpdf -Z x T

Re: man Macro Package and pdfmark

> ??? Have you actually used stand-alone `info` recently? In its > standard configuration, you only need the arrow keys together with the > enter key to navigate. That's not what I'm talking about. In Emacs, I'm used to smashing `c-h o` to bring up the documentation for the symbol at point. In

Re: man Macro Package and pdfmark

> The info stuff alienates anyone who is not an emacs fan I'm an Emacs fan, and I also find the Info system abhorrent and confusing. It's a different story if you're using Emacs, because the Info system is well-integrated and as easy to navigate as any other buffer (and most Emacs users will have

Re: she's it, not her ...

I once had a macro package named "My Ugly Macros", or "MUM" for short. It was a tongue-in-cheek reference to this package (though I ended up renaming it to "mono" instead; all I wanted was a package starting with "m". Because, you know, acro-package naming traditions). On Fri, 7 Feb 2020 at

Re: [groff] 02/07: **/*.man: Put subsection heads in sentence case.

> and maybe even a bit dated (though not being a native speaker, i may > be wrong about the latter). Title-case isn't dated, but it *is* difficult to enforce consistently when various style-guides differ in their opinions of what words to capitalise. In general, articles, prepositions, and

Re: hdtlb and \n[nl] register

Hi Sebastien, This doesn't solve the problem of the \n[nl] register, but you might want to check out pic(1). It's good for complex drawing and might be a better solution than hdtbl for drawing calendars. Regards, — John On Wed, 8 Jan 2020 at 15:48, Bjarni Ingi Gislason wrote: > On Tue, Jan

Re: Testing groff. Was: GNUism in groff tests

> and they don't have to be unit tests. In some ways, that's the worst > option because they tend to be trivial functions being tested Nobody's saying they should *all* be unit-tests. It's better to test components in isolation first, verify they do what they're supposed to, then follow up with

Re: GNUism in groff tests, was: pic anomalies

> For some standards, clarifying which one you want to follow can > be a tough problem (e.g. CSS, anyone?) CSS isn't one standard, but a family of standards . Each of which has varying levels of maturity, and only those that are listed as

Re: GNUism in groff tests, was: pic anomalies

> I've just read the specification and I don't think it buys us much. I wasn't suggesting TAP so much as recommending Perl's prove(1) for handling unit tests. It eliminates portability headaches and issues with Bashisms , and is pretty time-tested as far as

Re: GNUism in groff tests, was: pic anomalies

> As long as these tests use bash(1), i'm very reluctant to do that, > even though in general, running a test suite certainly makes sense > before you commit a package update. Given the so far very small > test coverage, the tests don't help much for package testing yet. > Then again, that is

Re: Two questons: Norwgegian characters and space when switching typeface

> In *roff languages Just to clarify, Roff and TeX are similar in that their macro packages are sometimes regarded as separate languages, especially if the macros themselves are written like a DSL of sorts. mdoc(7) is a noteworthy example of this. When learning to use Groff for the first time,

Re: Two questons: Norwgegian characters and space when switching typeface

> First question is on Norwegian characters: ø, å, and æ. It seems that > I cannot type them as plain text, because the produced PDF file gives > funny output. Files which contain Unicode characters need to be pre-processed with preconv(1). You can achieve this by running groff(1) with the `-k`

Re: [groff] A poor mans Excel

That reminds me of an idea for a preprocessor I had called xtbl, which could convert between common plain-text table formats... tbl(1), TSV, rST / Markdown, and HTML. > Code size: 130 lines of perl Show us the code and I'll see how far I can golf it down for you. :D On Thu, 10 Oct 2019 at

Re: [groff] groff + PDF/A?

Hi Paul, No, it doesn't. If PDF/A compliancy is a concern, you could try rendering to PostScript and using a program like GhostScript or Adobe Distiller to generate a PDF (which may or may not have an option to generate PDF/A-compliant documents). There are also multiple levels of conformance

Re: [groff] Of grog, preprocessors, and missing programs

> So it all works as is now you've written the code, you're just pointing > out that grog's current behaviour meant you had to take this route? I was basically explaining how this could be an issue instead of a minor annoyance. In my particular case, I need to support multiple Groff versions, so

Re: [groff] Of grog, preprocessors, and missing programs

> loadVersion()'s regexp can be simplified because `xx*' is `x+'. :-) Well-spotted refactoring error, thank you. ;-) > I didn't read all the way through that page and ended up skimming it. > You use grog if it's available, falling back on your own logic to > analyse the troff source. The

[groff] Of grog, preprocessors, and missing programs

I've noticed that grog(1) will suggest options for preprocessors irrespective of whether they're even available on the user's system. Some aren't part of Groff, like grap(1). Others are excluded from certain base installations — Ubuntu Server, for example, ships with pic(1) and tbl(1), but omits

Re: [groff] groff and pipes

> Creating a new file in Emacs with a line of ‘hello world!’ would create > a file that did not end in a linefeed. Oh, that's what you meant. You said "non-text files", so I assumed you were talking about binary formats. > You weird quoting is broken; see `around>'. Yikes. Okay, I know now not

Re: [groff] groff and pipes

*> Thus its trait of littering non-text files around> on Unix due to the last line not ending in ASCII LF.* What do you mean? I've never seen Emacs do this (unless you mean those lockfile symlinks it creates whilst editing a file). *> Emacs wasn't either.* Well, we all know GNU's Not Unix. ;-)

Re: [groff] 04/05: {g, n}roff.1.man: Give assistance to pager users.

technologies invented 50 years apart was seriously inspiring. On Wed, 3 Jul 2019 at 10:55, Damian McGuckin wrote: > On Wed, 3 Jul 2019, John Gardner wrote: > > > Surely 300 baud was a more refreshing[1] experience than an > > electromechanical teletypewriter, right? > &

Re: [groff] 04/05: {g, n}roff.1.man: Give assistance to pager users.

> > > *Particularly irritating was emacs's use of for* > *"search" because it conflicted with this flow-control, meaning* > *that you had to either reconfigure your tty settings or the**emacs > keybindings.* I still remember my first experience with Emacs: 1. Open file, edit buffer 2. Undo a

Re: [groff] 04/05: {g, n}roff.1.man: Give assistance to pager users.

MacBook's crappy screen ever again... On Wed, 3 Jul 2019 at 09:46, Damian McGuckin wrote: > On Wed, 3 Jul 2019, John Gardner wrote: > > >> *Some terminals, the Tek 401x series especially, could* *be configured > >> to tell the host to stop sending text on* *a "page full"

Re: [groff] 04/05: {g, n}roff.1.man: Give assistance to pager users.

nal emulators I have on hand at the moment, none of them are responding or behaving differently. I always assumed terminals had some form of paging ability, no matter how rudimentary, but I see how wrong I was On Wed, 3 Jul 2019 at 04:54, Dale Snell wrote: > On Tue, Jul 2, 2019 a

Re: [groff] man 7 groff; was nroff.1.man Make editorial fixes.

> > *When writing *roff text, you'll need to break your lines anyway, if > you're calling macros.* I'm speaking much more broadly about plain-text and prose in general. Specifically, mediums such as text-editors where soft-wrapping makes it easier for authors to lose track of how much they're

Re: [groff] man 7 groff; was nroff.1.man Make editorial fixes.

> > *or some other markup language that allows text reflow* Text reflow? What the hell is that? =) Seriously though, I advocate the "one sentence per line" rule in reflow-friendly languages as much as possible. Aside from

Re: [groff] 04/05: {g, n}roff.1.man: Give assistance to pager users.

> > *I was trying to get the 1976 edition of CSTR #54 to typeset the other > evening* Where did you manage to get hold of that? I was under the impression that the source code of CSTR #54 was long lost to the sands of time... :| BTW, stupid question: how did people in the 70s read lengthy files

Re: [groff] anyone seen ".ny0" ?

> > > > > *nobody seems to know, i guess the headers were generated automaticlyand > somehow the .ny0 got into that. Now i have a patch to add thedefinition of > ny0 but i would prefer to remove it complettly if one can tell me what it > is supposed to do*. Just tossing in a loose guess here,

Re: [groff] Wierd font troubles

. Given that both Fedora and Debian have > deprecated Type1 support, it probably won't be too much longer before those > fonts won't be available from the distros' repositories at all. > Show quoted text > --Dale > > -- > "And finally, _thinking_ is an exercise to which all too fe

Re: [groff] Wierd font troubles

> > > > *P.S. What's a .t1 file? My google-fu failed me; all I could find was > areference to "male MRI" files. Funny, I didn't know that MRI files > hadgender. At least, nobody said anything about it when my MRIs were > taken.* T1 = Type 1 font file

Re: [groff] Upgrade to 1.22.4 breaks PDF font

*> (although groff was installed from a pre-built package (or "bottle")), the only options were the "--prefix" option and "--without-x".* There used to be three other options as well: --with-gropdf (Enable PDF output support) --with-grohtml (Enable HTML output support (implies --with-gropdf))

Re: [groff] [patch] modernize -T ascii rendering of opening single quote

If my opinion matters in this discussion, then I'm tentatively opposed to this change. Reasons: — Folks limited to ASCII environments may be using a screen font with more suitable-looking quotes (e.g., Gallant) — Regression tests that assert man(1) output will break on systems with a modern

Re: [groff] [patch] modernize -T ascii rendering of opening single quote

*> It's if they choose, or are coerced, into a LC_CTYPE=C locale causing -Tascii that they see asymmetric `'.* Uhm. Is this issue more of a "would like to have" instead of something objectively problematic? For a start, I see ``this'' in project readmes and plain-text docs all the time, and

Re: [groff] [patch] modernize -T ascii rendering of opening single quote

*> I do seem to recall at least one terminal that displayed opening and> closing quotes (for the life of me, I cannot remember which one; I> honestly had more important things to commit to memory).* It might have been a Sun/SPARC terminal, which uses the nicest looking console font in existence:

Re: [groff] Loss of MSVC support

> who has access to both Windows and non-Windows tes platforms and > wants to try to reduce the Windows support burden in groff. Microsoft have a CI service called AppVeyor that offers pretty decent build configuration. For a free service, it's actually not bad. There's

Re: [groff] Loss of MSVC support

lling and managing packages on Windows machines, mainly for setting up CI. Never used ezwinports, I'll look into it. On Fri, 15 Feb 2019 at 04:21, Eli Zaretskii wrote: > > From: John Gardner > > Date: Thu, 14 Feb 2019 09:18:15 +1100 > > Cc: groff > > > > I admit

Re: [groff] Loss of MSVC support

> but there's also no great urgency to remove them, IMO Agreed. Personally, I think this is a non-issue. If Groff still uses backticks to support the (pre-POSIX) ancient Bourne Shell for Solaris 9-10, then we may as well remove those too if we're "modernising" the codebase... (I use "modernise"

Re: [groff] Loss of MSVC support

> Sorry for the false accusation about GOW lacking bash. I was in the middle of pointing out it has Bash . ;-) And, indeed, it does lack gcc and curses I'm afraid. > Am I selling it short? Possibly. But it provides the whole Unix

Re: [groff] Loss of MSVC support

> I run groff on windows a lot, but via cygwin, which I > believe means that mainline POSIX stuff works. I am > inclined to think that if you like the groff toolset, > you are likely to want other Unix capability, too, > and thus gravitate towards facilities like cygwin. I admit I don't have much

Re: [groff] Announcement and call for project submissions

*> OT: It's not obvious to me what offense John gave. Reading the thread,> there's a certain schoolmarmish officiousness in the reprimands. He> caught it on the chin for "sigh", "groan", and "ridiculous". He didn't> attack anyone. I'm left wondering which emoticons are prohibited.* I was also

Re: [groff] Announcement and call for project submissions

ady installable with Homebrew. =) That would be silly. On Thu, 31 Jan 2019 at 08:58, Ingo Schwarze wrote: > Hi John, > > John Gardner wrote on Wed, Jan 30, 2019 at 09:07:49PM +1100: > > > I've created a Homebrew "tap" <https://docs.brew.sh/Taps> for *roff o

[groff] Announcement and call for project submissions

I've created a Homebrew "tap" for *roff or man-related ports and packages which can be easily installed on macOS using Homebrew: https://github.com/Alhadis/homebrew-troff My attempt to submit man-db to Homebrew's core package registry didn't go as planned, which is a

Re: [groff] UTF8 characters to pdf

*> Would anyone who uses a Mac and is reasonably Homebrew-literate like to pick this up?* Done! See https://github.com/Homebrew/homebrew-core/pull/36469 (I CC'd you on GitHub anyway) On Mon, 28 Jan 2019 at 15:57, John Gardner wrote: > *> Would anyone who uses a Mac and is reasonably

Re: [groff] UTF8 characters to pdf

wrote: > > On Fri, Jan 25, 2019 at 02:10:32AM +1100, John Gardner wrote: > > > There was an attempt to get man-db > > > <https://github.com/Homebrew/homebrew-core/pull/25376> accepted in > > > Homebrew, but a patch was needed for macOS support, which Homebrew

Re: [groff] Fonts, PDF images, groff vs. heirloom troff

Nice tricks! Some day when I run out of idiotic OTT projects, I'll probably try to modernise DWB3.3 the way Gunnar Ritter modernised Heirloom Troff. Expect to see picasso(1) like you've never seen him before. ;-) On Sun, 27 Jan 2019 at 09:11, Robert Thorsby

Re: [groff] UTF8 characters to pdf

> Is there a Homebrew version of man that knows to do this? > Should there be? No and yes, in that order. :-\ There's probably a very binding reason for that; most likely a conflict with the system's default software. Homebrew are careful not to link formulae which cause "issues" with other

Re: [groff] UTF8 characters to pdf

> I'm not a Mac user so I don't know which you might prefer or what the tradeoffs are, but MacPorts has 1.22.3 and Homebrew has 1.22.4. I recommend sticking with Homebrew instead of MacPorts. Homebrew is much more ergonomic/user-friendly, has clearer and more accessible documentation, and gets

Re: [groff] UTF8 characters to pdf

Make sure you have GhostScript installed as well, especially if you plan on producing PDF versions of your documents: brew install ghostscript And yes, what Ralph said will fix the encoding issue. =) $ echo 'Hasta mañana. 32 años. ¡Está bien! ¡Sí!' > ~/Desktop/test.roff $ groff -Tutf8

[groff] Rate this hack on a scale of 0 to stupid

First, the situation: 1. I want/need a way to programmatically (and *reliably*) locate the directories containing a Groff installation's .tmac files. This is happening in JavaScript, without the user's intervention. 2. I don't want to make assumptions about standard tmac locations

Re: [groff] GNU troff version 1.22.4

Kudos to everyone's hard work! I did my part . :-) Merry Commit-mass, everybody! On Mon, 24 Dec 2018 at 22:43, Ingo Schwarze wrote: > Hi Bertrand, > > Bertrand Garrigues wrote on Sun, Dec 23, 2018 at 04:20:38PM +0100: > > > After a last

Re: [groff] 03/04: doc/groff.texi: Drop most "man" documentation.

> mdoc(7) applied the concept of semantic markup and of separation > of content and presentation at about the same time as HTML was > developed, whereas the basic concepts of man(7) are still stuck > in a paradigm of markup that faded away in the 1980ies And yet, mdoc(7) is fundamentally useless

Re: [groff] a5 paper size?

Hi Ricky, Try passing the paper-size option directly to Groff: groff -Tpdf *-P-l* … See groff(1), "USING GROFF" for more information on specifying paper-size. The "\X'papersize=…'" mechanism is designed for documents where certain pages have different dimensions to others. E.g., a PDF whose

Re: [groff] Regularize (sub)section cross references.

Maybe I'm approaching this from the wrong angle, but... I don't really see what the problem is. Documentation offers readers one language at a time. Sure, multilingual authors might split each page into, say, English or French. But unless it's crippling lack of Unicode/UTF-8 support which stops

Re: [groff] Regularize (sub)section cross references.

Just in case it's of interest to anybody, here's how CSS mediates stylistic capitalisation between locales: https://developer.mozilla.org/en-US/docs/Web/CSS/text-transform Some interesting notes on Greek letters that I don't think were touched on in this thread. On Tue, 18 Dec 2018 at 09:05,

Re: [groff] Regularize (sub)section cross references.

s and decide to improve > their English reading skills instead, which is very useful anyway. > So worrying about details of mandoc support for Japanese is mostly > a waste of time." > > Besides, having a small esszett at the end of an all-caps word in > a manual page title is

Re: [groff] Regularize (sub)section cross references.

st problem I know of is that the uppercasing transform of > German sharp S "ß" goes to "SS". (A recent version of Unicode did > introduce a capital sharp S but it might have only specialized uses; I'm > not sure all Germans would find it acceptable.) > > A 1-to-2

Re: [groff] Regularize (sub)section cross references.

> The problem with this, is that it ignores all but english languages. Shouldn't Groff have a more ergonomic alternative to `.tr` which is closer to the POSIX utility of the same name? .translate [A-Z] [a-z] Being a Perl lover, I'd love nothing better than to have full-blown regex support

Re: [groff] Regularize (sub)section cross references.

> Just press the keys "minus" and "i" in sequence to toggle > case-(in)sensitivity while in less. The more(1) you know. ;-) On Mon, 17 Dec 2018 at 08:52, Tadziu Hoffmann wrote: > > > You have to know ahead of time that you want a > > case-insensitive search and call less with the "-i" flag. >

Re: [groff] Regularize (sub)section cross references.

nly runs insensitively by default, but jumps to the next matching line as you're typing. Atom does the same. On Mon, 17 Dec 2018 at 08:31, G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > At 2018-12-17T08:21:40+1100, John Gardner wrote: > > *> How does the impor

Re: [groff] Regularize (sub)section cross references.

t;Ssssh...", which would actually make ".Sh" ".It" pretty concerning. ;-) You can get around this by using .Sh; a title attribute needn't be included if all you care about is having it pronounced letter-by-letter. So .Sh isn't necessary. On Mon, 17 Dec 2018 at 07:56,

Re: [groff] Regularize (sub)section cross references.

> or perhaps it was considered but consciously rejected because > situations existed where it would be detrimental? It could have been to make sections more conspicuous in text editors, making it easier for the author to spot sections when skimming a file. Doubt there was any syntax highlighting

Re: [groff] Work-related rants

ense as: *> using monstrous frameworks like wscons/systemd/c++/whatever* On Mon, 17 Dec 2018 at 04:07, Ingo Schwarze wrote: > Hi John, > > John Gardner wrote on Mon, Dec 17, 2018 at 02:33:25AM +1100: > > > I really do wish Mandoc would support the Troff intermediate > > o

Re: [groff] Work-related rants

> *pages 11 to 13 are about implementing a new output format,* I really do wish Mandoc would support the Troff intermediate output format. Even if processing text piped between programs isn't nearly as efficient as reading it from a compiled program, it's so much more flexible. On Mon, 17 Dec

Re: [groff] Regularize (sub)section cross references.

> Now arguably (for example, John Gardner said something like that) > that syntax rule is an anachronism and has detrimental effects, > for example confusing screen readers. Just to clarify what Ingo's remembering — non-visual agents (braille displays and speech-to-text programs) ha

Re: [groff] Design and Implementation of *roff

> So, if you are using a Unix/Linux system with standard > man-pages, on a command-line terminal enter: > man sex > and see what you get! I've been down this road once beefore the first time I had to write `man finger`... =) On Mon, 3 Dec 2018 at 05:52, Ted Harding wrote: > One thing that does

Re: [groff] Comments about the bug report #42675 (long)

I just finished reading all 9,535 bytes of Bjarni's e-mail, and I still don't have a single idea what he's talking baout... =( On Thu, 22 Feb 2018 at 13:10, Bjarni Ingi Gislason wrote: > Title: \} considered as macro argument regarding register .$ > > > The reported bug (#42675) is a panic

Re: [groff] Design and Implementation of *roff

> It seems relevant You're looking at the single-most accurate and complete timeline on Roff anywhere on the web. Parts of it are vague, because the ones who invented it hardly remembered many of the details over the decades. It's incredible that Jerome Saltzer is still alive (right?? He was

Re: [groff] mom manpage

eso wrote: > Hello Ingo, > > Ingo Schwarze wrote in <20181201120713.ga89...@athene.usta.de>: > |John Gardner wrote on Sat, Dec 01, 2018 at 05:36:25PM +1100: > |> Ingo Schwarze wrote: > |>> Even moderately large systems can be beautifully documented in a > |&

Re: [groff] mom manpage

> Software that inherently defies concise description is suspect on > its face. In all likelihood it was built by accumulation way beyond > the bounds of any organizing principles that the author(s) may have > had at the outset. MDN (Mozilla Development Network) is probably the first offender

Re: [groff] Design and Implementation of *roff

ive, twisted ways, they also elevate my respect for the folks who had to implement them in raw assembly in an era when computers had less processing power than my microwave... *salutes Osanna* On Sat, 1 Dec 2018 at 22:42, Pierre-Jean Fichet < pierrejean.fic...@posteo.net> wrote: >

Re: [groff] mom manpage

> Even moderately large systems can be beautifully documented in a > single manual page - for example, a shell It's amazing how true this is. Even with massive man-pages, it's still easier to find what I'm looking for in less(1) by hitting the `/` key and typing a search string. It's quite

Re: [groff] Design and Implementation of *roff

Insanity. Seriously. Reimplementing Troff is a task best not attempted at all. The grammar is horribly complex, the language riddled with cryptic, arcane features, and most importantly, it's not one program. It's several: the Troff pipeline involves preprocessors, postprocessors, and bundled

Re: [groff] Release Candidate 1.22.4.rc3

> Yeah. Even Mojave (the latest MacOS) has Groff 1.19.2. I basically have > to recompile and overwrite the base install after every system update. You should really be using Homebrew for that: $ brew install groff $ which groff /usr/local/bin/groff However, the problem Ingo

Re: [groff] Bold v Italics: Dawn of Justice

Concerning the issue of emphasising fixed-width text differently in nroff and troff, here's a weird hack I've used that works: .\" Adaptive monospace fonts > .ie t \{ > . ds ` \\f(CR > . ds ' \\fP >

Re: [groff] man-page fixes

> > *The most needless words of all are promotional. No man page should utter > words like "powerful", "extraordinarily versatile", "user-friendly", or > "has a wide range of options".* I couldn't agree more, Doug. *curl(1)* reminds me of this every time I run `man curl` for a reminder on what

Re: [groff] improve a few terminal renderings of special characters

*> This is an excellent resource that I hadn't seen before.* I was wondering why I hadn't seen this before either. I wished I'd found it earlier. It isn't included in OpenBSD's source tree, nor is it present in the system's documentation. Is there any reason for this? *> IME `catman' pages are

Re: [groff] improve a few terminal renderings of special characters

8 at 23:01, Ingo Schwarze wrote: > Hi John, > > John Gardner wrote on Sat, Sep 01, 2018 at 10:26:40PM +1000: > > > Ah I see, thanks. I might end up whitelisting sane systems (*BSD) and > > stupidly predictable ones (macOS), falling back to a JS-based > > implementa

Re: [groff] improve a few terminal renderings of special characters

a pattern ... which is probably the closest I've come to finding an equivalent to `man -k` on Solaris.. I blame Oracle. Always blame Oracle. On Sat, 1 Sep 2018 at 21:41, Ingo Schwarze wrote: > Hi, > > this likely isn't quite as bad as you seem to fear. > > John Gardner wrote on Wed, Au

Re: [groff] Inexplicable error using tbl(1) 1.19.2 on macOS

arry Kollar wrote: > > > > John Gardner wrote: > > > > Now, we all know Apple are clueless and continue to ship the most ancient > > versions of software fathomable, but I find it impossible to believe that > > at some point in Groff's history, there was a published tbl(1

Re: [groff] improve a few terminal renderings of special characters

What sort of things would you like seeing it do as a backend? ;-) On Fri, 31 Aug 2018 at 00:59, Ralph Corderoy wrote: > Hi John, > > Stop replacing man. > Integrate Roff.js as a groff and man backend instead, > in the manner of gxditview. > > -- > Cheers, Ralph. >

Re: [groff] improve a few terminal renderings of special characters

I'm afraid you lost me at several parts of your email, mate... I'm not very good at putting up what people are putting down, so to speak, so harsh, tactless honesty has always had a way of getting through to me the best. ;-) On Fri, 31 Aug 2018 at 00:06, Ralph Corderoy wrote: > Hi John, > > >

Re: [groff] improve a few terminal renderings of special characters

> whereis(1)? Again, not POSIX, but might not deviate so much. Sadly, it really does. I'll leave you with macOS's annoyingly terse manpage for the whereis(1) utility: *WHEREIS*(1) General Commands Manual > *WHEREIS*(1) > *NAME* > *whereis* – locate programs > *SYNOPSIS* >

Re: [groff] improve a few terminal renderings of special characters

> > I wonder if John Gardner's HTML-canvas renderer could lay down text > > in a dark grey that's additive to what's already there, thus > > over-striking would have an effect, e.g. `\z~o' as well as bold. Does this not work already? Overstriking diacritics should work the same for the renderer

Re: [groff] Inexplicable error using tbl(1) 1.19.2 on macOS

l's manpage, citing no serious compatibility issues that would suggest my usage of it was wrong. On Wed, 22 Aug 2018 at 12:08, Bjarni Ingi Gislason wrote: > On Wed, Aug 22, 2018 at 08:24:21AM +1000, John Gardner wrote: > > [...] > > Would still like to know what the hell

Re: [groff] Inexplicable error using tbl(1) 1.19.2 on macOS

line 10: \\rq instead of \(rq line 350: \<* and \>* instead of \*< and \*> line 178: unknown macro XR (did you mean SX?) Damn, your eyes are certainly sharper than mine were at the hour I wrote this. Good catch! The code samples in the first-half of the document were also being mangled

Re: [groff] Inexplicable error using tbl(1) 1.19.2 on macOS

Sigh, yes, that'll teach me for not being clear... The markup I posted which generated that error was *reduced* from previously valid markup (and the error messages remained the same). To the best of my understanding, though, the original `tbl(1)` markup

<    1   2   3   4   >