doc/Why_R_mode_not_S_mode.txt

   1
   2 O.k., here are now some general remarks.  Tony asked
   3
   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?
   7
   8 Let me try to answer that.
   9
  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.
  17
  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.
  23
  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).
  35
  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
  38 convenient otherwise.
  39
  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?
  43
  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.
  47
  48 (And of course, we know that there are major differences in the I/O
  49 system, for example.)
  50
  51 Please let me know what you both think about this.
  52
  53 -k
  54
  55 PS.  From the length of this message it should already be clear that I
  56 am willing to put some time into this :-)