Re: AW: Same coloring as GNU Emacs not possible due to fewer face types

FUT xemacs-design. Moved from xemacs-beta. Jeff> But I can imagine lots of other things - like when you do Jeff> sed -e "blah" at a shell prompt that "blah" is in Jeff> sed-script-mode Modes are something else again. I've long had it in mind that modes should attach to extents, not to buffers. But I don't know how easy that would be to do. Jeff> You're losing me here. How would buffer locales, or even Jeff> mode locales simplify the rats nest proliferation of faces? Because apps should just take the default. (This was not clear, mostly because I'm making this up as I go along. :) What I meant was that Gnus and VM would both use the generic "message-header-mail-from" face. If a _user_ wanted to customize Gnus and VM to have different appearance of that face, then Custom would attach Gnus customizations to the face in Gnus's *Article* buffers. Jeff> Mapping a logical face 'warning' to 'red' is fine, and even Jeff> logical, but having physical faces like 'sans Jeff> serif-blue-on-black' seems to be going down the same path Jeff> that lead to the proliferation of faces in the first place. Not really. If applications use purely logical faces (ie, they carry no specs except parent) and we make the parent a specifier (this is an extension to the current implementation, parent is currently just a face), then when the user wants to use "something like the gnus-rogue-custom-warning-color-bonanza face" they can instance the parent (look it up in the specifier), and inherit from that physical face elsewhere without worrying that (a) larsi's whim or (b) their own Gnus customizations will change the second logical face. Ie, physical faces would be created once, and they would be set up to have some sort of commonality across devices. Then they shouldn't be changed or customized. Logical faces would be the object for application tweaks and user customizations. Jeff> Maybe I don't understand specifiers A specifier is a dictionary for values, where the keys are display contexts: windows, buffers, frames, devices, global. I'd like to extend to modes (collections of buffers) and maybe extents (a subobject of a buffer). Where multiple specifications apply, they are given precedence according to the order above. A specifier tag is a way for an application to identify specifications it has placed on the specifier. It has internal uses as well, but here it just means that Gnus can add and remove specs without worrying about trashing some other app's, or the user's, specs. Specifiers are optimized for handling display parameters. Jeff> But, I'm assuming that you really mean a multiple Jeff> inheritance scheme where a logical face can inherit Jeff> attributes from multiple other logical and physical faces eg Jeff> (define-face socket (sans-serif blue on-black)) No, it's not multiple inheritance in that sense. More like this (define-face socket ((display-is-x-p sans-serif-blue-on-black) (buffer-is-*Article*-p sans-serif-blue-on-default))) where logical face instantiation is implemented like (catch 'found (let ((specs (face-spec-list face)) spec) (while specs (let* ((spec (pop specs)) (test (car spec)) (phys-face (cadr spec))) (when (funcall test (window-to-redisplay)) (throw 'found phys-face))))) fallback-physical-face) The multiple inheritance you're talking about is already more or less implemented as "face merging". Basically, faces are merged across extents. So using [] to mark extents, an MUA might do something like 12 3 4 [[From:][ Stephen Turnbull [<stephen(a)xemacs.org&gt;]]] where extent 1 would specify from-header-face, extent 2 would specify header-tag-face, extent 3 would specify header-value-face, and extent 4 would specify address-spec-face. Then the MUA would use some sort of orthogonal convention, like the inherits from physical face 'blue), header tags are bold roman (physical face 'bold), header values are normal weight roman (physical face 'default), and address-specs are normal weight italic (physical face 'italic)---this overrides the header value face, because the extent is more specific. Note that you need at least extents 2, 3, and 4, anyway, and quite likely your header parser has identified the endpoints of extent 1, so it's easy to add that extent and a face for it. Jeff> What can't gnu emacs do? set-face-parent or the specifier Jeff> tags? Specifiers. You can't do them in Lisp, because in general you do not want to call Lisp from redisplay (and besides, it has to be very fast). AFAIK that goes for GNU as much as it goes for XEmacs. So they'd have to (re)implement specifiers, as that's all Ben Wing/Sun code. Ben has indicated willingness to sign papers, but Sun never has. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.