emacs-devel
[Top][All Lists]
Advanced

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

Re: mode-line-format - local variableness


From: Stefan Monnier
Subject: Re: mode-line-format - local variableness
Date: Mon, 06 Apr 2009 09:30:50 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux)

> Oh, I thought it _was_ always buffer-local, even in recent Emacs.
> And I thought the manual was advising not to use `let' with
> buffer-local variables. 

"Always buffer-local" is used for variables for which a "global value"
basically doesn't make any sense.  `buffer-file-name' for example.
mode-line-format, OTOH has a default global value shared by most
buffers.  Ideally it probably shouldn't even be made buffer-loal by
`setq' but only by `make-local-variable'.

> That text is not too clear to me. Is it trying to say instead to not
> use `let' with a variable that _will be_ buffer-local but is not yet
> so? But it's OK to use `let' with a variable that is already
> buffer-local? Not too clear, IMO.

In general it's better to avoid mixing let and buffer-local.  If you
have to, then try to make sure that during the let, the variable's
buffer-localness is not changed.
In older versions of Emacs (<21 IIRC) you alsa had to try and avoid
switching into another buffer during the let (or at least revert back to
the same buffer before finishing the let).

> Whether or not that is actually cleaner, I don't know, but it
> certainly looks so.  I admit that I don't understand the problem with
> `let' and buffer-local-to-be-but-not-yet vars.

(let ((x e1)) e2) is more or less equivalent to

   (let ((old-x x))
     (unwind-protect
         (progn (setq x e1) e2)
       (setq x old-x)))

So if the buffer-localness of x is changed in `e2' we have a problem: if
old-x was read from the global part of `x', should (setq x old-x) assign
to the new buffer-local part of `x' or to the global part of `x'
or both?  If OTOH `old-x' was read from the buffer-local part of `x' but
`x' was kill-local-variable'd, should (setq x old-x) "reset" the global
part of `x' or do nothing?

There are reasonable choices for these questions, but no matter what you
choose, you will sooner or later find a situation where it doesn't
actually do what was intended, and furthermore, the implementation tends
to be painful and costly, which is a bummer since it's supposed to be
a *very* rare case that's fairly easy to avoid, yet you'll end up paying
for it all the time.


        Stefan




reply via email to

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