Printing elisp char literals

Printing elisp char literals

[Stefan Monnier]

Let's say I have an integer.  How can I check whether it's a char ?
`char-valid-p' is only part of the answer, because I'd like to know
if the integer is a char-with-modifiers also.  The best I could come
up with right now is:

   (char-valid-p (logand char ?\x3fffff))

Is the mask available somewhere or do I simply have to hardcode it
like that ?

Furthermore, in order to print this integer in a form like ?\C-a,
what should I do ?  The best I could come up with is:

    (let ((s (single-key-description char)))
      (while (string-match "\\`\\(\\\\[MCAHSs]-\\)*\\(\\)[MCAHSs]-." s)
        (setq s (replace-match "\\" t t s 2)))
      (concat "?" s))


-- Stefan

Re: Printing elisp char literals

[David Kastrup]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> Let's say I have an integer.  How can I check whether it's a char ?
> `char-valid-p' is only part of the answer, because I'd like to know
> if the integer is a char-with-modifiers also.  The best I could come
> up with right now is:
> 
>    (char-valid-p (logand char ?\x3fffff))
> 
> Is the mask available somewhere or do I simply have to hardcode it
> like that ?
> 
> Furthermore, in order to print this integer in a form like ?\C-a,
> what should I do ?  The best I could come up with is:
> 
>     (let ((s (single-key-description char)))
>       (while (string-match "\\`\\(\\\\[MCAHSs]-\\)*\\(\\)[MCAHSs]-." s)
>         (setq s (replace-match "\\" t t s 2)))
>       (concat "?" s))

IIRC, XEmacs has sort of an opaque character representation type, so
it might be worth borrowing an idea or two from them in this regard
before reinventing the wheel.  Stephen, any idea of whether something
might apply here?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Printing elisp char literals

[Stephen J. Turnbull]

>>>>> "David" == David Kastrup <David.Kastrup@t-online.de> writes:

    David> "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>
    David> writes:

    >> Let's say I have an integer.  How can I check whether it's a
    >> char ?

Doesn't the optional argument to char-valid-p do the right thing?

And pretty clearly `event-modifiers' extracts the modifiers into a
Lispy format.

    David> IIRC, XEmacs has sort of an opaque character representation
    David> type, so it might be worth borrowing an idea or two from
    David> them in this regard before reinventing the wheel.  Stephen,
    David> any idea of whether something might apply here?

Besides the fact that it looks like these APIs already exist, even for
more complex cases I don't think so.  While I believe the XEmacs model
is a good one, it took several years to shake out many bugs due to
errors in porting code from the old "characters are a subset of
integers" model.

This would best be done in combination with a large revision of basic
Mule functionality, such as in emacs-unicode, if it's considered
desirable.


-- 
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.

Miles' patch still fixes xfaces.c

[Robert J. Chassell]

The recent change to xfaces.c has not fixed the problem that
no one can permanently change
        :weight bold 
to
        :weight normal
in the variable `mode-line-buffer-identification', which is
buffer-local and in other places.

As far as I know, this problem resulted from a change on 19 Nov 2002
in mode-line-buffer-identification

(Several other bugs also appeared at the same time.)

Although the bug does not look too bad with a plain vanilla instance
of Emacs, with an `10x20' font, 
    -Misc-Fixed-Medium-R-Normal--20-200-75-75-C-100-ISO8859-1
the new bold creation technique fills in letters such as `m'
so that they become unreadable rectangles.

The word `Emacs' becomes unreadable.

Fortunately, Miles Bader posted a semi-fix on 18 Dec 2002.  This was a
`semi-fix' because his code sometimes led to a race condition and a
crash in Emacs.  But not very often.

Mile's patch is

    diff -u -r1.266 xfaces.c
    --- src/xfaces.c	17 Nov 2002 23:51:19 -0000	1.266
    +++ src/xfaces.c	18 Dec 2002 05:26:34 -0000

and works with the new version of xfaces.c, version 1.277 
(CVS from 2003 May 26 23:00 UTC)

However, it would be nice to see a clean fix to this problem, which is
to be able to specify any characteristic for `bold', including a
color, and including being able to set the weight of something that is
`bold' to `normal'.

The old messages are: 

    Bold by moving pixels problem
    starting on 20 Nov 2002

    signal handling bogosities
    starting on 19 Dec 2002

The patch is from 

    From: Miles Bader <miles@lsi.nec.co.jp>
    Subject: Re: Bold by moving pixels problem
    Date: 18 Dec 2002 19:01:01 +0900

