> I meant that a facility should be added to `window-text-pixel-size' so
 > that callers like `string-pixel-width' can ask for having no (X) limit
 > without specifying a large number themselves.  Basically I want to use:
 >
 >    (window-text-pixel-size window (point-min) (point) t)
 >                                                      ^^^
 >     (or some other value that `window-text-pixel-size'
 >     should understand as meaning "no limit" for X-LIMIT)
 >
 > instead of:
 >
 >    (window-text-pixel-size window (point-min) (point) 123456789)
 >
 > The default behavior of the function should stay the same.

OK.

 >> Any clients of 'window-text-pixel-size' like 'string-pixel-width' can
 >> easily set X-LIMIT to some sufficiently large value without affecting
 >> the basic functionality of 'window-text-pixel-size'.
 >
 > Yes, that's the simplest solution, but I find passing a random magic number
 > instead of providing a simple interface to say "I don't want to use a limit"
 > (like Y-LIMIT already allows, as I previously mentioned) rather inelegant :)

Agreed (also because 'most-positive-fixnum' and anything beyond INT_MAX
as argument don't work at the moment which is confusing).

 > Minus one glaring issue:
 > `string-pixel-width' is using `buffer-size' as the X-LIMIT, but
 > that function returns the amount of characters in the buffer.
 > This means that instead of returning the pixel width, it merely
 > returns the amount of characters in a string.  If I change that,
 > everything else seems to be in good order.

Yes.  This wasn't a very bright idea.  The function will now be

(defun string-pixel-width (string)
   "Return the width of STRING in pixels."
   (with-temp-buffer
     (insert string)
     (car (buffer-text-pixel-size nil nil t))))

as you suggested.  The xdisp.c change is attached.  Apply the
'string-pixel-width' change manually.

Thanks, martin