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

Previous Next

Full log

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

From: "Jacob S. Gordon" <jacob.as.gordon <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78528 <at> debbugs.gnu.org
Subject: Re: bug#78528: [PATCH v1] calc: Allow strings with higher character
 codes
Date: Mon, 2 Jun 2025 15:28:16 -0400

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,

-- 
Jacob S. Gordon
jacob.as.gordon <at> gmail.com

======================

Please avoid sending me HTML emails and MS Office documents.
https://useplaintext.email/#etiquette
https://www.gnu.org/philosophy/no-word-attachments.html

Previous Next

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