bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22519: 25.1.50; Emacs gets stuck while doing incremental search forw


From: Vincent Belaïche
Subject: bug#22519: 25.1.50; Emacs gets stuck while doing incremental search forward
Date: Tue, 15 Mar 2016 16:53:05 +0100

Dear Eli,

Just one more word: if I omit the `(recenter)' statement after each word
insertion, then processing time is OK, utf-8 does it even a little
shorter than latin-9, probably due to this there are fewer characters in
the buffer.

So, it really has to do with display refresh.

VBR,
        Vincent.


Le 15/03/2016 14:28, Vincent Belaïche a écrit :
> Dear Eli,
>
> Ok, I decided to make some test bench (herein attached).
>
> I get the following interaction:
>
>  $ ./emacs-bug22519.sh --fundamental no
> -| mode: normal
> -| latin-9=(0.588 5 0.031999999999999994)
> -| utf-8=(111.257 146 1.3299999999999979)
>  $ ./emacs-bug22519.sh --fundamental yes
> -| mode: fundamental
> -| latin-9=(0.209 0 0.0)
> -| utf-8=(95.442 129 1.121)
>
>
> As you see, in normal mode utf-8 is 189 times slower than latin-9, and
> in fundamental mode, it is 456 times slower.
>
> So, IMHO it is a bug: user expererience is *GREATLY* damaged when you
> have the funny math symbols displayed.
>
> Please feel free to ask me to modify the attached script according to
> your wishes, eg to new command line option, like making configurable
> number of word insertion for shorter tests.
>
> VBR,
>       Vincent.
>
> Le 13/03/2016 17:19, Eli Zaretskii a écrit :
>>> From: vincent.belaiche@gmail.com (Vincent Belaïche)
>>> Cc: Vincent Belaïche <vincent.belaiche@gmail.com> ,
>>>  22519@debbugs.gnu.org
>>> Date: Sun, 13 Mar 2016 09:10:11 +0100
>>>
>>> Oooops... It is back again. It seems that this has to do with how long
>>> the Emacs session has been open. I was comparing the 2016-01-29 Emacs
>>> the session of which had been open for a couple of days with the
>>> recently build 2016-03-11 Emacs the session of which was just open. And
>>> the latter seemed not to have the problem any longer.
>>
>> I have now tried this file in a session that has been running for 10
>> days, and I see no problems with this file.
>>
>>> Not correct, the editing is lengthy *ALSO* with the latter Emacs.
>>>
>>> Please note that only the latex2e-fr.texi buffer is slow, the other
>>> buffers behave OK.
>>
>> I'm afraid this is something specific to your configuration, so you
>> will have to find which parts of your configuration cause this issue.
>> Also, you originally talked about Emacs getting stuck, while now you
>> seem to say about slow editing -- is this really the same problem, and
>> if so, does it get stuck or just works slowly?
>>
>> In any case, without additional information I don't see how we could
>> move further in debugging this problem.  I'd begin with looking into
>> the minor modes you have enabled in that buffer, disabling them one by
>> one, until the problem goes way.  If that doesn't help, look at
>> features that hook into post-command-hook.
>






reply via email to

[Prev in Thread] Current Thread [Next in Thread]