%s is neither a Command command nor a source

[astoff]

I've had these lines in my config since time immemorial:

  (consult-customize consult--source-bookmark
                     consult--source-recent-file
                     consult--source-project-recent-file
                     :preview-key "M-.")

With the update to Consult 3.3 this breaks with the message "consult--customize-put: consult--source-bookmark is neither a Command command nor a source". The fix is easy (those symbols now are single-dashed) but I never received any deprecation warning, so maybe the final renaming was premature?

[minad]

There was a deprecation warning for some time starting from version 3.0. If you upgrade directly from 2.x to 3.3 you might not get the warning. The problem with deprecation warnings in the init.el is anyway that people don't see them, as long as the init.el is not compiled.

[astoff]

Well, I don't think you can expect all users to compile their init files. There even is (or was) a recommendation against it somewhere in the documentation. In my case, because my init full of with-eval-after-loads, I can't byte compile it without a bunch of spurious warnings anyway.

[minad]

Yes, there is actually no possibility to safely deprecate anything which is used in init.el.

[minad]

Btw, if one interprets your issue in a narrow minded way, consult--source-* had been private all along, so you should expect it to vanish at any point. ;)

I don't mean this seriously, since consult--source-* sources had been documented and used prominently in customizable variables. That's the reason for making these sources finally public.

[astoff]

Right, there's no good general way to deprecate user-facing variables. I guess my point is, since here you're crafting an error message anyway, you might as well mention the deprecations in the error message.

Also, I think a one-time error (better: a warning with a fuller explanation referring to consult-customize instead of consult--customize-put) would be more appropriate in this case. I was getting the error every time I tried to use a Consult command, instead of having my (mis)configuration ignored (which would also be the usual effect of a (setq deprecated-variable ...)).

[minad]

I guess my point is, since here you're crafting an error message anyway, you might as well mention the deprecations in the error message.

Well, the error message has been there all along to catch invalid variables. It doesn't have to do anything with the deprecation. But I could have added a deprecation message there during the deprecation period. This would have been reasonable.

Also, I think a one-time error (better: a warning with a fuller explanation referring to consult-customize instead of consult--customize-put) would be more appropriate in this case.

Agree. No idea to improve this though - the user-error thrown from consult--customize-put will take the topmost element from the stack and print it as part of the message 🤷🏾

Maybe it would be better to turn consult-customize into a plain function instead of a macro.

I was getting the error every time I tried to use a Consult command, instead of having my (mis)configuration ignored (which would also be the usual effect of a (setq deprecated-variable ...)).

Hmm, that's odd. I had assumed that the error would be shown once during initialization - this was at least my intention.

EDIT: I think maybe the problem is that Consult loading fails as consequence of the error. I've changed this now to print a warning instead and improved the warning message.

[minad]

I think this can be closed now, given the change to a warning. This way the error is effectively ignored.

[astoff]

Thanks!