Re: Tabs are ready? -> Let us give a definition of tabs.

[Nix <nix@esperi.org.uk>]

On 13 Feb 2012, Tom Tromey outgrape:

>>>>>> "Nix" == Nix  <nix@esperi.org.uk> writes:
>
> Nix> Well, yes, but that's really *because* nobody could figure out
> Nix> consistent and unsurprising semantics regarding the interaction of
> Nix> *-local variables with (let ...). That problem remains: it's there even
> Nix> for buffer-locals, which we are surely not planning to deprecate.
>
> What are the problems with just buffer-locals?  I thought they were
> pretty well-defined.

Agreed, but that doesn't mean they're not problematic.

>                       There's some text and an example in the manual
> that explains the weird case.  If there are other weird cases, I would
> like to know what they are.

See, the intuitive definition of buffer-locals would have them nesting
just underneath the global scope, so they would never ever supplant let
bindings. I can't imagine anyone actually wanting the current semantics:
they are purely an implementation artifact.

Can you recall any elisp code that establishes let bindings, switches
buffers, then operates under the assumption that some or all of its let
bindings or parameters may have changed? Because that's what we should
be doing if we actually think those semantics make sense and don't want
our elisp code broken by users establishing whatever buffer-local
bindings they like. Nobody actually codes that way, because it would be
insane. Instead we *hope* that nobody establishes makes variables
buffer-local whose names overlap the names of any local variables or
parameters. Generally, we are lucky (and it is actually quite hard to
contrive a case that is broken by the current rules). But this is hardly
ideal!

More worryingly, if you choose the wrong name for your buffer-local
variable, parameters and local bindings will smash it out of hand, with
no warnings at all. *This* is easy to contrive a test for: just try
assigning a local value to a buffer-local variable named 'start': it
doesn't even survive a round of C-h v and quit-window!

We may be saved here by the relatively large size of the space available
for names, and by the fact that mostly it is Lisp code that establishes
new global and buffer-local bindings, not users. But it is still icky
and feels *wrong* and generally makes my correctness-inclined skin
crawl.

> Once you add other kinds of locals you have to decide how they all
> interact.

Yep. That's what I meant by someone having to sit down and define the
semantics of this sort of thing before adding any new types of
locally-scoped variable. But the behaviour of buffer-locals is, to be
honest, already a bug, documented or not. You can break all sorts of
core Emacs functions with M-x make-local-variable, which is not
documented nor expected by users who do it.

>            That is a lot harder than just defining how buffer-locals
> act.

Unfortunately they do not currently act in a way I would consider
consistent. "The global value is global, the local value is less local
than 'let' unless you switch buffers inside a 'let' whereupon it is
suddenly more local than 'let', even if you switch back again" is not
sane. It happens to be easy to implement, but it doesn't follow anything
I would consider normal scoping rules for any language.

It so happens that this rarely causes trouble. But *ick*.

-- 
NULL && (void)