GNU bug report logs - #73084
[PATCH] Include the variable name in the `setopt` warning

Previous Next

Package: emacs;

Reported by: Okamsn <okamsn <at> protonmail.com>

Date: Sat, 7 Sep 2024 00:24:01 UTC

Severity: normal

Tags: patch

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 73084 in the body.
You can then email your comments to 73084 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#73084; Package emacs. (Sat, 07 Sep 2024 00:24:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Okamsn <okamsn <at> protonmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 07 Sep 2024 00:24:01 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Okamsn <okamsn <at> protonmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Include the variable name in the `setopt` warning
Date: Sat, 07 Sep 2024 00:23:00 +0000
[Message part 1 (text/plain, inline)]
Hello,

The attached patch adds the variable name to the `setopt` warning.

I write my Emacs config in an Org file, from which I make the Emacs Lisp 
file.  Currently, if `setopt` detects that the value I wish to make a 
variable hold does not conform to the variable's Custom.el type, then it 
reports the type and the problematic value, but not the variable itself, 
when I open Emacs.  This adds extra steps to editing the code in the Org 
file to fix the warning, especially when the value is created 
programmatically.  It would be faster to search for the variable name 
directly in the Org file and to then re-tangle the Org file.

Thank you.
[0001-Include-the-variable-name-in-the-warning-in-setopt-s.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#73084; Package emacs. (Sat, 07 Sep 2024 12:45:01 GMT) Full text and rfc822 format available.

Message #8 received at 73084 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Okamsn <okamsn <at> protonmail.com>
Cc: 73084 <at> debbugs.gnu.org
Subject: Re: bug#73084: [PATCH] Include the variable name in the `setopt`
 warning
Date: Sat, 07 Sep 2024 12:36:05 +0000
Okamsn <okamsn <at> protonmail.com> writes:

> Hello,
>
> The attached patch adds the variable name to the `setopt` warning.
>
> I write my Emacs config in an Org file, from which I make the Emacs Lisp 
> file.  Currently, if `setopt` detects that the value I wish to make a 
> variable hold does not conform to the variable's Custom.el type, then it 
> reports the type and the problematic value, but not the variable itself, 
> when I open Emacs.  This adds extra steps to editing the code in the Org 
> file to fix the warning, especially when the value is created 
> programmatically.  It would be faster to search for the variable name 
> directly in the Org file and to then re-tangle the Org file.

I think this is a good idea!  What might also be useful would be to
generate line warnings, as the backtrace should have the necessary
information.

> Thank you.
>
> From 7cc7134b1b751428b7c14a0b54f55193a59363b1 Mon Sep 17 00:00:00 2001
> From: Earl Hyatt <okamsn <at> protonmail.com>
> Date: Fri, 6 Sep 2024 20:04:24 -0400
> Subject: [PATCH] Include the variable name in the warning in `setopt--set'.
>
> Including the variable name makes it easier to find the location of the
> error.
>
> * lisp/cus-edit.el (setopt--set): Include the variable name in the
> warning.
> ---
>  lisp/cus-edit.el | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lisp/cus-edit.el b/lisp/cus-edit.el
> index 9f5ac47490c..035499deb71 100644
> --- a/lisp/cus-edit.el
> +++ b/lisp/cus-edit.el
> @@ -1072,7 +1072,7 @@ setopt--set
>    ;; Check that the type is correct.
>    (when-let ((type (get variable 'custom-type)))
>      (unless (widget-apply (widget-convert type) :match value)
> -      (warn "Value `%S' does not match type %s" value type)))
> +      (warn "`%s': Value `%S' does not match type %s" variable value type)))
>    (put variable 'custom-check-value (list value))
>    (funcall (or (get variable 'custom-set) #'set-default) variable value))

-- 
	Philip Kaludercic on siskin




Reply sent to Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility. (Sun, 08 Sep 2024 06:23:02 GMT) Full text and rfc822 format available.

Notification sent to Okamsn <okamsn <at> protonmail.com>:
bug acknowledged by developer. (Sun, 08 Sep 2024 06:23:02 GMT) Full text and rfc822 format available.

Message #13 received at 73084-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Okamsn <okamsn <at> protonmail.com>
Cc: 73084-done <at> debbugs.gnu.org
Subject: Re: bug#73084: [PATCH] Include the variable name in the `setopt`
 warning
Date: Sun, 08 Sep 2024 09:21:59 +0300
> Date: Sat, 07 Sep 2024 00:23:00 +0000
> From:  Okamsn via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> The attached patch adds the variable name to the `setopt` warning.
> 
> I write my Emacs config in an Org file, from which I make the Emacs Lisp 
> file.  Currently, if `setopt` detects that the value I wish to make a 
> variable hold does not conform to the variable's Custom.el type, then it 
> reports the type and the problematic value, but not the variable itself, 
> when I open Emacs.  This adds extra steps to editing the code in the Org 
> file to fix the warning, especially when the value is created 
> programmatically.  It would be faster to search for the variable name 
> directly in the Org file and to then re-tangle the Org file.

Thanks, I made the warning say

  Value `foo' for variable `bar' does not match its type "type"

I installed this on the master branch, and I'm therefore closing this
bug.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sun, 06 Oct 2024 11:24:13 GMT) Full text and rfc822 format available.

This bug report was last modified 255 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.