GNU bug report logs -
#63648
29.0.90; project.el: with switch-use-entire-map, switch-project errors on non-project commands
Previous Next
Reported by: Spencer Baugh <sbaugh <at> janestreet.com>
Date: Mon, 22 May 2023 16:29:02 UTC
Severity: normal
Found in version 29.0.90
Done: Dmitry Gutov <dmitry <at> gutov.dev>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
On 23/08/2023 16:53, Spencer Baugh wrote:
> Oh, another thought (which maybe should be discussed on emacs-devel):
> maybe we don't need to make this specific next-default-directory var.
>
> Instead, maybe what we want is a way to bind a dynamic variable
> *without* changing the buffer-local value. It would shadow the existing
> binding, but if we explicitly switched buffer we'd get back to the old
> value. So we'd have:
>
> (special-let ((default-directory newval))
> (assert default-directory newval))
>
> and
>
> (special-let ((default-directory newval))
> (set-buffer (current-buffer))
> (assert default-directory oldval))
Where does the main logic run in this case?
If we call set-buffer before the main logic is ran, the old value of dd
will be used.
If we call set-buffer after the main logic is ran, we could as well use
plain 'let' because that's what it does: restores the previous values at
the end (and we know that it doesn't suit our purpose).
I was also considering rebinding the global value of dd instead, but
that turned out to be even sillier, since any new buffer inherits the
local value of this var from the previous buffer, the global one isn't
used anywhere (or doesn't seem to be).
(cl-letf (((default-value 'default-directory) "~/Documents/"))
(with-temp-buffer
(message "dv %s" (default-value 'default-directory))
(message "lv %s" default-directory)))
So to make use of this, every relevant spot would have to look up the
global value of this var manually. Might as well use the special var
that we already have (...-override).
This bug report was last modified 1 year and 200 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.