Re: [Texmacs-dev] Scheme to Prolog

[Henri Lesourd]

Joris van der Hoeven wrote:

> On Wed, Feb 14, 2007 at 03:32:25PM +0100, Henri Lesourd wrote:
>  
>
> > > 1) I don't think that functions like buffer-tree are "redudant":
> > > this is the *clean* way to get the current buffer tree.
> > >
> > >      
> > Providing a clean API wich only provides means for getting
> > the *current* buffer tree is good, and perhaps it is clean, but
> > unfortunately it is also *incomplete* : very naturally, one is
> > also lead to think about getting info about the other buffers.
> >    
>
> Sure, this has also be foreseen, although the mechanism still
> has to be made more robust. The idea would be to have a construct
>
>         (with-buffer buf
>           ...)
>
> which temporarily changes the working buffer. However, the buffer
> type is not yet exported to the glue, so only a weaker replacement
> for this construct is available right now.
>
> For your memory: in the final API, there will be a few global
> variables which we do not want to pass as parameters to all routines.
> These are (I might forget a few):
>
>         * The current window
>         * The current buffer
>         * The current drd
>         * The current cursor
>         * The current selection
>
> Each of these important parameters can locally be changed
> using a corresponding with- construct.
>
>  
What you are proposing is useful, but it is in no way an answer
to the question raised in the first place : where are the functions
that can be used to get info about the _set_ of currently opened
buffers, in your proposal above ?

Currently, the only thing I can think of for implementing such
a function is a hack around (get-buffer-menu). The clean way
to do this would be something like :
<<
(buffer-trees) -> LIST of BUFFER-DESCR
>>

where BUFFER-DESCR is an object containing (at least)
the following slots :
{
-> the url of the corresponding file (if any) ;
-> the current buffer tree ;
}

Such a thing is absolutely not difficult to implement, and
it is a very naturally expected part of the buffers API, because
once it is possible to get info about the *current* buffer, of
course thinking about the more general way of dealing with
*all* the buffers is the very next step.

Too often, such very next steps from a particular case to
the more general case are forgotten in our APIs, and thus
in effect, it leads to the necessity of implementing  crappier
ways to deal with such more general cases. But from where
stems the problem in the first place ?