From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Mauro Aranda Newsgroups: gmane.emacs.bugs Subject: bug#15214: 24.3.50; `Revert This Session's Customization' does not do what it says Date: Wed, 1 Jan 2020 11:47:45 -0300 Message-ID: References: <8b504c44-91b3-4c9f-bca5-3b4d1547f67f@default> <83mub8laut.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="000000000000982373059b15292d" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="53089"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 15214@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 01 15:49:12 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1imfJA-000Dfk-Aw for geb-bug-gnu-emacs@m.gmane.org; Wed, 01 Jan 2020 15:49:12 +0100 Original-Received: from localhost ([::1]:58922 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1imfJ9-0007VP-49 for geb-bug-gnu-emacs@m.gmane.org; Wed, 01 Jan 2020 09:49:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46970) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1imfJ1-0007V6-U6 for bug-gnu-emacs@gnu.org; Wed, 01 Jan 2020 09:49:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1imfJ0-0002Vk-3a for bug-gnu-emacs@gnu.org; Wed, 01 Jan 2020 09:49:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58620) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1imfIz-0002Ui-UX for bug-gnu-emacs@gnu.org; Wed, 01 Jan 2020 09:49:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1imfIz-0007dN-TD for bug-gnu-emacs@gnu.org; Wed, 01 Jan 2020 09:49:01 -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, 01 Jan 2020 14:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15214 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 15214-submit@debbugs.gnu.org id=B15214.157789008629281 (code B ref 15214); Wed, 01 Jan 2020 14:49:01 +0000 Original-Received: (at 15214) by debbugs.gnu.org; 1 Jan 2020 14:48:06 +0000 Original-Received: from localhost ([127.0.0.1]:36360 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1imfI5-0007cD-KL for submit@debbugs.gnu.org; Wed, 01 Jan 2020 09:48:06 -0500 Original-Received: from mail-lj1-f177.google.com ([209.85.208.177]:35797) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1imfI4-0007bk-1o for 15214@debbugs.gnu.org; Wed, 01 Jan 2020 09:48:04 -0500 Original-Received: by mail-lj1-f177.google.com with SMTP id j1so31089414lja.2 for <15214@debbugs.gnu.org>; Wed, 01 Jan 2020 06:48:03 -0800 (PST) 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=eCoK6o6SBc0oPKSMGt1oH5L95tB4YaUu1pfSi9hPThk=; b=aDWo2cq2UwfLrOew/H0DuJNQbLeY9aUCp2yqJkrn74NlUf0Vz0sDVeOQOHJNOfXVS+ /62VslElYrl5cCKNS8ESvzrMUlHBzs56v4SK8Vb/0uboag7+ruU6QFYjlE6jd5wjf0ii cffu6tc4OBIFUdGtT0mJ+oNLkapv/3w2LhVk+hZ+8HlBbLYEoqjQpuSleZJyblJBJ+uI zi2FsmYbciBfGX3hdOJyWLsg6eVSWWKN3Bo68blN+ltbK+F219TEmbYfA1r1QR053JNh KPPNJ8Ck6CeuaWH1loT2mHo7TNKF6utxvJY8T6LzzteTr0riqo5xLgkdHru1kk5twLO6 f9LQ== 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=eCoK6o6SBc0oPKSMGt1oH5L95tB4YaUu1pfSi9hPThk=; b=PKYBGh1ctl24jXfqW3CFTyOqQbDGn786B/c2HkjpqmGmxvj70iFeMi5lB4Q4DIlZ4S aNeT6z1JtPwfulhVMFl7qP3qI6QN0bs7oIADvYGHkWtom9lwqgBbvNZobANNlIgHSRU/ IJ0lNq8yapfWufTm912bQohRI+gjHx+3nihGFShxQfu1ZKvimEIFjlKJdqoYIjAavNGH xNQs3gPj9mfytWxeW5zeFbfhiRGyf0TtsajeSypgq8iFRmm19fOTHn2q6kVntxNkyEIG y48crNwbsnTAaB3VvAmA57oOA4gez5rrsZQx5oK5zOI6xCWiMS/zQalg+FoFPjhsMVMO ah9A== X-Gm-Message-State: APjAAAWq9ukmju+bB0rx98hbHm9dI3pa/fGgEfePEiZ6KXFPEBeS4pVf tiGJPko0zEgDHPwGPBp2PbnqXBOvGm0/LgZCJoA= X-Google-Smtp-Source: APXvYqxfgoo0mmGqmzOCQYX/cNvRvraqEM32sF3wQEPSLU/xIuqxPaV7Q3UYkLl2dMqjrgK1yF8YoKbUJU1dkO15cD8= X-Received: by 2002:a2e:8152:: with SMTP id t18mr45932282ljg.255.1577890077999; Wed, 01 Jan 2020 06:47:57 -0800 (PST) In-Reply-To: <83mub8laut.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:174036 Archived-At: --000000000000982373059b15292d Content-Type: multipart/alternative; boundary="000000000000982371059b15292b" --000000000000982371059b15292b Content-Type: text/plain; charset="UTF-8" Eli Zaretskii writes: >> From: Mauro Aranda >> Date: Mon, 30 Dec 2019 18:30:31 -0300 >> >> > Click State and Revert This Session's Customization. > > You should instead click "Set to Backup Value". The Revert button is > in general for variables you have saved for future sessions. For user options that are of boolean type, that works well. But for other kinds of user options, there is a risk it won't work: 1. emacs -Q 2. M-x customize-variable dired-kept-versions 3. Edit the field to 3 and then Set for current session. 4. Now edit it to 4, and then Set for current session. Now "Set to Backup Value" won't ever take you back to the state before your session's customizations. >> The function that runs for that option is custom-variable-reset-saved, >> and the doc string of custom-variable-reset-saved says something similar. > > The doc string is ambiguous, and the code definitely does NOT intend > to reset the value, just to remove the recorded setting, so that it > won't be saved in the custom file. That code was installed in What part of the doc string do you find ambiguous? Personally, I was baffled about the (themed or standard) part, because if there is a theme value (other than the user theme), that value counts as the saved value too. As for the intentions of the code, a symbol with no 'saved-value property set would be enough for the customization to not be saved in the custom file, AFAICS. It's true that it does not intend to reset the value, but at least my reading of the doc string makes me think it does, the Emacs manual says it does, and even though the use case is rare, I think it's better to do it. > response to a very similar bug report (bug#9509, except that it > complained that Emacs signals an error for a variable that was never > saved). I very much doubt that Chong, who made that change, omitted > setting the value by mistake. In Bug#9509 the suggestion was to revert those settings to the un-customized value. I can't tell whether Chong was inclined to take that suggestion or not, but I do think that we should take it. > In general, there's a feature creep here: this menu item was > originally only for customized options that were saved during this > session. That was lifted back then, and now we want also to change > the value, although another menu item exists to do just that. See the first part of my reply. I don't think there is another menu item in an emacs -Q session able to take one back to the uncustomized value, reliably. >> The attached patch fixes custom-variable-reset-saved to do what it says >> it does when the variable has no previous saved value. > > I won't object too much to such a change, if you still think it's TRT > here after reading the above, but I wonder whether it would be cleaner > and safer to set just the value, and move the funcall out of the > if-else form, so that we'd have only one funcall, and it will be > inside ignore-errors. I still think it would be a good addition to the code. In case you are OK with it, I attach a patch with moves the funcall outside of the if-else form. Best regards, Mauro. --000000000000982371059b15292b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Eli Zaretskii <eliz@gnu= .org> writes:

