From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Comments on display.texi Date: Sun, 26 Sep 2004 14:20:16 -0400 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: Reply-To: rms@gnu.org NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1096222883 16420 80.91.229.6 (26 Sep 2004 18:21:23 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 26 Sep 2004 18:21:23 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 26 20:21:16 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CBde8-0006NN-00 for ; Sun, 26 Sep 2004 20:21:16 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CBdkK-0002qL-KD for ged-emacs-devel@m.gmane.org; Sun, 26 Sep 2004 14:27:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CBdjr-0002af-Ad for emacs-devel@gnu.org; Sun, 26 Sep 2004 14:27:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CBdjp-0002Zq-Kt for emacs-devel@gnu.org; Sun, 26 Sep 2004 14:27:09 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CBdjp-0002ZU-2w for emacs-devel@gnu.org; Sun, 26 Sep 2004 14:27:09 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CBddB-0007yg-Aw for emacs-devel@gnu.org; Sun, 26 Sep 2004 14:20:17 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1CBddA-0006qR-Vp; Sun, 26 Sep 2004 14:20:17 -0400 Original-To: storm@cua.dk (Kim F. Storm) In-reply-to: (storm@cua.dk) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:27583 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27583 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. 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? > @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. 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. > @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. 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. Meanwhile, why does the code only support 255 different values? That arbitrary limit is embarrassing. What would it cost to get rid of that limit?