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

From: Mauro Aranda <[email-masked]>
Date: Sat, 24 Oct 2020 09:33:29 -0300

Drew Adams <[email-masked]> writes:

>> Coming back to this, perhaps a good place to warn about a bad
>> default value is where we find it for the first time.  So I attach a
>> patch that makes the restricted-sexp widget warn (but not error out)
>> if the internal value is not a string.
>
>> When the user clicks the INS button, the following warning pops up:
>> 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)
>>
>> which I hope conveys good enough information to fix the mistake.
>>
>> I made it just a warning, because this mistake doesn't always result in
>> a messed up buffer.  But it can be changed to an error, of course.
>
> I may have forgotten some of what this is about.  If so,
> please ignore...
>
> 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.

> 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?