>> From: Mauro Aranda <maurooaranda@gmail.com>
>> Date:= Mon, 30 Dec 2019 18:30:31 -0300
>>
>> > Click State = and Revert This Session's Customization.
>
> You should ins= tead click "Set to Backup Value".=C2=A0 The Revert button is
&= gt; in general for variables you have saved for future sessions.

For= user options that are of boolean type, that works well.=C2=A0 But for
o= ther kinds of user options, there is a risk it won't work:

1. em= acs -Q
2. M-x customize-variable dired-kept-versions
3. Edit the fiel= d to 3 and then Set for current session.
4. Now edit it to 4, and then S= et for current session.

Now "Set to Backup Value" won'= t ever take you back to the state before
your session's customizatio= ns.

>> The function that runs for that option is custom-variab= le-reset-saved,
>> and the doc string of custom-variable-reset-sav= ed says something similar.
>
> The doc string is ambiguous, and= the code definitely does NOT intend
> to reset the value, just to re= move the recorded setting, so that it
> won't be saved in the cus= tom file.=C2=A0 That code was installed in

What part of the doc stri= ng do you find ambiguous? Personally, I was
baffled about the (themed or= standard) part, because if there is a
theme value (other than the user = theme), that value counts as
the saved value too.

As for the inte= ntions of the code, a symbol with no 'saved-value property
set would= be enough for the customization to not be saved in the custom
file, AFA= ICS.=C2=A0 It's true that it does not intend to reset the value, butat least my reading of the doc string makes me think it does, the Emacsmanual says it does, and even though the use case is rare, I think it'= s
better to do it.

