[climacs-devel] buffer-object vs. element* and such

Robert Strandh strandh at labri.fr
Sun Jan 16 06:25:21 UTC 2005


Hello, 

Aleksandar Bakic writes:
 > Hi,
 > 
 > Some recent changes to buffer.lisp broke my experimental code that uses a
 > non-standard buffer class. Namely, code like this:
 > 
 > (defmethod end-of-line ((mark mark-mixin))
 >   (let* ((offset (offset mark))
 > 	 (buffer (buffer mark))
 > 	 (chain (slot-value buffer 'contents))
 > 	 (size (nb-elements chain)))
 >     (loop until (or (= offset size)
 > 		    (eql (element* chain offset) #\Newline))
 > 	  do (incf offset))
 >     (setf (offset mark) offset)))
 > 
 > The above method is specialized on mark-mixin only, not on standard-buffer.
 > However, since recently it calls nb-elements and element*. I would rather see
 > size and buffer-object instead. 

I think I did that because I needed the additional speed.  And it is a
temporary hack because with a buffer implementation using lines, it
would have an immediate implementation anyway. 

 > There are similar calls in, say,
 > redisplay-with-syntax in syntax.lisp, where one would expect the code not to
 > depend on flexichain. 

No, that's not quite true.  The calls to the flexichain functions in
that case have nothing to do with the buffer, only with the fact that
the cache uses a flexichain to hold lines.  

 > On other places, such as caching for fast redisplay, the
 > dependence on flexichain is explicit and that is fine with me (I need to take a
 > closer look at caching and see how it relates to non-standard buffers).

I think that's the only dependence. 

 > Please let me know if I can make changes wrt. the above arguments or if you
 > have objections.

I am afraid I must object.  end-of-line was a major bottleneck and
needed more speed.  

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------



More information about the climacs-devel mailing list