GNU bug report logs - #61274
29.0.60; dabbrev-capf signals errors

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 61274 in the body.
You can then email your comments to 61274 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: bug-gnu-emacs <at> gnu.org
Cc: monnier <at> iro.umontreal.ca
Subject: 29.0.60; dabbrev-capf signals errors
Date: Sat, 04 Feb 2023 12:03:26 +0100

The completion-at-point-function `dabbrev-capf' sometimes signals
errors. It would be good if the function would not do that but return
nil if no completions are found, such that the next Capf from the list
of completion functions gets its chance to run.

1. Start emacs -Q
2. Evaluate (require 'dabbrev).
3. Evaluate (setq completion-at-point-functions '(dabbrev-capf)) in the
scratch buffer.
4. Type `x M-TAB` in the scratch buffer. I observe the following error:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  dabbrev--goto-start-of-abbrev()
  dabbrev--abbrev-at-point()
  dabbrev-capf()
  completion--capf-wrapper(dabbrev-capf all)
  completion-at-point()
  funcall-interactively(completion-at-point)
  command-execute(completion-at-point)

Furthermore if no completions are found `dabbrev-capf' signals an error.
The messages buffer will then contain:

Scanning for dabbrevs...done
completion--some: No dynamic expansion for "xyz" found

In GNU Emacs 29.0.60 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.16.0, Xaw scroll bars) of 2023-01-26 built on projects
Repository revision: f8c95d1a7681e861fc22d2a040cda0ddfe23eff4
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 61274 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#61274: 29.0.60; dabbrev-capf signals errors
Date: Sat, 04 Feb 2023 15:16:42 +0200

> Cc: monnier <at> iro.umontreal.ca
> From: Daniel Mendler <mail <at> daniel-mendler.de>
> Date: Sat, 04 Feb 2023 12:03:26 +0100
> 
> The completion-at-point-function `dabbrev-capf' sometimes signals
> errors. It would be good if the function would not do that but return
> nil if no completions are found, such that the next Capf from the list
> of completion functions gets its chance to run.
> 
> 1. Start emacs -Q
> 2. Evaluate (require 'dabbrev).
> 3. Evaluate (setq completion-at-point-functions '(dabbrev-capf)) in the
> scratch buffer.
> 4. Type `x M-TAB` in the scratch buffer. I observe the following error:
> 
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>   dabbrev--goto-start-of-abbrev()
>   dabbrev--abbrev-at-point()
>   dabbrev-capf()
>   completion--capf-wrapper(dabbrev-capf all)
>   completion-at-point()
>   funcall-interactively(completion-at-point)
>   command-execute(completion-at-point)
> 
> Furthermore if no completions are found `dabbrev-capf' signals an error.
> The messages buffer will then contain:
> 
> Scanning for dabbrevs...done
> completion--some: No dynamic expansion for "xyz" found

The patch below fixes the error.

Regarding "No dynamic expansion" error: what did you expect to happen
instead and why?  IOW, what is the expected result of having
dabbrev-capf alone in completion-at-point-functions, and then typing
"x M-TAB"?