> response to a very similar bug report (bu= g#9509, except that it
> complained that Emacs signals an error for a= variable that was never
> saved).=C2=A0 I very much doubt that Chong= , who made that change, omitted
> setting the value by mistake.
In Bug#9509 the suggestion was to revert those settings to the
un= -customized value.=C2=A0 I can't tell whether Chong was inclined to
take that suggestion or not, but I do think that we should take it.<= br>

> In general, there's a feature creep here: this menu i= tem was
> originally only for customized options that were saved duri= ng this
> session.=C2=A0 That was lifted back then, and now we want a= lso to change
> the value, although another menu item exists to do ju= st that.

See the first part of my reply.=C2=A0 I don't think the= re is another menu
item in an emacs -Q session able to take one back to = the uncustomized
value, reliably.
=C2=A0 =C2=A0 =C2=A0 =C2=A0
>= ;> The attached patch fixes custom-variable-reset-saved to do what it sa= ys
>> it does when the variable has no previous saved value.
&g= t;
> I won't object too much to such a change, if you still think= it's TRT
> here after reading the above, but I wonder whether it= would be cleaner
> and safer to set just the value, and move the fun= call out of the
> if-else form, so that we'd have only one funcal= l, and it will be
> inside ignore-errors.

I still think it wou= ld be a good addition to the code.=C2=A0 In case you are
OK with it, I a= ttach a patch with moves the funcall outside of the
if-else form.
Best regards,
Mauro.
--000000000000982371059b15292b-- --000000000000982373059b15292d Content-Type: text/x-patch; charset="US-ASCII"; name="0001-Reset-to-the-standard-value-when-reverting-session-s.patch" Content-Disposition: attachment; filename="0001-Reset-to-the-standard-value-when-reverting-session-s.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_k4vez0ot0 RnJvbSAwZjEzMDcyMzlkMjlmNGEwNjg3OGM5NTg0MGQ5YTQzMzE4Zjg1N2I1IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBNYXVybyBBcmFuZGEgPG1hdXJvb2FyYW5kYUBnbWFpbC5jb20+ CkRhdGU6IE1vbiwgMzAgRGVjIDIwMTkgMTg6MTA6MjggLTAzMDAKU3ViamVjdDogW1BBVENIXSBS ZXNldCB0byB0aGUgc3RhbmRhcmQgdmFsdWUgd2hlbiByZXZlcnRpbmcgc2Vzc2lvbidzCiBjdXN0 b21pemF0aW9ucwoKKiBsaXNwL2N1cy1lZGl0LmVsIChjdXN0b20tdmFyaWFibGUtcmVzZXQtc2F2 ZWQpOiBXaGVuIHRoZXJlIGlzIG5vCnByZXZpb3VzIHNhdmVkIHZhbHVlLCByZXNldCB0byB0aGUg c3RhbmRhcmQgdmFsdWUuICAoQnVnIzE1MjE0KQotLS0KIGxpc3AvY3VzLWVkaXQuZWwgfCAxOSAr KysrKysrKysrLS0tLS0tLS0tCiAxIGZpbGUgY2hhbmdlZCwgMTAgaW5zZXJ0aW9ucygrKSwgOSBk ZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9saXNwL2N1cy1lZGl0LmVsIGIvbGlzcC9jdXMtZWRp dC5lbAppbmRleCA0Mzk2NjdhLi44YTVmYzhjIDEwMDY0NAotLS0gYS9saXNwL2N1cy1lZGl0LmVs CisrKyBiL2xpc3AvY3VzLWVkaXQuZWwKQEAgLTMwMzUsMTcgKzMwMzUsMTggQEAgY3VzdG9tLXZh cmlhYmxlLXJlc2V0LXNhdmVkCiBiZWZvcmUgdGhpcyBvcGVyYXRpb24gYmVjb21lcyB0aGUgYmFj a3VwIHZhbHVlLiIKICAgKGxldCogKChzeW1ib2wgKHdpZGdldC12YWx1ZSB3aWRnZXQpKQogCSAo c2F2ZWQtdmFsdWUgKGdldCBzeW1ib2wgJ3NhdmVkLXZhbHVlKSkKLQkgKGNvbW1lbnQgKGdldCBz eW1ib2wgJ3NhdmVkLXZhcmlhYmxlLWNvbW1lbnQpKSkKKwkgKGNvbW1lbnQgKGdldCBzeW1ib2wg J3NhdmVkLXZhcmlhYmxlLWNvbW1lbnQpKQorICAgICAgICAgdmFsdWUpCiAgICAgKGN1c3RvbS12 YXJpYWJsZS1iYWNrdXAtdmFsdWUgd2lkZ2V0KQogICAgIChpZiAobm90IChvciBzYXZlZC12YWx1 ZSBjb21tZW50KSkKLQk7OyBJZiB0aGVyZSBpcyBubyBzYXZlZCB2YWx1ZSwgcmVtb3ZlIHRoZSBz ZXR0aW5nLgotCShjdXN0b20tcHVzaC10aGVtZSAndGhlbWUtdmFsdWUgc3ltYm9sICd1c2VyICdy ZXNldCkKLSAgICAgIDs7IE90aGVyd2lzZSwgYXBwbHkgdGhlIHNhdmVkIHZhbHVlLgotICAgICAg KHB1dCBzeW1ib2wgJ3ZhcmlhYmxlLWNvbW1lbnQgY29tbWVudCkKLSAgICAgIChjdXN0b20tcHVz aC10aGVtZSAndGhlbWUtdmFsdWUgc3ltYm9sICd1c2VyICdzZXQgKGNhci1zYWZlIHNhdmVkLXZh bHVlKSkKLSAgICAgIChpZ25vcmUtZXJyb3JzCi0JKGZ1bmNhbGwgKG9yIChnZXQgc3ltYm9sICdj dXN0b20tc2V0KSAnc2V0LWRlZmF1bHQpCi0JCSBzeW1ib2wgKGV2YWwgKGNhciBzYXZlZC12YWx1 ZSkpKSkpCisgICAgICAgIDs7IElmIHRoZXJlIGlzIG5vIHNhdmVkIHZhbHVlLCByZW1vdmUgdGhl IHNldHRpbmcuCisgICAgICAgIChjdXN0b20tcHVzaC10aGVtZSAndGhlbWUtdmFsdWUgc3ltYm9s ICd1c2VyICdyZXNldCkKKyAgICAgIChzZXRxIHZhbHVlIChjYXItc2FmZSBzYXZlZC12YWx1ZSkp CisgICAgICAoY3VzdG9tLXB1c2gtdGhlbWUgJ3RoZW1lLXZhbHVlIHN5bWJvbCAndXNlciAnc2V0 IHZhbHVlKQorICAgICAgKHB1dCBzeW1ib2wgJ3ZhcmlhYmxlLWNvbW1lbnQgY29tbWVudCkpCisg ICAgKGlnbm9yZS1lcnJvcnMKKyAgICAgIChmdW5jYWxsIChvciAoZ2V0IHN5bWJvbCAnY3VzdG9t LXNldCkgIydzZXQtZGVmYXVsdCkgc3ltYm9sCisgICAgICAgICAgICAgICAoZXZhbCAob3IgdmFs dWUgKGNhciAoZ2V0IHN5bWJvbCAnc3RhbmRhcmQtdmFsdWUpKSkpKSkKICAgICAocHV0IHN5bWJv bCAnY3VzdG9taXplZC12YWx1ZSBuaWwpCiAgICAgKHB1dCBzeW1ib2wgJ2N1c3RvbWl6ZWQtdmFy aWFibGUtY29tbWVudCBuaWwpCiAgICAgKHdpZGdldC1wdXQgd2lkZ2V0IDpjdXN0b20tc3RhdGUg J3Vua25vd24pCi0tIAoyLjcuNAoK --000000000000982373059b15292d--