bug#25152: 25.1; Customize: errors for `restricted-sexp' in `repeat'

[Drew Adams <drew.adams@oracle.com>]

> > If the problem is the default value then it's not up to
> > a user to fix it, and most users won't know how to deal
> > with such a warning (or error).  They can expect warnings
> > and errors about their own behavior, but not messages
> > about some problem with the defcustom definition.
>
> I didn't mean to say it was up to the user to fix it.  I said "good
> enough information to fix the mistake", meaning the user can report to
                                                  ^^^^^^^^^^^^^^^^^^^
> the maintainer the warning text along with the actions that triggered
> it, and the maintainer should be able to take it from there.

The user has to be able to understand that that;
that is, to know that it's a maintainer problem
and they should report it.  I don't think your
current user message invites that understanding.

> > If the problem can't be detected before a user tries to
> > customize, then maybe, when she does, the warning should
> > make it very clear that the _default_ value is a mismatch
> > and advise the user to report a bug to the library author.
>
> I think it is clear it is about the default value.  The message says
> "A widget of type restricted-sexp has a bad default value."
>
> > IOW make clear that it's not about the user doing
> > something wrong (and don't prevent the user from
> > continuing to customize to a valid value).
>
> I don't see how a user could think he did something wrong with the
> warning text I suggested.  I certainly don't think I did something wrong
> whenever I get Gtk-CRITICAL messages while using some software.
>
> And since it is a warning, the user can continue customizing the value.
> So, I think that's covered.
>
> > Make it very
> > clear that the problem is with the maintainer of the code,
> > and suggest that the user report the problem.  And give
> > the user some detailed info that can be copied in a report
> > to the library maintainer.
>
> Do you think the example text I gave in the
> previous message lacks some information about
> the widget that triggered the warning?  If so,
> what do you think is missing?

This is the message you suggested, right?

 Warning (widget-bad-default-value): 
 A widget of type restricted-sexp has a bad default value.
 value: nil
 match function: widget-restricted-sexp-match
 match-alternatives: (functionp)

Yes, I think that message is not so helpful for
users.  Most users won't know what a widget is,
or a restricted-sexp, or any of the rest.  They
won't know  what this is all about, or what
they're supposed/asked to do about it.

And yet it's a message aimed at users (who else
will see it?).

What I suggested was that the message to users
should tell them:

1. The default value for the option is invalid.
   (Speak of option, not widget.)
2. They should report this as a bug to the maintainer.
3. They can still customize the option, to give it
   a valid value.

If possible, we should also tell them _how_ to
report the problem to the maintainer.  At least
as a fallback, we can tell them to use `M-x
report-emacs-bug'.

We can tell them to use `report-emacs-bug' if we
can determine that the widget is vanilla.  And we
might tell them that anyway, even if we have no
idea who the maintainer is.

IOW, this is a message to a user who tries to
interact with Customize.  Either we say nothing
or we tell the user there's a problem with the
default value, and in the latter case we suggest
that they report the problem to whoever defined
the default value.

What we should avoid is giving the user an
impression that they shouldn't continue to try to
customize the option, or that they themselves did
something wrong.  And we should avoid confusing
them, speaking in terms of code/implementation.

I may be missing something, but it seems to me
that the message you're reporting is not for a
user - it's a message to someone who can fix the
problem, and maybe even someone who caused it.
AFAICT, the message you're sending is a message
for a maintainer, not for a user.

If this were a byte-compiler message, it might
be OK.  Users know that those messages are
generally about the code being compiled, which
is not something they're (typically) responsible
for.

But a message responding to an interactive user
action can't be something that talks about the
underlying code (which isn't the user's fault) -
UNLESS the message tells the user clearly that
it's about that code AND asks them to report it
to someone who might fix it.

Just one opinion.