Simplify redisplay-x/separate_textual_runs

Stephen J. Turnbull stephen at xemacs.org
Mon Apr 2 00:30:03 EDT 2007


Aidan Kehoe writes:

 >  > 6.  Reorganize separate_textual_runs_mule and add comments to explain
 >  >     what's going on.
 > 
 > Where you’ve rewritten comments, your rewrites are more opaque to me than
 > what was there before. But then I wrote what was there before (still long
 > enough ago to need to understand it though), so maybe that’s not surprising.

I did rewrite the comment about using int, not UExtbyte, for byte1 and
byte2.  Someone who knows Mule well would guess UExtbyte, I agree, but
my purpose for the comment is to explain why those *must* be ints,
even though C would normally coerce other, more intuitive, integral
types to whatever is needed.  This minimal approach is purely a matter
of style; if you still dislike it I'll correct the misspelling of
UExtbyte and otherwise leave it alone.

I thought the comment "The graphic property is only relevant if we're
neither doing the CCL conversion nor doing the UTF-16 conversion" was
misplaced.  Some people will incorporate that comment by forming a
mental model where the flags are mutually exclusive, and thus
understand why the cases in computation of byte1 and byte2 come in
that order, but others will not.  So I chose to move it and make it
more explicit in the comment about "sloppy" flag handling.  Mostly a
matter of style.

I will change the comment about "sloppy" to

/* These flags are almost mutually exclusive, but we're sloppy about
   resetting "shadowed" flags.  So the flags must be checked in the
   proper order in computing byte1 and byte2, below. */

My substitution for "The graphic property is only relevant ..." is
cryptic, I agree.  I will make it more precise:

/* The charset must have an ISO 2022-compatible font index.
   There are two "registers" (what ISO fonts use for font index).
   GL (graphic == 0) has the high bit of each octet reset,
   GR (graphic == 1) has it set. */

I will also incorporate your explanation about what happens if
ccl_setup_program fails.  How about

/* Check for CCL charset.
   If setup_ccl_program fails, we'll get a garbaged display.
   This should not ever happen, but if it does it would be harmless,
   unless the X server has buggy handling of characters not defined in
   the font, and may be marginally more useful to users and debuggers
   than replacing everything with some fixed replacement character. */

Thanks for the review!




More information about the XEmacs-Patches mailing list