bug#65414: save-some-buffers-functions are unexpectedly called when save-some-buffers pred is non-nil

bug#65414: save-some-buffers-functions are unexpectedly called when save-some-buffers pred is non-nil

[Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Functions which are added to save-some-buffers-functions are always
called when save-some-buffers runs, even when a PRED argument is
specified. This leads to unexpected behavior when PRED is intended to
limit saving buffers to a specific set of file buffers, as in Magit's
magit-save-repository-buffers function.

abbrev--possibly-save is added to save-some-buffers-functions by default
now, so whenever magit-save-repository-buffers runs, Emacs prompts to
save unsaved abbrevs (as well any other functions in the list).

I propose that we pass along the PRED argument of save-some-buffers to
each of save-some-buffers-functions, allowing them to determine what is
appropriate to do. Alternatively, we could pass along the return value
of files--buffers-needing-to-be-saved, which is a list of buffers.

Thoughts?

Joseph

bug#65414: save-some-buffers-functions are unexpectedly called when save-some-buffers pred is non-nil

[Eli Zaretskii]

> Cc: jonas@bernoul.li
> Date: Sun, 20 Aug 2023 21:06:54 -0700
> From:  Joseph Turner via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Functions which are added to save-some-buffers-functions are always
> called when save-some-buffers runs, even when a PRED argument is
> specified. This leads to unexpected behavior when PRED is intended to
> limit saving buffers to a specific set of file buffers, as in Magit's
> magit-save-repository-buffers function.
> 
> abbrev--possibly-save is added to save-some-buffers-functions by default
> now, so whenever magit-save-repository-buffers runs, Emacs prompts to
> save unsaved abbrevs (as well any other functions in the list).

Why is asking whether to save the abbrevs a problem in the case of
magit-save-repository-buffers?

And are you saying that before the change which added
save-some-buffers-functions, Emacs was not saving the abbrevs when
save-some-buffers was called?  If so, in what Emacs version was this
so?

> I propose that we pass along the PRED argument of save-some-buffers to
> each of save-some-buffers-functions, allowing them to determine what is
> appropriate to do. Alternatively, we could pass along the return value
> of files--buffers-needing-to-be-saved, which is a list of buffers.

We need a better understanding of the situation before we can discuss
solutions, so please fill-in the blanks outlined above.  (The solution
you propose is not very backward-compatible, so probably not
acceptable anyway, as Emacs 29 was already released with the current
code.  But let's defer this discussion until the issue is more clear.)

bug#65414: save-some-buffers-functions are unexpectedly called when save-some-buffers pred is non-nil

[Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> Why is asking whether to save the abbrevs a problem in the case of
> magit-save-repository-buffers?

magit-save-repository-buffers docstring reads "Save file-visiting
buffers belonging to the current repository." IIUC, prompting to save
abbrevs here is an undesirable implementation side-effect.

Another example: hyperdrive.el adds to save-some-buffers-functions for
saving hyperdrive file buffers:

https://git.sr.ht/~ushin/hyperdrive.el/tree/d7dc7a08ba47761108cf98e21ffa2d8dad28f34a/item/hyperdrive.el#L99

After this change, magit-save-repository-buffers now prompts to save
irrelevant hyperdrive file buffers. I would like some way to tell
hyperdrive--save-some-buffers not to prompt the user to save hyperdrive
buffers from inside magit-save-repository-buffers.

> And are you saying that before the change which added
> save-some-buffers-functions, Emacs was not saving the abbrevs when
> save-some-buffers was called?  If so, in what Emacs version was this
> so?

The behavior of saving abbrevs when a PRED function is passed to
save-some-buffers has not changed in Emacs 29. I just think that there
may be room for improvement now that save-some-buffers-functions allows
any package to add to save-some-buffers-functions.

> We need a better understanding of the situation before we can discuss
> solutions, so please fill-in the blanks outlined above.

I hope the explanation above is clear. Sorry for starting off on the
wrong foot with an XY problem!

Thank you!

Joseph

bug#65414: save-some-buffers-functions are unexpectedly called when save-some-buffers pred is non-nil

[Eli Zaretskii]

> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: 65414@debbugs.gnu.org, jonas@bernoul.li
> Date: Wed, 23 Aug 2023 16:57:06 -0700
> 
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Why is asking whether to save the abbrevs a problem in the case of
> > magit-save-repository-buffers?
> 
> magit-save-repository-buffers docstring reads "Save file-visiting
> buffers belonging to the current repository." IIUC, prompting to save
> abbrevs here is an undesirable implementation side-effect.

Why is it undesirable?  save-some-buffers always saved abbrevs, didn't
it?  And it did so independently of PRED, right?  So how did this
problem suddenly started affecting Magit?

IOW, I still don't have a clear idea what caused this problem, if
(AFAIU) it is a problem that started happening recently.

> Another example: hyperdrive.el adds to save-some-buffers-functions for
> saving hyperdrive file buffers:
> 
> https://git.sr.ht/~ushin/hyperdrive.el/tree/d7dc7a08ba47761108cf98e21ffa2d8dad28f34a/item/hyperdrive.el#L99
> 
> After this change, magit-save-repository-buffers now prompts to save
> irrelevant hyperdrive file buffers. I would like some way to tell
> hyperdrive--save-some-buffers not to prompt the user to save hyperdrive
> buffers from inside magit-save-repository-buffers.

Why do you want to do that?  Whether or not to prompt the user abides
by the common protocol defined by save-some-buffers: if it's called
with the argument ARG non-nil (which should happen interactively when
the user invokes the command with a prefix argument), there's no
prompt, otherwise Emacs prompts.  Why magit-save-repository-buffers
wants to break this common protocol?

I feel that I'm still missing something important, which causes you to
want a different behavior from magit-save-repository-buffers.  For
starters, can you describe how magit-save-repository-buffers ends up
calling save-some-buffers-functions in enough detail for me to
understand why you think saving these buffers is deemed "undesirable"?

> > And are you saying that before the change which added
> > save-some-buffers-functions, Emacs was not saving the abbrevs when
> > save-some-buffers was called?  If so, in what Emacs version was this
> > so?
> 
> The behavior of saving abbrevs when a PRED function is passed to
> save-some-buffers has not changed in Emacs 29. I just think that there
> may be room for improvement now that save-some-buffers-functions allows
> any package to add to save-some-buffers-functions.

We could try thinking about some backward-compatible change to the
save-some-buffers-functions feature, but a better understanding of the
issue is still needed.

Thanks.

bug#65414: save-some-buffers-functions are unexpectedly called when save-some-buffers pred is non-nil

[Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Cc: 65414@debbugs.gnu.org, jonas@bernoul.li
>> Date: Wed, 23 Aug 2023 16:57:06 -0700
>>
>> magit-save-repository-buffers docstring reads "Save file-visiting
>> buffers belonging to the current repository." IIUC, prompting to save
>> abbrevs here is an undesirable implementation side-effect.
>
> Why is it undesirable?  save-some-buffers always saved abbrevs, didn't
> it?  And it did so independently of PRED, right?  So how did this
> problem suddenly started affecting Magit?
>
> IOW, I still don't have a clear idea what caused this problem, if
> (AFAIU) it is a problem that started happening recently.

This problem is not new. However, now that save-some-buffers-functions
has been added, the problem goes beyond abbrevs.

>> Another example: hyperdrive.el adds to save-some-buffers-functions for
>> saving hyperdrive file buffers:
>>
>> https://git.sr.ht/~ushin/hyperdrive.el/tree/d7dc7a08ba47761108cf98e21ffa2d8dad28f34a/item/hyperdrive.el#L99
>>
>> After this change, magit-save-repository-buffers now prompts to save
>> irrelevant hyperdrive file buffers. I would like some way to tell
>> hyperdrive--save-some-buffers not to prompt the user to save hyperdrive
>> buffers from inside magit-save-repository-buffers.
>
> Why do you want to do that?  Whether or not to prompt the user abides
> by the common protocol defined by save-some-buffers: if it's called
> with the argument ARG non-nil (which should happen interactively when
> the user invokes the command with a prefix argument), there's no
> prompt, otherwise Emacs prompts.  Why magit-save-repository-buffers
> wants to break this common protocol?

I think magit-save-repository-buffers follows the common protocol
correctly.

> I feel that I'm still missing something important, which causes you to
> want a different behavior from magit-save-repository-buffers.  For
> starters, can you describe how magit-save-repository-buffers ends up
> calling save-some-buffers-functions in enough detail for me to
> understand why you think saving these buffers is deemed "undesirable"?

The issue is not that save-some-buffers prompts instead of saving
without questions.

What is undesirable to me is that save-some-buffers unconditionally
calls each one of save-some-buffers-functions, regardless of PRED. This
means that when save-some-buffers is used with the intention to save
only a handful of files (as with magit-save-repository-buffers),
save-some-buffers-functions are all called, even when irrelevant.

Thanks again for your patience :)

Joseph

bug#65414: save-some-buffers-functions are unexpectedly called when save-some-buffers pred is non-nil

[Eli Zaretskii]

> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: 65414@debbugs.gnu.org, jonas@bernoul.li
> Date: Fri, 25 Aug 2023 23:38:18 -0700
> 
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Why is it undesirable?  save-some-buffers always saved abbrevs, didn't
> > it?  And it did so independently of PRED, right?  So how did this
> > problem suddenly started affecting Magit?
> >
> > IOW, I still don't have a clear idea what caused this problem, if
> > (AFAIU) it is a problem that started happening recently.
> 
> This problem is not new. However, now that save-some-buffers-functions
> has been added, the problem goes beyond abbrevs.
> 
> >> Another example: hyperdrive.el adds to save-some-buffers-functions for
> >> saving hyperdrive file buffers:
> >>
> >> https://git.sr.ht/~ushin/hyperdrive.el/tree/d7dc7a08ba47761108cf98e21ffa2d8dad28f34a/item/hyperdrive.el#L99
> >>
> >> After this change, magit-save-repository-buffers now prompts to save
> >> irrelevant hyperdrive file buffers. I would like some way to tell
> >> hyperdrive--save-some-buffers not to prompt the user to save hyperdrive
> >> buffers from inside magit-save-repository-buffers.
> >
> > Why do you want to do that?  Whether or not to prompt the user abides
> > by the common protocol defined by save-some-buffers: if it's called
> > with the argument ARG non-nil (which should happen interactively when
> > the user invokes the command with a prefix argument), there's no
> > prompt, otherwise Emacs prompts.  Why magit-save-repository-buffers
> > wants to break this common protocol?
> 
> I think magit-save-repository-buffers follows the common protocol
> correctly.
> 
> > I feel that I'm still missing something important, which causes you to
> > want a different behavior from magit-save-repository-buffers.  For
> > starters, can you describe how magit-save-repository-buffers ends up
> > calling save-some-buffers-functions in enough detail for me to
> > understand why you think saving these buffers is deemed "undesirable"?
> 
> The issue is not that save-some-buffers prompts instead of saving
> without questions.
> 
> What is undesirable to me is that save-some-buffers unconditionally
> calls each one of save-some-buffers-functions, regardless of PRED. This
> means that when save-some-buffers is used with the intention to save
> only a handful of files (as with magit-save-repository-buffers),
> save-some-buffers-functions are all called, even when irrelevant.

So your problem is with Lisp programs that add functions to
save-some-buffers-functions, but don't expect or don't want those
functions to be called each time save-some-buffers is invoked?

I'm not sure how did those Lisp programs get the idea that
save-some-buffers-functions will not be called always -- is it hinted
by some documentation somewhere?  If not, I'd say that those Lisp
programs have a bug that needs to be fixed in those programs.  Right?

In any case, not calling save-some-buffers-functions when PRED is
non-nil is not something we can do, as that would be an incompatible
behavior change.  We could perhaps add PRED to the arguments with
which save-some-buffers-functions are called, as an optional argument.
Would that be satisfactory?

bug#65414: save-some-buffers-functions are unexpectedly called when save-some-buffers pred is non-nil

[Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 940 bytes --]


Eli Zaretskii <eliz@gnu.org> writes:
> So your problem is with Lisp programs that add functions to
> save-some-buffers-functions, but don't expect or don't want those
> functions to be called each time save-some-buffers is invoked?

Yes.

> I'm not sure how did those Lisp programs get the idea that
> save-some-buffers-functions will not be called always -- is it hinted
> by some documentation somewhere?  If not, I'd say that those Lisp
> programs have a bug that needs to be fixed in those programs.  Right?

I agree.

> In any case, not calling save-some-buffers-functions when PRED is
> non-nil is not something we can do, as that would be an incompatible
> behavior change.  We could perhaps add PRED to the arguments with
> which save-some-buffers-functions are called, as an optional argument.
> Would that be satisfactory?

Yes, that would solve the interference between Magit and hyperdrive.el.

See patch.

Thank you!

Joseph


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Pass-PRED-to-each-of-save-some-buffers-functions.patch --]
[-- Type: text/x-diff, Size: 2175 bytes --]

From 28e8745b579da5f83afc7f9eb5b5ed2df2f3204e Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Sat, 26 Aug 2023 00:50:28 -0700
Subject: [PATCH] Pass PRED to each of save-some-buffers-functions

* lisp/abbrev.el (abbrev--possibly-save): Ignore PRED
* lisp/files.el (save-some-buffers-functions): Fix documentation
(save-some-buffers): Pass PRED to each of save-some-buffers-functions
---
 lisp/abbrev.el | 2 +-
 lisp/files.el  | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/lisp/abbrev.el b/lisp/abbrev.el
index e1311dbc83b..43e7c7e5e5d 100644
--- a/lisp/abbrev.el
+++ b/lisp/abbrev.el
@@ -1242,7 +1242,7 @@ which see."
               '(edit-abbrevs-mode-font-lock-keywords nil nil ((?_ . "w"))))
   (setq font-lock-multiline nil))
 
-(defun abbrev--possibly-save (query &optional arg)
+(defun abbrev--possibly-save (query &optional arg _pred)
   ;; Query mode.
   (if (eq query 'query)
       (and save-abbrevs abbrevs-changed)
diff --git a/lisp/files.el b/lisp/files.el
index 29d109ab385..6ab10cc3310 100644
--- a/lisp/files.el
+++ b/lisp/files.el
@@ -6003,8 +6003,8 @@ function should return non-nil if there is something to be
 saved (but it should not actually save anything).
 
 If the first argument is something else, then the function should
-save according to the value of the second argument, which is the
-ARG argument from `save-some-buffers'.")
+save according to the values of the second and third arguments,
+which are the ARG and PRED arguments from `save-some-buffers'.")
 
 (defun save-some-buffers (&optional arg pred)
   "Save some modified file-visiting buffers.  Asks user about each one.
@@ -6099,7 +6099,7 @@ after saving the buffers."
 	         save-some-buffers-action-alist))
           ;; Allow other things to be saved at this time, like abbrevs.
           (dolist (func save-some-buffers-functions)
-            (setq inhibit-message (or (funcall func nil arg) inhibit-message)))
+            (setq inhibit-message (or (funcall func nil arg pred) inhibit-message)))
           (or queried (> files-done 0) inhibit-message
 	      (cond
 	       ((null autosaved-buffers)
-- 
2.41.0

bug#65414: save-some-buffers-functions are unexpectedly called when save-some-buffers pred is non-nil

[Eli Zaretskii]

> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: 65414@debbugs.gnu.org, jonas@bernoul.li
> Date: Sat, 26 Aug 2023 00:32:23 -0700
> 
> 
> > In any case, not calling save-some-buffers-functions when PRED is
> > non-nil is not something we can do, as that would be an incompatible
> > behavior change.  We could perhaps add PRED to the arguments with
> > which save-some-buffers-functions are called, as an optional argument.
> > Would that be satisfactory?
> 
> Yes, that would solve the interference between Magit and hyperdrive.el.
> 
> See patch.

Hmm... but how to make this change backward-compatible?  I mean, if
there's some function out there that is used in
save-some-buffers-functions, and it was written to accept only 2
arguments, we cannot safely call it with 3 arguments, can we?

Stefan, do we have any way of doing that without causing errors?

If not, perhaps the way forward is to bind some variable around the
call to these functions, whose value will be PRED?

bug#65414: save-some-buffers-functions are unexpectedly called when save-some-buffers pred is non-nil

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> > In any case, not calling save-some-buffers-functions when PRED is
>> > non-nil is not something we can do, as that would be an incompatible
>> > behavior change.  We could perhaps add PRED to the arguments with
>> > which save-some-buffers-functions are called, as an optional argument.
>> > Would that be satisfactory?
>> Yes, that would solve the interference between Magit and hyperdrive.el.
>> See patch.

[ Sorry, `debbugs.gnu.org` appears to be down, so I couldn't read the
  whole bug report, so I haven't seen the patch among other things.
  Hopefully that doesn't invalidate my comment :-)  ]

> Hmm... but how to make this change backward-compatible?  I mean, if
> there's some function out there that is used in
> save-some-buffers-functions, and it was written to accept only 2
> arguments, we cannot safely call it with 3 arguments, can we?

AFAICT `save-some-buffers-functions` is brand new in Emacs-29.1 and
currently gets called sometimes with 1 and sometimes with 2 arguments
(that's a somewhat unusual API in this respect), so it's probably OK to
break backward compatibility because it will only affect fresh code that
can easily be adjusted.

[ Arguably, it would be even better to arrange for `hyperdrive.el` to
  save its buffers "in the usual way", i.e. relying on
  `buffer-offer-save`, `save-buffer`, `buffer-save-without-query, ...  ]


        Stefan

bug#65414: save-some-buffers-functions are unexpectedly called when save-some-buffers pred is non-nil

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Joseph Turner <joseph@breatheoutbreathe.in>,  65414@debbugs.gnu.org,
>   jonas@bernoul.li
> Date: Sun, 03 Sep 2023 13:06:07 -0400
> 
>  Sorry, `debbugs.gnu.org` appears to be down

It is back up.

bug#65414: save-some-buffers-functions are unexpectedly called when save-some-buffers pred is non-nil

[Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

> [ Arguably, it would be even better to arrange for `hyperdrive.el` to
>   save its buffers "in the usual way", i.e. relying on
>   `buffer-offer-save`, `save-buffer`, `buffer-save-without-query, ...  ]

I was not aware of `buffer-offer-save`. Thank you for the suggestion!
Since we already rely on `save-buffer`, setting `buffer-offer-save` to t
is much simpler than adding to `save-some-buffers-functions`. It also
resolves the interference between Magit and hyperdrive.el.

However... I wonder what the intended purpose of
`save-some-buffers-functions` is if packages like `hyperdrive.el` are
intended to use `buffer-offer-save`?

Joseph

bug#65414: save-some-buffers-functions are unexpectedly called when save-some-buffers pred is non-nil

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> However... I wonder what the intended purpose of
> `save-some-buffers-functions` is if packages like `hyperdrive.el` are
> intended to use `buffer-offer-save`?

IIUC the purpose is to save things that are kept in variables rather
than buffers.


        Stefan

bug#65414: save-some-buffers-functions are unexpectedly called when save-some-buffers pred is non-nil

[Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

>> However... I wonder what the intended purpose of
>> `save-some-buffers-functions` is if packages like `hyperdrive.el` are
>> intended to use `buffer-offer-save`?
>
> IIUC the purpose is to save things that are kept in variables rather
> than buffers.

Good to know. Thanks!

bug#65414: save-some-buffers-functions are unexpectedly called when save-some-buffers pred is non-nil

[Eli Zaretskii]

> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: Eli Zaretskii <eliz@gnu.org>, 65414@debbugs.gnu.org, jonas@bernoul.li
> Date: Sun, 03 Sep 2023 10:52:39 -0700
> 
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > [ Arguably, it would be even better to arrange for `hyperdrive.el` to
> >   save its buffers "in the usual way", i.e. relying on
> >   `buffer-offer-save`, `save-buffer`, `buffer-save-without-query, ...  ]
> 
> I was not aware of `buffer-offer-save`. Thank you for the suggestion!
> Since we already rely on `save-buffer`, setting `buffer-offer-save` to t
> is much simpler than adding to `save-some-buffers-functions`. It also
> resolves the interference between Magit and hyperdrive.el.

Does this mean we can close this issue without any changes to the
save-some-buffers-functions machinery?

bug#65414: save-some-buffers-functions are unexpectedly called when save-some-buffers pred is non-nil

[Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On September 4, 2023 3:53:24 AM PDT, Eli Zaretskii <eliz@gnu.org> wrote:
>Does this mean we can close this issue without any changes to the
>save-some-buffers-functions machinery?

That's fine by me, yes.

Thank you for taking the time to walk me through to a solution!!

Joseph

bug#65414: save-some-buffers-functions are unexpectedly called when save-some-buffers pred is non-nil

[Eli Zaretskii]

> Date: Mon, 04 Sep 2023 08:54:52 -0700
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> CC: monnier@iro.umontreal.ca, 65414@debbugs.gnu.org, jonas@bernoul.li
> 
> 
> 
> On September 4, 2023 3:53:24 AM PDT, Eli Zaretskii <eliz@gnu.org> wrote:
> >Does this mean we can close this issue without any changes to the
> >save-some-buffers-functions machinery?
> 
> That's fine by me, yes.

Done.

> Thank you for taking the time to walk me through to a solution!!

You are welcome.

bug#65414: save-some-buffers-functions are unexpectedly called when save-some-buffers pred is non-nil

[Juri Linkov]

>> > In any case, not calling save-some-buffers-functions when PRED is
>> > non-nil is not something we can do, as that would be an incompatible
>> > behavior change.  We could perhaps add PRED to the arguments with
>> > which save-some-buffers-functions are called, as an optional argument.
>> > Would that be satisfactory?
>>
>> Yes, that would solve the interference between Magit and hyperdrive.el.
>>
>> See patch.
>
> Hmm... but how to make this change backward-compatible?  I mean, if
> there's some function out there that is used in
> save-some-buffers-functions, and it was written to accept only 2
> arguments, we cannot safely call it with 3 arguments, can we?

If nothing else helps, just catch 'wrong-number-of-arguments',
then call with an obsolete signature again.

bug#65414: save-some-buffers-functions are unexpectedly called when save-some-buffers pred is non-nil

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Joseph Turner <joseph@breatheoutbreathe.in>,  Stefan Monnier
>  <monnier@iro.umontreal.ca>,  jonas@bernoul.li,  65414@debbugs.gnu.org
> Date: Sun, 03 Sep 2023 20:22:56 +0300
> 
> > Hmm... but how to make this change backward-compatible?  I mean, if
> > there's some function out there that is used in
> > save-some-buffers-functions, and it was written to accept only 2
> > arguments, we cannot safely call it with 3 arguments, can we?
> 
> If nothing else helps, just catch 'wrong-number-of-arguments',
> then call with an obsolete signature again.

I was hoping for a cleaner, more elegant solution.  Still do.