[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on display.texi
From: |
Kim F. Storm |
Subject: |
Re: Comments on display.texi |
Date: |
Sun, 26 Sep 2004 22:38:12 +0200 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3.50 (gnu/linux) |
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
- Comments on display.texi, Kim F. Storm, 2004/09/25
- Re: Comments on display.texi, Richard Stallman, 2004/09/26
- Re: Comments on display.texi,
Kim F. Storm <=
- Re: Comments on display.texi, Richard Stallman, 2004/09/27
- Re: Comments on display.texi, Kim F. Storm, 2004/09/28
- Re: Comments on display.texi, Richard Stallman, 2004/09/28
- Re: Comments on display.texi, Kim F. Storm, 2004/09/29
- Re: Comments on display.texi, David Kastrup, 2004/09/29