[Texmacs-dev] Re: working with TeXmacs

[Joris van der Hoeven]

Hi Michael,

> Back from Prague....

Hope you had a good time.

> I have now been working with TeXmacs and R together, to 
> do some statistical analysis. I really liked it! Very nice to work with. 
> It is the first time that I really have a way to print the statistical 
> analysis that I do with R.

I am very happy to hear that.

> 1. How do you insert an input field in an R session? I.e. I have an R 
> session, 
> and I want to send a line to the session, and get the result without messing 
> up what the session already contains. 

There is no easy way to do that yet :^(
You should manually insert a blank paragraph and
enter an "input" tag using "\"

> 2. The window that reports on generating fonts is anoying. It floats above 
> everything, and sticks to the middle of the desktop even when you switch 
> desktop, and it has no handles/minimize buttons. Usually, you would want to 
> switch to read e-mail, or browse the web while the fonts are being generated. 
> I would make it a regular window, that pops to the front of the screen, and 
> that's it.

Yes, we want to improve this, but it turns out to be technically
non-trivial. But this is on the wish-list...

> 3. It seems that TeXmacs autosaves to a file called filename~, every couple 
> of 
> minutes. Usually I would expect the file balled filename~ to be the backup 
> file, i.e. the file before the last save was done. Emacs usually autosaves to 
> a file falled #filename#, and when it save to filename, it backs its current 
> contents to filename~
> That seems reasonable... But I would certainly not use filename~ for 
> autosaves, when I as a user would assume that these contain backups. 
> (autosaves are newer than the file, and backups are older than the file)

Hmm, I forwarded this message to the developers list;
maybe an item for the wish-list...

> 4. When clicking on the scroll bar, above or below the scroller, I would 
> prefer if the screen moved 1/2 window or a whole window up/down. Currently it 
> seems to move by 3 lines. There are only two ways of quickly scrolling 
> through the document:
>  a. grab the scroller, and move it with the mouse
>  b. move the cursor to the left of the text, where it is outside all areas,
>     and then scroll with page up/down. Otherwise the cursor will get "caught"
>     in one of the sessions.

Just click with the right-hand button...

> 5. It is a problem that the text returned from a session is inserted at the 
> current cursor position. One has to get used to not move the cursor in the 
> session while it is still calculating. A better way would be to remember 
> where to insert.

I know, but this is technically more complex.
Nevertheless, we are definitely moving forward to this.

> I haven't yet gone back to work on the R interface. I have currently 2 things 
> in mind: one is to make the interface more robust - currently it can get 
> "stuck" when waiting for output from R.

The interface probably does not get stuck,
unless the scripts incorrectly recognize the end of input/output.
However, you indeed can have the problem that the output appears
on the wrong place when moving around the cursor during computations.

> If one is not worried about what output belongs to what input, then I could 
> make the whole system easier - just send to R whatever the user writes, and 
> send back whatever R writes. The user than has to be carefull not to move 
> while R is still calculating and things like that.

Yes, but if we want to make things robust it is natural that
we know when input/output starts and ends, right?

> Another possibility is to use some features of the fact that we are dealing 
> with a terminal. I can actually know when R is waiting for more input. That 
> would be good if at some point you plan to incorporate a system that would 
> insert text no at the current cursor position, but at the cursor position 
> when the input was sent to R. I could then somehow tell TeXmacs: this is the 
> output that belongs to input no. 3, this is the output that belongs to input 
> no. 4, and so on.

That sounds good. We indeed plan to add support for this as soon as
we can remember the position where the output should appear.

> The first way is simpler, but I think that the 2nd way should be used. 
> Then there is the problem of the dependence on expect. I could drop the 
> dependence on Expect, by re-implementing the parts I need, or include the 
> parts of Expect that are needed with the program.... I'll see.

Yes, that would be great; if we want the interface to be used,
it definitely should be very easy to install. Ideally, the user should
just have both systems on the harddisk and everything works.

Notice that I included part of your interface into the last
release 1.0.0.24. In order to recognize multiple-line input,
you may already change

        (connection-format "r" "verbatim" "generic")

to

        (connection-format "r" "generic" "generic")

Best wishes, Joris