2
O.k., here are now some general remarks. Tony asked
4
Also, why are you interested in writing an R-mode, rather than
5
modifying the S-mode? I'm curious as to what features you feel are
6
needed? or is it simply a matter of avoiding code bloat?
8
Let me try to answer that.
10
* Apparently, S-mode currently is not maintained. This is a real
11
problem. I don't know if Richard Stallman (hereafter, RMS) is currently
12
aware of how well R is progressing. I am sure he would eventually love
13
to include it into the `GNU' distribution, and I am also sure that he
14
will like to include support for it in GNU Emacs. This means that code
15
will have to be cleaned (and copyrights transferred etc). No
16
maintainer, and code which is not `clean' ... no inclusion.
18
* Another crucial problem is terminology. If the documentation keeps
19
talking about sending to an S process etc, and it is in fact an R
20
process ... I am not sure how users feel about that. I am also not
21
sure how much Ross & Robert want R to be treated as markedly different
22
from S, or what the authors of S-mode think of that.
24
* I've encountered a similar situation with MATLAB and Octave. An Emacs
25
MATLAB mode had been around for quite a while. Eventually, John Eaton
26
(the author of Octave) modified this to work under Octave, too (which is
27
harder because there are syntactic differences as well). This did not
28
work satisfactorily. Two more hacked-up MATLAB mode versions appeared
29
(one by me). So, John wrote a new Octave mode based on F77 mode. Of
30
course, this was not the optimal thing either. Eventually I ended up
31
writing octave-mode (plus I/O stuff etc) from scratch. This code will
32
now be included in the next version (19.35) of GNU Emacs, and from what
33
I heard also runs without problems under XEmacs (which I cannot confirm
34
because I use GNU Emacs).
36
In a way, the situation Octave/MATLAB is very similar to R/S. It might
37
have been possible to have a joint mode, but it turned out to be more
40
* Another thing is, what happens if we start putting even more effort
41
into improving R support in S-mode. Will this eventually be merged into
42
the `proper' S-mode distribution?
44
* Thus, the question is whether it is both possible and feasible to have
45
a package which FULLY works under R and S AND solves the obvious
46
documentation problems.
48
(And of course, we know that there are major differences in the I/O
51
Please let me know what you both think about this.
55
PS. From the length of this message it should already be clear that I
56
am willing to put some time into this :-)
added
removed
doc/Why_R_mode_not_S_mode.txt
