home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Source Code 1993 July / THE_SOURCE_CODE_CD_ROM.iso / gnu / lucid / bug-lucid-emacs / text0256.txt < prev    next >
Encoding:
Text File  |  1993-07-04  |  2.4 KB  |  48 lines
  1. I suppose it would be reasonable for emacs to store the bold/italic/etc face
  2. values of the first screen into the "global" face list to provide a reasonable
  3. dfault for them.
  4.  
  5. I guess I think that screen-specific face attributes are a fairly dubious
  6. feature, and since I don't use them, I'm not sure whether the implications of
  7. this change would matter.
  8.  
  9. Basically, if you had things set up so that the FOO screen used a 10pt font,
  10. and the BAR screen used a 14pt font, and all other screens used a 12pt font by
  11. default, then the `bold' faces on those various screens would use different
  12. fonts (and the "global" bold face wouldn't have a font specified at all, since
  13. `bold' is one of the faces computed by the `create-screen-hook' (well, really
  14. by `x-initialize-other-random-faces')).
  15.  
  16. So, since the font-lock-keyword-face is created by copying the bold face, and
  17. is not re-copied on a per-screen basis via the `create-screen-hook', it would
  18. end up getting the font (and font-size) of whichever screen was created first,
  19. instead of the same font as the bold face on the current screen, and you'd
  20. have mixed 12 and 14pt text on newly-created screens.
  21.  
  22. This is better than the current behavior, which is that font-lock-keyword-face
  23. has no font at all on screens that are created after the
  24. font-lock-keyword-face is initialized.  But...
  25.  
  26. If code on the create-screen-hook were to re-copy the screen-specific version
  27. of the font-lock-keyword-face from bold each time a screen were created, then
  28. everything would always work as expected, even wrt the font sizes.  But that's
  29. a lot of work, that I don't think should be imposed on everyone who wants to
  30. make a new face which is "a copy of bold."
  31.  
  32. I think the root of the problem here might be that we're using the X font
  33. specifications (which suck) instead of attaching more symbolic attributes to
  34. faces, like "this face is bold" instead of "this face is this exact font,
  35. which we think is a bold version of the default font in the default size which
  36. we've computed via a whole slew of dubious heuristics."
  37.  
  38. But the same problem would rear its head again if you had some face that you
  39. wanted to be green in some screens and blue in others, and had a second face
  40. that you wanted to be a "copy" of that.  What does it mean for it to be a
  41. copy?  Should it always have the same attributes as the first face, even on
  42. newly created screens where that first face has some totally new value?
  43.  
  44. What a mess.
  45.  
  46.     -- Jamie
  47.  
  48.