From debbugs-submit-bounces@debbugs.gnu.org Wed May 21 03:03:11 2025 Received: (at submit) by debbugs.gnu.org; 21 May 2025 07:03:11 +0000 Received: from localhost ([127.0.0.1]:43557 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uHdTp-0006vs-N8 for submit@debbugs.gnu.org; Wed, 21 May 2025 03:03:11 -0400 Received: from lists.gnu.org ([2001:470:142::17]:41676) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uHYLZ-0000w1-Re for submit@debbugs.gnu.org; Tue, 20 May 2025 21:34:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uHYLU-0000Hy-AO for bug-gnu-emacs@gnu.org; Tue, 20 May 2025 21:34:12 -0400 Received: from mail-qv1-xf2e.google.com ([2607:f8b0:4864:20::f2e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1uHYLQ-0007Zo-Np for bug-gnu-emacs@gnu.org; Tue, 20 May 2025 21:34:12 -0400 Received: by mail-qv1-xf2e.google.com with SMTP id 6a1803df08f44-6f8b10b807fso67420946d6.1 for ; Tue, 20 May 2025 18:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1747791246; x=1748396046; darn=gnu.org; h=mime-version:message-id:date:subject:to:from:from:to:cc:subject :date:message-id:reply-to; bh=OsJCxqlfJzc0MMxTZr3VMMCR+xDEIl57lSuFl220lsg=; b=MOvThC+9igSrcpVsLazQYxM+VWODSzxXqzsrQZHrAHL54TXxMC/Run70brOkU1V6gv Vj3ImyRtORpSljdyjBBskMKEYquWJe0wJ6sBeO6SNAzTKO96pkXIWgIB1PJPGST26IM9 +wXQvd5LIHC0ElN7n6b1WpTjiSXZKJfd9yJfQushskw7k7w1rSZYs7M3r+t2A5JOqmzo vzyxf1CdgrcoOCMihOklgsdduxb97YreKSl9gV3C+RibKaijGOnDXJG/6SpCoMA/+bbh ilyeiXSKbhDxfqFe/nTR4q7zhBSmFI+UEvz+IbgpFDCpxlfdKHgvfV01YQuNrmybgilj N/kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747791246; x=1748396046; h=mime-version:message-id:date:subject:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=OsJCxqlfJzc0MMxTZr3VMMCR+xDEIl57lSuFl220lsg=; b=dRxh8IXhcg8btjPBC+cbvFnqEC5byPKdaVZx1N2NPLaANOjowEvsU8Jyo4W/ZztvmX qo0WUPGd/bZRDadNM6LS8VYhnHqBSQd/AkeFlmVdK5BDSx8AlrQOOPwh7jdYTZLaTslJ L/TQUNxbC2JbMqbAFw58PpdfJ6bMn9VTsaKQYftmP6kuC5TTNCvebWnbL5CAqPGePi5t j2ojYSWrG4E0aXkXp/LFR7+rqxgTGjXyi7TUaFWq6v1jwPnO3Oz1tzJAG0tuWbPsYUXf 7RUsFZtcx4wCd1Z+3bxvfec/64QIExbL9SpdP+aIvpeK7XnyLAa19s22tw4vGaV1qK2D CGxw== X-Gm-Message-State: AOJu0YxRo/PGfeYE2s+ELSzjdsYA/WEO/8taMohyapuIrq5Dpx7yUfPG wtFncE/bGSYycYJZza/YmBN0yZlXa4WrW7G9hcgj6vumwNg9t0j/rmH5Ysrvxg== X-Gm-Gg: ASbGncv5fN6CnPmFXdwVa4SJIif6eOQ7URH3cUmVTdaP/ZU52HJvIoPJH7CxAjnqQe0 zzdn5EDOlW5j+tX8WV7oIBtdRIRpzCOjEImd/qyLoQzFSxFO9EYR00ZjSGKGjnZ3yzN1cpAJ0B2 TAOu0kwXLPGOh0ZJYRvxqiSqXynzjDPi3ViMBnzS6jHkwomtGbfRt2CQytYNkRvCuOUO7dRnwd8 XJEg2jnqauRHxNUaFth8G320nQpSkmz59/LdZmDEue/u8jtlfFIxT5rjY0NklroUPjyjjVriBUv Hw00bw/toaFBBvi1DF2F/nXkjZwWIVcTKcRJDMBe6o+IpYW+cx33kwFAR3goKbFjRXk2QjUXlfP WOxFTgn7W X-Google-Smtp-Source: AGHT+IEPfTLQVQeq5zIAKB5G0zBrLX0EdXW62aHaDiExOjem8JuooHQ+bXdMftxIUBwwHniiCIUL6g== X-Received: by 2002:a05:6214:20ab:b0:6f8:8fdf:f460 with SMTP id 6a1803df08f44-6f8b084af84mr286599236d6.9.1747791245462; Tue, 20 May 2025 18:34:05 -0700 (PDT) Received: from localhost (135-23-138-165.cpe.pppoe.ca. [135.23.138.165]) by smtp.gmail.com with UTF8SMTPSA id 6a1803df08f44-6f8b096dda9sm78737956d6.71.2025.05.20.18.34.04 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 May 2025 18:34:05 -0700 (PDT) From: "Jacob S. Gordon" To: bug-gnu-emacs@gnu.org Subject: [PATCH v1] calc: Allow strings with higher character codes Date: Tue, 20 May 2025 21:34:02 -0400 Message-ID: <87ldqqoigl.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=2607:f8b0:4864:20::f2e; envelope-from=jacob.as.gordon@gmail.com; helo=mail-qv1-xf2e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Wed, 21 May 2025 03:03:06 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Tags: patch Hello all, Please find below a feature proposal for strings in `calc', and a first draft of a patch attached to this message. Motivation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Suppose you're working with Unicode code points in `calc', and you end up with the following vector on the stack. You'd like to know what a string composed of these character codes would look like, so you toggle `calc-display-strings' (`d "') and =E2=80=A6 nothing happens. ,---- | 1: [383, 117, 99, 99, 101, 383, 115] `---- Later, in an `org-mode' file you have the following table with a list of dates in the first column. Since [formulas] can be any algebraic expression understood by `calc', and `calc' [understands dates], you try to insert a Unicode character for rows where the first column is in the past. When you evaluate the formula (`C-c C-c' on the `#+TBLFM:' line) `calc' stops short of displaying the string. ,---- | | Date | Past? | | |------------------+-----------------| | | [2025-05-01 Thu] | string([10003]) | | | [2026-05-01 Fri] | | | #+TBLFM: $2 =3D if($1 < now(), string("=E2=9C=93"), string("")) `---- Both of these problems are due to the fact that some or all of the character codes are outside the `Latin-1' (8-bit) range. If we replace this hard-coded limitation with a custom variable and increase its value, both of these use-cases can be supported. ,---- | 1: "=C5=BFucce=C5=BFs" `---- ,---- | | Date | Past? | | |------------------+-------| | | [2025-05-01 Thu] | =E2=9C=93 | | | [2026-05-01 Fri] | | | #+TBLFM: $2 =3D if($1 < now(), string("=E2=9C=93"), string("")) `---- The alternative is that the user has to exit `calc' (or its syntax) and dip into `Lisp': ,---- | (concat '(383 117 99 99 101 383 115)) `---- ,---- | | Date | Past? | | |------------------+-------| | | [2025-05-01 Thu] | =E2=9C=93 | | | [2026-05-01 Fri] | | | #+TBLFM: $2 =3D '(if (time-less-p (org-read-date t t $1) (current-time)) = "=E2=9C=93" "") `---- [formulas] [understands dates] Proposal & Impact =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The attached patch introduces a custom variable `calc-string-maximum-character' (optimistically versioned for `31.1'), which replaces a hard-coded maximum in the function `math-vector-is-string'. This variable defaults to `0xFF' in order to preserve the current behaviour, but otherwise can be any character up to `(max-char)'. Since the vector contents are passed to `math-vector-to-string', the Unicode-aware `concat' has no problem with the higher characters: ,---- | (defun math-vector-to-string (a &optional quoted) | (setq a (concat (mapcar (lambda (x) (if (consp x) (nth 1 x) x)) | (cdr a)))) | [=E2=80=A6]) `---- Here are the outstanding issues I've identified for discussion: 1. Since users can blow past the variable type and set `calc-string-maximum-character' to /anything/, I'm not sure the patch's error handling is enough. If a hapless user sets it to something invalid like a string (`"invalid"', let's say), then with the current patch they'll encounter at least two kinds of errors: a) With the following vector on the stack, executing `calc-display-strings' (`d "') will display `Wrong type argument: number-or-marker-p, "invalid"' in the minibuffer, /and/ enter a string display mode where the vector isn't rendered as seen in the second block below. ,---- | 1: [0, 1, 2] `---- ,---- | 1: . `---- Only executing `calc-display-strings' (`d "') again will toggle the display mode and show the original vector. This is a bad experience for the user, and should be mitigated by raising an error in `calc-display-strings' before the display mode is toggled. b) If a user tries to enter a string algebraically with `calc-algebraic-entry' (`''), say `string("abc")', the same message from the first error will appear in the minibuffer, but the string is not added to the stack. This is slightly cryptic, but not as bad an experience as the first error. 2. With a higher value of `calc-string-maximum-character', the displayed string could contain right-to-left or a bidirectional mixture of characters that could conceivably interfere with the `calc' alignment functions `calc-left-justify' (`d <'), `calc-center-justify' (`d =3D'), and `calc-right-justify' (`d >'). Toggling the display of the following vectors reveals a misalignment of the fully Arabic string under center justification, and misalignment of the full- and mixed-Arabic strings under right justification. None of these contain any of the funky bidirectional Unicode markers so I'm not sure if there's other problems lurking. ,---- | 3: [108, 101, 102, 116, 45, 116, 111, 45, 114, 105, 103, 104, 116] | 2: [1605, 1606, 32, 1575, 1604, 1610, 1605, 1610, 1606, 32, 1573, 160= 4, 1609, 32, 1575, 1604, 1610, 1587, 1575, 1585] | 1: [108, 101, 102, 116, 45, 1610, 1605, 1610, 1606] `---- ,---- | 3: "left-to-right" | 2: "=D9=85=D9=86 =D8=A7=D9=84=D9=8A=D9=85=D9=8A=D9=86 =D8=A5=D9=84=D9= =89 =D8=A7=D9=84=D9=8A=D8=B3=D8=A7=D8=B1" | 1: "left-=D9=8A=D9=85=D9=8A=D9=86" `---- ,---- | 3: "left-to-right" | 2: "=D9=85=D9=86 =D8=A7=D9=84=D9=8A=D9=85=D9=8A=D9= =86 =D8=A5=D9=84=D9=89 =D8=A7=D9=84=D9=8A=D8=B3=D8=A7=D8=B1" | 1: "left-=D9=8A=D9=85=D9=8A=D9=86" `---- ,---- | 3: "left-to-right" | 2: "=D9=85=D9=86 =D8=A7=D9=84= =D9=8A=D9=85=D9=8A=D9=86 =D8=A5=D9=84=D9=89 =D8=A7=D9=84=D9=8A=D8=B3=D8=A7= =D8=B1" | 1: "left-=D9=8A=D9= =85=D9=8A=D9=86" `---- Also, combining diacritical marks appear as separate characters, but I'm not sure if this is the expected behaviour and/or related to my configuration. ,---- | 1. [117, 776] `---- ,---- | 1: "u=CC=88" `---- 3. I haven't found any internal references to `math-vector-is-string' that look like they could conflict with this change (`math-format-flat-expr-fancy', `math-compose-expr', `calc-kbd-query'). Existing references are mostly related to displaying strings from vectors, `string' or `bstring' objects, and composite objects involving vectors or strings, but I could use an extra set of eyes to confirm. Since `org-mode' uses `calc' expressions in tables, I might need to get their concurrence with the change. I'm unaware of any third-party dependencies on this function. 4. For unit tests, are there any naming conventions I should follow? I just stuck all of the tests in one place for `math-vector-is-string'. Thanks for your consideration! -- Jacob S. Gordon jacob.as.gordon@gmail.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please avoid sending me HTML emails and MS Office documents. https://useplaintext.email/#etiquette https://www.gnu.org/philosophy/no-word-attachments.html In GNU Emacs 30.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.49, cairo version 1.18.4) System Description: Arch Linux Configured using: 'configure --with-pgtk --sysconfdir=3D/etc --prefix=3D/usr --libexecdir=3D/usr/lib --localstatedir=3D/var --disable-build-details --with-cairo --with-harfbuzz --with-libsystemd --with-modules --with-native-compilation=3Daot --with-tree-sitter 'CFLAGS=3D-march=3Dx86-= 64 -mtune=3Dgeneric -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3D3 -Wformat -Werror=3Dformat-security -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -g -ffile-prefix-map=3D/build/emacs/src=3D/usr/src/debug/emacs -flto=3Dauto' 'LDFLAGS=3D-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,-z,pack-relative-relocs -flto=3Dauto' 'CXXFLAGS=3D-march=3Dx86-64 -mtune=3Dgeneric -O2 -pipe -fno-plt -fexceptio= ns -Wp,-D_FORTIFY_SOURCE=3D3 -Wformat -Werror=3Dformat-security -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Wp,-D_GLIBCXX_ASSERTIONS -g -ffile-prefix-map=3D/build/emacs/src=3D/usr/src/debug/emacs -flto=3Dauto'' --=-=-= Content-Type: text/patch Content-Disposition: attachment; filename=v1-0001-calc-Allow-strings-with-higher-character-codes.patch >From ffc1813155f8e23db271c01c249c163912ecf377 Mon Sep 17 00:00:00 2001 From: "Jacob S. Gordon" Date: Mon, 19 May 2025 15:05:37 -0400 Subject: [PATCH v1] calc: Allow strings with higher character codes The current behavior of the functions 'calc-display-strings', 'strings', and 'bstrings' is to skip any vector containing integers outside the Latin-1 range (0x00-0xFF). We introduce a custom variable 'calc-string-maximum-character' to replace this hard-coded maximum, and to allow vectors containing higher character codes to be displayed as strings. The default value of 0xFF preserves the existing behavior. * lisp/calc/calc.el (calc-string-maximum-character): Add custom variable 'calc-string-maximum-character'. * lisp/calc/calccomp.el (math-vector-is-string): Replace hard-coded maximum with 'calc-string-maximum-character', and the 'natnump' assertion with 'characterp'. The latter guards against the maximum being larger than '(max-char)', but not on invalid types of the maximum such as strings. * test/lisp/calc/calc-tests.el (calc-math-vector-is-string): Add tests for 'math-vector-is-string' using different values of 'calc-string-maximum-character'. * doc/misc/calc.texi (Quick Calculator, Strings, Customizing Calc): Add variable definition for 'calc-string-maximum-character' and reference thereof when discussing 'calc-display-strings'. Generalize a comment about string display and availability of 8-bit fonts. --- doc/misc/calc.texi | 56 +++++++++++++++++++++++------- etc/NEWS | 13 ++++++- lisp/calc/calc.el | 31 +++++++++++++++++ lisp/calc/calccomp.el | 15 +++++--- test/lisp/calc/calc-tests.el | 67 ++++++++++++++++++++++++++++++++++++ 5 files changed, 164 insertions(+), 18 deletions(-) diff --git a/doc/misc/calc.texi b/doc/misc/calc.texi index 61466b55201..eda442ecb38 100644 --- a/doc/misc/calc.texi +++ b/doc/misc/calc.texi @@ -10179,7 +10179,7 @@ Quick Calculator is displayed only according to the current mode settings. But running Quick Calc again and entering @samp{120} will produce the result @samp{120 (16#78, 8#170, x)} which shows the number in its -decimal, hexadecimal, octal, and ASCII forms. +decimal, hexadecimal, octal, and character forms. Please note that the Quick Calculator is not any faster at loading or computing the answer than the full Calculator; the name ``quick'' @@ -10836,11 +10836,11 @@ Strings @cindex Strings @cindex Character strings Character strings are not a special data type in the Calculator. -Rather, a string is represented simply as a vector all of whose -elements are integers in the range 0 to 255 (ASCII codes). You can -enter a string at any time by pressing the @kbd{"} key. Quotation -marks and backslashes are written @samp{\"} and @samp{\\}, respectively, -inside strings. Other notations introduced by backslashes are: +Rather, a string is represented simply as a vector all of whose elements +are integers in the Latin-1 range 0 to 255. You can enter a string at +any time by pressing the @kbd{"} key. Quotation marks and backslashes +are written @samp{\"} and @samp{\\}, respectively, inside strings. +Other notations introduced by backslashes are: @example @group @@ -10857,21 +10857,24 @@ Strings @noindent Finally, a backslash followed by three octal digits produces any -character from its ASCII code. +character from its code. @kindex d " @pindex calc-display-strings Strings are normally displayed in vector-of-integers form. The @w{@kbd{d "}} (@code{calc-display-strings}) command toggles a mode in which any vectors of small integers are displayed as quoted strings -instead. +instead. The display of strings containing higher character codes can +be enabled by increasing the custom variable +@code{calc-string-maximum-character} (@pxref{Customizing Calc}). The backslash notations shown above are also used for displaying -strings. Characters 128 and above are not translated by Calc; unless -you have an Emacs modified for 8-bit fonts, these will show up in -backslash-octal-digits notation. For characters below 32, and -for character 127, Calc uses the backslash-letter combination if -there is one, or otherwise uses a @samp{\^} sequence. +strings. For ASCII control characters (below 32), and for the +@code{DEL} character (127), Calc uses the backslash-letter combination +if there is one, or otherwise uses a @samp{\^} sequence. Control +characters above 127 are not translated by Calc, and will show up in +backslash-octal-digits notation. The display of higher character codes +will depend on your display settings and system font coverage. The only Calc feature that uses strings is @dfn{compositions}; @pxref{Compositions}. Strings also provide a convenient @@ -35684,6 +35687,33 @@ Customizing Calc The default value of @code{calc-gregorian-switch} is @code{nil}. @end defvar +@defvar calc-string-maximum-character +@xref{Strings}.@* + +The variable @code{calc-string-maximum-character} is the maximum value +of a vector's elements for @code{calc-display-strings}, @code{string}, +and @code{bstring} to display the vector as a string. This maximum +@emph{must} represent a character, i.e. it's a non-negative integer less +than or equal to @code{(max-char)} or @code{0x3FFFFF}. Any negative +value effectively disables the display of strings, and for values larger +than @code{0x3FFFFF} the display acts as if the maximum were +@code{0x3FFFFF}. Some natural choices (and their resulting ranges) are: + +@itemize +@item +@code{0x7F} or 127 (ASCII), +@item +@code{0xFF} or 255 (Latin-1, the default), +@item +@code{0x10FFFF} (Unicode), +@item +@code{0x3FFFFF} (Emacs). +@end itemize + +The default value of @code{calc-string-maximum-character} is @code{0xFF} +or 255. +@end defvar + @node Reporting Bugs @appendix Reporting Bugs diff --git a/etc/NEWS b/etc/NEWS index 4ad6c48d78a..58d0c18b2ba 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -2106,7 +2106,18 @@ is bound to 'C-l' in the calendar buffer. You can now use the mouse wheel to scroll the calendar by 3 months. With the shift modifier, it scrolls by one month. With the meta modifier, it scrolls by year. - + +** Calc + +*** New user option 'calc-string-maximum-character'. + +Previously, the 'calc-display-strings', 'string', and 'bstring' +functions only considered integer vectors whose elements are all in the +Latin-1 range 0-255. This hard-coded maximum is replaced by +'calc-string-maximum-character', and setting it to a higher value allows +the display of matching vectors as Unicode strings. The default value is +'0xFF' or '255' to preserve the existing behavior. + * New Modes and Packages in Emacs 31.1 ** New minor mode 'delete-trailing-whitespace-mode'. diff --git a/lisp/calc/calc.el b/lisp/calc/calc.el index a7bd671998e..a350419b320 100644 --- a/lisp/calc/calc.el +++ b/lisp/calc/calc.el @@ -628,6 +628,37 @@ calc-infinite-mode (defcalcmodevar calc-display-strings nil "If non-nil, display vectors of byte-sized integers as strings.") +(defcustom calc-string-maximum-character #xFF + "Maximum value of vector contents to be displayed as a string. + +If a vector consists of characters up to this maximum value, the +function `calc-display-strings' will toggle displaying the vector as a +string. This maximum value must represent a character (see `characterp'). +Some natural choices (and their resulting ranges) are: + +- `0x7F' (`ASCII'), +- `0xFF' (`Latin-1', the default), +- `0x10FFFF' (`Unicode'), +- `0x3FFFFF' (`Emacs'). + +Characters for low control codes are either caret or backslash escaped, +while others without a glyph are displayed in backslash-octal notation. +The display of strings containing higher character codes will depend on +your display settings and system font coverage. + +See the following for further information: + +- info node `(calc)Strings', +- info node `(elisp)Text Representations', +- info node `(emacs)Text Display'." + :version "31.1" + :type '(choice (restricted-sexp :tag "Character Code" + :match-alternatives (characterp)) + (const :tag "ASCII" #x7F) + (const :tag "Latin-1" #xFF) + (const :tag "Unicode" #x10FFFF) + (const :tag "Emacs" #x3FFFFF))) + (defcalcmodevar calc-matrix-just 'center "If nil, vector elements are left-justified. If `right', vector elements are right-justified. diff --git a/lisp/calc/calccomp.el b/lisp/calc/calccomp.el index cc27e6c2025..7e1f8378d80 100644 --- a/lisp/calc/calccomp.el +++ b/lisp/calc/calccomp.el @@ -907,13 +907,20 @@ math-compose-rows (concat " " math-comp-right-bracket))))) (defun math-vector-is-string (a) + "Return t if A can be displayed as a string, and nil otherwise. + +Elements of A must either be a character (see `characterp') or a complex +number with only a real character part, each with a value less than or +equal to the custom variable `calc-string-maximum-character'." (while (and (setq a (cdr a)) - (or (and (natnump (car a)) - (<= (car a) 255)) + (or (and (characterp (car a)) + (<= (car a) + calc-string-maximum-character)) (and (eq (car-safe (car a)) 'cplx) - (natnump (nth 1 (car a))) + (characterp (nth 1 (car a))) (eq (nth 2 (car a)) 0) - (<= (nth 1 (car a)) 255))))) + (<= (nth 1 (car a)) + calc-string-maximum-character))))) (null a)) (defconst math-vector-to-string-chars '( ( ?\" . "\\\"" ) diff --git a/test/lisp/calc/calc-tests.el b/test/lisp/calc/calc-tests.el index 42eb6077b04..2fd6a6be45e 100644 --- a/test/lisp/calc/calc-tests.el +++ b/test/lisp/calc/calc-tests.el @@ -879,5 +879,72 @@ calc-math-read-preprocess-string (should-error (math-read-preprocess-string nil)) (should-error (math-read-preprocess-string 42))) +(ert-deftest calc-math-vector-is-string () + "Test `math-vector-is-string' with varying `calc-string-maximum-character'. + +All tests operate on both an integer vector and the corresponding +complex vector. The sets covered are: + +1. `calc-string-maximum-character' is a valid character. The last case +with `0x3FFFFF' is borderline, as integers above it will not make it +past the `characterp' test. +2. `calc-string-maximum-character' is negative, so the test always fails. +3. `calc-string-maximum-character' is above `(max-char)', so only the +first `characterp' test is active. +4. `calc-string-maximum-character' has an invalid type, which triggers +an error in the comparison." + (cl-flet* ((make-vec (lambda (contents) (append (list 'vec) contents))) + (make-cplx (lambda (x) (list 'cplx x 0))) + (make-cplx-vec (lambda (contents) + (make-vec (mapcar #'make-cplx contents))))) + ;; 1: calc-string-maximum-character is a valid character + (dolist (maxchar '(#x7F #xFF #x10FFFF #x3FFFFD #x3FFFFF)) + (let* ((calc-string-maximum-character maxchar) + (small-chars (number-sequence (- maxchar 2) maxchar)) + (large-chars (number-sequence maxchar (+ maxchar 2))) + (small-real-vec (make-vec small-chars)) + (large-real-vec (make-vec large-chars)) + (small-cplx-vec (make-cplx-vec small-chars)) + (large-cplx-vec (make-cplx-vec large-chars))) + (should (math-vector-is-string small-real-vec)) + (should-not (math-vector-is-string large-real-vec)) + (should (math-vector-is-string small-cplx-vec)) + (should-not (math-vector-is-string large-cplx-vec)))) + ;; 2: calc-string-maximum-character is negative + (let* ((maxchar -1) + (calc-string-maximum-character maxchar) + (valid-contents (number-sequence 0 2)) + (invalid-contents (number-sequence (- maxchar 2) maxchar)) + (valid-real-vec (make-vec valid-contents)) + (invalid-real-vec (make-vec invalid-contents)) + (valid-cplx-vec (make-cplx-vec valid-contents)) + (invalid-cplx-vec (make-cplx-vec invalid-contents))) + (should-not (math-vector-is-string valid-real-vec)) + (should-not (math-vector-is-string invalid-real-vec)) + (should-not (math-vector-is-string valid-cplx-vec)) + (should-not (math-vector-is-string invalid-cplx-vec))) + ;; 3: calc-string-maximum-character is larger than (max-char) + (let* ((maxchar (+ (max-char) 3)) + (calc-string-maximum-character maxchar) + (valid-chars (number-sequence (- (max-char) 2) (max-char))) + (invalid-chars (number-sequence (1+ (max-char)) maxchar)) + (valid-real-vec (make-vec valid-chars)) + (invalid-real-vec (make-vec invalid-chars)) + (valid-cplx-vec (make-cplx-vec valid-chars)) + (invalid-cplx-vec (make-cplx-vec invalid-chars))) + (should (math-vector-is-string valid-real-vec)) + (should-not (math-vector-is-string invalid-real-vec)) + (should (math-vector-is-string valid-cplx-vec)) + (should-not (math-vector-is-string invalid-cplx-vec))) + ;; 4: calc-string-maximum-character has the wrong type + (let* ((calc-string-maximum-character "wrong type") + (contents (number-sequence 0 2)) + (real-vec (make-vec contents)) + (cplx-vec (make-cplx-vec contents))) + (should-error (math-vector-is-string real-vec) + :type 'wrong-type-argument) + (should-error (math-vector-is-string cplx-vec) + :type 'wrong-type-argument)))) + (provide 'calc-tests) ;;; calc-tests.el ends here base-commit: 87fa5f565d70c514bd47b59bb0ef0cba8750e983 -- Jacob S. Gordon jacob.as.gordon@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 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri May 30 14:11:02 2025 Received: (at submit) by debbugs.gnu.org; 30 May 2025 18:11:02 +0000 Received: from localhost ([127.0.0.1]:50536 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uL4C5-0000qD-Gb for submit@debbugs.gnu.org; Fri, 30 May 2025 14:11:02 -0400 Received: from lists.gnu.org ([2001:470:142::17]:52742) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uKzQE-0002uf-22 for submit@debbugs.gnu.org; Fri, 30 May 2025 09:05:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uKzQ3-0005RS-IY for bug-gnu-emacs@gnu.org; Fri, 30 May 2025 09:05:07 -0400 Received: from mail-qt1-x831.google.com ([2607:f8b0:4864:20::831]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1uKzQ1-0003R4-68 for bug-gnu-emacs@gnu.org; Fri, 30 May 2025 09:05:06 -0400 Received: by mail-qt1-x831.google.com with SMTP id d75a77b69052e-4766cb762b6so21610541cf.0 for ; Fri, 30 May 2025 06:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748610303; x=1749215103; darn=gnu.org; h=content-transfer-encoding:in-reply-to:content-language:references :to:from:subject:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=1AObCn3uKDDnAjBdE3xXj8KhTomNkmHxMKZV6qo9bRQ=; b=JeoFN1zAFXC21Hmzry3Ag8C/cD6pHHpqx0lXrY8DCKIhaui3E7Qfm4IGHIcU/gzjZm yMFawOhtknS8stH8veYloizjegRjk2cQrYXxThMhBI/e9MfqZKjyW5Q6eguA27i7aRPb gHFrt6U6H0yvw2zUc1vZO3OL9yE0fT/aPPMtui8AGCVV6GR3Ue6KU0mCku62mISULzXm x9lsFQ55OwSS7uy+biXR41deBauReG6tlIz7P8b7tUw6Yv9BGpxYAus3rBp6OwQOhqoH 7aSSTiFXieOhW0DGhitC/xy4qkYQn/cJPUyEHXMCyw5ZqqZCNLnSJcVQ6O81CI4VZQ4a qqjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748610303; x=1749215103; h=content-transfer-encoding:in-reply-to:content-language:references :to:from:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1AObCn3uKDDnAjBdE3xXj8KhTomNkmHxMKZV6qo9bRQ=; b=SyCPORiE76NKfHTDedYXbDzsQCTE851f04TpQFDjZOoRa5ZaEtgzbA4SwMrt907wtW KIuljZ5g+VMDJ8OGlv/utKdu5jcuGrzGYUf6wrzQqi7AUpEx/irtJxdJJTZI9PGkkwMZ eh6p2MitS23aER2mQrUw0ctVkgIZCxrpLGTomLL2D8UyktwpBA7kjRg+c+J49Ns1elQM cNXel4y1nNQ7MC43E3fX5zQRx3e1GzYPkKgGdalASq5mI30SvQuD5NpkERwpN2tFwPjJ Im6bc+HhXOy3VrmJ+PEPzlry59c3kyN4iAlPyPdOAPNQ99dH5vIRU4DOcXsLv8jtWzpX fliQ== X-Gm-Message-State: AOJu0Yy4ni5siT6sfTMPcjd0Rr2hDduJOCK8ejcNcx2N3//3OFeG3uDm l3LDSas72GzjUwx7d/r/oGWoZSzyA3xt+LO0pnOn1j+S2Es7wpWPmSdGqLTFdw== X-Gm-Gg: ASbGncsxufWkBUArOSwINbXiKbNc+H/NpmKma0/C56gdhTCwxu/9vlbTm1u/eEYAphU 5PgDxN9GTdEcJPYlfT5dvoi7rEkUHYhqMY9vJIzPh5fx6XsvMGpsB3SHHcbJAz4vwqTs4Wky00H JujFJ8oVpsTEB9Lb/uPIdu61yTOCZfjKJ5cMmnGnnQG9uaFxVQCQtt6MDXmCeJ4IyfhBITPnS7u O6jnuG2uxJHdq5DtukIl4JfWiFUn4LuN5etaRQPkGZwbv7Chvn3hoxjIiBj8wd8Qc/hAmeOy619 KHYsE+xnepeLP/onjQriSMUiYyq/LUBMFl1A+gv+xMNlBwHrr+5j6+8l0w4x8JG3L3PWS00jvQp UVyuL7+1tAS9hmrs= X-Google-Smtp-Source: AGHT+IEGv5Zceq0UkJkIxiy2pekb8eQiBH787LTeP8PiwnFsAgdG0Zm6TlrA7Vbv73cUzhEpKRKnSg== X-Received: by 2002:a05:622a:5c90:b0:494:7347:d73f with SMTP id d75a77b69052e-4a440958de6mr60786131cf.11.1748610303028; Fri, 30 May 2025 06:05:03 -0700 (PDT) Received: from [192.168.1.10] (135-23-138-165.cpe.pppoe.ca. [135.23.138.165]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-4a435a840bdsm19582741cf.77.2025.05.30.06.05.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 May 2025 06:05:02 -0700 (PDT) Message-ID: <50b8dbc6-c4c3-495f-bd88-1a600ee793d4@gmail.com> Date: Fri, 30 May 2025 09:05:01 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1] calc: Allow strings with higher character codes From: "Jacob S. Gordon" To: bug-gnu-emacs@gnu.org References: <87ldqqoigl.fsf@gmail.com> Content-Language: en-CA In-Reply-To: <87ldqqoigl.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=2607:f8b0:4864:20::831; envelope-from=jacob.as.gordon@gmail.com; helo=mail-qt1-x831.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Fri, 30 May 2025 14:11:00 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hello again, On 2025-05-20 21:34, Jacob S. Gordon wrote: > Please find below a feature proposal for strings in `calc', and a first > draft of a patch attached to this message. Any thoughts on this patch? -- Jacob S. Gordon jacob.as.gordon@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 From debbugs-submit-bounces@debbugs.gnu.org Sat May 31 02:27:22 2025 Received: (at 78528) by debbugs.gnu.org; 31 May 2025 06:27:23 +0000 Received: from localhost ([127.0.0.1]:54710 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uLFgf-0006Ng-EB for submit@debbugs.gnu.org; Sat, 31 May 2025 02:27:22 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34934) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uLFgd-0006MJ-5J for 78528@debbugs.gnu.org; Sat, 31 May 2025 02:27:19 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uLFgX-0000nG-OZ; Sat, 31 May 2025 02:27:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=lyNOPVS0dM+fNfT9zQvzPXX2jKj1hI8a3Y4Xh7gD0gA=; b=pj9NBw0HThIq XdkylSAQBkTX8EA1z+J/7JVwli1lncJZ88Jqu/zvMuhc1Eg4RL1NnrSeOo2QErnY+rpGwtuODDXdK pCLj9Rf5k+zLPwerDoYJHb+rP4twsRwZ2MJh+24TWKsEj/WX77uc+U2TMrvuM/QTx09zvyTxAQsA/ UKrAl7dI70oRZ/MNnGxJGfW1Gv8rAwQwPBi4+carUk5i4aRhPmyUacZcRByuFAIzBuG6gH59vQAL1 +Y1VPvEyACzYK18+IIb3OUDDfnZPRIRp5SEIV6a4SVcweEqmZuanyKzuHvRAlglYN/1q999DzPEu9 xljetYcbBiCHcd9xhnJ6bw==; Date: Sat, 31 May 2025 09:27:11 +0300 Message-Id: <867c1xthvk.fsf@gnu.org> From: Eli Zaretskii To: "Jacob S. Gordon" In-Reply-To: <50b8dbc6-c4c3-495f-bd88-1a600ee793d4@gmail.com> (jacob.as.gordon@gmail.com) Subject: Re: bug#78528: [PATCH v1] calc: Allow strings with higher character codes References: <87ldqqoigl.fsf@gmail.com> <50b8dbc6-c4c3-495f-bd88-1a600ee793d4@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78528 Cc: 78528@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 30 May 2025 09:05:01 -0400 > From: "Jacob S. Gordon" > > Hello again, > > On 2025-05-20 21:34, Jacob S. Gordon wrote: > > Please find below a feature proposal for strings in `calc', and a first > > draft of a patch attached to this message. > > Any thoughts on this patch? It's in my (too long, admittedly) queue. Can you think of any possible downsides to installing the patch? 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. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 03 00:00:40 2025 Received: (at 78528) by debbugs.gnu.org; 3 Jun 2025 04:00:41 +0000 Received: from localhost ([127.0.0.1]:58558 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uMIpK-00086Z-Fe for submit@debbugs.gnu.org; Tue, 03 Jun 2025 00:00:40 -0400 Received: from mail-qt1-x82a.google.com ([2607:f8b0:4864:20::82a]:43042) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uMApb-0005NP-My for 78528@debbugs.gnu.org; Mon, 02 Jun 2025 15:28:24 -0400 Received: by mail-qt1-x82a.google.com with SMTP id d75a77b69052e-4a42f28017eso58585591cf.0 for <78528@debbugs.gnu.org>; Mon, 02 Jun 2025 12:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748892498; x=1749497298; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=jkBF4goLsy0uIrfXQwnVcYwrk+/v1hJvsPIns+becyU=; b=DYOdCID8YvWQvWNHCaBNHS1X08g/gcC6089ZX8t/1C4oNW/yce+xKF2f0dSwND1tb5 DOF9DTPPki/SI+KwLp12OnHJBT17EN3rkQtOq+ViD/a0PM/lHDfEpYBr2cdTm6HEsCwN 7UJTPCbO1qf3M6gpJ10iVazFH882pWPT+g81kXXZZZedss1NpfKdudc3rP0B0GxF77EI vz13dG92sOROp0j5QvRhVRODihkHPCwXFRL83AF48pNpnCoLG8HPDbo8RJQ+MsTEIetG vsFIu9S7BuPYZ7i3I9Mqgbc4K7XeQG6nwKP68D/BscXuTbSIulwJIOa8Ki563+Garhvj K3wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748892498; x=1749497298; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jkBF4goLsy0uIrfXQwnVcYwrk+/v1hJvsPIns+becyU=; b=rdJk1oHU0F2Uin6w+5FGZVMqbZWjLvevC62IwhDMTAZEJT7VbYL9kh1UezcU5KEiot HzYRlxYal7tURLb8YzfBPa25buu3/D0TueJqPXHVgZqHYZVBxiRgXzwcCQ8uS/3CbNw9 Sv/YGg6ElUphyPCl7y3C4bQL98CAfM2EA9wEUcjFOblYlB8iPOHeG1+mS6hnB6p4uzN7 8YY5yKUXUCFFazZXvjHTsIMWT2mb27lctQIYLXCPOg2N/0yVnWvPbnj7IVLQEDwu8j7+ HerUuj5fCBF/diDMCA3nTN3a4O7uDvPfw/HuY7nigTWNxkYtYP3lb9q5TfUpkdj+GQMt GYNA== X-Gm-Message-State: AOJu0Yw/GjUyC++JBzB90pMiE3Zp8uc3uHhEanrRjpG5cmRXwf83Kwml CfmalX5EtjjOKPrzRdoX4MtuFhG2qZ/RqKOIDLYG/Dz/p9xSzOTY7JS6 X-Gm-Gg: ASbGncsFzf/4kSGJVnUgoRLw8uGSOYeKT+NlZoVS/dygIZIiWx9v2QGtHJ77vC/2Lfb kOHARNeJbgk6uctfj4Rs5tK/Zxonp54b7lgUHFP9gPR2YNGt7T4/TvQSZRx9MagwVU6A8mECihz mL27eLVBPINcg7vnMTIVx/Hoj+dIkZnUztvyFXLSJ2lv/C9HlaNQAEwnfYBh56OWNldg5JhDHit wxQa9XuYi/c+a9HDSI0ZW58xo2WvqS2as6rzxCdf6FYJkqAZueClk+wpOAASHbjrO5P232i8ITz 3ZUbTFGSKWrRIzteeqyi0Gv/asa0SAOzLpwetFk6Amu8WhPuIn7x9tuYEaAKTDAgGW2s1PC/6Vb Syp5cq25yfEjS74lOZXxKjPjRT+HCGg9YSoUi X-Google-Smtp-Source: AGHT+IFS2ZelIdaC1P9+MNkdXujqLxTdXrQwCdDWp4xwCFrqMVKXwcRqDJWPi053jU7h8emgwPdpVA== X-Received: by 2002:a05:6214:242f:b0:6f5:4dfa:6944 with SMTP id 6a1803df08f44-6faed795ec2mr12767556d6.3.1748892497771; Mon, 02 Jun 2025 12:28:17 -0700 (PDT) Received: from [192.168.1.10] (135-23-138-165.cpe.pppoe.ca. [135.23.138.165]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6fac6d4c91esm65692876d6.32.2025.06.02.12.28.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jun 2025 12:28:17 -0700 (PDT) Message-ID: <26591d0e-3c8e-462b-b99d-530c0831aabe@gmail.com> Date: Mon, 2 Jun 2025 15:28:16 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#78528: [PATCH v1] calc: Allow strings with higher character codes To: Eli Zaretskii References: <87ldqqoigl.fsf@gmail.com> <50b8dbc6-c4c3-495f-bd88-1a600ee793d4@gmail.com> <867c1xthvk.fsf@gnu.org> From: "Jacob S. Gordon" Content-Language: en-CA In-Reply-To: <867c1xthvk.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78528 X-Mailman-Approved-At: Tue, 03 Jun 2025 00:00:37 -0400 Cc: 78528@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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@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 From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 03 07:42:14 2025 Received: (at 78528) by debbugs.gnu.org; 3 Jun 2025 11:42:14 +0000 Received: from localhost ([127.0.0.1]:32826 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uMQ22-0005PP-1p for submit@debbugs.gnu.org; Tue, 03 Jun 2025 07:42:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41960) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uMQ1z-0005Ot-1c for 78528@debbugs.gnu.org; Tue, 03 Jun 2025 07:42:11 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uMQ1s-0007Qp-57; Tue, 03 Jun 2025 07:42:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=1LMjuliqXIljZeCi0bxdPQPFKUNf/pk4UzkUjsqaRwE=; b=dTjwX81G0mx7WWpro9fg lYwhLo8mnO4E4ZKR5wv582O6MPUtH2wvS6c70Jp414G+ehKRZIXBC+3lpr69/C+TRIRnjw0yMKcml ZLm9iFwlmV7de8OaeNF43MUe3YJiRvAHSZZTVifKt06ZxxlB3z8fcL53XG/coMP7xPNGLEbtQSytb QbHM0S/Q5l0epNAJJpGTymZ03ah9oAhn+MgwXo9rzcusqqIoKrae9aVcUNzKj9k5fSwHTo0YhQVVW uO2UFa3Ssr4gotbmMVns45oA2xiotuU2ptivi4cq9ltWZ4CZsQq4fApINEZ/NsJ8nzQyrNnTi6GMz isLHUTrtw7GeTg==; Date: Tue, 03 Jun 2025 14:42:01 +0300 Message-Id: <86o6v5njau.fsf@gnu.org> From: Eli Zaretskii To: "Jacob S. Gordon" In-Reply-To: <26591d0e-3c8e-462b-b99d-530c0831aabe@gmail.com> (jacob.as.gordon@gmail.com) Subject: Re: bug#78528: [PATCH v1] calc: Allow strings with higher character codes References: <87ldqqoigl.fsf@gmail.com> <50b8dbc6-c4c3-495f-bd88-1a600ee793d4@gmail.com> <867c1xthvk.fsf@gnu.org> <26591d0e-3c8e-462b-b99d-530c0831aabe@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78528 Cc: 78528@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 2 Jun 2025 15:28:16 -0400 > Cc: 78528@debbugs.gnu.org > From: "Jacob S. Gordon" > > > 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, form sent off-list. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 14 10:13:08 2025 Received: (at 78528-done) by debbugs.gnu.org; 14 Jun 2025 14:13:09 +0000 Received: from localhost ([127.0.0.1]:39690 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQRd3-0002TK-Qf for submit@debbugs.gnu.org; Sat, 14 Jun 2025 10:13:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41116) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQRcf-0002Qo-Ci for 78528-done@debbugs.gnu.org; Sat, 14 Jun 2025 10:13:01 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uQRcZ-0006Pm-MU; Sat, 14 Jun 2025 10:12:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=O8cdsDgplCMmnCRx3KXmFhqREefmrU6pwJApTfqTchw=; b=cHJr/Z8gQ9WKST3s1HI3 eokLM4pNpe0vEJMzP6wLhPbapadxF16aP367UnyEi7gpL6X9W7mopbdZdJHZmPUvtt0ORmzFJRJje KGlg7Fb6jrnFZqeBEjhEhE+abCpyRvD7rTboYgjxgcB2Uc7OYaoa4KHvXJTw1CidSe5Cm0b+Whbcf VQUwXIcqesdY2na5nbwBorbzTUUrTaUhJhlpz1glkGKNiiAGwHa1PuJMOsBIAvdxJu2JO4bkEYRkp EFkICtZJZKdrg/8sHfcOEXgPmypsi55Tz4boIoavfUSckqwXKBMxnzqta7N70ElDrMGIEXOeNJN3s 0xZFTLozIHEt1Q==; Date: Sat, 14 Jun 2025 17:12:34 +0300 Message-Id: <864iwis97x.fsf@gnu.org> From: Eli Zaretskii To: "Jacob S. Gordon" In-Reply-To: <26591d0e-3c8e-462b-b99d-530c0831aabe@gmail.com> (jacob.as.gordon@gmail.com) Subject: Re: bug#78528: [PATCH v1] calc: Allow strings with higher character codes References: <87ldqqoigl.fsf@gmail.com> <50b8dbc6-c4c3-495f-bd88-1a600ee793d4@gmail.com> <867c1xthvk.fsf@gnu.org> <26591d0e-3c8e-462b-b99d-530c0831aabe@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78528-done Cc: 78528-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 2 Jun 2025 15:28:16 -0400 > Cc: 78528@debbugs.gnu.org > From: "Jacob S. Gordon" > > 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 14 10:54:30 2025 Received: (at 78528-done) by debbugs.gnu.org; 14 Jun 2025 14:54:30 +0000 Received: from localhost ([127.0.0.1]:40163 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQSH7-0000qO-8N for submit@debbugs.gnu.org; Sat, 14 Jun 2025 10:54:30 -0400 Received: from mail-qv1-xf35.google.com ([2607:f8b0:4864:20::f35]:47378) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uQSH3-0000p9-M7 for 78528-done@debbugs.gnu.org; Sat, 14 Jun 2025 10:54:27 -0400 Received: by mail-qv1-xf35.google.com with SMTP id 6a1803df08f44-6fae04a3795so32900596d6.3 for <78528-done@debbugs.gnu.org>; Sat, 14 Jun 2025 07:54:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749912860; x=1750517660; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:cc:content-language:from :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=IF23frT4iD5WCFohYy7LDZvLMfeJY72llZpBeHpFJzg=; b=Vz9hueUUfMWMCduSrhPrWqXaz8F43R0/rRLZHHnZ6zzalboRtgiTcoJnBOlHpmbGf4 AScEDQv3J5e80vO2vfQN1DE43d/5BSPL/rtSvXzlQxm9HiuDROINU0sHnPRqujZ4KE5I rZK7zp9IaLuKsQr18YkwS1Bzh4vstkKvt0e7b2LoDZO0KcZMrOOtO4xvURP8yLMtCPrK koby7NhojY4S1TeCBeUptbUHobw7Y1BymZNe8BrzSS9wgPHbmIFWfyHYJs4LXzyg91O9 Gsl0ghcytqbKfRgbGXxKkcPrLf8CaYyD3mZKvy6ropiWlUah8mXH+9RiIvtR+aLy99ma PT3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749912860; x=1750517660; h=content-transfer-encoding:in-reply-to:cc:content-language:from :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=IF23frT4iD5WCFohYy7LDZvLMfeJY72llZpBeHpFJzg=; b=ei/6cdOjTosVYG+g/UiA60qKyBKxvYPl2rLpUvEkBywubAFvqMzggM1ZM6HpYDlwW/ lmqIY9p2wk9wstC2SUqGrrRimcv0nB2aGEGvQCuxViQyo++d0TrtXJBGcWG3V9AXwyRQ WP+EpCPziO66ZvA9SK6xPrLSlIAYwms3AcruwwDe1IcDBp81n3iN9HFTD8bRYHR1WNv9 4b0PaJa2pzFY5DOI+zwB6fVCNkN+wO7ZnTlmREgnF8xeghzKs+XbMmglymDFjLkuCj6h WhY1YOj2TCSTi7u1EI25p4XKG/Ye5e2Nvfnby1rHgaPSjPKWddIxeu8oS9CPjmkMzb6v YQjQ== X-Gm-Message-State: AOJu0Yztl2FSIwU2UUNg7ZJEPrS7L4XjGvEyWd4O1KETuHiUdiUuRuyR 28KyaEaQyMUWOqMhtF2PHH4RcWbEa4VznWnLbtFNXOvwFKbKBxUtHxLjGuzIoA== X-Gm-Gg: ASbGncuSqqPdeDYNrqQYx4Ua6kT8nxPjhAXdqCbvWslhzeevjRKtUug4swirhbeuPUr dc8rsyU1bcmP6l0ejiXtTGa0w+Fc6iF9LwD44I2TFQufRqyqFEvvif04nNHMOmySHUE+qWjz3iV 1LcS03qeseS1osp8iy0pJ9MicbvCuxDCSKc0x/IY9wfn+LhHtIB/IWX1LzmEFdX3W3xb91PkRxI cIzRQQn87WUd55bxObXk2D7j4q829YpTomGqYCsqHBnYf2BhSnGVmNJkk18wFnwOCM85xra5Hj9 NgEZi+ehAr8L30zHToijDX1OYS0OCKoHd4kswGBzoPfihZeWVGyo8CkxAGDyuORzBNP8+09vjvq bQdpiigQd21Arz1MVGI5UoFs/jQ== X-Google-Smtp-Source: AGHT+IHlCfYY8odmH5QQGIg4HPTBTau0Dj/iBJssAdGPP3K/xfrha1TiAwbW2rU8o9VlwasDmumAgw== X-Received: by 2002:a05:6214:5707:b0:6ec:edf9:4658 with SMTP id 6a1803df08f44-6fb477262e5mr58186466d6.18.1749912859933; Sat, 14 Jun 2025 07:54:19 -0700 (PDT) Received: from [192.168.1.10] (135-23-138-165.cpe.pppoe.ca. [135.23.138.165]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6fb35b2f9c4sm32557196d6.26.2025.06.14.07.54.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 14 Jun 2025 07:54:19 -0700 (PDT) Message-ID: <2cfc8994-5d6a-4995-8e27-8706774d74ec@gmail.com> Date: Sat, 14 Jun 2025 10:54:18 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#78528: [PATCH v1] calc: Allow strings with higher character codes To: Eli Zaretskii References: <87ldqqoigl.fsf@gmail.com> <50b8dbc6-c4c3-495f-bd88-1a600ee793d4@gmail.com> <867c1xthvk.fsf@gnu.org> <26591d0e-3c8e-462b-b99d-530c0831aabe@gmail.com> <864iwis97x.fsf@gnu.org> From: "Jacob S. Gordon" Content-Language: en-CA In-Reply-To: <864iwis97x.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78528-done Cc: 78528-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 2025-06-14 10:12, Eli Zaretskii wrote: > I've installed this on the master branch, and I'm closing the bug. Oh, I wasn’t expecting that due to a few rough edges I raised (e.g. alignment, type-checking on the variable). But since it’s opt-in and only appears in a few places, there’s no issue. I’ll continue looking at this and send a patch in a new thread when ready? Thanks, -- Jacob S. Gordon jacob.as.gordon@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 From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 14 11:18:21 2025 Received: (at 78528) by debbugs.gnu.org; 14 Jun 2025 15:18:21 +0000 Received: from localhost ([127.0.0.1]:40702 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQSeC-0005uV-8f for submit@debbugs.gnu.org; Sat, 14 Jun 2025 11:18:21 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55096) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQSe8-0005t9-T9 for 78528@debbugs.gnu.org; Sat, 14 Jun 2025 11:18:18 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uQSe3-0005XP-4v; Sat, 14 Jun 2025 11:18:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=6Z/mChGIHe/fCQdTug9CBbJ44JKveDTzO2opcw0fKMQ=; b=WpiylYmgCS/pGqIP+Ms4 h8GW5C171pDYIXY7uyhHgJcF6ThyFflVyeaVB3YHpm8pPq2/Y8BxU6nP5z0KRIadsGUgFP1W3t54T NWPRJxZCsYA3uFcU3OS1sP5wwN3WvYAB7/JsEr+3k9JFUOLI+Hmtl/ZtGmu783SShxpurtKslBqG/ cLo/MkJXgy8s+fWECgMjPaZ+KsFHOYwhoMI+vanuwUuY6HC+CLTmxTkJM3S0wOBHTs5JH0UAsrOHB /rFdDelQL6t/mbS29IvQoLJal6d8j6zoM3ehNugEXT77Y7TDLQmYl7yI1rfp5u7w/E1cV3HD8OtoO 6wdNBoSn55YaEw==; Date: Sat, 14 Jun 2025 18:18:07 +0300 Message-Id: <86plf6qrm8.fsf@gnu.org> From: Eli Zaretskii To: "Jacob S. Gordon" In-Reply-To: <2cfc8994-5d6a-4995-8e27-8706774d74ec@gmail.com> (jacob.as.gordon@gmail.com) Subject: Re: bug#78528: [PATCH v1] calc: Allow strings with higher character codes References: <87ldqqoigl.fsf@gmail.com> <50b8dbc6-c4c3-495f-bd88-1a600ee793d4@gmail.com> <867c1xthvk.fsf@gnu.org> <26591d0e-3c8e-462b-b99d-530c0831aabe@gmail.com> <864iwis97x.fsf@gnu.org> <2cfc8994-5d6a-4995-8e27-8706774d74ec@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78528 Cc: 78528@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 14 Jun 2025 10:54:18 -0400 > From: "Jacob S. Gordon" > Cc: 78528-done@debbugs.gnu.org > > On 2025-06-14 10:12, Eli Zaretskii wrote: > > I've installed this on the master branch, and I'm closing the bug. > > Oh, I wasn’t expecting that due to a few rough edges I raised (e.g. > alignment, type-checking on the variable). But since it’s opt-in and > only appears in a few places, there’s no issue. > > I’ll continue looking at this and send a patch in a new thread when > ready? Sure, please do.