Subject: Re: bug#78528: [PATCH v1] calc: Allow strings with higher character codes
From: Eli Zaretskii <[email-masked]>
To: "Jacob S. Gordon" <[email-masked]>
Cc: [email-masked]
Date: Sat, 14 Jun 2025 17:12:34 +0300
List-Id: <debbugs-submit.debbugs.gnu.org>

> Date: Mon, 2 Jun 2025 15:28:16 -0400
> Cc: [email-masked]
> From: "Jacob S. Gordon" <[email-masked]>
> 
> Hello,
> 
> On 2025-05-31 09:27 Eli Zaretskii wrote:
> > It's in my (too long, admittedly) queue.
> 
> No problem, thanks for the confirmation.
> 
> > Can you think of any possible downsides to installing the patch?
> 
> Nothing that I don’t think can be ironed out.
> 
> + The custom variable defaults to the previously hard‐coded value, so
> unless users change it, `calc' will act the same as before.
> 
> + This variable only affects the display of vectors‐of‐chars, and
> touches none of the underlying types (e.g., algebraic variables are
> still restricted to a basic Latin-Greek range through an independent
> parsing step).
> 
> + Allowing a higher maximum means that users can encounter characters
> without a fixed width, or contextual forms that change the rendered
> string length. Alignment/justification, and some elements of
> “compositions” assume fixed-width characters for their calculations,
> so their results can be off. Here are some representative examples
> from all the affected compositions (the extent is font‐dependent):
> 
>   + `choriz' (horizontal composition) optionally takes a `SEP' vector:
> 
>   #+begin_src calc
>   choriz([a b/c],"✕")
>   #+end_src
> 
>   #+begin_src text
>   1:  a✕b / c
>   #+end_src
> 
>   + Only the `crule' component of vertical compositions is affected,
>   which optionally takes a character to form the horizontal rule. For
>   example, comparing the em dash, hyphen-minus, and hyphen,
>   respectively, the hyphen rule isn’t full enough:
> 
>   #+begin_src calc
>   cvert([a + 1, cbase(crule("—")), b^2])
>   cvert([a + 1, cbase(crule("-")), b^2])
>   cvert([a + 1, cbase(crule("‐")), b^2])
>   #+end_src
> 
>   #+begin_src text
>   3:  a + 1
>       —————
>        b^2
>   2:  a + 1
>       -----
>        b^2
>   1:  a + 1
>       ‐‐‐‐‐
>        b^2
>   #+end_src
> 
>   + `cspace', `cvspace', `ctspace', `cbspace' all take strings as an
>   optional second argument to repeat some number of times, and will
>   behave similarly to `string' with respect to alignment.
> 
>   + `cwidth' counts characters, and will be different from the actual
>   length with variable-width characters or contextual forms. I’m less
>   familiar with vertically‐oriented scripts, but I imagine `cheight'
>   can suffer similarly with something like `cvspace'.
> 
>   + Any user‐defined compositions involving strings may be affected if
>   they make the same assumptions about string width, increase the
>   custom variable, and include offending characters.
> 
> + With the `calc-big-language' display mode (`d B'), but none of the
> other modes, pure RTL strings are aligned opposite to the LTR strings.
> 
> > In any case, to accept such a large contribution we'd need you to
> > sign the copyright assignment agreement (which you currently don't
> > have, AFAICT). If you are willing to do that, I will send you the
> > form to fill and the instructions to go with it.
> 
> That’s right, I haven’t signed the copyright assignment agreement yet,
> but I’m willing.

Thanks, since the copyright assignment paperwork is now done, I've
installed this on the master branch, and I'm closing the bug.