GNU bug report logs - #74090
31.0.50; Problems with dabbrev-expand

Previous Next

Full log

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

From: Juri Linkov <juri <at> linkov.net>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 74090 <at> debbugs.gnu.org
Subject: Re: bug#74090: 31.0.50; Problems with dabbrev-expand
Date: Mon, 02 Dec 2024 09:33:51 +0200

> I've added a test but I'm somewhat dissatisfied with it.  I wanted to
> essentially reproduce the behavior I see with the patch, described
> above.  However, after killing buffer "foo", the message about no
> further expansion is from a user-error in dabbrev-expand, and on hitting
> this in the test run, the test immediately finishes.  So I used
> should-error with :type 'user-error and the test succeeds, but I cannot
> test for the final buffer content nor the message displayed by
> user-error.  If anyone has an idea how to do that or otherwise improve
> the test, please chime in.

Probably 'condition-case' could help to catch a user-error.
Or maybe better to set a buffer-local or let-bind 'command-error-function'
like e.g. in 'minibuffer-error-initialize'.

Then you can let-bind 'set-message-function' to catch a message
to check it (but I don't remember if the error calls the message function).

OTOH, I don't understand why the test immediately finishes after 'should-error'?
There are many tests that call 'should-error' sequentially like:

  (ert-deftest abbrev-table-empty-p-test ()
    (should-error (abbrev-table-empty-p 42))
    (should-error (abbrev-table-empty-p "aoeu"))
    (should-error (abbrev-table-empty-p '()))
    (should-error (abbrev-table-empty-p []))

And indeed implementation of 'should-error' already has 'condition-case'.

Previous Next

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