emacs-devel
[Top][All Lists]
Advanced

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

Re: face-remapping patch


From: David Kastrup
Subject: Re: face-remapping patch
Date: Wed, 28 May 2008 15:33:44 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

Miles Bader <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>>> When a major mode to remaps `default' to `my-mode-default', existing
>>> mechanisms can be used to handle things like user-customization of
>>> `my-mode-default'.
>>
>> This really sounds like a problem space usually addressed with
>> "specifiers" in XEmacs.  Unfortunately, I have never been able to figure
>> them out.
>
> That doesn't make them sound very promising...

As far as I can tell, XEmacs uses them to map pretty much everything
(images, toolbars, possibly also keymaps, faces) to "locales", namely
buffers, windows, displays.  So you can have images that get
instantiated differently depending on the output device.  The
instantiation works with some sort of caching mechanism and is pretty
efficient.

That's my basic handwaving about the functionality as I think I have
been able to understand.  The implementation is, as far as I can tell,
not done using opaque data structures but rather some sort of alist-like
stuff.  This would actually be more like an Emacs-typical approach to
data structures rather than an XEmacs approach.

The problem when I tried figuring them out is that there was not an
Emacs quality approach to either the documentation or the APIs.

A unified approach to "terminal-, buffer-, window-, frame-local"
certainly would have quite a bit of appeal.  Even if XEmacs specifiers
are good for all of that (I am not sure about it, actually), they don't
unify with normal buffer-locality but have a separate mechanims.  They
also don't work transparently like buffer-locality: dealing with
specifier-locality needs to be done manually, and there is not even a
feature-complete API for all operations you would need.

But that does not mean that taking a thorough look at the problem space
presumably covered by XEmacs specifiers would be amiss.

-- 
David Kastrup




reply via email to

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