[climacs-devel] Marks, Buffers and Panes

[Aleksandar Bakic]

Hi,

I sent a reply yesterday, but it did not seem to pass through.

Since (1) you want to pass a mark instead of climacs-buffer, and (2) the
implementation buffer (accessible via the mark) knows nothing about the syntax,
we have a problem of the kind I found sometime in February, when I proposed
adding layers of abstractions instead of lumping together all kinds of
functionalities in the same buffer class. I agree with you that the
implementation buffer ideally should not know about one that has the syntax
slot. Now, if you still do not want to pass buffers to your functions, perhaps
you can pass them a different kind of mark, say delegation-mark (or
climacs-mark, with even more information), which has information both about the
climacs-buffer and the regular mark. This is also an opportunity to classify
the functions based on the functionality and information they need. Just a
hint, perhaps you will come up with something simpler and cleaner.

Alex

--- John Q Splittist <splittist at yahoo.com> wrote:

> I am rewriting some of the commands to be available more generally as
> functions, for the building up of further functions and commands. My
> idea was that, instead of taking the GNU Emacs approach of having every
> function operating on the current buffer, only to wrap it later in
> something that dynamically changes what the 'current buffer' is,
> functions should be passed a mark, and operate on the relevant buffer
> etc from information gained from the mark.
> 
> In general this works very well - com-foo calls foo with (point
> (current-window)), com-bar (numarg) calls bar with point and count, and
> so on. Where it doesn't work is if foo or bar need to know what the
> current syntax for a buffer is, because, for example, they call
> end-of-definition, which specializes on syntax. The problem is that from
> a supplied mark, the function foo can only access the implementation
> buffer, not the enclosing delegating buffer, which is where the syntax is.
> 
> One answer would be to put a slot on delagatee buffers which points back
> at their delegates. While convenient, I fear this breaks some part of
> the abstraction. So I ask for comments.
> 
> JQS
> _______________________________________________
> climacs-devel mailing list
> climacs-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/climacs-devel
> 



		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs