From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Mauro Aranda Newsgroups: gmane.emacs.bugs Subject: bug#25152: 25.1; Customize: errors for `restricted-sexp' in `repeat' Date: Sat, 24 Oct 2020 09:33:29 -0300 Message-ID: References: <45d48716-1ac9-4cb3-9c64-042dddee4e77@default> <3a76061b-efa8-41b3-9baf-e3297a79b847@default> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000004f279305b269e8c0" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25571"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 25152@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 24 14:34:31 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kWIkh-0006TD-Ay for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 24 Oct 2020 14:34:31 +0200 Original-Received: from localhost ([::1]:43068 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kWIkg-0002FJ-2M for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 24 Oct 2020 08:34:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47794) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kWIkF-0002EV-0g for bug-gnu-emacs@gnu.org; Sat, 24 Oct 2020 08:34:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49587) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kWIkE-0000Sg-JI for bug-gnu-emacs@gnu.org; Sat, 24 Oct 2020 08:34:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kWIkE-0005s8-FG for bug-gnu-emacs@gnu.org; Sat, 24 Oct 2020 08:34:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Mauro Aranda Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 24 Oct 2020 12:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25152 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 25152-submit@debbugs.gnu.org id=B25152.160354283122549 (code B ref 25152); Sat, 24 Oct 2020 12:34:02 +0000 Original-Received: (at 25152) by debbugs.gnu.org; 24 Oct 2020 12:33:51 +0000 Original-Received: from localhost ([127.0.0.1]:32900 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kWIk2-0005rd-Hg for submit@debbugs.gnu.org; Sat, 24 Oct 2020 08:33:50 -0400 Original-Received: from mail-wm1-f42.google.com ([209.85.128.42]:50539) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kWIk0-0005rN-7B for 25152@debbugs.gnu.org; Sat, 24 Oct 2020 08:33:49 -0400 Original-Received: by mail-wm1-f42.google.com with SMTP id 13so5050126wmf.0 for <25152@debbugs.gnu.org>; Sat, 24 Oct 2020 05:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c/vhuE8bl0cRioT/GW3duxPNtmY9aVIk1+nT+E6b/lw=; b=F35FEbDTLo2eXVj+MMVWMe5s6QhlPCFCJEXtMRY4IFeNH326+0a2FvDX2TaH3o+yL9 r1H8FNVgOtXVTBMi9rs42HXQwNKqFe9eyuwP3SxQTPyMMEcN8/XqqaiLFuQke4tkozqG YCrxRijsMMJmv8A6M2AEKYaP/nkOugst593bSTUXwJzO5d76d7PKTIBNXzna3aLsdyap 3+JaA4hgM3o7RgIkVMeLprXTO/oRLrqeisKRtywCRmsH1PkRHcuGAkUIDwsOJg9ooYeM H/qplsMKFs6gLo9MHDEVzkh/p92vyrTj9PxVYzxJ+YgFuQlkU0sxXsOedn04QJJ42AG5 HyeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c/vhuE8bl0cRioT/GW3duxPNtmY9aVIk1+nT+E6b/lw=; b=Ql/8XrAm2Pznz6JeqfHdwCBC2qqHW9QfXlzWXYGcrRcW86y2OJTosRu+mwzYjLqDME gKhw2Cy76dn/Nsq8txHLHfAlWmE6pLaFLi3x4iL8p5SYi50Ru8WSdAfa4J+CdHkzMcre 38XrtovzZ5jspgwJ2a5V55gxZ5k88+JDh7MKP+/HRHnGkfQnWa+Mb0tp2hbm1pes28wh ymzvAxRvYF8mBhnNLOZ3gKgYVHDyu/hMaRsN2Ri63MRlxEItNqK8DRfYGwSGIu3qWoQD W00kuF+A+hpzZVIJFIi+AxWMyOlslFCkIduckaZcRb+MLtknwSeojddL2PY4hbsm9zYf qz+w== X-Gm-Message-State: AOAM532CNrDxgt0cj/IuFrVPdzLYHmjJGNEO13zo43bhvYX2BXZRCZTr CMTqa24RnrnNkDrNZoquGWfMKD/LuiCkpY0QJfg= X-Google-Smtp-Source: ABdhPJytgTAK0fQFtCjZoAMG3wA6xhzTEtOBx49XP6JWFb9htPFaMiv3T5p8cH4uJZ4wlS6eglQEkutfRip4XZZAO9I= X-Received: by 2002:a1c:dc43:: with SMTP id t64mr6996001wmg.6.1603542822363; Sat, 24 Oct 2020 05:33:42 -0700 (PDT) In-Reply-To: <3a76061b-efa8-41b3-9baf-e3297a79b847@default> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:191419 Archived-At: --0000000000004f279305b269e8c0 Content-Type: text/plain; charset="UTF-8" Drew Adams 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? --0000000000004f279305b269e8c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Drew Adams <dr= ew.adams@oracle.com> writes:

>> Coming back to this, pe= rhaps a good place to warn about a bad
>> default value is where w= e find it for the first time.=C2=A0 So I attach a
>> patch that ma= kes the restricted-sexp widget warn (but not error out)
>> if the = internal value is not a string.
>
>> When the user clicks th= e INS button, the following warning pops up:
>> Warning (widget-ba= d-default-value):
>> A widget of type restricted-sexp has a bad d= efault value.
>> value: nil
>> match function: widget-res= tricted-sexp-match
>> match-alternatives: (functionp)
>><= br>>> which I hope conveys good enough information to fix the mistake= .
>>
>> I made it just a warning, because this mistake do= esn't always result in
>> a messed up buffer.=C2=A0 But it can= be changed to an error, of course.
>
> I may have forgotten so= me of what this is about.=C2=A0 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).=C2=A0 They can expect warnings
> and errors ab= out their own behavior, but not messages
> about some problem with th= e defcustom definition.

I didn't mean to say it was up to the us= er to fix it.=C2=A0 I said "good
enough information to fix the mist= ake", meaning the user can report to
the maintainer the warning tex= t along with the actions that triggered
it, and the maintainer should be= able to take it from there.

> If the problem can't be detect= ed before a user tries to
> customize, then maybe, when she does, the= warning should
> make it very clear that the _default_ value is a mi= smatch
> and advise the user to report a bug to the library author.
I think it is clear it is about the default value.=C2=A0 The message = says
"A widget of type restricted-sexp has a bad default value.&quo= t;

> IOW make clear that it's not about the user doing
>= ; something wrong (and don't prevent the user from
> continuing t= o customize to a valid value).

I don't see how a user could thin= k he did something wrong with the
warning text I suggested.=C2=A0 I cert= ainly don't think I did something wrong
whenever I get Gtk-CRITICAL = messages while using some software.

And since it is a warning, the u= ser can continue customizing the value.
So, I think that's covered.<= br>
> Make it very
> clear that the problem is with the maintai= ner of the code,
> and suggest that the user report the problem.=C2= =A0 And give
> the user some detailed info that can be copied in a re= port
> to the library maintainer.

Do you think the example tex= t I gave in the previous message lacks some
information about the widget= that triggered the warning?=C2=A0 If so, what do
you think is missing?<= br>
--0000000000004f279305b269e8c0--