Re: Rant - Elisp terminology is deceptive

[Kelly Dean <kelly@prtime.org>]

David Kastrup wrote:
> A buffer does not have an "environment".

What do you call the thing that lists the bindings of buffer-local variables to values? The standard term for a list of bindings of variables to values that's used for resolving variable references, both in Lisp and elsewhere, is ‟environment”.

> It has a list of global variable values
> to substitute whenever it is made current.

You mean like a closure can have? (A closure's environment can also have variables with names that aren't names of global variables, but that's not the point here.)
(setq foo
      (lexical-let ((shift-select-mode 'bar))
	(lambda () shift-select-mode)))
(funcall foo) → bar

> buffer-local variables _are_ buffer-local versions of _global_
> variables.

shift-select-mode above is a closure-local version of a global variable.

> With setq-default you are not setting
> a value that is in any manner more or less global than a buffer-local
> setting.

setq-default sets the global variable, which is visible in other buffers (unless they shadow it with their own buffer-locals).
A buffer-local variable is not visible in other buffers.

I don't know how buffer-locals are implemented internally, but from a user's (and Elisp programmer's) point of view, a buffer has an environment with variables that shadow global variables. If the value of each variable in that environment is stored as part of the structure that stores the value of the same-named global variable rather than being stored in a separate list of bindings for the environment, that's irrelevant. The effect is the same.

The help system agrees with me. It doesn't call buffer-locals ‟global”. It _contrasts_ buffer-locals and globals. E.g. describe-variable for mark-active tells me:
mark-active is a variable defined in `buffer.c'.
Its value is t
Local in buffer *Help*; global value is nil