[climacs-devel] two buffer/mark proposals

[Robert Strandh]

Hello, 

Aleksandar Bakic writes:
 > > You can do item number one over the weekend if you like. 
 > 
 > I am working on it. I noticed the following so far:
 > 
 > 1. buffer-column/line-number seems like a part of the buffer protocol, but is
 > not documented.
 > 
 > 2. possibly-expand-abbrev takes a mark and then expect that there is a method
 > abbrev-expander for the buffer of the mark. It works thaks to the abbrev-mixin
 > being inherited from by climacs-buffer.
 > 
 > I wrote a delegating-buffer class, which inherits from the buffer class, and
 > changed climacs-buffer to inherit from it instead of the standard-buffer class.
 > I also wrote extended-standard-buffer class that inherits from standard-buffer
 > and abbrev-mixin, and put an instance of it into the default initargs of
 > climacs-buffer. This way, I can pass a different buffer implementation when
 > instantiating climacs-buffer. I also had to make sure that all marks created in
 > pane.lisp are getting an appropriate buffer implementation as their :buffer
 > argument (using clone-mark and low/high-mark, because mark implementations know
 > about the corresponding buffer implementations).
 > 
 > I am learning about other pieces of climacs while doing this, so even if you
 > think this is not a good approach, time is not wasted. However, perhaps it
 > would be better to break the functionality into something like:
 > 
 > 1. buffer protocol (buffer and mark implementations)
 > 2. extended buffers (like the abbrev solution, unless it should be changed)
 > 3. climacs-buffer with its gui-level stuff that can work with different
 > implementations
 > 
 > Currently, all the above is mixed together in climacs-buffer, so there may be
 > application-specific code that has access to all the three layers above. I am
 > debugging an undo-related problem right now. If I manage to fix it and similar
 > issues (the problem is, I have to try all the functionality manually as there
 > are no tests), I would check my changes in. I'll wait for some feedback first.

Your guesses are as good as mine.  It often helps to implement
something  in order to see whether the architecture is supporting the
implementation.  If it doesn't work out, we'll change it again.  

-- 
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.
---------------------------------------------------------------------