|
From: | Henri Lesourd |
Subject: | Re: [Texmacs-dev] Scheme to Prolog |
Date: | Wed, 14 Feb 2007 16:02:35 +0100 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 |
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 ?
[Prev in Thread] | Current Thread | [Next in Thread] |