At 2025-03-10T14:57:24-0500, Dave Kemper wrote:
> On Sun, Mar 9, 2025 at 11:03 AM G. Branden Robinson
> wrote:
> > it appears that "removing" characters may have never really worked,
> > because the act of looking one up created it.
>
> Do you have sample input
[looping in groff@gnu since this turned into a status report]
At 2025-03-09T15:49:10+0100, Alejandro Colomar wrote:
> On Sun, Mar 09, 2025 at 01:12:40PM +, Deri wrote:
> > I'm wondering why you switched from using a more "up to date" groff
> > back to the 1.23.0 version.
>
> I bought a new dr
[self-follow-up]
At 2025-02-24T04:02:55-0600, G. Branden Robinson wrote:
> Anyone familiar with the discussions on this list of the
> conflation of adjustment and alignment in *roff will understand
> why the advice Bjarni offered was bad--it defeats the user's
>
At 2025-02-23T23:34:36-0600, Dave Kemper wrote:
> On Sun, Feb 23, 2025 at 8:52 PM G. Branden Robinson
> wrote:
> > At 2025-02-24T03:36:28+0100, onf wrote:
> > > I think the point is that such filenames aren't being used,
> >
> > No, that's not "the
At 2025-02-23T20:13:59+0100, onf wrote:
> Removing the -ms makes the issue disappear. The issue must originate
> in ms's definition of the TS macro,
No.
> since adding
> .ds TS
>
> at the beginning of the document fixes the issue even when -ms is
> included.
>
> By the way, your table data in
Hi Francesco,
At 2025-02-23T19:00:17+0100, Francesco Ariis wrote:
> a question about table width and line width.
>
> Attached is an MRE which displays my problem, which you can
> run with `groff -ms -t -Tpdf test.ms > out.pdf`
>
> In the document:
> 1. line width is set to 17cms
> 2. I inser
At 2025-02-24T03:36:28+0100, onf wrote:
> On Mon Feb 24, 2025 at 2:36 AM CET, G. Branden Robinson wrote:
> > [...]
> > My lodestar on this point is that we can use C and the shell to create
> > files named with trailing spaces, so there's no reason *roff, as a bona
>
At 2025-02-24T02:44:35+0100, onf wrote:
> On Mon Feb 24, 2025 at 1:09 AM CET, G. Branden Robinson wrote:
> > [...]
> > diff --git a/src/roff/troff/input.cpp b/src/roff/troff/input.cpp
> > index 2656ff236..cf750bc73 100644
> > --- a/src/roff/troff/input.cpp
> &g
[re-titling sub-thread again]
At 2025-02-22T17:59:10-0600, Dave Kemper wrote:
> I still suspect that that benefit stands even if the file-opening
> function is modified to chop trailing spaces from the name. That
> would prevent groff from opening a file named "trailing space ", but
> any real-wo
At 2025-02-23T23:52:07+0100, onf wrote:
> I would argue that the fact the second argument to lf is not used by
> groff to access the file system doesn't change its semantics of being
> a filename. Especially since soelim emits lf requests for all the .so
> calls it replaces, meaning that whatever
At 2025-02-23T17:23:35+0100, Benno Schulenberg wrote:
> > Regarding the hyphenation problem, the lump in the carpet moves
> > after groff 1.22.4. Because HTML output now produces −
> > entities rather than hyphens from *roff minus special characters
> > (`\-`), [...]
>
> Ouch! I don't like the l
At 2025-02-23T21:21:37+0100, onf wrote:
> For all the other requests which use filenames (hpf, hpfa, lf -- am I
> mistaken, or did we forget about lf? --, nx, so), it treats spaces as
> an argument separator.
No, I didn't forget about `lf`. See comment #0 ("original submission")
to Savannah #6510
At 2025-02-23T20:22:38+0100, onf wrote:
> On Sun Feb 23, 2025 at 5:23 PM CET, Benno Schulenberg wrote:
> > > Regarding the hyphenation problem, the lump in the carpet moves
> > > after groff 1.22.4. Because HTML output now produces −
> > > entities rather than hyphens from *roff minus special char
[giving this sub-thread a more appropriate title]
At 2025-02-22T23:23:35+0100, onf wrote:
> [re-arranging]
>
> On Sat Feb 22, 2025 at 9:37 PM CET, G. Branden Robinson wrote:
> > At 2025-02-22T16:38:00+0100, onf wrote:
> > [...]
> > > I feel like changing ab, hpf, hp
At 2025-02-22T16:38:00+0100, onf wrote:
> I forgot to emphasize the likely largest obstacle, which is the fact
> that it
(presumably Savannah #66625, and/or changes already in Git)
> would break compatibility with documents written for neatroff.
In what way?
> Ali seems averse to breaking backw
[self-reply; Benno not CCed]
At 2025-02-22T02:40:32-0600, G. Branden Robinson wrote:
> Hi Benno,
>
> I have some partial good news.
[...]
> I'm attaching HTML renderings with groff 1.23.0 and the bleeding edge.
For once I _didn't_ forget the attachments; I checked my S
Hi Benno,
I have some partial good news.
At 2025-02-17T11:52:27+0100, Benno Schulenberg wrote:
> Op 16-02-2025 om 15:13 schreef G. Branden Robinson:
> > > Is there a way to mark such long options in the man page so that
> > > browsers are prevented from breaking the m
At 2025-02-22T01:31:28+0100, onf wrote:
> On Sat Feb 22, 2025 at 12:12 AM CET, G. Branden Robinson wrote:
> > At 2025-02-21T15:22:02+0100, onf wrote:
> > [...]
> > > Ideally, `so` would behave like `tm` except it would trim spaces
> > > at the end, but I underst
At 2025-02-22T00:11:13+0100, onf wrote:
> By the way, Heirloom troff has floating point registers.
Just converting the type backing groff's registers from `int` to `long`
is a significant refactor, because it implicates other things like the
formatting of diagnostic messages. I found this out whe
At 2025-02-21T15:22:02+0100, onf wrote:
> On Fri Feb 21, 2025 at 3:14 PM CET, onf wrote:
> > Well, I have thought about it a bit since yesterday and I think
> > making `so` similar to `tm` would be a better idea:
> > $ 9 nroff << EOF
> > .tm Lorem ipsum dolor \" print to stderr
> > EOF
> >
Hi Francesco,
At 2025-02-21T16:19:25+0100, Francesco Ariis wrote:
> can I format/scale numbers when interpolating them?
Not without arithmetic, as far as I know.
> Long explanation follows.
>
> While writing a minimal reproducible example for this list,
> I found myself typing:
>
> Lin
At 2025-02-21T04:30:57+0100, onf wrote:
> On Fri Feb 21, 2025 at 2:27 AM CET, G. Branden Robinson wrote:
> > [...]
> > So in groff Git HEAD (actually, in Git for the past few months),
> > you've been able to do this:
> >
> > .so Planet "X".lrc
&g
Hi Larry,
At 2025-02-20T16:49:47-0800, Larry McVoy wrote:
> On Thu, Feb 20, 2025 at 06:36:29PM -0600, G. Branden Robinson wrote:
> > At 2025-02-20T19:39:37+0100, onf wrote:
> > > On Thu Feb 20, 2025 at 5:59 PM CET, Douglas McIlroy wrote:
> > > > The idea that the
The discussion about `so` request usage got me to thinking, so I decided
to flag another consequence of the newly consistent system for handling
file name arguments to *roff requests.
The short version is that if you've been doing stuff like this:
.so "5150".lrc
to read a file named "5150".lrc--
At 2025-02-20T19:39:37+0100, onf wrote:
> On Thu Feb 20, 2025 at 5:59 PM CET, Douglas McIlroy wrote:
> > The idea that the argument of .so might contain unquoted spaces is
> > anathema--contrary to groff convention and fortunately not supported.
>
> As far as I know, .so currently doesn't support
At 2025-02-20T15:55:40-0500, Steve Izma wrote:
> For what it's worth, I've always abhorred filenames with word spaces
> -- they usually require extra consideration in shell scripts and other
> programs.
Yes. I remember around 2002 or so when Apple released an iTunes update
that didn't appreciate
I don't intend to address the "line selection by number from a sourced
file" issue in this sub-thread. The point here is to increase awareness
of developments in the forthcoming groff 1.24.0.
At 2025-02-20T16:28:02-0500, Douglas McIlroy wrote:
> Indeed, .so does not keep a quoted argument togethe
At 2025-02-19T16:46:51-0800, Larry McVoy wrote:
> On Wed, Feb 19, 2025 at 11:46:30PM +, Neil Johnson wrote:
> > With my alternative syntax:
> >
> > .SO[2-11] /my/source/file
> > .SO[40-50] /my/source/file
> > .SO[...] /my/source/file
>
> I like this form. Though the o
At 2025-02-19T23:46:30+, Neil Johnson wrote:
> That's actually where I started from as well! Except file names after
> the ".so" can have spaces in them on some platforms, and I don't
> believe there is a requirement to escape them, so something like this
> would be valid:
>
> .SO /my/
[CCing groff@gnu list because some problems arise here that merit being
findable by search of its list archives]
Hi Deri,
At 2025-02-17T18:52:46+, Deri wrote:
> > programs in constructed pipeline:
> >
> > GNU grops (groff) version 1.23.0.2695-49927
> > GNU troff (groff) version
At 2025-02-16T22:22:02+0100, onf wrote:
> Actually, setting table of contents items was what lead me to discover
> .linetabs in the first place, because without it, multiline TOC items
> break when left-adjusted. It doesn't work as it should even with
> linetabs, though, which might be a bug. Sorry
At 2025-02-16T18:52:49-0400, Sebastien Peterson-Boudreau wrote:
> > Hi Sebastian,
> >
> > I'm sorry it's taken a while to follow up with you.
> No worries. It's a small and (somewhat) insignificant patch. I figured
> someone would see it eventually, and even if they didn't, hopefully
> anyone runn
[really, _really_, off-topic]
At 2025-02-16T19:53:41+0100, onf wrote:
> The problem with Graeber in general is that he is guided more by
> ideology than a honest search for truth.
Everyone who writes on matters "political" (as assessed by the entire
population, since a single voice suffices to br
At 2025-02-16T19:55:39+0100, onf wrote:
> By the way, I was asking for references to the passages of Old
> Testament you mentioned. (If I understood you correctly, that is.)
Oh. I have no fancy citation for that, just Leviticus 25:8-13, but I
got that from Wikipedia. Most of the Biblical literac
At 2025-02-16T16:46:44+0100, onf wrote:
> > Surely this oversight has nothing to do with the ownership of most
> > consumer debt [] by those occupying the commanding heights of our
> > economies.
>
> Hm, that's really interesting. Do you happen to have any sources to
> back this up?
While my rema
Hi Benno,
At 2025-02-16T12:04:05+0100, Benno Schulenberg wrote:
> In the HTML version of a man page it can happen that a long option
> (like --restricted) occurs near the right edge and that the browser
> splits the thing into "--" at the end of the line and "restricted"
> at the beginning of the
Hi onf,
At 2025-02-10T18:23:14+0100, onf wrote:
> On Mon Feb 10, 2025 at 2:56 PM CET, Tadziu Hoffmann wrote:
> > > AT&T troff stores font size in points. This means it
> > > converts the argument to .ps from whatever unit it's in
> > > (default is points) to basic units and then divides that
> > >
At 2025-02-16T04:37:46+0100, onf wrote:
> > https://www.youtube.com/watch?v=BOvAbjfJ0x0
>
> Take note that (IIRC) the conclusion of research surrounding the
> Prisoner's Dilemma has been that the best strategy is to reciprocate,
> but also sometimes forgive.
Yes. The conclusion of the video, IIR
At 2025-02-16T04:19:20+0100, onf wrote:
> On Sun Feb 16, 2025 at 4:01 AM CET, G. Branden Robinson wrote:
> > At 2025-02-16T03:50:30+0100, onf wrote:
> > > Seems like you are assuming bad faith where there is none. I was
> > > not trying to characterize your train o
At 2025-02-09T03:48:33+0100, onf wrote:
> On Sun Feb 9, 2025 at 3:20 AM CET, onf wrote:
> > [...]
> > TL;DR:
> > With the default settings, a tab essentially translates into a
> > horizontal motion. [...]
> > This is because tab stops are related to the beginning of a paragraph
> > rather than the
Hi onf,
At 2025-02-16T03:50:30+0100, onf wrote:
> On Sun Feb 16, 2025 at 3:17 AM CET, G. Branden Robinson wrote:
> > At 2025-02-16T02:44:12+0100, onf wrote:
> > > Seems like you found yourself in a familiar situation:
> > > "This under-documented code
At 2025-02-16T02:44:12+0100, onf wrote:
> On Sun Feb 16, 2025 at 2:09 AM CET, G. Branden Robinson wrote:
> > At 2025-01-29T00:57:19-0400, sebastien peterson boudreau wrote:
> > > The quotes for `i'th and `i+1'th are very important because the
> > > parser
s.
You're right! Back in November 2020, I "corrected" this example.
commit dfa7b3108f24c30a1fe7b723d2c7fee7ebbd9671
Author: G. Branden Robinson
Date: Wed Nov 4 21:41:11 2020 +1100
man pages: Convert .nf/fi/nh/hy non[s]ense to .EX/EE.
[...]
* src/preproc/pic/p
At 2025-02-10T14:56:28+0100, Tadziu Hoffmann wrote:
>
> > AT&T troff stores font size in points. This means it
> > converts the argument to .ps from whatever unit it's in
> > (default is points) to basic units and then divides that
> > by the size of 1 point.
>
> Did AT&T troff actually allow the
At 2025-02-07T16:20:23+0100, onf wrote:
> I've been wondering lately about the rationale behind solving the
> problem of font sizes being integer-only by adding scaled points.
It's covered in groff_diff(7), the man page I believe you said you
always forget about.
groff_diff(7):
Fractional type
Hi Alex,
At 2025-02-09T00:59:50+0100, Alejandro Colomar wrote:
> On Sat, Feb 08, 2025 at 05:46:19PM -0600, G. Branden Robinson wrote:
> > _If_ you advise the use of tab characters _only_ when filling is
> > disabled, as, apropos of the Subject line, is the case in
> > (dis
[looping in groff list because I bring up grotty *roff details]
(in both senses of "grotty"!)
Hi Alex,
At 2025-02-08T23:57:07+0100, Alejandro Colomar wrote:
> On Sat, Feb 08, 2025 at 11:44:43PM +0100, Alejandro Colomar wrote:
> > Personally, I prefer tabs for actual programming. But for manual
At 2025-01-27T16:32:03-0600, G. Branden Robinson wrote:
> At 2025-01-27T17:46:14+, Colin Watson wrote:
> > It should be a matter of removing .gitmodules and instead setting
> > GNULIB_REVISION in bootstrap.conf to refer to the desired Gnulib
> > commit ID. You can
At 2025-02-06T23:23:57-0600, Dave Kemper wrote:
> On Tue, Feb 4, 2025 at 6:05 PM Tadziu Hoffmann
> wrote:
> > Given that so many attributes (for example, the hyphenation
> > mode) are in fact associated with the environment, I just
> > found it surprising that this isn't, (and the info file
> > do
Hi onf,
At 2025-02-04T20:53:03+0100, onf wrote:
> Let nroff explain it:
> $ nroff -ww << EOF
> .tm \n[.hla]
> .ev epigram
> .hla fr
> .tm \n[.hla]
> .ev
> .tm \n[.hla]
> EOF
> en
> fr
> fr
An excellent procedure, one I endorse.
> In other words, hyphenation language setting
At 2025-02-04T22:15:47+0100, Tadziu Hoffmann wrote:
> > In other words, hyphenation language setting is not local
> > to the environment...
>
> But French would allow hyphenation of "commonplaces".
Yes it would!
Uh-oh! My puzzler was somewhat defective. The French hyphenation
patterns never g
Hi Tadziu,
At 2025-02-04T13:58:26+0100, Tadziu Hoffmann wrote:
> > [...] explain why the word "commonplaces" hyphenates in the second
> > exhibit but not the first.
>
> Interesting! It's not clear from the documentation why it behaves
> this way (or even, once you know how to fix it, what specif
Hi folks,
I have another puzzler.
(A few people--they know who they are--are disqualified from this
challenge. Please don't spoil it. ;-) )
Consider the following input:
$ cat EXPERIMENTS/multilingual-trivia-challenge.groff
.sp
.ce 1
A Study in Redheads
.sp
.ev epigram
.hla fr
.hy 6
.ad r
L'ho
At 2025-01-29T16:56:25+0100, onf wrote:
> On Wed Jan 29, 2025 at 9:27 AM CET, G. Branden Robinson wrote:
> > I forgot to mention that the quoted presentation corresponds to the
> > `cflags` request.
>
> Listing the property codes used by cflags in groff(7) would be nice.
Y
At 2025-01-29T03:06:48-0600, Dave Kemper wrote:
> On Tue, Jan 28, 2025 at 6:40 PM G. Branden Robinson
> wrote:
> > The feature [the `cflags` request] may already exist.
> >
> > Hyphenation doesn't apply to East Asian scripts, but breaking does.
>
> Oh, you&#x
At 2025-01-28T18:40:15-0600, G. Branden Robinson wrote:
> At 2025-01-28T18:35:25-0600, Dave Kemper wrote:
> > On Tue, Jan 21, 2025 at 8:11 AM onf wrote:
> > > I think groff would benefit from neatroff's hydash request:
> > > hydash CHARS
> > > S
At 2025-01-28T21:07:51-0600, Dave Kemper wrote:
> On Mon, Jan 27, 2025 at 6:27 AM G. Branden Robinson
> wrote:
> > Dave Kemper's done some solid QA work that should avoid
> > embarrassment in groff 1.24.0.rc1.
>
> Thanks! But so that the record's not overstat
At 2025-01-28T18:35:25-0600, Dave Kemper wrote:
> On Tue, Jan 21, 2025 at 8:11 AM onf wrote:
> > I think groff would benefit from neatroff's hydash request:
> > hydash CHARS
> > Specify the list of characters after which words may be broken
> > (even when hyphenation is disabled) without
Hi Colin,
At 2025-01-27T17:46:14+, Colin Watson wrote:
> On Mon, Jan 27, 2025 at 06:26:22AM -0600, G. Branden Robinson wrote:
> > Me neither! Years ago I used to tolerate this and found myself much
> > happier when I forced an 80-column limit on man pages I viewed.
> >
Hi Ingo,
At 2025-01-24T07:47:00+0100, Ingo Schwarze wrote:
> G. Branden Robinson wrote on Wed, Jan 22, 2025 at 08:47:20PM -0600:
> > At 2025-01-22T07:10:54+0100, Ingo Schwarze wrote:
> >> It does not require the user to provide any new configuration or
> >> opti
[self-follow-up]
I forgot to type out one of the numbered points I had in mind.
At 2025-01-22T20:47:25-0600, G. Branden Robinson wrote:
> > Maybe what you have in mind is that i abhor a few specific sections
> > that are occasionally seen in the wild, most notably OPTIONS
> >
respond in so much detail to my tentative thoughts in this area. You
have practical expertise in the problem domain (or a closely related
one, at least) and I appreciate your sharing of it.
> G. Branden Robinson wrote on Tue, Jan 21, 2025 at 01:19:08PM -0600:
> > At 2025-01-21T16:05
At 2025-01-21T22:31:44+0100, onf wrote:
> On Tue Jan 21, 2025 at 8:29 PM CET, G. Branden Robinson wrote:
> > Yeah, but I won't have to go sticking my hand into unfamiliar places
> > in the formatter, and we get to keep the output language
> > ASCII-simple.
>
>
Hi Deri,
I've owed you a reply to a message since last month, but you went and
made it easy for me to address one point so I'mma do that.
At 2025-01-21T16:31:17+, Deri wrote:
> On Tuesday, 21 January 2025 05:59:41 GMT G. Branden Robinson wrote:
> [...]
> > The good
Hi onf,
At 2025-01-21T16:05:18+0100, onf wrote:
> On Tue Jan 21, 2025 at 6:59 AM CET, G. Branden Robinson wrote:
> > At 2025-01-20T01:48:19+0100, onf wrote:
> > > And it works quite nicely, actually. The definitions are generated
> > > automatically, so all manpages w
Hi Ihor,
At 2025-01-19T14:04:21+, Ihor Radchenko wrote:
> "onf" writes:
>
> >> I am wondering if the situations like the above should be caught by
> >> groff linter. Currently, they seem not.
> >
> > They actually are:
> > ...
> > troff::2: warning: cannot select font 'C'
> > One two thr
At 2025-01-20T03:27:07+0100, Ingo Schwarze wrote:
> > The definitions are generated automatically, so all manpages written
> > in mdoc benefit from it. I assume groff mdoc + man-db doesn't
> > implement this?
>
> Not that i know of. It would actually be much harder to implement
> in groff than i
Hi onf,
At 2025-01-20T01:48:19+0100, onf wrote:
> Actually, BSD mandoc does implement this, it's just documented at
> a poorly visible place in the docs. BSD mandoc's man(1):
> MANPAGER
> Any non-empty value of the environment variable MANPAGER is
> used instead of the standard pagin
At 2025-01-20T16:43:34-0600, G. Branden Robinson wrote:
> I'm attaching the current version of my "make-groff-fast" script,[1]
> which I run _all the time_.
Take a drink and/or claim your wager winnings.
Regards,
Branden
#!/bin/sh
set -e
: ${TAG:=HEAD}
: ${DESTDIR:=$HOME/
At 2025-01-20T12:38:24-0500, T. Kurt Bond wrote:
> I always install a personal copy of groff in a directory that my user
> owns, ensure that is in the path before the location of the system
> groff, and never use root access for installing fonts. I realize this
> may not be suitable for everyone.
At 2025-01-20T18:15:48+0100, Francesco Ariis wrote:
> Hello groff users,
>
> how to convert .tff fonts to something usable by `groff`, without
> sudo access?
In groff 1.23.0, both the grops(1) and gropdf(1) man pages document a
procedure for doing this. It is admittedly more tedious than usi
At 2025-01-17T02:34:17+, Bjarni Ingi Gislason wrote:
> It is no longer distributed by Debian.
>
> Its website "www.snake.net" does not answer to a ping call.
>
> Its last maintainer in Debian was Colin Watson.
Thanks for noting this, Bjarni. Like you, I seem to remember that Colin
has
Hi Bruno,
At 2025-01-16T21:45:44+0100, Bruno Haible wrote:
> G. Branden Robinson wrote:
> > [please keep groff@ in CC list, as I'm not subscribed]
> >
> > I'm having C++-related declaration clash trouble on Solaris 11.
> > Since both header files involved in
Hi Alex & Ingo,
At 2025-01-08T19:31:04+0100, Alejandro Colomar wrote:
> If you want an actual manual page where this would make sense, look at
> dl_iterate_phdr(3).
This is a better place to start than the specimen you offered first, in
my opinion. As I've said elsewhere, I think the objective o
Hi Francesco,
You got several good answers; I wanted to add a few points.
At 2025-01-07T19:27:56+0100, Francesco Ariis wrote:
> I recently discovered `groff`. As an exercises I am typesetting my
> CV in it (`groff -ms`). Say I want to put the link to my personal
> website, what directive/macro
At 2025-01-02T19:55:57+0100, Ingo Schwarze wrote:
> I'm not opening a Savannah ticket because i see no danger of
> this patch lingering. If no groff developer objects, i'm planning
> to push it in a few days. If there is useful feedback, a tweaked
> version might get pushed, but either way, we'll
Hi onf,
[replying to 2 messages]
At 2025-01-02T15:29:59+0100, onf wrote:
> I don't know why it took me so long, but I think what you're looking
> for is this:
> \fC\f(CRLorem\fR
Not a bad idea, but while you're there, given Ihor's ambitious
portability objectives, you might as well scoop up th
Hi Ihor,
At 2024-12-31T18:15:57+, Ihor Radchenko wrote:
> "G. Branden Robinson" writes:
>
> > I understand now. I've taken some time to learn a bit more about
> > Org mode, and also that org-man.el seems to be something close to
> > the bleeding edge;
Hi Ihor,
At 2025-01-01T09:38:37+, Ihor Radchenko wrote:
> "onf" writes:
>
> >> Also, what if we leave \fC and add \f[CR]/.EX on top?
> >> AFAIU, the worst case scenario for \fC is that it does nothing. By
> >> leaving it there, we thus retain old working exports working while also
> >> addin
Hi folks,
I've decided to put `QS` and `QE` macros for man(7) on the shelf--
indefinitely and perhaps permanently.
Instead I'm adding some advice to the groff_man_style(7) page in the
"Notes" section alongside other Q&As.
• When and how should I use quotation marks?
As noted above i
[Ingo: see bottom of message for a possible mandoc(1) bug in footnote 2]
Hi Ihor,
At 2024-12-22T15:41:57+, Ihor Radchenko wrote:
> "G. Branden Robinson" writes:
>
> >> Jeremy suggests that "C" may be an old alias for Courier, and if
> >> th
Hi onf,
At 2024-12-20T14:15:43+0100, onf wrote:
> On Fri Dec 20, 2024 at 3:45 AM CET, G. Branden Robinson wrote:
> > Yes. I think we could do more to encourage people to understand the
> > availability of the grout format as a resource on more occasions, in
> > a similar
Hi onf,
At 2024-12-20T13:59:13+0100, onf wrote:
> > [...] Before the BSD community decided upon the performative
> > wokeness of rabid allergies to copyleft and (at OpenBSD at least)
> > C++.
>
> I kinda get where they are coming from with C++, though. Last time I
> tried patching groff, I was f
Hi Alex,
At 2024-12-20T12:11:00+0100, Alejandro Colomar wrote:
> On Thu, Dec 19, 2024 at 09:31:49PM -0600, G. Branden Robinson wrote:
> > For some vendors, the end of the Unix Wars meant the end of
> > development. Lay off all the engineers and collect rents from
> >
Hi Doug,
Thanks for considering my proposal. I see that I've not done the best
job documenting the problems of the status quo, and that even with that,
my solution may not suffice to address them.
At 2024-12-20T10:00:25-0500, Douglas McIlroy wrote:
> > * People may discover that quotation marks
Hi onf,
At 2024-12-20T02:21:00+0100, onf wrote:
> I assume the reason for using the strings `lq` and `rq` instead of
> characters of the same name is that the strings can be defined
> differently based on the current locale,
If so, that was pretty forward-looking for Berkeley in 1980.
> so that
Hi Alex,
At 2024-12-20T00:39:19+0100, Alejandro Colomar wrote:
> On Wed, Dec 18, 2024 at 08:00:53PM -0600, G. Branden Robinson wrote:
> > Synopsis:
> >
> > .QS [suppress-initial-word-hyphenation?]
> >Begin quotation. An opening quotation mark is formatted.
Hi Bjarni,
Wrong enumeration? You are mistaken.
At 2024-12-19T23:04:23+, Bjarni Ingi Gislason wrote:
> Still current:
>
> adjustment types: 0 1 3 5 (left both center right)
> no-adjustment modes: 0 2 4
>
> So enumeration '0' is the same for two different statuses but should
> be di
At 2024-12-19T22:48:41+0100, onf wrote:
> On Thu Dec 19, 2024 at 8:43 PM CET, G. Branden Robinson wrote:
> > At 2024-12-19T20:23:56+0100, onf wrote:
> > > Although looking up Unicode codepoint numbers is arguably better
> > > than seeing gibberish, neither is a par
At 2024-12-19T20:23:56+0100, onf wrote:
> On Thu Dec 19, 2024 at 7:15 PM CET, G. Branden Robinson wrote:
> > At 2024-12-19T17:20:09+, Deri wrote:
> > > I don't mind, I just thought you considered readability of the grout
> > > file important [1],
> >
Hi Deri,
At 2024-12-19T17:20:09+, Deri wrote:
> On Thursday, 19 December 2024 00:34:49 GMT G. Branden Robinson wrote:
> > Is [UTF-8-encoded characters in grout] something you want? What
> > should the consequences of invalid or incomplete UTF-8 sequences be?
>
> I don&#
[self-correcting follow-up]
At 2024-12-18T20:00:53-0600, G. Branden Robinson wrote:
> Pro:
> * People may discover that quotation marks are properly available in
> the man(7) language, a fact that has been obscure for 45 years.
> (The `\*(lq` and `\*(rq` syntax has been availab
ace change will be necessary. I
don't expect many users to nest quotations in any event.
At 2024-12-18T14:48:35-0600, Dave Kemper wrote:
> On Mon, Dec 16, 2024 at 8:28 AM G. Branden Robinson
> wrote:
> > I don't feel I have sufficiently broad knowledge of what man-parsing
> &
At 2024-12-18T20:28:17+, Deri wrote:
> On Wednesday, 18 December 2024 18:12:01 GMT G. Branden Robinson wrote:
> > [1] You already know what's coming. My hobnail boots and swagger
> > stick say "you get code points 0x20 to 0x7E in your
> > uninte
Hi Deri,
At 2024-12-18T17:41:59+, Deri wrote:
> On Wednesday, 18 December 2024 01:07:45 GMT G. Branden Robinson wrote:
> > This is an extremely helpful presentation. I have some questions.
> >
> > 1. Where was the foregoing distinction documented in, say, the
>
Hi Deri,
At 2024-12-18T16:51:59+, Deri wrote:
> Import is not ready for primetime, its not finished. It was originally
> conceived for non-standard import of images. Typically where you want
> the rendered image to be a precise size (i.e. fill to the edges of an
> A4 page), ignoring the XY rat
[looping in groff list; please reply to it as well, as I am not
subscribed to emacs-orgmode]
Hi Xiyue, Ihor, and Jeremy,
I stumbled across this thread while researching problems have
encountered with groff, which I maintain for the GNU Project.
At 2024-02-29T23:51:29-0800, Xiyue Deng wrote:
> "m
Hi Deri,
At 2024-12-18T11:10:52+, Deri wrote:
> I wrote "pdf: pdfpic" to mimic the behaviour of .PSPIC, render image
> down from current point, not realising (until now!) that "ps: import"
> renders the image up from the current point. This difference in
> behaviour is somewhat masked because
Hi Deri,
I'm going to quote your whole presentation (omitting quotes of myself)
because it is a tour de force of explication.
At 2024-12-18T00:19:28+, Deri wrote:
> The model I use to understand the difference between \X and \!
> (.device and .output) is that one uses an in-band channel (\X)
At 2024-12-18T01:04:58+0100, Tadziu Hoffmann wrote:
> > Wrapping a diversion inside a character definition is indeed a
> > novel thing to do. At first blush, I admire the creativity.
> > At second blush, the prescriptivist and black-gloved input
> > validator in me recoils. ("Why isn't this banne
1 - 100 of 1249 matches
Mail list logo