Thanks!

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Miles' patch still fixes xfaces.c

[Richard Stallman]

    The recent change to xfaces.c has not fixed the problem that
    no one can permanently change
	    :weight bold 
    to
	    :weight normal
    in the variable `mode-line-buffer-identification', which is
    buffer-local and in other places.

I don't remember the issue.  What does it mean to "permanently change"
this?  And why can't you do it?  What happens if you try?

    Fortunately, Miles Bader posted a semi-fix on 18 Dec 2002.  This was a
    `semi-fix' because his code sometimes led to a race condition and a
    crash in Emacs.  But not very often.

    Mile's patch is

	diff -u -r1.266 xfaces.c
	--- src/xfaces.c	17 Nov 2002 23:51:19 -0000	1.266
	+++ src/xfaces.c	18 Dec 2002 05:26:34 -0000

What is the change?  (I gather the change was not installed.)

Can Miles explain what caused the problem?
Maybe we can find a better fix based on that info.

Re: Miles' patch still fixes xfaces.c

[Robert J. Chassell]

   I don't remember the issue.  What does it mean to "permanently change"
   this?  And why can't you do it?  What happens if you try?

By "permanently change", I mean, put a change in my .emacs file that works.

The problem is that on my screen, some fonts display an unreadable
bold face when bold is set in the default manner.  A buffer list and
the mode line put some text in bold, the the problem is very
noticeable.

My solution is to change the `bold' weight to `normal' and to indicate
`bold' by changing the the color of the text.

The problem has been that the method of setting bold has been
hardwired at a low level, so it has been impossible to change the
font in my .emacs file.

In other words, by default `bold' is treated as a hard-wired command
to make the lines on a glyph wider.  It should be treated as the
equivalent of @strong in Texinfo, which indicates an argument that can
be displayed in various ways.

