bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#54399: 27.2; Problems with (let ((custom-variable ...)) (autoload-fu


From: Stefan Monnier
Subject: bug#54399: 27.2; Problems with (let ((custom-variable ...)) (autoload-function ...))
Date: Tue, 12 Apr 2022 18:15:18 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

> Probably because I don't really understand all the concepts involved
> here. But I expect functions that operate on the default value of the
> buffer-local dimension to behave the same way regardless of whether the
> current buffer happens to have actually a local value.

You're looking at the dimensions in the wrong way.  It's like when we
split a window in two.  Some persons will say it's split vertically
(because the two new windows are stacked vertically) while others will
say it's split horizontally (because the line delimiting the two new
windows is horizontal).

When I say that `default-value` operates on the buffer-localness, I mean
that the difference `default-value` and `symbol-value` only differ with
respect to whether they consider a buffer-local value or not.

They're both stuck in the current (i.e. most deeply nested) let-binding
in either case.

IOW, the choice between `default-value` and `symbol-value` lets you walk
along the line between buffer-local and not-buffer-local, but it does
not let you walk up the stack of nested let-bindings.
Only `default-toplevel-value` lets you do that (and it only does that on
the non-buffer-local part of the space: there is nothing like
`symbol-toplevel-value` which would let you find the "top-level
buffer-local value").

> But never mind, I just wanted to ensure that the current behavior was
> the expected one

It is, yes.


        Stefan






reply via email to

[Prev in Thread] Current Thread [Next in Thread]