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#59937: 28.2; Bad defcustom behavior Date: Wed, 14 Dec 2022 19:20:29 -0300 Message-ID: <5a25029e-f20b-4c17-2bba-0b4bf7510a69@gmail.com> References: <533dba58-e543-f356-664f-5dfa0b85467c@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13462"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Cc: "59937@debbugs.gnu.org" <59937@debbugs.gnu.org> To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Dec 14 23:21:18 2022 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 1p5a7q-0003ES-0M for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 14 Dec 2022 23:21:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p5a7e-00035z-2F; Wed, 14 Dec 2022 17:21:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p5a7b-00035C-Ey for bug-gnu-emacs@gnu.org; Wed, 14 Dec 2022 17:21:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p5a7b-0003f8-6W for bug-gnu-emacs@gnu.org; Wed, 14 Dec 2022 17:21:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p5a7a-0001Pf-SV for bug-gnu-emacs@gnu.org; Wed, 14 Dec 2022 17:21:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Mauro Aranda Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 14 Dec 2022 22:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59937 X-GNU-PR-Package: emacs Original-Received: via spool by 59937-submit@debbugs.gnu.org id=B59937.16710564445382 (code B ref 59937); Wed, 14 Dec 2022 22:21:02 +0000 Original-Received: (at 59937) by debbugs.gnu.org; 14 Dec 2022 22:20:44 +0000 Original-Received: from localhost ([127.0.0.1]:41947 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p5a7I-0001Ok-2Q for submit@debbugs.gnu.org; Wed, 14 Dec 2022 17:20:44 -0500 Original-Received: from mail-oa1-f52.google.com ([209.85.160.52]:44977) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p5a7D-0001Oc-94 for 59937@debbugs.gnu.org; Wed, 14 Dec 2022 17:20:42 -0500 Original-Received: by mail-oa1-f52.google.com with SMTP id 586e51a60fabf-1447c7aa004so18571177fac.11 for <59937@debbugs.gnu.org>; Wed, 14 Dec 2022 14:20:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=6au6ZPXF0e6nHMufDUDqdKr9j0Ddepx9vRUiZjr71v4=; b=NQzhLz9eIlLRPLk2lXNplahss3wqCKV+mDHIZDVkIXd0Onvd5NMPPpxr0ZD/znZTCH I7p7tPXDMHqBwMA+kmLQxGi1R3SlrWZb1dkM62pqIAOCvmSp1g/EhxiS2SRPm0eF3zMs QFJvltZp9W1bY8EbgYKZCXULCtYWYpiP9ffgvb2tW1rD3pB1HH4LYacZsnr4Twyv95q9 zq4iF8DnUAbtNfAqR7BbWcByGhA7YLpSlFhjXIf9cd8mqgTQ+Cima6rArlR1rjEPnkQe /SF3wwI2Ev1Jb6KHfopvGUWc36yRL8zr8HCYrs9K8xRSFZ7yZxzwDFGjSnX8HrdAJWtQ RMrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6au6ZPXF0e6nHMufDUDqdKr9j0Ddepx9vRUiZjr71v4=; b=JdYafApmI08nDpDAo8Ov/jHyp5sRjkwKeF/OI/rZEJw7ZrzlRbqVS6df0yNka/dCJ0 S1GfBn47haLgeQbt0yzp/q81/PHHYPiUyi/aj0nOYN6nhfyY52K41f/nWXClo18yqWt2 N8hX+PWH9LcZzt8f5ICoV16+Viox2fcCB1oZkrlkrlSCjl7L5p9u/rR5p5/FS0armVba qrlmeptOAQStiy1fF0spP9v9nCMXzoZUX3zC+3XUdt4gDIzAiSZhlfrl1T1tgXxM4wLD 2nlQFUtMoZd4x6GSFr/EEfjGxwUgOfMNQBmJKNSLqlpHxyWEE2LmvrBa7FOiuX6FRQIH a1/w== X-Gm-Message-State: ANoB5pmddmLF8pPe4hu+MSZP6X1y/4MQscZ73Ber/fseBacLhtIaGr2L Z/RShQwd3iikBqXWR56yJdU= X-Google-Smtp-Source: AA0mqf5edVs9wNKq5khzoBtpgp4x4klvRha6ZapueH8mPZ3Wy/k1cR2R0PKECIYGSQp0q6bQmUtPEA== X-Received: by 2002:a05:6871:786:b0:143:4c24:a77 with SMTP id o6-20020a056871078600b001434c240a77mr14703659oap.32.1671056433502; Wed, 14 Dec 2022 14:20:33 -0800 (PST) Original-Received: from [192.168.0.234] ([181.228.28.240]) by smtp.gmail.com with ESMTPSA id j18-20020a4adf52000000b004a085ddc771sm2730122oou.6.2022.12.14.14.20.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Dec 2022 14:20:32 -0800 (PST) Content-Language: en-US In-Reply-To: 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:251006 Archived-At: Drew Adams writes: >> Oh, I think I see a way around that now.  I think the following will >> take care of: >> >> 1.  Being able to create the restricted-sexp (sub)widget even if the >> default value isn't valid. >> (Which I think it's one of your main points throughout the bug report) >> >> 2.  Being able to do it without prompting or whatsoever. >> (Which is one of my main points in this conversation). > > Fabulous! > >> When the restricted-sexp widget has to be created, if there's a valid >> default value we create it with that one (like I showed in my previous >> message), but if there's not we create it empty. >> >> Let me know if you agree with that. > > 100%.  I hope you can do it without too much trouble. > It will make a big difference, I think, including > perhaps in how much people make use of `restricted-sexp'. > >> As I've said, I don't think we need to (nor want to) prompt.  I think >> the prompt there is just an accident, and I would like to avoid it. >> Sorry if I sound stubborn about this, but I'm convinced that prompting >> at that time of the widget's creation can be really harmful. > > I was seeing prompting only as a necessity as long as the code > requires a value before it can create the UI field for the > `restricted-sexp'.  If you can dispense with that need then great! > Certainly it would be much better not to have any prompting > (especially not with just the default prompt). Great! I'll work on it.  I hope I don't find any surprises. >> I've seen things like: >> (defcustom foo nil >>    "..." >>    :type '(repeat (function :value t))) >> >> And I would like to make more evident these kind of errors.  But if we >> find a way to cope with an invalid default value for the restricted-sexp >> widget, then it might be fine to remove it (I'm not so sure yet). > > I thought it already coped with invalid input. > I guess I was mistaken.  It definitely should. > > Generally, all Customize UI fields (including > buttons, checkboxes, etc.) do check the input > for validity, I think.  Not necessarily at the > time you edit but at least when you try to set > the value to what your editing resulted in. Yes, Customize checks at the time of creation (and inserts "(mismatch)" when the value isn't valid), and at the time of setting/saving. But the Widget code does not check when creating the widget. >> Yes, thanks to your response I was able to see a way to create the >> editable field (with value ""), when there's no valid default value. > > Really glad I could contribute something to this, > by my incessant arguing/questioning. ;-) > I appreciate your working on this.  I doubt that > anyone else would try to tackle it. :-) >>  > And definers ideally shouldn't need to specify >>  > default values for such fields - the set of >>  > predicates should be able to define what kind >>  > of UI field is needed. >> >> I'm not sure if I understand what you say here.  I don't think it's >> possible to figure out a good value to use as a default from the >> predicates: that's why my idea is about creating it with the empty >> string. > > Ah.  Maybe we do disagree, in the sense that I still > don't understand. > > Is there a _logical_ requirement that there be a > value, in order to create the editable field for > the `restricted-sexp'?  I don't think there should > be. > > That's different from the need for a value because > the current code works that way. > > But I really don't see why a value is needed.  All > the code needs to do is create an editable field > that expects text that satisfies the predicates, > no?  Of what (logical) use is the ("default") value? I think you're right on point.  It's just that the code works that way, and makes assumptions that there is always going to be a value (default or edited). >> So, would you agree to creating the restricted-sexp widget with an empty >> editable field, in case the default value is not valid? > > In case it's missing, definitely. > > In case it's not valid?  I guess so, but in that > case it would be good to signal an error (somehow), > or a message saying that it's invalid and so will > be ignored (create the field without any value). > >> Then the need to provide a valid default value is not so strong anymore >> (but still should be encouraged, I think), and Customize can work better >> and more intuitively when there isn't a valid default value. > > It all sounds good to me.  Looking forward to > whatever you come up with.  Thx. I'll see what I can do in the next days.  Thanks!