Re: frame-local variables weirdness

["Stephen J. Turnbull" <stephen@xemacs.org>]

FWIW, let me remind you that XEmacs has specifiers, which allow rather
flexible mix and match of buffer-local, window-local, and frame-local
properties.
The point is that specifiers have a separate API, no unmarked magic.

This has been a workable compromise for me in those cases where I want
to use it (eg, faces, where specifiers implement flexibility very similar to
Emacs's defface; XEmacs's faces are implemented as a wrapper around
a set of specifiers containing display properties).  There are a few other cases
where I've enjoyed the flexibility (usually controlling behavior of functions
associated with active regions in a display, and in controlling display elements
such as toolbars, tabs, and scrollbars).

David Kastrup may have an informative opinion, since he found XEmacs's glyph
(~ Emacs image) API, uh, "annoying" (and even its author admits it's probably
excessively complex and detailed).  But I'm not sure whether he objects to the
idea of such an API, or merely to XEmacs's implementation in glyphs.

On 10/15/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> > I found the discussion.  I see that someone asked for a feature to
> > display frame-specific data in the mode line, and I decided this
> > general feature (with which the job could be done) was cleaner and
> > simpler than a specific feature which could do only that one job.
>
> That's a reasonable request, and indeed there are situations where we can
> lookup a variable but we cannot call a function which could potentially run
> arbitrary code.
> Maybe that's enough to keep the feature.
>
> > Since it isn't very useful, we can take it out if we cannot fix it.
> > But first let's try to fix it.
>
> But the above request does not mean we need to be able to mix&match
> let-bindings, buffer-local, and frame-local variables.  If we disallowed the
> buffer-local&frame-local variables, the problem would disappear.  This part
> of the language is already complex enough as it stands.
>
>
>         Stefan
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>