GNU bug report logs - #67536
29.1; Calc mode's math-read-preprocess-string conses unnecessarily

Previous Next

Full log

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

From: Raffael Stocker <r.stocker <at> mnet-mail.de>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 67536 <at> debbugs.gnu.org
Subject: Re: bug#67536: 29.1; Calc mode's math-read-preprocess-string conses
 unnecessarily
Date: Sat, 02 Dec 2023 20:26:58 +0100

Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:

> There are minor points that could be addressed: `mapc` is often better
> replaced with `dolist`;

Is this the case? As ‘mapc’ is implemented directly in C and ‘dolist’
falls back to ‘while’, I thought it would be the other way around.  But
of course I never compared them.

> the first position of a buffer is 1, not 0;

Yes, I could have done that one better.  I was to lazy to check...

> and perhaps iterating through all elements of math-read-replacement-list isn't ideal.
> Here's a variant which computes a single regexp to do the job and should cons a bit less.

I thought about the possibility of doing this, but I didn't want to open
that can of worms.  Not iterating definitely sounds right, though.

However, I checked your proposed version and there is an issue with
replacement of sub- and superscripts.  Here are a few test strings I
used on my version, with the comparison strings supplied by the
original:

--8<---------------cut here---------------start------------->8---
(string= (math-read-preprocess-string "±⁷⁽⁽⁽⁽₄₄ds₇⅟⅟l⅛⅛µ3¾⁶⁴₍∞≤")
         "+/-^(7(((()_(44)ds_(7)1:1:l(1:8)(1:8)μ3(3:4)^(64)_(()inf<=")
(string= (math-read-preprocess-string "dsfjlsajflk klfsld flsd fkls fkl jfjls")
         "dsfjlsajflk klfsld flsd fkls fkl jfjls")
(string= (math-read-preprocess-string "") "")
--8<---------------cut here---------------end--------------->8---

The last two tests work fine (as there are no replacements), but for the
first, your function produces this incorrect result:

"+/-^(7)^(()^(()^(()^(()_(4)_(4)ds_(7)1:1:l(1:8)(1:8)μ3(3:4)^(6)^(4)_(()inf<="

> Raffael, maybe you could see if this makes a difference in Org table performance.

I'm looking forward to doing so.

Regards,
Raffael

Previous Next

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