diff --git a/lisp/dabbrev.el b/lisp/dabbrev.el
index a4b4d07..deba082 100644
--- a/lisp/dabbrev.el
+++ b/lisp/dabbrev.el
@@ -400,6 +400,8 @@ dabbrev-completion
 
 (defun dabbrev-capf ()
   "Dabbrev completion function for `completion-at-point-functions'."
+  (or (stringp dabbrev--abbrev-char-regexp)
+      (dabbrev--reset-global-variables))
   (let* ((abbrev (dabbrev--abbrev-at-point))
          (beg (progn (search-backward abbrev) (point)))
          (end (progn (search-forward abbrev) (point)))

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61274 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#61274: 29.0.60; dabbrev-capf signals errors
Date: Sat, 4 Feb 2023 17:03:26 +0100

On 2/4/23 14:16, Eli Zaretskii wrote:
> The patch below fixes the error.

Thanks!

> Regarding "No dynamic expansion" error: what did you expect to happen
> instead and why?  IOW, what is the expected result of having
> dabbrev-capf alone in completion-at-point-functions, and then typing
> "x M-TAB"?

I would expect the completion UI to show a message, instead of an error
from the Capf. For example if you start emacs -Q, type "nonexistent
M-TAB" in the scratch buffer to access the normal Elisp completions.
Then you will see the message "No match" in the minibuffer. If
`dabbrev-capf' would not throw an error, we would get the same message.

Daniel

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 61274 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#61274: 29.0.60; dabbrev-capf signals errors
Date: Sat, 04 Feb 2023 18:54:01 +0200

> Date: Sat, 4 Feb 2023 17:03:26 +0100
> Cc: 61274 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> From: Daniel Mendler <mail <at> daniel-mendler.de>
> 
> On 2/4/23 14:16, Eli Zaretskii wrote:
> > The patch below fixes the error.
> 
> Thanks!

Should I install it?

> > Regarding "No dynamic expansion" error: what did you expect to happen
> > instead and why?  IOW, what is the expected result of having
> > dabbrev-capf alone in completion-at-point-functions, and then typing
> > "x M-TAB"?
> 
> I would expect the completion UI to show a message, instead of an error
> from the Capf. For example if you start emacs -Q, type "nonexistent
> M-TAB" in the scratch buffer to access the normal Elisp completions.
> Then you will see the message "No match" in the minibuffer. If
> `dabbrev-capf' would not throw an error, we would get the same message.

maybe dabbrev-capf is unsuitable to serve as the value of
completion-at-point-functions?

Stefan, any comments?

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 61274 <at> debbugs.gnu.org
Subject: Re: bug#61274: 29.0.60; dabbrev-capf signals errors
Date: Sat, 04 Feb 2023 12:13:27 -0500

> maybe dabbrev-capf is unsuitable to serve as the value of
> completion-at-point-functions?

As the name implies, it's a function designed specifically for use on
`completion-at-point-functions`.  Maybe dabbrev is not well adapted
for use within a normal completion UI, but `dabbrev-capf` should do its
best to obey the rules of `completion-at-point-functions`, so I think
the behavior Daniel suggests is indeed what `dabbrev-capf` should try
to do.

Those people who don't like it can use dabbrev via various other UIs.


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: mail <at> daniel-mendler.de, 61274 <at> debbugs.gnu.org
Subject: Re: bug#61274: 29.0.60; dabbrev-capf signals errors
Date: Sat, 04 Feb 2023 19:17:16 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Daniel Mendler <mail <at> daniel-mendler.de>,  61274 <at> debbugs.gnu.org
> Date: Sat, 04 Feb 2023 12:13:27 -0500
> 
> > maybe dabbrev-capf is unsuitable to serve as the value of
> > completion-at-point-functions?
> 
> As the name implies, it's a function designed specifically for use on
> `completion-at-point-functions`.  Maybe dabbrev is not well adapted
> for use within a normal completion UI, but `dabbrev-capf` should do its
> best to obey the rules of `completion-at-point-functions`, so I think
> the behavior Daniel suggests is indeed what `dabbrev-capf` should try
> to do.

Then there's something here that puzzles me: the recipe presented by
Daniel is basically identical to what dabbrev-completion does.  And
yet dabbrev-completion produces different effects when invoked in the
same buffer with the same text at point.  What is responsible for the
difference in behavior?

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61274 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#61274: 29.0.60; dabbrev-capf signals errors
Date: Sat, 4 Feb 2023 18:23:47 +0100

On 2/4/23 17:54, Eli Zaretskii wrote:
>> Date: Sat, 4 Feb 2023 17:03:26 +0100
>> Cc: 61274 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
>> From: Daniel Mendler <mail <at> daniel-mendler.de>
>>
>> On 2/4/23 14:16, Eli Zaretskii wrote:
>>> The patch below fixes the error.
>>
>> Thanks!
> 
> Should I install it?

Yes, please, if Stefan agrees. He added dabbrev-capf.

Daniel

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 61274 <at> debbugs.gnu.org
Subject: Re: bug#61274: 29.0.60; dabbrev-capf signals errors
Date: Sat, 4 Feb 2023 18:30:41 +0100

On 2/4/23 18:17, Eli Zaretskii wrote:
>> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
>> Cc: Daniel Mendler <mail <at> daniel-mendler.de>,  61274 <at> debbugs.gnu.org
>> Date: Sat, 04 Feb 2023 12:13:27 -0500
>>
>>> maybe dabbrev-capf is unsuitable to serve as the value of
>>> completion-at-point-functions?
>>
>> As the name implies, it's a function designed specifically for use on
>> `completion-at-point-functions`.  Maybe dabbrev is not well adapted
>> for use within a normal completion UI, but `dabbrev-capf` should do its
>> best to obey the rules of `completion-at-point-functions`, so I think
>> the behavior Daniel suggests is indeed what `dabbrev-capf` should try
>> to do.
> 
> Then there's something here that puzzles me: the recipe presented by
> Daniel is basically identical to what dabbrev-completion does.  And
> yet dabbrev-completion produces different effects when invoked in the
> same buffer with the same text at point.  What is responsible for the
> difference in behavior?

You mean that the stringp type error does not occur? There is some code
in `dabbrev-completion' which sets up Dabbrev (resets variables etc), so
this is likely causing the difference.

However the second issue still occurs even with `dabbrev-completion'.
When I execute `dabbrev-completion' in a buffer where no completions are
found, I get the message "dabbrev--abbrev-at-point: No possible
abbreviation preceding point", while the message should be the usual "No
match" from `completion-at-point'. At this point we are moving into
problematic territory however, since Stefan reimplemented
`dabbrev-completion' based on `dabbrev-capf'. We may want a more
specific error message for `dabbev-completion', while we don't want any
errors signalled by `dabbrev-capf', such that it conforms to the
`completion-at-point-functions' contract.

Daniel

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 61274 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#61274: 29.0.60; dabbrev-capf signals errors
Date: Sat, 04 Feb 2023 20:09:50 +0200

> Date: Sat, 4 Feb 2023 18:30:41 +0100
> Cc: 61274 <at> debbugs.gnu.org
> From: Daniel Mendler <mail <at> daniel-mendler.de>
> 
> > Then there's something here that puzzles me: the recipe presented by
> > Daniel is basically identical to what dabbrev-completion does.  And
> > yet dabbrev-completion produces different effects when invoked in the
> > same buffer with the same text at point.  What is responsible for the
> > difference in behavior?
> 
> You mean that the stringp type error does not occur? There is some code
> in `dabbrev-completion' which sets up Dabbrev (resets variables etc), so
> this is likely causing the difference.

This is solved by my patch.

I thought there was some difference in behavior even after that, but
it looks like I cannot reproduce it now, so I will consider that my
dream.

> However the second issue still occurs even with `dabbrev-completion'.
> When I execute `dabbrev-completion' in a buffer where no completions are
> found, I get the message "dabbrev--abbrev-at-point: No possible
> abbreviation preceding point", while the message should be the usual "No
> match" from `completion-at-point'.

I see a different message:

  completion--some: No dynamic expansion for "x" found in this-buffer

Which IMO is completely reasonable.

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61274 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#61274: 29.0.60; dabbrev-capf signals errors
Date: Sat, 4 Feb 2023 19:21:47 +0100

On 2/4/23 19:09, Eli Zaretskii wrote:
>> However the second issue still occurs even with `dabbrev-completion'.
>> When I execute `dabbrev-completion' in a buffer where no completions are
>> found, I get the message "dabbrev--abbrev-at-point: No possible
>> abbreviation preceding point", while the message should be the usual "No
>> match" from `completion-at-point'.
> 
> I see a different message:
> 
>   completion--some: No dynamic expansion for "x" found in this-buffer
> 
> Which IMO is completely reasonable.

It is for `dabbrev-completion` but not for `dabbrev-capf', which should
better not throw any errors, such that the next Capf gets its chance to
run as I mentioned in my initial mail. Maybe Stefan has some more
comments on how we could resolve this?

Daniel

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61274 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#61274: 29.0.60; dabbrev-capf signals errors
Date: Sat, 15 Feb 2025 22:03:52 +0100

Daniel Mendler <mail <at> daniel-mendler.de> writes:

> On 2/4/23 17:54, Eli Zaretskii wrote:
>>> Date: Sat, 4 Feb 2023 17:03:26 +0100
>>> Cc: 61274 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
>>> From: Daniel Mendler <mail <at> daniel-mendler.de>
>>>
>>> On 2/4/23 14:16, Eli Zaretskii wrote:
>>>> The patch below fixes the error.
>>>
>>> Thanks!
>> 
>> Should I install it?
>
> Yes, please, if Stefan agrees. He added dabbrev-capf.
>
> Daniel

I believe this issue can be closed. Maybe Stefan can confirm?

Daniel

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 61274 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#61274: 29.0.60; dabbrev-capf signals errors
Date: Sat, 15 Feb 2025 17:58:33 -0500

>>> Should I install it?
>> Yes, please, if Stefan agrees. He added dabbrev-capf.

I agree with the patch.

> I believe this issue can be closed.

AFAICT the patch has not been installed, tho.

As for the UI part, I think it's OK if the message changes to "No
match".


        Stefan

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

From: Alcor <alcor <at> tilde.club>
To: 61274 <at> debbugs.gnu.org
Subject: Re: bug#61274: 29.0.60; dabbrev-capf signals errors
Date: Thu, 18 Sep 2025 20:45:19 +0200

This bug is still present on Emacs 30.2.

I would also like to add that Eli's patch does not fully fix the issue
on 30.2 - typing x M-TAB results in a different backtrace.

As a workaround, I've resorted to using CAPE's cape-dabbrev-capf [1], as
recommended by people in #emacs, which seems to do the right
thing. However, it would still be preferable if the built-in dabbrev
CAPF were to be fixed.

[1] https://github.com/minad/cape

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alcor <alcor <at> tilde.club>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 61274 <at> debbugs.gnu.org
Subject: Re: bug#61274: 29.0.60; dabbrev-capf signals errors
Date: Sat, 20 Sep 2025 13:18:00 +0300

> Date: Thu, 18 Sep 2025 20:45:19 +0200
> From:  Alcor via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> This bug is still present on Emacs 30.2.

Since the patch was approved, I've now installed it on the master
branch.

> I would also like to add that Eli's patch does not fully fix the issue
> on 30.2 - typing x M-TAB results in a different backtrace.

Please show a full recipe starting from "emacs -Q".

Thanks.

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

From: Alcor <alcor <at> tilde.club>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61274 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#61274: 29.0.60; dabbrev-capf signals errors
Date: Sat, 20 Sep 2025 20:41:57 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Please show a full recipe starting from "emacs -Q".

(Emacs 30.2)

1. Start with the patch applied
2. M-: (require 'dabbrev)
3. C-x h DEL (clear the buffer)
4. M-x fundamental-mode
5. Type the following into the buffer (\n represents a newline): Glamorgan\nGlasgow\n
6. M-: (setq completion-at-point-functions (list t 'dabbrev-capf))
7. M-x completion-preview-mode
8. Type the following: Gla (Observe the completion preview overlay at this point)
9. Then type x, producing "Glax" (any other character except m or s would work too)

The following error is then raised and output on *Messages*:

Error in post-command-hook (completion-preview--post-command): (user-error "No dynamic expansion for \"Glax\" found")

My point is: I believe raising `user-error' in a CAPF when no matches
are found is incorrect behavior. CAPE's implementation doesn't do that.

The problem should be also reproducible with other completion
frameworks, I used `completion-preview-mode' for the recipe since it's
included in Emacs 30+.

Cheers,
-A.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alcor <alcor <at> tilde.club>
Cc: 61274 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#61274: 29.0.60; dabbrev-capf signals errors
Date: Sat, 20 Sep 2025 17:46:43 -0400

> My point is: I believe raising `user-error' in a CAPF when no matches
> are found is incorrect behavior.

Agreed.  If we want to raise such an error it needs to be done
elsewhere, in code written "on top of" the completion-at-point-function.


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 61274 <at> debbugs.gnu.org, alcor <at> tilde.club
Subject: Re: bug#61274: 29.0.60; dabbrev-capf signals errors
Date: Sun, 21 Sep 2025 12:29:46 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  61274 <at> debbugs.gnu.org
> Date: Sat, 20 Sep 2025 17:46:43 -0400
> 
> > My point is: I believe raising `user-error' in a CAPF when no matches
> > are found is incorrect behavior.
> 
> Agreed.  If we want to raise such an error it needs to be done
> elsewhere, in code written "on top of" the completion-at-point-function.

Like this?

diff --git a/lisp/dabbrev.el b/lisp/dabbrev.el
index 00a7357..e19508d 100644
--- a/lisp/dabbrev.el
+++ b/lisp/dabbrev.el
@@ -422,11 +422,6 @@ dabbrev-capf
                   (let ((completion-list
                          (dabbrev--find-all-expansions abbrev ignore-case-p))
                         (completion-ignore-case ignore-case-p))
-                    (or (consp completion-list)
-                        (user-error "No dynamic expansion for \"%s\" found%s"
-                                    abbrev
-                                    (if dabbrev--check-other-buffers
-                                        "" " in this-buffer")))
                     (setq list
                           (cond
                            ((not (and ignore-case-p dabbrev-case-replace))

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

From: Alcor <alcor <at> tilde.club>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61274 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#61274: 29.0.60; dabbrev-capf signals errors
Date: Sun, 21 Sep 2025 12:34:39 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> diff --git a/lisp/dabbrev.el b/lisp/dabbrev.el
> index 00a7357..e19508d 100644
> --- a/lisp/dabbrev.el
> +++ b/lisp/dabbrev.el
> @@ -422,11 +422,6 @@ dabbrev-capf
>                    (let ((completion-list
>                           (dabbrev--find-all-expansions abbrev ignore-case-p))
>                          (completion-ignore-case ignore-case-p))
> -                    (or (consp completion-list)
> -                        (user-error "No dynamic expansion for \"%s\" found%s"
> -                                    abbrev
> -                                    (if dabbrev--check-other-buffers
> -                                        "" " in this-buffer")))
>                      (setq list
>                            (cond
>                             ((not (and ignore-case-p dabbrev-case-replace))

This does slightly improve things in the sense that it no longer results
in an error being raised. But for some reason, it only works _once_
i.e. C-M-i or `completion-preview-mode' only finds a match successfully
a single time, afterwhich it never finds a match, likely due to invalid
dabbrev state.

IMO - `dabbrev--reset-global-variables' should be executed
unconditionally (or the conditional should be fixed, see below) to
ensure that dabbrev's state variables are reset (this is indeed what
CAPE's cape-dabbrev-capf seems to do). IOW I'd propose the following
(which works for me):

--- a/lisp/dabbrev.el
+++ b/lisp/dabbrev.el
@@ -400,8 +400,7 @@
 
 (defun dabbrev-capf ()
   "Dabbrev completion function for `completion-at-point-functions'."
-  (or (stringp dabbrev--abbrev-char-regexp)
-      (dabbrev--reset-global-variables))
+  (dabbrev--reset-global-variables))
   (let* ((abbrev (dabbrev--abbrev-at-point))
          (beg (progn (search-backward abbrev) (point)))
          (end (progn (search-forward abbrev) (point)))

Alternatively, the following also works:

--- a/lisp/dabbrev.el
+++ b/lisp/dabbrev.el
@@ -400,7 +400,7 @@
 
 (defun dabbrev-capf ()
   "Dabbrev completion function for `completion-at-point-functions'."
-  (or (stringp dabbrev--abbrev-char-regexp)
+  (or (stringp dabbrev-abbrev-char-regexp)
       (dabbrev--reset-global-variables))
   (let* ((abbrev (dabbrev--abbrev-at-point))
          (beg (progn (search-backward abbrev) (point)))

Could it be that `(stringp dabbrev--abbrev-char-regexp)' is a typo?
`dabbrev--abbrev-char-regexp' is always a string (e.g. "\\sw\\|\\s_")
for me, so the reset isn't executed due to short circuiting. At any
rate: The reset logic needs to be fixed, but I can't tell which way is
the correct one as I don't quite understand what the purpose of the
conditional wrapping the reset is.

Cheers,
-A.

PS: Maybe the `or' in the original fix is meant to be an `if'. This
makes more sense to me:

--- a/lisp/dabbrev.el
+++ b/lisp/dabbrev.el
@@ -400,7 +400,7 @@
 
 (defun dabbrev-capf ()
   "Dabbrev completion function for `completion-at-point-functions'."
-  (or (stringp dabbrev--abbrev-char-regexp)
+  (if (stringp dabbrev--abbrev-char-regexp)
       (dabbrev--reset-global-variables))
   (let* ((abbrev (dabbrev--abbrev-at-point))
          (beg (progn (search-backward abbrev) (point)))

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alcor <alcor <at> tilde.club>
Cc: 61274 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#61274: 29.0.60; dabbrev-capf signals errors
Date: Wed, 24 Sep 2025 16:59:31 -0400

[Message part 1 (text/plain, inline)]

> --- a/lisp/dabbrev.el
> +++ b/lisp/dabbrev.el
> @@ -400,8 +400,7 @@
>  
>  (defun dabbrev-capf ()
>    "Dabbrev completion function for `completion-at-point-functions'."
> -  (or (stringp dabbrev--abbrev-char-regexp)
> -      (dabbrev--reset-global-variables))
> +  (dabbrev--reset-global-variables))
>    (let* ((abbrev (dabbrev--abbrev-at-point))
>           (beg (progn (search-backward abbrev) (point)))
>           (end (progn (search-forward abbrev) (point)))

I think that's right since matches what the `dabbrev-completion` did
before introducing the capf code.
But it makes the call to `dabbrev--reset-global-variables` that's in
`dabbrev-completion` redundant, so the patch should also remove the code
from there.

So I pushed the patch below to `master`.

We may want to try and be a bit more clever about caching, since the
capf function may be called more often, but I don't know how important
it is in practice, but we can leave it for later.


        Stefan

[dabbrev.patch (text/x-diff, inline)]

commit 77921ce458452312595696082379340802dc7bd4
Author: Alcor <alcor <at> tilde.club>
Date:   Wed Sep 24 16:58:08 2025 -0400

    (dabbrev-capf): Improve last fix for bug#61274
    
    Copyright-paperwork-exempt: yes
    
    * lisp/dabbrev.el (dabbrev-completion): Don't call
    `dabbrev--reset-global-variables` any more.
    (dabbrev-capf): Call it here, unconditionally, instead.

diff --git a/lisp/dabbrev.el b/lisp/dabbrev.el
index 00a73572fb1..8f8c691fe5d 100644
--- a/lisp/dabbrev.el
+++ b/lisp/dabbrev.el
@@ -391,7 +391,6 @@ dabbrev-completion
 If the prefix argument is 16 (which comes from \\[universal-argument] \\[universal-argument]),
 then it searches *all* buffers."
   (interactive "*P")
-  (dabbrev--reset-global-variables)
   (setq dabbrev--check-other-buffers (and arg t))
   (setq dabbrev--check-all-buffers
         (and arg (= (prefix-numeric-value arg) 16)))
@@ -400,8 +399,7 @@ dabbrev-completion
 
 (defun dabbrev-capf ()
   "Dabbrev completion function for `completion-at-point-functions'."
-  (or (stringp dabbrev--abbrev-char-regexp)
-      (dabbrev--reset-global-variables))
+  (dabbrev--reset-global-variables)
   (let* ((abbrev (dabbrev--abbrev-at-point))
          (beg (progn (search-backward abbrev) (point)))
          (end (progn (search-forward abbrev) (point)))

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

From: Alcor <alcor <at> tilde.club>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 61274 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#61274: 29.0.60; dabbrev-capf signals errors
Date: Thu, 25 Sep 2025 00:07:09 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> But it makes the call to `dabbrev--reset-global-variables` that's in
> `dabbrev-completion` redundant, so the patch should also remove the code
> from there.

Thanks for installing the patch. However, I was informed by a user on
#emacs that it breaks the dabbrev tests. Specifically, I assume that the
tests now fail because `dabbrev--reset-global-variables' call was
removed from `dabbrev-completion'.

I guess the redundant call should be retained in the interim, so as to
avoid any unintended breakage?

-A.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alcor <alcor <at> tilde.club>
Cc: 61274 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#61274: 29.0.60; dabbrev-capf signals errors
Date: Thu, 25 Sep 2025 15:27:18 -0400

> Thanks for installing the patch. However, I was informed by a user on
> #emacs that it breaks the dabbrev tests. Specifically, I assume that the
> tests now fail because `dabbrev--reset-global-variables' call was
> removed from `dabbrev-completion'.

More specifically, it's because it now happens *after* setting
`dabbrev--check-other-buffers` and `dabbrev--check-all-buffers` (and
thus overrides those settings.

I installed a change which makes the tests pass again, but it's
a bit ugly.


        Stefan

Message #72 received at 61274-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 61274-done <at> debbugs.gnu.org, alcor <at> tilde.club
Subject: Re: bug#61274: 29.0.60; dabbrev-capf signals errors
Date: Sat, 11 Oct 2025 11:20:40 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  61274 <at> debbugs.gnu.org
> Date: Thu, 25 Sep 2025 15:27:18 -0400
> 
> > Thanks for installing the patch. However, I was informed by a user on
> > #emacs that it breaks the dabbrev tests. Specifically, I assume that the
> > tests now fail because `dabbrev--reset-global-variables' call was
> > removed from `dabbrev-completion'.
> 
> More specifically, it's because it now happens *after* setting
> `dabbrev--check-other-buffers` and `dabbrev--check-all-buffers` (and
> thus overrides those settings.
> 
> I installed a change which makes the tests pass again, but it's
> a bit ugly.

Thanks.  Since there were no further comments, I presume we can close
this now.

Previous Next

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