Re: Test succeeding only from edebug

["Andreas Röhler" <andreas.roehler@easy-emacs.de>]

Am 06.08.24 um 03:49 schrieb Michael Heerdegen via Users list for the 
GNU Emacs text editor:
> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>
>> Here ist the test, which should remove all braces in buffer:
>>
>> (ert-deftest ar-trim-braced-in-region-test ()
>>    (ar-test-with-elisp-buffer-point-min
>>        "{asdf} {asdf} {asdf}"
>>        (goto-char (point-min))
>>        (set-mark (point))
>>      (end-of-line)
>>      (ar-trim-braced-in-region-atpt)
>>      (should (eq (char-before) ?f))))
>>
>>>     Or fails compiled and interpreted?
>> Usually don't compile my stuff.
> Ah ok...so there is no error, just the test fails.
>
> In my experience it is so that when something works correctly when
> edebugged but not when run normally, very often the code assumes a state
> that is only reached after a (or multiple) redisplay operations have
> been performed.  When edebugging Emacs gets idle in situations when it
> is normally not (each time edebug stops).
>
> I'm not sure which part of your code could rely on such an assumption,
> I'm too tired atm too study all details.  Could be font-locking that has
> not yet been performed - if your test makes use of font-lock features.
>
> If adding an explicit (redisplay) call at the end of the buffer setup
> in the definition of `ar-test-with-elisp-buffer-point-min' or before the
> `should' call helps then this would be it.  In case of font-lock you
> would then want to call (font-lock-ensure) to force font-locking
> explicitly before Emacs gets idle.
Yes, however, not at stake here.
> Please tell me if that helps to make any progress - else I try to have
> an even closer look tomorrow.
>
>
> Grüße,
>
> Michael.
>

putting a

(sit-for 0.5)

into ar-thing-in-thing seems to solve it.

Thanks again,

Andreas