unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Ignacio Casso <ignaciocasso@hotmail.com>
To: 54399@debbugs.gnu.org, larsi@gnus.org,
	Michael Heerdegen <michael_heerdegen@web.de>
Subject: bug#54399: 27.2; Problems with (let ((custom-variable ...)) (autoload-function ...))
Date: Tue, 12 Apr 2022 11:13:27 +0200	[thread overview]
Message-ID: <PAXPR06MB776028CFD4246956E22CE0C7C6ED9@PAXPR06MB7760.eurprd06.prod.outlook.com> (raw)
In-Reply-To: <PAXPR06MB77608504A9705F55BD7FC456C6109@PAXPR06MB7760.eurprd06.prod.outlook.com>


> I think custom.el already uses `set-default-toplevel-value' where
> appropriate by default. So my request is (1) to correct the docstrings
> in custom.el to reflect so, so that users know to use it instead of
> `set-default', and (2) Add some warnings somewhere, although I'm not
> sure where.
> 
> I personally can not think of a single case in which someone would want
> to use `set-default' instead of `set-default-toplevel-value'. If I
> understand them correctly, they both do the same outside a let binding,
> and I don't see why someone would want the `set-default' behavior inside
> the let binding. In fact, I guess most people assume that `set-default'
> behaves like `set-default-toplevel-value' (I did at least).
> 
> So I would at least talk about this in the docstrings of `set-default',
> and also `default-value' and `default-boundp' which suffer the same
> problem. In fact, now that I see it, the docstring of the later is just
> wrong. The others just don't mention let bindings and only talk about
> buffer-local bindings, but that one explicitly says that the function
> can be used to know if a variable has a non-void value outside of a
> let-binding, and with dynamic binding that doesn't work (see snippet
> below).
> 
>   (setq lexical-binding nil)
>   (let ((another-fresh-var 1))
>     (default-boundp 'another-fresh-var)) ;; I expect nil, it returns t


Hello,

I was revisiting this bug report and writing a patch to correct and
update some docstrings, both in custom.el and for `default-value',
`set-default' and `default-boundp'. But for the last three, I'm no
longer sure if the errors are in the implementation or the docstrings,
since I have found more strange cases while experimenting. In a few
words, those functions behave differently inside let bindings depending
on whether the current buffer has or not a local value for the variable,
which I find a little bit inconsistent. If it has, they behave as they
"toplevel" counterparts (`default-toplevel-value',
`set-default-toplevel-value'). If they don't, they behave as I explained
in previous emails. I describe those cases below, with code snippets and
comments. Note that the behavior also depends on whether lexical binding
is enabled or not. I use dynamic binding in these examples.

;;;; `default-value'

;; default defined, buffer-local undefined
(defvar var1 "default")
(let ((var1 "inside let")) (default-value 'var1)) ;; returns "inside let"

;; default defined, buffer-local defined
(defvar var2 "default")
(setq-local var2 "buffer-local")
(let ((var2 "inside let")) (default-value 'var2)) ;; returns "default"

;; default undefined, buffer-local undefined
(let ((var3 "inside let")) (default-value 'var3)) ;; returns "inside let"

;; default undefined, buffer-local defined
(setq-local var4 "buffer-local")
(let ((var4 "inside let")) (default-value 'var4)) ;; void-variable error


;;;; `default-boundp'

;; default defined, buffer-local undefined
(defvar var5 "default")
(let ((var5 "inside let")) (default-boundp 'var5)) ;; returns t

;; default defined, buffer-local defined
(defvar var6 "default")
(setq-local var6 "buffer-local")
(let ((var6 "inside let")) (default-boundp 'var6)) ;; returns t

;; default undefined, buffer-local undefined
(let ((var7 "inside let")) (default-boundp 'var7)) ;; returns t

;; default undefined, buffer-local defined
(setq-local var8 "buffer-local")
(let ((var8 "inside let")) (default-boundp 'var8)) ;; returns nil


;;;; `set-default'

;; default defined, buffer-local undefined
(defvar var9 "default")
(let ((var9 "inside let"))
  (set-default 'var9 "new-default")
  var9)                                          ;; returns "new-default"
var9                                             ;; returns "default"
(default-value 'var9)                            ;; returns "default"

;; default defined, buffer-local defined
(defvar var10 "default")
(setq-local var10 "buffer-local")
(let ((var10 "inside let"))
  (set-default 'var10 "new-default")
  var10)                                         ;; returns "inside let"
var10                                            ;; returns "buffer-local"
(default-value 'var10)                           ;; returns "new-default"

;; default undefined, buffer-local undefined
(let ((var11 "inside let"))
  (set-default 'var11 "new-default")
  var11)                                         ;; returns "new-default"
var11                                            ;; void-variable error
(default-value 'var11)                           ;; void-variable error

;; default undefined, buffer-local defined
(setq-local var12 "buffer-local")
(let ((var12 "inside let"))
  (set-default 'var12 "new-default")
  var12)                                         ;; returns "inside let"
var12                                            ;; returns "buffer-local"
(default-value 'var12)                           ;; returns "new-default"


Should I go ahead and just update the docstrings so that they reflect
this behavior, and then close this bug report? Or do you think that the
code should be changed too? For the later I don't think I could help,
since that code is too low level for me.





  parent reply	other threads:[~2022-04-12  9:13 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-15 11:50 bug#54399: 27.2; Problems with (let ((custom-variable ...)) (autoload-function ...)) Ignacio Casso
2022-03-17 11:23 ` Lars Ingebrigtsen
2022-03-18  0:22   ` Michael Heerdegen
2022-03-18  1:02     ` Michael Heerdegen
2022-03-18  9:32     ` Lars Ingebrigtsen
2022-03-18  9:38       ` Ignacio Casso
2022-04-12 13:18         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-12 13:23           ` Ignacio Casso
2022-04-12 13:55             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-12  9:13 ` Ignacio Casso [this message]
2022-04-12 11:38   ` Eli Zaretskii
2022-04-12 12:16     ` Ignacio Casso
2022-04-12 13:35       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-12 14:27         ` Ignacio Casso
2022-04-12 15:04           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-12 15:27             ` Ignacio Casso
2022-04-12 22:15               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-13 15:26                 ` Ignacio Casso
2022-04-13  0:24         ` Michael Heerdegen
2022-04-13  3:26           ` Glenn Morris
2022-04-13  3:43             ` Michael Heerdegen
2022-04-12 15:24       ` Eli Zaretskii
2022-04-13 17:22         ` Ignacio Casso
2022-04-12 13:19   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-04-12 13:51     ` Ignacio Casso
2022-04-12 15:22       ` Eli Zaretskii
2022-04-13  0:06         ` Michael Heerdegen
2022-04-13 12:08           ` Ignacio Casso
2022-05-12  2:32             ` Lars Ingebrigtsen
2022-05-12  6:58               ` Ignacio Casso
2022-05-12  7:34                 ` Eli Zaretskii
2022-05-12  8:14                   ` Ignacio Casso
2022-05-12  8:36                     ` Eli Zaretskii
2022-05-12  8:41                       ` Ignacio Casso
2022-05-12  9:40                         ` Eli Zaretskii
2022-05-12 11:49                           ` Lars Ingebrigtsen
2022-06-09 15:02                         ` Lars Ingebrigtsen
2022-06-09 21:19                           ` Ignacio Casso
2022-06-10  9:13                             ` Lars Ingebrigtsen
2022-06-10 14:01                               ` dick
2022-06-11 10:51                                 ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=PAXPR06MB776028CFD4246956E22CE0C7C6ED9@PAXPR06MB7760.eurprd06.prod.outlook.com \
    --to=ignaciocasso@hotmail.com \
    --cc=54399@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    --cc=michael_heerdegen@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).