not sure how long ago i made some of these changes... the sleep

[ess.git] / doc / TODO

        -*- indented-text -*-

$Revision: 4.13 $


 The original TODO list (nothing fixed there yet):
===========================================================

The following things need to be fixed. In a very rough order of priority.

* (DS) M-RET in *S* doesn't work properly with multi-line inputs.

* (DS) Typing C-c C-d in an S-mode buffer can read the wrong file
  (apparently the wrong value of S-directory is used.)

* (DS) Maybe S-eval-region should do S-view-at-bottom, too

* (DS) It would be nice to interpret a nil value of S-directory as the
  default directory.

* (DS) Add a predicate to control when S-object-list is dumped. It would
  be nice to dump this only if an assignment has taken place or the
  search list has changed.

* (DS) C-u -1 C-c C-x C-c C-o produces odd results

* (DS) Automate inferior-S-send-input to delay sending to the S process
  until a complete command has been typed. (I.e. when presented with
  an incomplete command, RET behaves like LFD). If this is done,
  multi-line commands will always get into the history as one entry.

* (DS) The menus need finetuning, and a binding to a keyboard key.

* (DS) Need to decide on a sensible policy on csh-like history references.
  At the moment, expanding such references is only possible from the
  menu.

* (DS) Need a keystroke to kill an edit buffer *and* the associated file.

* (DS) Need a function to copy an object to a new object *and* copy
   it's source file to a new source file, modifying the target of
   the assignment.

* (DS) Debugging support, through trace() and tprint()

* (DS) Modify S-beginning-of-function so that, with arg n, will move out
   n layers of nested functions. Wiht C-u arg, move to outermost
   function definition

* (DS) Rewrite the S-command and S-eval-visibly functions to use
  transaction queues (so that we can really have S running in the
  background) This is a big job.

=============================================================
Here is the new set (a start for S-mode 5.0). 
NOTE: Not all of these are clean OR are even consistent.
--------------------------------------------

* (KH) Fix indentation for "{" in the GNU style...

  Kurt> * What I also find frustrating is that the GNU style does
  Kurt> not get the indentation of `{' in:
  Kurt>       fun <- function(x, y, z) {
  Kurt> right (in fact, the results of hitting TAB on the second
  Kurt> line seem to vary).  But it is not important.

* (KH) It may be worth while replacing
        ("^[>+]" . font-lock-keyword-face)
  in R-inf-font-lock-keywords by
        ("^[RS]?[>+]" . font-lock-keyword-face)
  (or perhaps something even better assuming the coexistence of processes
  called R, S, S<something> on a system with the corresponding prompts.

  (MM) Yes, add "S4"  to this list to get something like

  ("^[RS]?[1-9.]?[>+]" . font-lock-keyword-face)

  is not quite correct, since it includes  ".3>" buth should rather
  "R0.50>".

* (KH) In R at least, asking for deletion of a file after loading it with C-c
  C-l does not make sense.

  (MM) Yes! -- this has been a real pain, especially when the file was
  version-controlled, it sometimes has just been deleted w/o asking !

* (KH) Also, there is no support for an Emacs-specific startup file.  This is
  not really important right now, I think, but anything based on comint
  and term should support that.

  (Tony, if you look at my R-inf.el, you'll notice that some effort goes
  into doing the right thing with output from startup args and files.)

* (KH) The function S-complete-object-name() in S-inf.el currently
  returns 
        
        (or (comint-dynamic-simple-complete  pattern components) 'none)

  with the comment `always return a non-nil value to prevent history
  expansions'.  Do you have an idea what that means?

  Is there any good reason to break the Emacs/Comint convention that a
  completer should return a non-nil value only if it did successfully
  complete?

  The specific reason why I ask is the following:

  S-inf does

        (setq comint-dynamic-complete-functions
              '(S-complete-filename
                S-complete-object-name
                comint-replace-by-expanded-history))

  I don't care about the last and prefer

        (setq comint-dynamic-complete-functions
              '(S-complete-object-name
                comint-dynamic-complete-filename))

  Note the reversed order of filename and object name completions.  I
  think it makes more sense that way, because if I have the file
  `anthony.dat' in my current dir and do

        anthony <- read.table("anthony.dat")

  then typing `ant TAB' at the R prompt should complete to `anthony'
  as an object name, as I can always force the filename in the current
  dir by `./ant TAB'.

  However, as S-complete-object-name() always returns a non-nil value,
  the comint file name completion simply does not happen (well
  ... that's at least what I think is the case ... but then also, what
  is the point to have comint-replace-by-expanded-history() in the
  list of completers, when it definitely will never be called
  ... hmmm.)

  Please let me know what you think.  My suggestion would be to simply
  change the last 2 lines of the code for S-complete-object-name() to

        (comint-dynamic-simple-complete pattern components))))

  and set comint-dynamic-complete-functions as I do :-)

  Well ... what I said was not quite right, as S-complete-object-name
  also tries to do something about `./ant RET'.  In any case, please
  let me know what you think.

* (AJR) Need an AUTOCONF for configuring Makefile, etc...

* (AJR) Move S-extras into the mainstream distribution files and as an 
  S-site example.

* (KH) So, need a "create-debian" entry in the Makefile.

* (KH) MINOR REMARK:  Currently, we have American and English spelling
  together.  If we want to change this, please add it to the TODO list.

* (KH) MINOR REMARK: Some of the doc strings are not o.k. (first
   sentence longer than one line ).  We eventually need to fix this,
   but perhaps not for 4.9.

* (KH) Btw, why not have `M-x vista' too?

* (KH) MAJOR REMARK I:

  The code for getting the `right' history file does not work.  E.g.,
  when I start R and XLS in the same directory, they both use
  .Rhistory.

  For a possible solution, see the novel below.

* (KH) MAJOR REMARK II:

  The code

