[Texmacs-dev] Re: I am stuck

[Joris van der Hoeven]

> I want to make a scheme function that takes a buffer and a text as an 
> argument. When applied it should enter the text given as argument
> at the prompt in the buffer (we can assume there is already a session 
> opened) and then send it.

As I said before, the current scheme interface is not yet very clean.
I can give you a few hints, but it is likely that you will have to make
several modifications when the interface gets more robust.

First of all, one has to distinguish between

  * Windows: a window on your screen, which may contain
    several views in the future.

  * Views: A particular view of a buffer (buffers may
    have multiple views).

  * Buffer: Something which (usually) corresponds to a file somewhere.

Most functionality of TeXmacs which you are interested in naturally
attaches to one of these classes. For instance:

  * The current cursor position is part of the View.

  * The current tree being edited is part of the Buffer.

Unfortunately, these separations are not yet cleanly reflected
in the scheme interface. For instance, you can not perform
an operation on a particular view; what you can do with
switch-to-buffer is select an arbitrary view of a buffer and
display it in the active window (i.e. the window with pointer focus).

A temporary hack for your question might be to select the buffer
you want, to insert the text using insert-tree or insert-tree-go-to
and then switch back to the original buffer.

But you have no possibility yet to let this apply to another window
than the window with the pointer focus. This is probably what
is missing for you, right?

So what would probably be helpful for you is the implementation of
something to switch to particular windows, particular views and
particular buffers. But this raises the following problems:

  * How do we identify buffers, windows and views in the scheme interface.

  * How can we avoid conflicts? For instance, if we select another view and
    then apply a function relative to the current *window*, this function
    might want to do some operations on the current view attached to it,
    which is *not* the global current view.

    Also, imagine that you pilot your session in another window (w2)
    from a main window (w1), but that the user puts another view
    in w2 then the session that you think is in it.
    You have to foresee this kind of anomalities.

> A typical use is to apply it from a menu.
> If there is more than one session started (I do not have this at the 
> moment), then maybe the function should take an extra session as an 
> argument.

Probably rather a view, because the same session may be used
in several views...

I am sorry that all this is a bit complicated,
but you have to remember that everything has to become
compatible with the multiple-view multiple-session constraints.

Yours, Joris