For example, I want to change  mode-line-buffer-identification
in my .emacs file by setting it like this:

    (setq
     mode-line-buffer-identification
     (quote
      (#("%14b" 0 4
         (face
          ;; (:weight bold)
          (:weight normal)
        ...

but that fails.  The buffer name still is unreadable because the lines
that make up the characters continue to be wider than usual.  The
buffer name is not changed to normal weight, unless I apply Miles'
fix.

The same happens with the buffer names in a buffer list.

   Can Miles explain what caused the problem?
   Maybe we can find a better fix based on that info.

I hope so.  He predicted that his fix would cause Emacs to crash
occasionally, and he was right, although crashes are rare.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Miles' patch still fixes xfaces.c

[Richard Stallman]

	(setq
	 mode-line-buffer-identification
	 (quote
	  (#("%14b" 0 4
	     (face
	      ;; (:weight bold)
	      (:weight normal)
	    ...

    but that fails.  The buffer name still is unreadable because the lines
    that make up the characters continue to be wider than usual.  The
    buffer name is not changed to normal weight, unless I apply Miles'
    fix.

Can you show me that fix?  Maybe we can change it not to crash.

Re: Miles' patch still fixes xfaces.c

[Robert J. Chassell]

    Can you show me that fix?  Maybe we can change it not to crash.

Here it is:

------- Start of forwarded message -------
To: bob@rattlesnake.com
System-Type: i686-pc-linux-gnu
From: Miles Bader <miles@lsi.nec.co.jp>
Date: 18 Dec 2002 19:01:01 +0900
In-Reply-To: <buoisxtazqu.fsf@mcspd15.ucom.lsi.nec.co.jp>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
cc: emacs-devel@gnu.org
Subject: Re: Bold by moving pixels problem
Reply-To: Miles Bader <miles@gnu.org>


- --=-=-=

Here's an updated version of my patch, that uses a list of functions:



- --=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
  filename=realize-face-filter-20021218-0.patch
Content-Description: realize-face-filter-20021218-0.patch

2002-12-17  Miles Bader  <miles@gnu.org>

	* xfaces.c (Vrealize_face_filter_functions): New variable.
	(realize_face): If Vrealize_face_filter_functions has a non-nil
	value, use it to filter the face attributes before realization.
	Use new calling conventions for realize_x_face, realize_tty_face,
	and load_face_font.
	(realize_x_face, realize_tty_face): Add new argument FACE, and
	change return type to void.  Use FACE instead of creating our own.
	(load_face_font): Add a new argument ATTRS, and use it instead of
	FACE->lface.
	(syms_of_xfaces): Initialize Vrealize_face_filter_functions.

Index: src/xfaces.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/xfaces.c,v
retrieving revision 1.266
diff -u -r1.266 xfaces.c
- --- src/xfaces.c	17 Nov 2002 23:51:19 -0000	1.266
+++ src/xfaces.c	18 Dec 2002 05:26:34 -0000
@@ -422,6 +422,13 @@
 
 Lisp_Object Vtty_defined_color_alist;
 
+/* A list of functions to perturb faces before final realization.
+   They are passed a lisp-vector containing all the attributes of the
+   fully-specified face, and can change any that they wish. */
+
+Lisp_Object Vrealize_face_filter_functions;
+
+
 /* Counter for calls to clear_face_cache.  If this counter reaches
    CLEAR_FONT_TABLE_COUNT, and a frame has more than
    CLEAR_FONT_TABLE_NFONTS load, unused fonts are freed.  */
@@ -481,7 +488,7 @@
 static unsigned char *xstrlwr P_ ((unsigned char *));
 static void signal_error P_ ((char *, Lisp_Object));
 static struct frame *frame_or_selected_frame P_ ((Lisp_Object, int));
- -static void load_face_font P_ ((struct frame *, struct face *, int));
+static void load_face_font P_ ((struct frame *, struct face *, Lisp_Object *, int));
 static void load_face_colors P_ ((struct frame *, struct face *, Lisp_Object *));
 static void free_face_colors P_ ((struct frame *, struct face *));
 static int face_color_gray_p P_ ((struct frame *, char *));
@@ -502,10 +509,10 @@
 static int cmp_font_names P_ ((const void *, const void *));
 static struct face *realize_face P_ ((struct face_cache *, Lisp_Object *, int,
 				      struct face *, int));
- -static struct face *realize_x_face P_ ((struct face_cache *,
- -					Lisp_Object *, int, struct face *));
- -static struct face *realize_tty_face P_ ((struct face_cache *,
- -					  Lisp_Object *, int));
+static void realize_x_face P_ ((struct face *, struct face_cache *,
+				Lisp_Object *, int, struct face *));
+static void realize_tty_face P_ ((struct face *, struct face_cache *,
+				  Lisp_Object *, int));
 static int realize_basic_faces P_ ((struct frame *));
 static int realize_default_face P_ ((struct frame *));
 static void realize_named_face P_ ((struct frame *, Lisp_Object, int));
@@ -1245,14 +1252,15 @@
 
 #ifdef HAVE_WINDOW_SYSTEM
 
- -/* Load font of face FACE which is used on frame F to display
- -   character C.  The name of the font to load is determined by lface
- -   and fontset of FACE.  */
+/* Load font of face FACE with attributes ATTRS which is used on frame F to
+   display character C.  The name of the font to load is determined by
+   lface and fontset of FACE.  */
 
 static void
- -load_face_font (f, face, c)
+load_face_font (f, face, attrs, c)
      struct frame *f;
      struct face *face;
+     Lisp_Object *attrs;
      int c;
 {
   struct font_info *font_info = NULL;
@@ -1262,7 +1270,7 @@
   face->font_info_id = -1;
   face->font = NULL;
 
- -  font_name = choose_face_font (f, face->lface, face->fontset, c,
+  font_name = choose_face_font (f, attrs, face->fontset, c,
 				&needs_overstrike);
   if (!font_name)
     return;
@@ -6678,6 +6686,11 @@
      int former_face_id;
 {
   struct face *face;
+  /* The set of attributes this face is know by to the user, as opposed to
+     the set actually used to render the face.  They're usually the same
+     as, but may be different if some attribute is changed by
+     realize-face-filter.  */
+  Lisp_Object *orig_attrs = attrs;
 
   /* LFACE must be fully specified.  */
   xassert (cache != NULL);
@@ -6691,41 +6704,70 @@
       free_realized_face (cache->f, former_face);
     }
 
+  if (CONSP (Vrealize_face_filter_functions))
+    {
+      /* Call these user-defined functions to perturb the face attributes
+	 before realization.  */
+      Lisp_Object filters, cycle_check;
+      Lisp_Object lface = Fmake_vector (make_number (LFACE_VECTOR_SIZE),
+					Qunspecified);
+
+      bcopy (attrs, XVECTOR (lface)->contents,
+	     LFACE_VECTOR_SIZE * (sizeof *attrs));
+
+      cycle_check = Qnil;
+      for (filters = Vrealize_face_filter_functions;
+	   CONSP (filters);
+	   filters = XCDR (filters))
+	{
+	  safe_call1 (XCAR (filters), lface);
+	  cycle_check = CYCLE_CHECK (cycle_check, filters, 50);
+	  if (NILP (cycle_check))
+	    break;		/* cycle detected */
+	}
+
+      attrs = XVECTOR (lface)->contents;
+    }      
+
+  /* Allocate a new realized face.  */
+  face = make_realized_face (orig_attrs);
+
+  /* Fill it in.  */
   if (FRAME_WINDOW_P (cache->f))
- -    face = realize_x_face (cache, attrs, c, base_face);
+    realize_x_face (face, cache, attrs, c, base_face);
   else if (FRAME_TERMCAP_P (cache->f) || FRAME_MSDOS_P (cache->f))
- -    face = realize_tty_face (cache, attrs, c);
+    realize_tty_face (face, cache, attrs, c);
   else
     abort ();
 
   /* Insert the new face.  */
- -  cache_face (cache, face, lface_hash (attrs));
+  cache_face (cache, face, lface_hash (orig_attrs));
 #ifdef HAVE_WINDOW_SYSTEM
   if (FRAME_WINDOW_P (cache->f) && face->font == NULL)
- -    load_face_font (cache->f, face, c);
+    load_face_font (cache->f, face, attrs, c);
 #endif  /* HAVE_WINDOW_SYSTEM */
   return face;
 }
 
 
- -/* Realize the fully-specified face with attributes ATTRS in face
- -   cache CACHE for character C.  Do it for X frame CACHE->f.  If C is
- -   a multibyte character, BASE_FACE is a face that has the same
- -   attributes.  Otherwise, BASE_FACE is ignored.  If the new face
- -   doesn't share font with the default face, a fontname is allocated
- -   from the heap and set in `font_name' of the new face, but it is not
- -   yet loaded here.  Value is a pointer to the newly created realized
- -   face.  */
+/* Realize into FACE the fully-specified face with attributes ATTRS in face
+   cache CACHE for character C.  Do it for X frame CACHE->f.  If C is a
+   multibyte character, BASE_FACE is a face that has the same attributes.
+   Otherwise, BASE_FACE is ignored.  If the new face doesn't share font
+   with the default face, a fontname is allocated from the heap and set in
+   `font_name' of the new face, but it is not yet loaded here.  Value is a
+   pointer to the newly created realized face.  */
 
- -static struct face *
- -realize_x_face (cache, attrs, c, base_face)
+static void
+realize_x_face (face, cache, attrs, c, base_face)
+     struct face *face;
      struct face_cache *cache;
      Lisp_Object *attrs;
      int c;
      struct face *base_face;
 {
 #ifdef HAVE_WINDOW_SYSTEM
- -  struct face *face, *default_face;
+  struct face *default_face;
   struct frame *f;
   Lisp_Object stipple, overline, strike_through, box;
 
@@ -6733,9 +6775,6 @@
   xassert (SINGLE_BYTE_CHAR_P (c)
 	   || base_face);
 
- -  /* Allocate a new realized face.  */
- -  face = make_realized_face (attrs);
- -
   f = cache->f;
 
   /* If C is a multibyte character, we share all face attirbutes with
@@ -6751,7 +6790,7 @@
 
       /* to force realize_face to load font */
       face->font = NULL;
- -      return face;
+      return;
     }
 
   /* Now we are realizing a face for ASCII (and unibyte) characters.  */
@@ -6921,7 +6960,6 @@
     face->stipple = load_pixmap (f, stipple, &face->pixmap_w, &face->pixmap_h);
 
   xassert (FACE_SUITABLE_FOR_CHAR_P (face, c));
- -  return face;
 #endif /* HAVE_WINDOW_SYSTEM */
 }
 
@@ -7012,17 +7050,16 @@
 }
 
 
- -/* Realize the fully-specified face with attributes ATTRS in face
- -   cache CACHE for character C.  Do it for TTY frame CACHE->f.  Value is a
- -   pointer to the newly created realized face.  */
+/* Realize into FACE the fully-specified face with attributes ATTRS in face
+   cache CACHE for character C.  Do it for TTY frame CACHE->f.  */
 
- -static struct face *
- -realize_tty_face (cache, attrs, c)
+static void
+realize_tty_face (face, cache, attrs, c)
+     struct face *face;
      struct face_cache *cache;
      Lisp_Object *attrs;
      int c;
 {
- -  struct face *face;
   int weight, slant;
   int face_colors_defaulted = 0;
   struct frame *f = cache->f;
@@ -7030,8 +7067,6 @@
   /* Frame must be a termcap frame.  */
   xassert (FRAME_TERMCAP_P (cache->f) || FRAME_MSDOS_P (cache->f));
 
- -  /* Allocate a new realized face.  */
- -  face = make_realized_face (attrs);
   face->font_name = FRAME_MSDOS_P (cache->f) ? "ms-dos" : "tty";
 
   /* Map face attributes to TTY appearances.  We map slant to
@@ -7068,8 +7103,6 @@
       && face->background == FACE_TTY_DEFAULT_FG_COLOR
       && face->foreground == FACE_TTY_DEFAULT_BG_COLOR)
     face->tty_bold_p = 0;
- -
- -  return face;
 }
 
 
@@ -7670,6 +7703,14 @@
 Each element is a regular expression that matches names of fonts to
 ignore.  */);
   Vface_ignored_fonts = Qnil;
+
+  DEFVAR_LISP ("realize-face-filter-functions",
+	       &Vrealize_face_filter_functions,
+	       doc:/* A list of functions to perturb faces before final realization.
+They are passed a lisp-vector containing all the attributes of the
+fully-specified face, and can change any that they wish. */);
+  Vrealize_face_filter_functions = Qnil;
+
 
 #ifdef HAVE_WINDOW_SYSTEM
   defsubr (&Sbitmap_spec_p);

- --=-=-=



Also, here's a lisp file that implements some filters:



- --=-=-=
Content-Type: application/emacs-lisp
Content-Disposition: attachment; filename=relfilt.el
Content-Description: Some filters for face-realization

(defun lface-emulate-bold-with-color (lface)
  (if (memq (aref lface 4)
	    '(bold heavy extra-bold semi-bold ultra-bold))
      (let ((fg-vals (color-values (aref lface 8))))
	;; unboldify
	(aset lface 4 'normal)
	;; Tweak the fg color to indicate bold.
	(cond ((equal fg-vals '(65535 65535 65535))
	       (aset lface 8 "khaki"))
	      ((equal fg-vals '(0 0 0))
	       (aset lface 8 "orange4"))
	      (t
	       ;; intensify the color
	       (aset lface 8 (highlight-color (aref lface 8) 2 5000)))))))

(defun lface-replace-italic-with-underline (lface)
  (if (not (eq (aref lface 5) 'normal))
      (progn
	;; remove italics
	(aset lface 5 'normal)
	;; underline (we preserve an existing value, in case it's colored)
	(if (null (aref lface 6))
	    (aset lface 6 t)))))

(push 'lface-emulate-bold-with-color realize-face-filter-functions)
(push 'lface-replace-italic-with-underline realize-face-filter-functions)
(clear-face-cache)

;;; highlight-color function
(defconst highlight-color-dark-boost-limit 48000)
(defun highlight-color (color factor &optional delta)
 "Return a color which is lighter or darker than COLOR by FACTOR and DELTA."
 (let* ((old-rgb (if (stringp color) (color-values color) color))
	(red (car old-rgb))
	(green (cadr old-rgb))
	(blue (nth 2 old-rgb))
	(bright (/ (+ (* red 2) (* green 3) blue) 6)))
   (setq red (min 65535 (* red factor)))
   (setq green (min 65535 (* green factor)))
   (setq blue (min 65535 (* blue factor)))
   (when (and (< bright highlight-color-dark-boost-limit) delta)
     ;; Make an additive adjustment to NEW, because it's dark enough so
     ;; that scaling by FACTOR alone isn't enough.
     (let* ((dimness
	     ;; How far below the limit this color is (0 - 1, 1 being darker).
	     (- 1 (/ (float bright) highlight-color-dark-boost-limit)))
	    (min-delta
	     ;; The additive adjustment.
	     (* delta dimness factor 0.5)))
       (cond ((< factor 1)
	      (setq red (max 0 (- red min-delta)))
	      (setq green (max 0 (- green min-delta)))
	      (setq blue (max 0 (- blue min-delta))))
	     (t
	      (setq red (min 65535 (+ red min-delta)))
	      (setq green (min 65535 (+ green min-delta)))
	      (setq blue (min 65535 (+ blue min-delta)))))))
   (format "#%04X%04X%04X" red green blue)))

- --=-=-=



- -Miles
- -- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

- --=-=-=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

- --=-=-=--
------- End of forwarded message -------