bug#31558: 27.0; `custom-file' settings messed up by Emacs 27

[Drew Adams]

> >> Maybe you put at the beginning of your custom file
> >> (or (locate-library "tramp") (provide 'tramp))
> >
> > Yes, I guess that would work and is better than nothing,
> > but it seems wrong to tell Emacs that something has
> > been provided that has not. ;-)
> >
> > Worse than style or ugliness, though, is that there
> > might be code here or there that tests
> > (featurep 'tramp) and acts accordingly.  That code
> > surely will be led astray by such a hack.
> 
> We're spaeking about Emacs < 22. How many such Emacsen are in use today,
> which also use packages checking for Tramp?

Yes, I said at the outset:

  Admittedly, this is probably not a problem that others
  will run into often.  But it is quite annoying for me.

I end up trying to remember to do this immediately after
saving any (!) user option in Emacs 26+: Open my
`custom-file' and delete the offending parts of the sexp.
Otherwise, when I later open Emacs 20 I get the error.

But when you say "which also use packages checking for
Tramp", what it really comes down to is being able to
use the same `custom-file' (which has only stuff that is
inserted automatically by Emacs) with multiple Emacs
releases (in this case including Emacs 20).

> > Seems like there should be a way for Tramp and
> > Customize to collaborate to produce a conditional
> > sexp that does not require tramp unconditionally.
> > E.g., one that tests (at time of evaluating
> > `custom-set-variables') whether Tramp is even
> > included in the Emacs version.
> >
> > Or maybe somehow just use a soft-require - the
> > equivalent of (require 'tramp nil t)?  Would that
> > work for Tramp, if it were possible for
> > `custom-set-variables'?
> >
> > Seems like something is missing from Emacs for
> > such cases.  A library wants to ensure that it is
> > loaded before evaluating a sexp that sets one of
> > its user options.  But if loading the library is
> > impossible then setting the variable is benign,
> > so a soft-require is all that is really needed.
> 
> If there were such a possibility I would consider it.

Can we perhaps consider this bug report as a request
for such an enhancement?

> But it must already exist for Emacsen < 22;

No, I don't think so.  (But I'm not sure what you mean.)
It would be enough that such a mechanism exists for
Emacs 26+ or whatever.

> I doubt we will change them if it's not possible yet.

Isn't it already possible to DTRT here (use a soft-require
instead of a hard-require)?

Can't Tramp, for example, just use a :set, or an :initialize,
function that does a soft-require, instead of using :require,
which puts a hard-require into `custom-file'?

Something like this, for example:

(defcustom tramp-verbose 3
  "..."
  :group 'tramp
  :type 'integer
  :set (lambda (sym val)
         (when (require 'tramp nil t)
           (custom-set-default sym val)))
  :initialize 'custom-initialize-set)

> And given the low likelihood plus the existing workaround,
> I believe it is not worth to spend time for this. Sorry.

I think the defcustom above would fit the bill, and it
would require no time to implement.  It just sets the
variable normally, but only if Tramp can first be loaded.

It does nothing is Tramp is not available.
(boundp 'tramp-verbose) returns nil in that case.

(Am I missing something?)