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

Previous Next

To reply to this bug, email your comments to 61274 AT debbugs.gnu.org.

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

Previous Next

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