Re: Comments on display.texi

[Kim F. Storm]

Richard Stallman <address@hidden> writes:

>     The code uses the integer value (the bitmap number), so I didn't see
>     any reason to use a symbol here.
>
> The reason is, it is more Lisp-like to use symbols than numbers.
> It is easier to debug a program when you see a symbol whose name
> is meaningful than when you see a number.

But when you start debugging this, you don't see the symbol name --
you will see the number.  The display property contains the number,
not the symbol.  

.. Similar to how display image properties work.

>
>     It is the same for e.g. images -- you specify the image, not a symbol
>     identifying an image.
>
> Sorry, I don't understand.  When you say "you specify the image",
> what data type is that?

An image is a list like this:
   (image :type xpm :file "splash.xpm")

To insert an image, a text property like this is used:

   (propertize "*" 'display '(image :type xpm :file "splash.xpm"))


If you define the image like this:

   (defimage splash-image ((:type xpm :file "splash.xpm")
                           (:type xbm :file "splash.xbm")))

the result is to set the value of splash-image to

    (image :type xpm :file "/home/kfs/fsf/latest/etc/splash.xpm")

To use the splash-image in a display property, you do:

   (propertize "*" 'display splash-image)

NOT

   (propertize "*" 'display 'splash-image)


So when you debug involving an image, you don't see the symbol either,
only the value.

I followed this pattern for fringe bitmaps...

>
>     > @item Value indicating that no fringe bitmap is present:
>     > @code{no-fringe-bitmap}.
>     > @c ??? I don't understand what that means.
>     > @c ??? Where would you find that value?
>
>     In the car or cdr of the return value from fringe-bitmaps-at-pos if
>     there is no bitmap in left or right fringe.
>
> It should use nil for that.
> nil is the canonical Lisp way to say such a thing.

Ok.

>
>     If you specify an undefined fringe bitmap in a display property,
>     e.g. using fringe bitmap number 100 and only 50 bitmaps are defined.
>     Then the fringe will contain the undef-fringe-bitmap (a question-mark).
>
> It would be better for this function to return the value you specified
> and for display to ignore undefined bitmaps.

Ok.

>
>     > @c ??? Why not return a list of symbols that identify the bitmaps?
>     > @c ??? This is Lisp, not C.
>
>     Internally the bitmaps are represented and managed using integers
>     (indexes), so there are no internal symbols defining bitmaps --- just
>     like there are no internal symbols defining images.
>
>     For simplicity, I chose to expose those integers as "opaque fringe
>     bitmap numbers".  Using symbols would be a lot of extra work for no
>     added functionality!
>
> Just because the internals use integers is no reason to design the
> Lisp-level interface that way.

But it is EXACTLY the same interface that is used for images.
It is just the value that is different.

>
> The change to use symbols would only affect two functions:
> define-fringe-bitmap and fringe-bitmaps-at-pos.  The symbol could
> still have an integer as its value.  define-fringe-bitmap would record
> the names of the symbols in a vector, indexed by the integer, and
> fringe-bitmaps-at-pos would get the symbols out of that vector.
>
> In addition, when the text property contains a symbol instead of the
> now-expected integer, use the symbol's value.

So if you insist on this change, should I change the image code to
do the same -- ?

>
>
>
> Meanwhile, why does the code only support 255 different values?

I don't think any code will need to use more than a few bitmaps, so I
thought a total of 255 would be sufficient.

For 21.4, I think that only gdb-ui use a few bitmaps.

> That arbitrary limit is embarrassing.  What would it cost to get
> rid of that limit?
>

The limit is controlled by FRINGE_ID_BITS (currently 8) defined in
dispextern.h, so it is extremely easy to raise the limit to e.g. 1023
or 2047 bitmaps.

There is a static array of fringe bitmap pointers; it has one pointer
element for each possible bitmap index.  Raising the limit would just
cost a few KB.  

If you want to remove the limitation completely, we could let the
table grow dynamically.

But even faces have a limit of 21^2-1, so emacs is not without
arbitrary limits.

So there must be some limit -- which ?  2^32-1 ?

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