bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #64216] [eqn] "{thick, thin}_space" parameters affect full- and hal


From: G. Branden Robinson
Subject: [bug #64216] [eqn] "{thick, thin}_space" parameters affect full- and half-width spaces ~ and ^
Date: Thu, 18 May 2023 20:24:15 -0400 (EDT)

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

                 Summary: [eqn] "{thick,thin}_space" parameters affect full-
and half-width spaces ~ and ^
                   Group: GNU roff
               Submitter: gbranden
               Submitted: Fri 19 May 2023 12:24:13 AM UTC
                Category: Preprocessor eqn
                Severity: 3 - Normal
              Item Group: Incorrect behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Fri 19 May 2023 12:24:13 AM UTC By: G. Branden Robinson <gbranden>
Doug McIlroy reported
[https://lists.gnu.org/archive/html/groff/2023-05/msg00065.html to the mailing
list]:

> man eqn says
>          set thin_space n
> causes n/100 em space to be "automatically inserted after punctuation
> characters", which are vaguely defined as "characters such as ',' "
>
> I used thin_space 0 to take away automatic space after . in formulas.
> To my surprise it also took away intentional spaces represented by ^.
>
> The loss of ^ threw away a lot of carefully crafted spaces, and even
> threw away spaces in some sporadic cases where I wanted to override
> thin_space 0.
>
> Another parameter, thick_space, has the same effect on ~.
>
> Apparently thin_space serves double duty--to control automatic spacing
> and to set the width of ^.
> 
> This coupling of function strikes me as a bug. One thinks of ^ and ~
> as groff keywords, not characters. And even if they are characters,
> they represent white space placed deliberately, not "automatically
> inserted".

Doug's assessment makes sense to Damian McGuckin and to me (see follow-ups on
the list).

Perhaps add new "full_width_space" and "half_width_space" parameters.







    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]