[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Specifiers
From: |
Stefan Monnier |
Subject: |
Re: Specifiers |
Date: |
Thu, 29 May 2008 13:36:47 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) |
> Note that this is mostly theoretic: in practice, one would rarely want
> to use different locus types for a single variable.
Until you get bug-reports. The situation changes significantly if you
disallow combining different locus types: it's still not great
performancewise, but it's much more sane.
>> - what about `let'? This one is really fun!
> `let' temporarily makes a locus-free binding. The locality gets
> restored at the end of let. This is not different to the current
> interaction of buffer-locality and let.
The current `let' behavior does not create temporarily
a locus-free binding. E.g.
(let ((default-directory "toto"))
(with-current-buffer "newbuf" default-directory)
does not return "toto".
>> what does
>> (let ((var val)) .. (make-local-variable 'var locus) ..)
>> do? how 'bout
>> (make-local-variable 'var foo) .. (let ((var val)) .. (setq var foo)?
>> or
>> (make-local-variable 'var foo)..(let ((var val))..(select-other-foo..)var)?
> It gets messy. But this messiness is nothing new:
There is something new about it, which is that as you add more types of
loci, it gets more and more difficult and costly to react to
locus-changes (e.g. set-buffer, select-window, select-frame, setq
major-mode, ...).
> The problem is that we already have buffer-locality and frame-locality
> and terminal-locality.
Indeed, that's a problem. But frame-locality is on the way out.
Buffer-locality is here to stay, I think.
As for terminal-locality it is both less clean (because it's not really
developped, e.g. no equivalent to local-variable-p), and less
problematic because it cannot be combined with buffer-locality or
frame-locality and it is automatically local to all terminals rather
than only some, so it basically doesn't have global bindings, and it
only applies to predefined variables.
> And the behavior of all those is currently inconsistent. The approach
> I proposed would make them consistent.
Show me a patch, so I can shoot holes through it.
Or better, don't bother: you'd be wasting your time.
> Adding something functionally similar to the existing localities but
> incompatible is not really helping keeping things simple.
You're looking for a simplicity akin to a 17-dimension "unifiying theory
of physics". You may end up with a single very powerful and orthogonal
set of features, but I do not believe you'll get something simple.
> And as long as not more than one locality was introduced, there would
> be no speed impact for the list-based implementation.
I do not know what you're referring to here.
Stefan
- Re: face-remapping patch, (continued)
- Re: face-remapping patch, Richard M Stallman, 2008/05/30
- Re: face-remapping patch, David Kastrup, 2008/05/30
- Re: face-remapping patch, Richard M Stallman, 2008/05/31
- Re: face-remapping patch, David Kastrup, 2008/05/31
- Re: face-remapping patch, Richard M Stallman, 2008/05/29
- Re: face-remapping patch, David Kastrup, 2008/05/29
- Specifiers (was: face-remapping patch), Stefan Monnier, 2008/05/29
- Re: Specifiers, David Kastrup, 2008/05/29
- Re: Specifiers,
Stefan Monnier <=
- Re: Specifiers, Stephen J. Turnbull, 2008/05/29
- Re: Specifiers (was: face-remapping patch), Richard M Stallman, 2008/05/29
- Re: Specifiers, Stefan Monnier, 2008/05/29
- Re: Specifiers, David Kastrup, 2008/05/30
- Re: Specifiers, Stefan Monnier, 2008/05/30
- Re: Specifiers, David Kastrup, 2008/05/30
- Re: Specifiers, Stefan Monnier, 2008/05/30
- Re: Specifiers, Richard M Stallman, 2008/05/31
- Re: face-remapping patch, Stefan Monnier, 2008/05/29
- Re: face-remapping patch, David Kastrup, 2008/05/29