[bug #58933] [PATCH] doc/groff.texi, man/groff.7.man: clarify description of \&

[Dave]

URL:
<https://savannah.gnu.org/bugs/?58933>

Summary: [PATCH] doc/groff.texi, man/groff.7.man: clarify
description of \&
Project: GNU troff
Submitted by: barx
Submitted on: Mon 10 Aug 2020 04:17:20 PM CDT
Category: Core
Severity: 3 - Normal
Item Group: Documentation
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Planned Release: None

_______________________________________________________

Details:

On a suggestion from Peter Schaffter
(http://lists.gnu.org/archive/html/groff/2020-07/msg00100.html) that \& is
best described as "a zero-width, non-printing character" -- itself in reply to
my observation that groff's current term, "zero-width space," is a bit
misleading, especially as that's the name of a Unicode character (U+200B)
equivalent to groff's \: rather than its \& -- I created this patch
(originally posted at
http://lists.gnu.org/archive/html/groff/2020-08/msg00014.html) to update
groff's documentation accordingly.

Both target files have changed since I created the patch, but it still (as of
commit 4ce01df7) applies cleanly.



_______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Mon 10 Aug 2020 04:17:20 PM CDT Name: zwnpc.patch Size: 3KiB By:
barx
update description of \&amp; in doc/groff.texi and man/groff.7.man
<http://savannah.gnu.org/bugs/download.php?file_id=49650>

_______________________________________________________

Reply to this item at:

<https://savannah.gnu.org/bugs/?58933>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

[G. Branden Robinson]

Update of bug #58933 (project groff):

Status: None => Need Info
Assigned to: None => gbranden

_______________________________________________________

Follow-up Comment #1:

How about just "non-printing character"?


commit b423e4ce784e7ad0ca1027ba6b57553ed272c74a
Author: G. Branden Robinson <g.branden...@gmail.com>
Date: Thu Aug 13 21:42:26 2020 +1000

[...]
* [style] Redefine \& as "non-printing character" in light of recent
discussion on groff list. (I find "zero-width" unnecessary; does a
character that doesn't print take up any space? Certainly not when it
isn't an \h or \v escape... ;-) )
[...]

[Dave]

Follow-up Comment #2, bug #58933 (project groff):

It's Peter's term; I'm just a fanboy. I agree that "zero-width" seems
redundant, but maybe he can think of something additional it communicates.

[Peter Schaffter]

Follow-up Comment #3, bug #58933 (project groff):

> It's Peter's term; I'm just a fanboy. I agree that "zero-width" seems
redundant, but maybe he can think of something additional it communicates.

It's the definition used by Ossana and Kernighan in the cstr54, not mine,
though they switch it around. I'm inclined to think zero-width is not
redundant, since a non-printing character could have a width. Zero-width,
non-printing clarifies this. I'd rather risk overstating than leaving room
for doubt. I suspect that was O&K's reasoning, too.

[Dave]

Follow-up Comment #4, bug #58933 (project groff):

Ah. I only have the November 1992 revision of CSTR #54 (I can't actually find
any earlier versions on the web), which calls it a "non-printing, zero-width
filler character." But I think the word "filler" is slightly misleading, so
the version without it is definitely better to me. I have no opinion about
the presence or absence of "zero-width."

[Dave]

Follow-up Comment #5, bug #58933 (project groff):

Looks to be fixed in commit 36b5c885
<http://git.savannah.gnu.org/cgit/groff.git/commit/?id=36b5c8852af098e6f06dbe2ab8e452a45b43d315>
(and I see my patch missed two of the four files that used the less accurate
terminology).

[G. Branden Robinson]

Update of bug #58933 (project groff):

Status: Need Info => Fixed
Open/Closed: Open => Closed
Planned Release: None => 1.22.5

_______________________________________________________

Follow-up Comment #6:

I had a moment of wavering doubt involving "string comparisons", but I
overcame them after writing enough short experiments. The key conclusion I
reached there is that formatting is not the same thing as rendering.

Closing per Dave's observation.