GNU bug report logs - #78528
[PATCH v1] calc: Allow strings with higher character codes

Previous Next

Full log

Message #22 received at 78528-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Jacob S. Gordon" <jacob.as.gordon <at> gmail.com>
Cc: 78528-done <at> debbugs.gnu.org
Subject: Re: bug#78528: [PATCH v1] calc: Allow strings with higher character
 codes
Date: Sat, 14 Jun 2025 17:12:34 +0300

> Date: Mon, 2 Jun 2025 15:28:16 -0400
> Cc: 78528 <at> debbugs.gnu.org
> From: "Jacob S. Gordon" <jacob.as.gordon <at> gmail.com>
> 
> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.