Re: display question: should ^N and \NNN widths be fixed?

[Thien-Thi Nguyen <ttn@giblet.glug.org>]

   From: Richard Stallman <rms@gnu.org>
   Date: Fri, 24 May 2002 15:14:02 -0600 (MDT)

   Currently the functions in indent.c don't handle variable width fonts at all.
   Extending them to do so is an important project.  When that is done, I expect
   it won't be too hard to handle these two cases also.

ok.  here's my proposal for doing this -- i hope everyone picks it apart
and/or lends expertise to fill the gaps so that emacs can have the best
variable-width font support possible:

 - establish iso-type contour
   + make indent.c C column vars float
   + make callers of indent.c C functions cast retval to int
   + make indent.c C getter functions compute and return float
   - make callers of indent.c C functions cast args to float
   - make indent.c C setter functions accept floats
 - selectively expand contour to propagate float usage
   - determine criteria for propagation
   - determine which funcs/vars fit that criteria (maybe all?)
   - do the changes where needed
     - remove casts
     - fix resulting breakage
 - introduce font sensitivity in column computations
   - unify current_column / current_column_1 / string_display_width
   - consult font text-property		<-- potential race condition?
   - (re-)optimize common cases
     - [maybe] extend width-run cache facilities
     - [maybe] do other caching

some of these (sub)tasks can (and probably should) be done concurrently.
that's not noted here explicitly, but should be easy enough to figure
out for anyone who wants to join in.

logistical questions: is it ok to make a branch in cvs?  what should it
be named?  where can we check in this kind of info for future reference?
is it ok to check in the above in etc/TODO?  if no, then where?  (IMHO,
digging through spam-ridden mailing list archives is neither fun nor
effective.)

thi