GNU bug report logs -
#54399
27.2; Problems with (let ((custom-variable ...)) (autoload-function ...))
Previous Next
Reported by: Ignacio Casso <ignaciocasso <at> hotmail.com>
Date: Tue, 15 Mar 2022 15:53:02 UTC
Severity: normal
Tags: moreinfo
Found in version 27.2
Fixed in version 29.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> 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
This bug report was last modified 2 years and 342 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.