GNU bug report logs - #20887
'make bootstrap' now verrrry slow due to recent isearch changes

Previous Next

Full log

View this message in rfc822 format

From: Artur Malabarba <bruce.connor.am <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 20887 <at> debbugs.gnu.org
Subject: bug#20887: 'make bootstrap' now verrrry slow due to recent isearch changes
Date: Thu, 25 Jun 2015 00:17:09 +0100

2015-06-24 21:05 GMT+01:00 Artur Malabarba <bruce.connor.am <at> gmail.com>:
>> Why only the second?  All you care about is decomposition, that is,
>> you need only loop over characters that have a non-nil value in the
>> decomposition property.  You will see in characters.el how you can use
>> map-char-table over a char-table loaded from uni-decomposition.el
>> (similar to what we do there with uni-bidi et.).  Won't that be much
>> faster?
>>
>> (I didn't actually try that, so perhaps I'm talking nonsense.)
>
> You're perfectly correct. I wasn't aware there's a char table for the
> decomposition property (or any of the char properties for that
> matter). Thanks, I'll add it in.

Actually, I spoke (and pushed) too soon. I have no idea how this works
The following code

(map-char-table
       (lambda (idx dec) (message "%S %S" idx dec))
       (unicode-property-table-internal 'decomposition))

calls the function a measly total of 100 times. The idx values are
things like below (which I understand), but the dec values are HUGE
strings (too big to post here, most of their content is the ^@ char)
which make no sense to me. Am I using this wrong?
(128 . 255)
(256 . 383)
(384 . 511)
(512 . 639)
(640 . 767)
(768 . 895)
(896 . 1023)
(1024 . 1151)
(1152 . 1279)

Previous Next

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