(condition-case ()
    (load S-object-name-db-file)
  (error
   (message "%s does not exist.  Consider running S-create-object-name-db."
            S-object-name-db-file)
   (ding)
   (sit-for 1)))

   in S.el causes several problems.

   First, it produces an error in the byte-compilation process.  I
   noticed that you put an empty S-namedb.el in the distribution, but
   that does not help if `nil' is not in the default load path
   (because then the current directory is not searched), which I think
   is the default.
   
   Second, there should obviously be different namedb for R and S.
   (What I really mean is that the setting of S-object-name-db must be
   a function of the implementation [have we officially decided on
   using `dialect'?]  used.  Hence, the right thing most likely is to
   execute the code not when loading S.el, but when it is clear which
   process is started (assuming we have different namedb's for each
   dialect).

   This could probably be as late as before inferior-S-mode-hook, but I am
   not sure.

   (Note:  currently  this is not a problem for me, because I only have R,
   but what does Martin do?)

* (KH) NOVEL:

  So I spent several hours yesterday trying to figure out the right way of
  solving our problems with local variables, in particular because Martin
  explicitly asked me to do (only to find that the next morning Tony had
  already done something about it ...).

  I think it is important to distinguish two kinds of variables that need
  to be taken care of.

  ** One group is those variables which need to be known when the inferior
  process is started (i.e., before the process and hence also its buffer
  exist).

  Such variables are
        *) dialect (currently transmitted through S-proc-prefix)
        *) program name (`R' might be on the load path)
        *) program args (such as for `-v 10' for R)
        *) program startup file (currently unused)
        *) program history file (???)

  ** The other group consists of those which are not needed for startup,
  but need to have the right buffer-local values in the interaction
  buffer, such as

        inferior-S-help-command
        inferior-S-objects-command

  etc.

  The problem we have is that there is NO WAY of passing non-global
  values to buffer-local variables in Emacs.  Something like

        (defun R ()
           (let ((inferior-S-var value))
             (inferior-S)))

  does not set inferior-S-var to value in the interaction buffer if it is
  local there.  (Sort of static scoping.)

  There are several possible solutions:

  ** Keep manipulating the global name space using setq-default, as b4
  did.  Of course, this is terrible, because it overrides defaults.

  ** Have one function which does something like

        (cond
         ((eq S-dialect "R")
          (setq ...))
         ((eq S-dialect "S4")
          (setq ...))
         (t
          (ERROR)))

  after calling make-local-variable() on the relevant variables, and wrap
  the code into a function.

  To add a dialect, users would need to to this in there inferior-S-mode
  hook, or to advise/change this function.

  ** Have a list similar to S-style-alist with settings for the variables,
  and a function which sets them.  This is similar to the above, but keeps
  the code for the function and the variables separate.

  ** Have a dialect specific hook, e.g.

        inferior-S-<dialect>-mode-hook

  ** Keep manupulating a non-dialect-specific hook in the global name
  space.  This is what we currently do, and not `optimal' for the same
  reason that using setq-default was not:  If we think of inferior-S as
  user function and S and R as simple wrappers, then calling these should
  not modify the behavior of the generic function.

  I think the KEY to a clean solution lies in the observation that there
  is really only ONE variable needed in both steps (i.e., cranking up the
  process and setting local variables in the interaction buffer), and that
  is the information about the CURRENT DIALECT (which I think is currently
  kept in `S-proc-prefix'.  We need to ensure that this variable has the
  right local value to be able to run a specific hook (or a simpler hook
  as explained above), and that it starts the right process in the right
  buffer etc.

  To get that, we could either create a global variable, KEEP IT GLOBAL,
  use let() in the wrappers, and assign to a local variable afterwards, or
  (and I think this is the right thing to do) PASS THE DIALECT INFORMATION
  AS AN ARGUMENT.  I.e., we would have

        (defun inferior-S (&optional dialect n)
           ...

  [NOTE:  I am not sure about the optional `n', and whether this is used.
  I think that users might want to have

        (defun R (&optional n) ...)
        (defun S (&optional n) ...)

  and we are safe to give inferior-S the interface we want because it is a
  NEW function anyway.  We could also have it prompt for all relevant
  variables if given a prefix ...]

  and have

        (defun R (&optional n)
           (interactive)
           (inferior-S "R" n))

  Now the function inferior-S has the information it needs.  It can figure
  out the `right' startup settings (history file, program name and args)
  based on the dialect information in the generic pre-run hook and perhaps
  a dialect-specific pre-run-hook, and PASS THE DIALECT INFORMATION ON to
  the function S-multi() [or whatever it will be called].  I.e., it could
  be

        (defun S-multi (name &optional buffer dialect) ...)

  S-multi can now do

        (make-local-variable 'S-dialect)
        (setq S-dialect (or dialect S-default-dialect))

  and go on with the buffer-specific settings, again using the dialect
  information as described above.

  [Yes, there should be a default dialect which is used when inferior-S is
  used directly.  Perhaps naming would be better with global S-dialect and
  inferior-S-dialect as the local one ...]

* (MM) My WISH:
  I'm using  ess-eval-region  and friends very often.

  If the region has leading TAB, I think the readline feature of R,
  does a huge 'completion ...'
  which can completely destray the whole evaluation.

  ((Try  C-c C-f  from within a function that has a bit of indentation,
    and therefore leading TABS (unless you 'untabified' it).
  ))

  Yes, I'll have to 'untabify' things before I send it to *R*, but it's a
  pain, anyway.
  One could do 'untabify'  in  ess-eval-region & ess-eval-visibly 
  in ess-inf.el.
  But actually this is not quite correct,
  since I may have real TABs in a string  

  nchar("       ") #-> 1 because it has one TAB

  which should not be converted to spaces.

  Hence my wish:
        Write a function 'untabify-leading-white-space'
        and apply it to the regions  in ess-eval-region  and  ..-visibly.

* (RMH)

  
  5. essd-s+3.el
  63                                 ;;(if (string= ess-version-running "S3")
  This comment seems inconsistent with ess-version-running.  I think it should be
                                     ;;(if (string= ess-version-running "S+3")
  
  
  7. ess-object-name-db-file
  ess.el line 775.  Why is this EVIL?  A nuisance I understand, but EVIL?
  Does the database get built automatically when ess-mode is installed?
  That would be the right thing to do.  Then individual users wouldn't need
  to know about it all.
  

  10 ess.el lines  254-270
  This is one of the things I put in my site-start.el.  I think this is
  too complicated.  I think that when item 2 of this note is corrected (that is
  run the ess-pre-run-hook before the things that depend on it) then the nil
  value will work as advertised and the comment beginning with the word
  " Alternatively," will become completely unnecessary.
  
  (defvar ess-directory (file-name-as-directory (getenv "HOME"))
    "*The directory ess is run from.  It must end in a slash.
  Provided as a default if ess-ask-for-ess-directory is non-nil.
  A nil value means use the current buffer's default directory.
  Buffer-local: in process buffers, this contains the directory ess was
  run from.")
  ;; You can put something like:
  ;; (setq ess-directory (file-name-as-directory (concat (getenv "HOME") "/ess/")))
  ;; in your ~/.emacs file and ess will always start up in your ~/ess directory.
  
  ;; Or you can say:
  ;; (setq ess-directory nil)
  ;; in your ~/.emacs file and ess will always start up in your current buffer's
  ;; default directory.
  
  
  [[[[ delete
  ;; Alternatively, you can get ess to start up in the current buffer's directory 
  ;; by putting this in your .emacs
  ;; (setq ess-pre-run-hook '((lambda () (setq ess-directory default-directory))))
  ;; Better (more correct) version:
  ;;    (defun ajr:ess-set-directory () 
  ;;     "Set ess-directory to current directory."
  ;;     (setq ess-directory default-directory))
  ;;    (add-hook 'ess-pre-run-hook 'ajr:ess-set-directory)
  ]]]]
  
* (RMH) From smode.cmt (from the S4 package):

  <-- AJR: some of these HAVE been done. -->

  
  e. Problem
  Working data will be in /usr/people/rmh/.Data 
  > !pwd
  /disk5/rmh/smode
  > 
  
  Reason:
  .Data has not yet been created in /disk5/rmh/smode
  
  Solution:
  quit S, mkdir .Data, start again
  Recommendation 1.  Tell users in README to create .Data first.
  Recommendation 2.  Tell users in README about Info item
   - User Option: S-directory
  I for one always want the current buffer's working directory.
  
  
  g. Question:
  S-help does the following:
          (S-command (format inferior-S-help-command object) tbuffer)
  which seems to going through more work than is often necessary.  When the
  .Cat.Help subdirectory exists, why not just M-x find-file the help file?
  
  
  
  
  2. S3, Splus 3.3, S4
  
  e. S-inf-font-lock-keywords
  In inferior-S-mode the expressions below are in the indicated faces:
  > tmp <- 1:3  # >     is in  font-lock-keyword-face
                # rest  is     font-lock-variable-name-face
  
    tmp <- 1:3  # <-    is in  font-lock-reference-face
                # rest  is in  default
  
  I don't understand why.
  >From the definitions in S-inf.el, I expected that there would be
  no dependence on the presence or absence of the leading prompt ">".
  In particular, I anticipated that <- would be in font-lock-reference-face
  with or without the prompt.
  
  
  f. S-inf-font-lock-keywords
  I recommend adding several keywords to S-inf-font-lock-keywords
  for S3 and Splus 3.3 as noted in the attached s3.el and splus.el.
  
  
  g. Interesting glitch
  While fixing C-c C-l for S4, I found the following:
  >From the *scratch* buffer, both the commands
    (S-command "source(\"junk.s\")\n" (get-buffer "*S-errors*"))
    (S-command "source(\"junk.s\")\n")
  work correctly when junk.s is ok.  
  
  The first one puts an error message in "*S-errors*" when junk.s has a
  problem.  But the second one loses the error message.  I chose not to
  investigate this further, since S-load-file uses the first form, and I
  doubt any person would consider using the second.
  
  
  3. S4 changes
  
  a. S-mode.el  [C-c C-l   S-load-file]
  
  ;;; The S4 requires the fixes to
  ; S-dump-error-re
  ; S-parse-errors
  ; S-prompt-wait
  ;;; in my s4.el in order to respond correctly to syntax errors
  ;;; during S-load-file.  
  ;;; Without these changes the system will freeze.
  ;;; (^G will clear the freeze, and ^XB *S-errors* will
  ;;; display the error message).
  
  
  b. S.el and S-site.el
  The variable S-version-running, defined in S.el, with the option to
  revise in S-site.el, needs to be redefined to identify version 4.
  Some of the items coded by S-version-running differ in Version 4.
  
  b1. S-inf.el
  (setq inferior-S-search-list-command "searchPaths()\n")
  ;;; This variable needs to depend on S-version-running.
  ;;; the function inferior-S-search-list-command should probably use
  ;;; inferior-S-search-list-command, but it actually has "search()\n"
  ;;; hard-wired in.
  
  ;;; inferior-S-objects-command is the same for version 4 as for version 3
  
  
  b2. S.el
  ;;;    inferior-S-help-command
  ;;;    inferior-S-search-list-command
  ;;;    S-dump-error-re
  Add a new line
  ;;;      inferior-S-objects-command
  
  
  b3. S-help.el
  ;;;  S-submit-bug-report needs to know about version 4 for a bug report
  ;;;  to be useful.
  
  
  c. Other changes in s4.el respond to changes in S4:
     .Help is now __Help
     Errors are now Problems
     "Dumped" messages now become offers to Debug
     Additional keywords should be fontified
  
  
  d. I have placed S-namedb.el in $SHOME in my s4.el file.  On further
  reflection it should probably be in the $SHOME/library/emacs/
  directory.  Question, does it make sense for S-namedb.el to be
  distributed in $SHOME/library/emacs as part of binary.*.tar.gz ?
    
* (RMH)

  Rather than have the site installer change the name of the directory,
  it should be possible to find it out automatically.  Here is the
  relevant code from my spread.frame package.  It assumes the user
  started up spread.frames by typing
     M-x load-file "/path/name"
  It then finds the directory associated with that path and goes from
  there.  Some similar trick should be doable when the user does a
     M-x load-library "name"
  
  
  (defun find-spread-frame-directory nil 
  "Locate directory in which spread.frame functions are stored."
    (list-command-history)
    (set-buffer "*Command History*")
    (goto-char (point-min))
    (search-forward "(load-file ") )
    (goto-char (1+ (match-end 0)))
    (setq beg (point))
    (end-of-line)
    (search-backward "/")
    (goto-char (match-end 0))
    (setq spread-frame-directory
        (expand-file-name (buffer-substring beg (point))))
    (kill-buffer "*Command History*"))

* (daven@stille.llnl.gov (David Nelson))
  
  Transcript mode is delightful, with one possible improvement. Quite
  often, when I'm in the middle of a session, I'd like to insert a
  comment in the transcript, preferably with a distinctive type face
  like those provided by "font lock".  Is there an easy way to do this
  that I'm just missing?

  (RMH's thought): 

  I'm writing to you rather than directly to daven@stille.llnl.gov
  (David Nelson) because I'm not sure how to tell him to do the
  following fix in .emacs or S-site.el because of the local variable
  issue or if it even is the right fix.

  I think the permanent answer should be for you to add the lines

  (make-local-variable 'comment-start)
  (setq comment-start "#")
  (make-local-variable 'comment-start-skip)
  (setq comment-start-skip "#+ *")

  copied from S-mode.el to the files S-trans.el and S-inf.el (4.8
  notation).  But when I tried it out with M-x eval-expression in the
  *S* buffer it didn't have the effect I anticipated.

  I can't figure out the intent or meaning of the line
   ("^\\*\\*\\\*.*\\*\\*\\*\\s *$" . font-lock-comment-face) ; S-mode msg
  from S-inf.el and S-trans.el

* (KH, 010897) Can we combine the inferior-ess font-lock-patterns for prompt
  and input into one regexp?  I.e., use

        ("^\\([a-zA-Z0-9 ]*[>+]\\)\\(.*$\\)"
         (1 font-lock-keyword-face)                ; prompt
         (2 font-lock-variable-name-face keep t))  ; input


* (KH, 010897) Perhaps one could have an option to install the Info
  files gzipped (as is default for e.g. Debian GNU/Linux).

* (RMH bad behavior)
  I loaded ess-site from *shell* in directory ~/
  Then I M-x S from that buffer.  It asked me about starting S in ~/
  The with in *shell* I  cd /disk05/rmh and M-x S from *shell* again.
  I think it should have attempted to start S from /disk05/rmh, but instead it
  again  asked me about starting S in ~/

* (AJR/RMH) make sure that font-lock stuff is properly set. (look into 
  file order, for example).

* (AJR) Kurt> * When first starting R and then XLS, we have

  Kurt> ess-history-file's value is ".Rhistory" Local in
  Kurt> buffer *R*; global value is ".XLShistory"

  Kurt> Why is there a non-nil global value?

  > Because of the nature of buffer-local variables.  It doesn't really
  > matter, since I'm ALWAYS ignoring the global value (at least that is
  > my intent).

* (MM) Date: Fri, 22 Aug 1997 09:11:25 +0200

  >>>>> "Kurt" == Kurt Hornik <hornik@ci.tuwien.ac.at> writes:

    >> * Questions: 1. I don't understand why ess-customize-alist is not
    >> buffer-local (This definition is from ess-vars.el.): (defvar
    >> ess-customize-alist nil "Variable settings to use for proper
    >> behavior.  Not buffer local!")  ;;(make-variable-buffer-local
    >> 'ess-customize-alist) ;;(setq-default ess-customize-alist nil)

    Kurt> Personally, I think that most of the (make-variable-buffer-local
    Kurt> ...)  and (setq-default ...) will have to be replaced eventually
    Kurt> by making the variables local when needed and passing them not in
    Kurt> the global environment but rather as explicit arguments to the
    Kurt> caller functions.

    Kurt> E.g.,

    Kurt>       (ess-start-process NAME BUF FILE ARGS ALIST)

    This is cleaner from a programming point of view,
    however is n't  this much less CPU efficient ??

    >> 3. Should ess-proc-prefix be renamed to ess-language?  I glanced at
    >> the result of 'grep ess-proc-prefix *.el' and don't immediately see
    >> a problem.

    Kurt> Yes, good idea.  Could we then have

    Kurt>       ess-language ess-dialect

    Yes, this looks like the thing to aim at !!
    Together with what Kurt wrote in the last e-mail's PS:

    Kurt>>> PS.  We should decide on a scheme for languages (S, XLS, ...)
    Kurt>>> and what we call ``dialects'' (for S: S3, S4, S+, ..., R).
    Kurt>>> This would allow us to have a general mechanism for dealing
    Kurt>>> with the above, such as
    Kurt>>> 
    Kurt>>> * In the caller function (M-x S, M-x R, ...) set language and
    Kurt>>> dialect.
    Kurt>>> 
    Kurt>>> * Then, we don't explicitly have to assign all variables which
    Kurt>>> should be local (such as font-lock-keywords) anyway, but could
    Kurt>>> figure them out by
    Kurt>>> 
    Kurt>>> looking for <language>-font-lock-keywords looking for
    Kurt>>> <language>-<dialect>-font-lock-keywords
    Kurt>>> 
    Kurt>>> Hooks could be organized similarly
    Kurt>>> ... (ess-inf-S-S4-mode-hook?)


* (RMH 31 Jul 1997 07:22:10 -0400 or earlier)

  * what it doesn't do 1. The effect of the second line is to prevent
  * font-lock information from happening on input lines.  The prompt
  * is highlighted, the rest of the line is not.  The effect is to
  * cancel the usefulness of syntax highlighting on user-typed
  * commands.  Syntax marking is only in effect when the system types
  * a function back to us.

  2. I can't figure out what the ess-mode msg line is doing.
     ("^\\*\\*\\\*.*\\*\\*\\*\\s *$" . font-lock-comment-face) ; ess-mode msg

  3. comments (beginning with #) are syntactically ignored by
  highlighting.  In ess-mode, comments are not picked up with this
  table (actually ess-mode-font-lock-keywords).  They are picked up by
  ess-mode-syntax-table on line 733 of ess-vars.el.

  4. what are the < > characters doing in this line:
   ("\\<\\(TRUE\\|FALSE\\|T\\|F\\|NA\\|NULL\\|Inf\\|NaN\\)\\>"
    . font-lock-type-face) ; keywords


  * open questions 

  1. I think I want ess-mode-font-lock-keywords to be effective in
  inferior-ess and in ess-transcript.  That means to the user, the <-
  and function and T and F will be highlighted as commands are typed
  in.

  2. That means to the ess-mode designer that the line
   ("^[a-zA-Z0-9 ]*[>+]\\(.*$\\)"
    (1 font-lock-variable-name-face keep t)) ; input
  is deleted from inferior-ess-font-lock-keywords.

  3. Further it means that inferior-ess-font-lock-keywords should be
  defined by adding additional definitions to
  ess-mode-font-lock-keywords.


  * harder questions

  1. these keywords are hardwired.  They should probably be put into
  the *-customize-alist.  In particular, S4 uses different keywords
  for errors (problems) and so forth.  It also uses different keywords
  for the Help file (__Help instead of .Help).  These are functional
  differences, not just cosmetic differences where the font would be
  wrong.  See the comments in essd-s4.el (based on my original s4.el).
  (just noticed, the current essd-s4.el has two ending pages.)  It is
  easy to make ess-mode work for S4 by overriding all the differences
  (which is how s4.el works).  It is harder to do it cleanly so the
  same emacs session can be used for S4 and S3.  Lots of currently
  hardwired variables need to be moved to the *-customize-alist first.
  xlispstat is quite differently structured, so I am sure that the
  keywords and highlighting here will be either irrelevant or harmful
  if applied directly.  customization is needed for that generality as
  well.

  * comments

  I'm confused?  I've always gotten comment highlighting in
  inferior-ess/S-mode.  Or do you mean that it's not done in the right
  place?

  correct, it is not done where you think it is done (right place or
  not).  It is done by ess-mode-syntax-table for inferior and
  transcript mode.  It is not done at all for ess-mode.  The font-lock
  settings seems to be irrelevant.

  * logic
    Richard> 4. what are the < > characters doing in this line:
    Richard>    ("\\<\\(TRUE\\|FALSE\\|T\\|F\\|NA\\|NULL\\|Inf\\|NaN\\)\\>"
    Richard>     . font-lock-type-face) ; keywords

  using the typeface for the inequalities, for boolean statements/tests.

  Not so.  The < > do not appear in font-lock-type-face.

  * Hmm... I think that was the font that was to be used for the prompt. 

  Not so.  The previous line is used for the prompt.  This line seems
  to be used to suppress font-lock control for all characters
  following the prompt.  Note that the (1 ...) is in the position
  normally taken by the "." .  I assume the keep makes it stay that
  way for the rest of the line.  I haven't bothered to read font.el to
  figure this out.


  * *Buffer List*
  .   text.st           0  ESS Transcript /disk05/rmh/text.st
      test.r            0  ESS[R]       /disk05/rmh/test.r
      test.s            0  ESS[S]       /disk05/rmh/test.s
   *  *S4*            236  Inf-ESS      

   Note that the *.r and *.s files include the [R] and [S].  The
   inferior processes do not include the ess-version-running, I wish
   they would.  The corresponding modelines are

   (ESS Transcript [] Font)
   (ESS[R] [none] Font)
   (ESS[S] [none] Font)
   (Inf-ESS [S4]:  run Font)

   I don't know the original intent of the [] and [none], but I would
   love to see the name of the buffer to which ^C^N is sending stuff.


   * ^C^N goes to the wrong inferior process.

   I opened test.r in the same directory as *R* and sent a line.  It
   went to the *S* buffer in a different directory and running the
   wrong program.  There needs to be a way for the system to ask me
   which process to use.  Also, it's default guessing system should
   have guessed *R* based on the file name test.r.



   * hooks

   in ess-vars.el, line 317 and following, some of the hooks are
   initialized to '() and others to nil.  Is there a difference?


   * ess-source-modes in ess-vars.el line 382
   Is this obsolete now that auto-mode-alist has the suffix information?


* (AJR, via MM, RMH, DB): distinguish between files of dumped objects
  and files of loading objects.

* (RMH/AJR)
    Richard> essl-sas.el
    Richard> SAS-log-mode

    Richard> As present, SAS-log-mode doesn't do anything but be
    Richard> human-readable.  My intent in basing it on
    Richard> ess-transcript-mode rather than on fundamental-mode is
    Richard> that when sas-clean-region and related functions are
    Richard> figured out, then the log file can be used to re-enter
    Richard> commands back to *SAS:1*.  We will look for all numbered
    Richard> lines between a
    Richard>  34   PROC abcd;
    Richard>  ...
    Richard>  38   run;
    Richard> pair, sas-clean-region them and send them over to
    Richard> *SAS:1*.  This is NOT an exercise for 5.0.  But because
    Richard> it is intended, I feel (weakly, not strongly) that it
    Richard> would be better to base SAS-log-mode on
    Richard> ess-transcript-mode.  This plan should be formally
    Richard> entered into the TODO list.

    I would agree with this.  I'd also like to make sure that we have a
    means of easily going between linked buffers.  Added into the TODO
    list. 

    Richard> While we are entering things in the TODO list, I would
    Richard> like to consider setting up *SAS:n* as a unix pipe,
    Richard> rather than as a unix buffer/file.  I don't know how to
    Richard> tell emacs to do that.  The idea is to mimic the behavior
    Richard> of the SAS edit window where, once the Submit menu item
    Richard> has been clicked, the window is emptied.

    No, I think that using as a buffer would be better (especially for
    debugging any weird problems).  Hiding it, though, will be desirable.

    Richard> I can also see a case for leaving the *SAS:n* buffer as a
    Richard> buffer.  We should consider making it read-only to force
    Richard> the user to do all thinking in the ex123.sas buffer.  The
    Richard> only reason I can currently think of for letting the user
    Richard> write directly in the *SAS:n* buffer is to enter the
    Richard> commands
    Richard>     stop;
    Richard> or
    Richard>     endsas;
    Richard> I can't think of any reason to save the *SAS:n* buffer
    Richard> and would like to know if there is any way to prevent the
    Richard> user from saving it.

    and not even that, since that should be the result of C-c C-q, so
    that we get a nice, uniform means of exiting.

  (RS1) I don't believe the sas-log-mode suggestions were ever implemented.
        In fact, sas-log-mode is not a default option anymore since there
        are so many different applications that create .log files.  
        Instead, a few changes were made to sas-mode based on requests for syntax
        highlighting of the .log.  This feature can be toggled on and off
        by F10.  This temporarily turns on sas-mode for .log files so you will
        not experience permanent extension collisions with other .log file
        generating applications.  Also, performance may be an issue.  
        Extremely long .log files (particularly those generated by macros
        that involve alot of code-generation) can be extremely time-consuming
        to fontify and lazy-locking is usually not an option due to the 
        complexity of the SAS regular expressions.  Fast-locking may help a
        bit, but font-locking of several minutes is not unheard of.
        Also, the font-lock code was re-written to properly highlight either 
        a .sas or a .log file.  See ess-sas-run-make-regexp below.

  (RS2) Rich re-did sas-log-mode to use the font-locking from ESS[SAS] and
        it seems to be working.  The only caveat is that I found that
        fast-lock is very slow for big .logs and I switched to lazy-lock
        and it is much faster, however, I have problems toggling; usually,
        after I turn it on, I can't turn it off; but, that's not so bad
        with lazy-lock.  Also, a new function creates transcript from 
        your .log, ess-sas-transcript

* (KH)  Font-lock needs to be more intelligent about recognizing
  reserved words in non-reserved contexts (such as in "strings").
  (RS1) If this was a SAS problem, then problem has been fixed.
        To turn on the new functionality,
        (setq ess-sas-run-make-regexp nil)

  (RS2) This is now the default and most known issues have been addressed;
        even hanging then statements!

* (AJR) SAS indenting needs to be fixed.

  (RS)  I don't know if this was fixed, but I haven't had any problems
        with indenting recently.

* (AJR) SAS fontlocking of comments needs to be fixed.
  (RS)  I believe this is done.  We made a few changes, but the biggest
        problem was that Emacs 19.34 was misbehaving.  
        See ess-sas-run-make-regexp above.

* (KH) explicit statement:
 
  I have only one remark (one of my usual ones).  I'd like to be able to
  pass command line arguments to the inferior process when it is started.
  This is currently not supported, and poses some difficulties with an
  interactive prompt mechanism.  (Also rules out my suggestion of using
  C-u to force prompting for command line args.)

  Hmm ...  Perhaps we should have a variable (ess-inf-always-prompt-...)
  to get around this problem?

* (RMH - SAS) 
  graphics are possible in two ways:
  a. proc gplot; plot a*b / vpos=25;
  b. goptions device=psfile;
     filename gsasfile 'temp.ps';
  and then use ghostview from another *shell* buffer.

  autoexec.sas defines the departmental printers and turns off
  overprinting.  My autoexec.sas file is:

  libname gdevice0 '/home/public/stat/gdevice0' ;
  options noovp;

* (RMH - SAS) I have another proposal for font-lock in SAS-mode.  I
  think it will be easy, but I would like discussion first.  My new
  proposal is that 

  proc whatever
  data myfile
  %macro macname

  and maybe a few others (including both the keyword and name of the
  dataset or proc) be in font-lock-function-name-face

  %include will be in font-lock-reference-face

  Any other FIRST word in a statement will be in
  font-lock-keyword-face

  My reasoning is that the current laundry list is too long, and still
  misses many keywords.  The structure of the SAS language is
  essentially keyword and arguments, so let's follow that.
  (RS) Essentially done.  The following statements are in 
       font-lock-reference-face:  macro statements, PROC ...,
       DATA, RUN, ENDSAS, and QUIT.
       See ess-sas-run-make-regexp above.

* (Tobias Laatsch - SAS) 
  There seem to be some problems fontifying SAS Comments in ESS 5.0
  Pre1. (I'm running xemacs 20.2 on AIX .) 
  Currently I recognized following problems:
  1) Multi-line-comments are not fontified. (open comment "/*", some
     lines of code,  close comment "*/") 
  2) When typing  / , " or '  in a comment-area, ESS fontifies the
     whole line as normal code instead of comment. 
  3) Typing a '* in a comment-area fontifies the rest of the line as
     string. 
  (RS) Fixed for /* */ style comments which are now handled by grammar
       only.  * ; and %* ; are still broken since they can't be
       specified by grammar.

* (AJR) 
    Richard> I think of S-transcript-mode as identical to
    Richard> inferior-S-mode except that the transmission is to the
    Richard> same buffer in inferior-S-mode and to a different buffer
    Richard> in transcript-mdoe.  So I expect ^M (enter) to behave
    Richard> normally for lines that begin with "> command" and "+
    Richard> continuation".

    Which is what my proposal does (send command, move to next prompt).

    What needs to be modified is that currently, it moves to any next
    prompt, including "+ ", rather than just to the next primary prompt -- 
    it is smart enough to strip the "+ " as well from the whole command,
    and collect the rest of the command line.   

    Richard> I haven't tried eval-region commands from either *S* or
    Richard> from a filename.st.  I think both ^C^N and ^C^R should
    Richard> make sense and work if the region is valid input.  Both
    Richard> modes should strip leading ">" and "+" characters.  I
    Richard> think that a region which is a subset of a line, or which
    Richard> doesn't begin with the standard prompt sequences, should
    Richard> send it over literally.

    So, C-c C-r would only send lines beginning with
    inferior-ess-primary-prompt (up to the last consecutive
    inferior-ess-secondary-prompt), strip off the prompt, and ignore lines
    which do not begin with prompts.  Does this sound correct 
    (for C-c C-r)?

    C-c C-n should be correct (comint-next-prompt).

* (KH/AJR)
  I see.  This is what the "help(\"%s\")\n" does.

  Well, we have the following problem.  The `new' interface to help()
  I created is

        help(topic, package = .package(), library = .lib.loc)

  This allows you to get help on a topic (R object, ie fun or var or
  whatever else is documented) in a package without loading it, via

        help(topic, p = PKG)

  I've eliminated the help(data = ) part, but there may soon be
  another argument to search for keys ...

  If we want people to be able to use the extended forms, we can

  * use "help(%s)\n" for the format, which means they have to quote
    special things as they would need to from the command line
 
  * or do something smarter, such as
        quote only if object does not contain ","
    which appears to be the right thing.

  What do you think?

  > How about this 3rd alternative?  

  > C-c C-v             works as usual
  > C-u C-c C-v prompts for the extra arguments (a "wizards
  >             help", of sorts)

  > Completion will only work with the prompt for the command, and will be 
  > turned off for the others? 

  > If not, we'll go with the "right thing" (option 2).

  The alternative sounds good.  We might still want to quote the help
  string in case it does not contain a `,', so that C-c C-v +
  continues to work ...

* (RMH) His (Tom Cook's) sas-get-dataset is a very good idea and was
  not in my proposal.  I would do it using the same mechanism that
  S-help uses to put the results of ?function into *help(function)*
  buffer.  It is a relative of ess-dump-object-into-edit-buffer.  The
  major difference is that there is no sense of editing the object and
  sending it back to S.  It is also a relative of the display of a
  spred.frame, with the difference again that there is no sense of
  editing the object.

  I like the switch-to-sas* functions.  I would like to generalize
  them back to S.  I think switch-to-S-source when entered from the
  *S* buffer should go to the filename.s that was the most recent
  sender of ^C^N or ^C^R.

  Here is cook's sas-mode-map and how it fits with my essd-sas.el
 
   "\C-c\C-i" 'indent-sas-statement)            \t  use recommended conventions
   "\C-c\C-a" 'beginning-of-sas-statement)      use
   "\e\C-a" 'beginning-of-sas-proc)             \M-\C-a
   "\e\C-e" 'next-sas-proc)                     \M-\C-e
   "\C-cs" 'switch-to-sas-source)               use
   "\C-cS" 'switch-to-sas-source-other-window)  use
   "\C-cg" 'switch-to-sas-log)                  use
   "\C-cG" 'switch-to-sas-log-other-window)     use
   "\C-cl" 'switch-to-sas-lst)                  use
   "\C-cL" 'switch-to-sas-lst-other-window)     use
   "\C-cr" 'run-sas-on-region)                  ^C^R
   "\C-c\C-l" 'submit-sas)                      ^C^B or ^C^L
   "\C-cd" 'sas-get-dataset)                    use
   "\C-c\C-c" 'switch-to-sas-process-buffer)    ^C^Z or ^C^Y

  (RS) Can't comment on the S aspects, but you can now browse/edit a permanent
       SAS dataset (provided the library definition appears in autoexec.sas)
       with F9.

* (AJR) REWRITE INFERIOR-ESS (AJR, for 5.1 series).

* (RMH) Add explicit directions on installing or using dir for info.
         Makefile  ; for 5.0
        line 96 of pre5/Makefile included dir.
        dir does not appear in lastpre/Makefile.
        dir does not appear at all in the directory.
        You did include instructions on line 194 on editing dir.
        dir is needed for the info system to get ess into its menu.
        Please include the sample dir (below) and instructions on
        editing site-start.el.  
        I have the following in my site-start.el
        ;;
           (defun add-info-path (newpath)
             (setq Info-default-directory-list
                   (cons (expand-file-name newpath)
                         Info-default-directory-list)))
        
           (add-info-path "/disk05/local/teTeX/info/")   ; stat dept
           (add-info-path "/disk05/local/emacs/S-mode/") ; stat dept
           (add-info-path "/disk05/local/info/")         ; stat dept
        ;; 

        Here is my 5 line dir file from S-mode 4.8.  It needs to be
        updated to 5.0.  The first line is blank. I think the blank
        line is required, although it might be there only for
        appearance when the info menu comes up.

        \x1f
        File: dir       Node: Top       This is the top of the INFO tree
        * Menu: The list of major topics begins on the next line.
        * S-mode: (S-mode).             S-mode Version 4.8


        This works correctly in Emacs 19.29.  My memory says that when
        I was playing with XEmacs a few months ago, the add-info-path
        didn't work correctly in XEmacs.  Only the first and last
        items on the Info-default-directory-list actually got
        displayed.

* (RMH) >From here on is NOT for 5.0

         ess-create-object-name-db and ess-load-object-name-db-file
        1. e-load-* doesn't ding if not there.  good
        2. I entered e-create-* manually and it did its job, creating
                   ess-s+3-namedb.el 
           in my home directory.  Then I did a name completion and ESS
           redid the entire set of searching the directories.
        3. mv ess-s+3-namedb.el to ESS-5.0/
        4. Quit emacs and start over
        5. Then I did a name completion and ESS redid the
           entire set of searching the directories.
        6. Quit emacs and start over
        7. Manually M-: (ess-load-object-name-db-file)
        8. Then I did a name completion and ESS redid the
           entire set of searching the directories.

* (RMH)  buffer choice (questions for 5.1)
        I opened lots of simultaneous processes.
        The q() from *R*.
        Then M-x XLS
        XLS came up in the *R* buffer

        Tried it again.  This time I C-c q() from *S4*.
        Then M-x S
        S+3:3 came up in *S4* buffer.

        This is obscure stuff.  What really should happen?

   Problem in inferior-ess: logic states that if the current buffer is
   iESS or ESS-trans, and doesn't have an active process, use it,
   instead of creating a new buffer. (AJR).

* (RMH) 
     * iESS [S+3]   5.0? 5.1?
     'single quotes' are in regular font
     "double quotes" are in quote font
     This differs from ESS[S] mode in which both kinds of
     quotes are in quote font. 
    
     Should be fixed in 5.0 if easy.  Not obvious to me where
     the problem is.  The identical S-syntax-table is in use
     in both iESS [S+3] and ESS[S].  The font-lock-keywords
     don't seem to me to be the problem.


* (RMH)
  Dumped problem in S+3
  Here is an example of the Dumped font problem in S+3:

  > "trellis.settings" + "x + z + abcdefghij + klmnopqrstuv"
  Error in "trellis.settings" + "x + z + abcdefghij ..: Non-numeric first operand
  Dumped
  > 

  Note that the Error description from S+3 truncates the command and
  adds the ".." to indicate the truncation.  Part of what gets
  truncated is the closing quotation mark.  Hence everything from that
  point on is still inside the opening quotation mark.  Everything
  includes the rest of the error description, the word "Dumped", the
  prompt on the next line, and all succeeding commands.  I normally go
  back and edit the line by adding the closing quote in front of the
  prompt

  Dumped
  "> 

  I would love for iESS [S+3] to monitor the word "^Dumped" and make sure the
  font is back to regular.


  * On the Dumped ".. font problem
  I have an answer that I am uncomfortable with.
  The problem:
    Error in "trellis.settings" + "x + z + abcdefghij ..: Non-numeric
                first operand 
    Dumped
  
  Potential Solution:
  a. Look for the pair "Error in"  and "Dumped"
  b. Verify the number of uses of '"'.
  c. Insert an extra '"' if needed after the ".." and before the ":", thus
    Error in "trellis.settings" + "x + z + abcdefghij ..": Non-numeric
                first operand 
  
  My discomfort is that we are then modifying the output, not just
  highlighting it.

* (BR) Scripts in S-PLUS 4.x provide quite similar functionality to
  the ESS front-end, and are worth investigating.

* (Duncan Murdoch, on IDEs): 

  I don't understand the details of what you're saying, but for an
  example of a very good IDE, you should look at Borland Delphi,
  version 3.  It has some very nice features:
 
  - at any point, you can ask to see a list of legal identifiers to
  insert.  These are presented in order from most to least local, so
  usually the one you want is near the top.  The IDE knows enough
  about the syntax of the current line to only suggest things that
  would be legal there.
  - when you type a dot (more or less equivalent to $ in S), you're
  presented with a list of fields and methods for the object or record
  you're working with.
  - you can point at any identifier and hit a key for the help for that
  identifier.  Because it's an object oriented system, there are often
  multiple different methods with the same name; the IDE picks the
  appropriate one by the context.

  Other unrelated things that Delphi does nicely which Splus would do
  well to emulate:

  - you can ask for a new object of a specific type, and it will insert
  appropriate skeleton code for it.
  - the object browser is quick and convenient to use!  Of course, the
  objects in Delphi tend to be quite different from the objects in
  S...
  - it has lots of nice visual design tools for writing user interface
  code.

* Bob_Dorazio@usgs.gov (Bob Dorazio) on IDEs:

  I have no experience with emacs, but in response to your question
  take a look at Watcom's IDE for C++.  This IDE is the best I have
  ever seen!  The source code editor is fantastic and the level of
  integration between the source code editor, the compiler, the
  debugger, and the utility for "building" executables or libraries
  surpasses that of any other IDE I have used.

*  From: Sandy Weisberg <sandy@stat.umn.edu>
Subject: Re: ESS 5.1.14 supports ARC
To: rossini@biostat.washington.edu
Date: Thu, 6 Jul 2000 09:42:19 -0500 (CDT)

The name of the program is Arc, capitalized because it is a proper name, but
otherwise a normal English language word.

Thanks for asking!
> 
> Thanks to Doug Bates' prodding, ESS 5.1.14 (Emacs Stat interface)
> released an hour ago, works with ARC).  
> 
> Should it be referred to by "ARC" or "Arc" (or?) in the ESS
> documentation (which still needs to be written)? 
> 

* From:         Sven Garbade[SMTP:garbade@psy.uni-muenchen.de]
  Subject:      Delete forward key
  
  I don´t like it that the delete-forward key deletes backwards in
  ESS-mode. My default option is, delete-forward deletes forward, but
  ess-mode ignore this. Is there a simple way to change this?
  (RS) Put this line in your .emacs file after you have loaded ESS:
       (define-key ess-mode-map [delete] 'delete-char)

* (RMH) Stata question: delimiter

  I noted that the command lines are duplicated.  You might need
    (setq comint-process-echoes t)
  in the defun stata



Date: Tue, 15 Jun 2004 01:11:33 -0400
From: "Richard M. Heiberger" <rmh@temple.edu> Add To Address Book | This is Spam 
Subject: Re: change in ESS with edit() in R 
To: rossini@u.washington.edu 
Cc: Stephen Eglen <stephen@anc.ed.ac.uk>, ess-core@stat.math.ethz.ch 



I think Tony spotted the source of the problem.  I think I did it.

The goal in ess-iw32.el was to change the behavior of 
ess-eval-linewise and ess-eval-region to call the Windows S-Plus GUI
through the DDE protocol.  This was successful.  I and others have used it daily
for the past 6 years.

I intended to restrict the change to the S-Plus
GUI.  My thinking at the moment is that I didn't do that restriction well enough.

I get an emacs freeze in both R and Sqpe on Windows.  An initial look at emacs
variables makes me think that the "if" tests in ess-iw32.el for the substitute
definitions of

ess-eval-region
ess-eval-linewise
ess-load-file
ess-dump-object-into-edit-buffer
ess-display-help-on-object
ess-dump-object

aren't precise enough to detect that R and Sqpe should not be sent to ddeclient.

This note goes on the master "To DO" list.  Do we have one?
Taking it off the list is not a high priority for me because the work around of
C-g is so easy.


Rich