[Top][All Lists]

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

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

From: Nix
Subject: Re: Tabs are ready? -> Let us give a definition of tabs.
Date: Mon, 13 Feb 2012 12:29:26 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.93 (gnu/linux)

On 13 Feb 2012, Stephen J. Turnbull verbalised:

> Nix writes:
>  > (The problem is simple: if a buffer and its frame *both* declare a
>  > variable to be 'local', which takes precedence? There is probably
>  > code that depends on *each* taking precedence, so any answer will
>  > be wrong.)
> I've not seen complaints about this in re: XEmacs specifiers where the
> default precedence is window beats buffer beats frame beats global
> beats baked-in-code-fallback.

Yeah, but horrible though specifiers are, at least they don't interfere
with normal variable lookup, which both has to remain consistent with
how it used to be (or break the world) *and* is time-critical. Calls to
'specifier-instance' just don't have the same criticality.

>                                (Of course that may be because people
> who need a different precedence use the DOMAIN parameter to
> `specifier-instance' -- but AFAIK only Ben Wing and I know that it
> exists.  *You* might, but who else would? :-)

Guilty :) I found it useful to use one set of colours on a TTY and
another in X...

> ISTM, that the question arises in Emacs because the *-local variables
> never had a different API from ordinary variable reference, so
> everybody just assumed it would DTRT for them.

Yep. However, I do think the Emacs approach is preferable *if* you can
work the wrinkles out: it's less irregular and more transparent. Nobody
gets confused about local variables the way everyone does about

Someone really should sit down with *-local variable precedence and give
it a good formal backing the way specifiers (sort of) got one. We
already have several layers of local variable: if one works, N should
work in an unsurprising fashion once the semantics are actually nailed
down. But it does mean you have to nail the semantics down first rather
than whapping in something that sort of works in the usual Emacs fashion

(note the careful absence of actors here: *I'm* not doing it anytime
soon! But the mythical impersonal infinite-in-capacity 'someone'
perhaps should.)

NULL && (void)

reply via email to

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