Re: cannot understand Elisp manual node Glyphs

[storm@cua.dk (Kim F. Storm)]

"Drew Adams" <drew.adams@oracle.com> writes:

>
> It seems to say that the glyphs that I am using, and should be using, have
> "simple glyph codes". It does not say what a glyph "code" is, BTW.
>
> It also says that a simple glyph code specifies both a character and a face.
> The character is the code mod 524288; the face number is the code / 524288.
>

I also find this part highly dubious - mainly by exposing internal
representation details.

> So how do I use that information, to apply a face to my vector of glyphs?
> Maybe that's not the right way to say it. How can I have the glyph vector
> that I use to display ^L appear in a particular face?
>

These functions are handy:

(defun make-glyph-with-face (c face)
  "Return a glyph code representing char C with face FACE."
  (logior c (lsh (face-id face) 19)))

(defun glyph-char (glyph)
  "Return the character of glyph code GLYPH."
  (logand glyph #x7ffff))

(defun glyph-face (glyph)
  "Return the face of glyph code GLYPH, or nil if glyph has no face."
  (let ((face-id (lsh glyph -19)))
    (car (delq nil (mapcar (lambda (face)
			     (and (eq (get face 'face) face-id)
				  face))
			   (face-list))))))

                               
> There seems to be a wide gulf between the kind of info that is available in
> this node (glyph codes, face numbers) and practical use of that information.
> I imagine that I'm not too far from my quest, but I haven't a clue where to
> head.
>
> ... Perhaps we can improve the manual a bit in the process.


I know this is not "the right time", but IMO adding these functions
could significantly improve both code and documentation.

I guess we wouldn't even need to describe what face numbers are
(actually, we don't -- there's no index entry for it).


So my proposal is to add thosed functions, to:

a) simplify the documentation (and code)
b) hide the technical details of glyph faces, and
c) allow us to change the implementation later without breaking code:

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk