headers
Martin Maechler | 1 Sep 2005 10:07
Picon
Favicon
Gravatar

Re: [ESS] several R versions

>>>>> "Kasper" == Kasper Daniel Hansen <khansen <at> stat.berkeley.edu>
>>>>>     on Wed, 31 Aug 2005 15:42:36 -0700 writes:

    Kasper> Hi Stephen On Aug 31, 2005, at 12:00 PM, Stephen
    Kasper> Eglen wrote:

    >>  hi Kasper, Kasper Daniel Hansen writes:
    >> 
    >>> Hi
    >>> 
    >>> I am currently using R with ESS v5.2.9 under Mac OS X
    >>> using Carbon Emacs (Emacs v. 22.0.50.1).
    >>> 
    >>> I have started to use two different R versions. The
    >>> standard stable release is called using R in the
    >>> shell. Then I have the development version which I start
    >>> using R-devel (this is a symlink in /usr/local/ bin).
    >>> 
    >>> I would like to use both versions in Emacs, eg. doing
    >>> something like (all this exact form is not really
    >>> relevant) M-x R and M-x R-devel
    >>> 
    >>> I assume that it is quite easy to do so, but how?
    >>> 
    >>> 
    >>  not trivial, but close; here is an excerpt from the
    >> documentation:
    >> 
    >> R on Unix systems: If you have "R-1.8.1" on your
    >> `exec-path', it can be started using `M-x R-1.8.1'.  By
(Continue reading)

Permalink | Reply | 4 comments |
headers
david whiting | 1 Sep 2005 10:52
Picon

Re: [ESS] several R versions

On 01/09/05, Martin Maechler <maechler <at> stat.math.ethz.ch> wrote:

[...]

> Well, I should agree with Kasper here,
> I've defined my own version of  'M-x R-devel' about 6 years ago...
> long before there were ess-r-versions around.
> 
> Kasper, for the moment, add the following to your ~/.emacs (or
> equivalent):
> 
> (defun R-devel (&optional start-args)
>   "Call the development version of R (using ESS)."
>   (interactive "P") (let ((inferior-R-program-name "R-devel")) (R start-args)))
> 
> ;; (let ..) defines variables local to its scope, very similar
> ;; to  R's  local(..)  construct.
> 
> 
> I hope one of us will find the time to make this work along the
> same line as "ess-r-versions" i.e., M-x R-devel will work automagically
> **WHEN** an "R-devel" is in your path.
> 
> Martin
> 

I'd just like to add a vote for this. I've been wanting this for
while. I don't think my elisp is good enough though to be able to
contribute something. I am going to try your R-devel.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Eglen | 1 Sep 2005 11:11
Picon
Picon
Favicon

Re: [ESS] several R versions

Martin, Kaspar,

I just took a deeper look into R-devel, and found the problem.

If I have a program called "R-devel" on my path, I need to put the
following in .emacs BEFORE ess-site is loaded:

(setq ess-r-versions '("R-1" "R-2" "R-devel"))
(require 'ess-site)

since the R versions are created only on startup.  Perhaps I need to
document that better in the string.  This means also that if people
customize it, either:

1. their customize should come before ess-site is loaded (hard)

2. the customize code dynamically recreates R-versions (neater).

But if we change the default of ess-r-versions to the above, we should
be Okay for most people, especially you Martin, so you should be able
to remove your 6 year old function!

Please check and get back to me! 

Stephen

______________________________________________
ESS-help <at> stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help
(Continue reading)

Permalink | Reply | 2 comments |
headers
Martin Maechler | 1 Sep 2005 11:23
Picon
Favicon
Gravatar

Re: [ESS] file name completion again

Thank you, Jean and David.

I now can re-produce your problem,
and yes, it's a bug caused by yet another incompatibility
between (GNU) emacs and Xemacs
--- actually I think two (related) incompatibilities :

1) The set of   comint-dynamic-complete-functions
   that is used when within *R* is very different for GNU emacs
   and Xemacs

2) Both
        (ess-complete-filename)                and 
        (comint-replace-by-expanded-filename)
   in Xemacs, give the ominous error message
      "last thing matched was not a buffer"
   but do work in GNU emacs. Note that 
       comint-replace-by-expanded-filename is part of (X)emacs itself,
   not ESS.
   Hence something it would have been good had the Xemacs
   maintainers made sure worked (the same as in Emacs).

   Anyway
   -------> something for ESS-core to fix / work around

But yes, it would have been great had we found out about the
details for this  *BEFORE* the release of ESS 5.2.9 ...
At the time, Jean first opened this topic, back in February,
I think we all believed it was just a general ESS misfeature,
and M-Tab ( = comint-replace-by-expanded-filename ) would at
(Continue reading)

Permalink | Reply | 3 comments |
headers
Martin Maechler | 1 Sep 2005 11:34
Picon
Favicon
Gravatar

Re: [ESS] several R versions

>>>>> "StEgl" == Stephen Eglen <S.J.Eglen <at> damtp.cam.ac.uk>
>>>>>     on Thu, 1 Sep 2005 10:11:50 +0100 writes:

    StEgl> Martin, Kaspar,
    StEgl> I just took a deeper look into R-devel, and found the problem.

    StEgl> If I have a program called "R-devel" on my path, I need to put the
    StEgl> following in .emacs BEFORE ess-site is loaded:

    StEgl> (setq ess-r-versions '("R-1" "R-2" "R-devel"))
    StEgl> (require 'ess-site)

    StEgl> since the R versions are created only on startup.  Perhaps I need to
    StEgl> document that better in the string.  This means also that if people
    StEgl> customize it, either:

    StEgl> 1. their customize should come before ess-site is loaded (hard)

    StEgl> 2. the customize code dynamically recreates R-versions (neater).

    StEgl> But if we change the default of ess-r-versions to the above, we should
    StEgl> be Okay for most people, especially you Martin, so you should be able
    StEgl> to remove your 6 year old function!

well, if we go down that road we should make it

 (setq ess-r-versions '("R-1" "R-2" "R-devel" "R-patched"))
 (require 'ess-site)

since that would allow to get rid of yet another 6 year old one :-)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Maechler | 1 Sep 2005 11:42
Picon
Favicon
Gravatar

[ESS] Xemacs again {was "file name completion again"}

Sorry but I have to voice this somewhere;
I'm again at a stage where I  **hate**  Xemacs :

On startup it ``kindly'' offers to migrate my ~/.emacs to
~/.xemacs/... --- which if I allowed it would completely break
my GNU emacs initialization.

Now that I told Xemacs *not* to migrate it, I found that it
``nicely'' edited my ~/.emacs  
**REPLACING** all my carefully collected customized variables
and faces by the simple three lines

(custom-set-variables
 '(load-home-init-file t t))
(custom-set-faces)

I found out when my dealing with attachments in e-mails wasn't
behaving as it used, and other "funny" things happened
-----------> AAAAAAAAAAAAAAAAAAARGH!

	     (luckily I found a backup of ~/.emacs)

In such moments I'm close to proposing to drop all support for
Xemacs...   but luckily these moments pass ... so you Xemacs
lovers don't have to be afraid yet.

Martin

______________________________________________
ESS-help <at> stat.math.ethz.ch mailing list
(Continue reading)

Permalink | Reply | 2 comments |
headers
Stephen Eglen | 1 Sep 2005 11:50
Picon
Picon
Favicon

[ESS] Xemacs again {was "file name completion again"}


 > In such moments I'm close to proposing to drop all support for
 > Xemacs...   but luckily these moments pass ... so you Xemacs
 > lovers don't have to be afraid yet.

I agree with you there - but I feel a bit more strongly, and my
moments do not pass!  I think the more people get behind Emacs, the
sooner XEmacs will become a thing of the past.  I spent a lot of time
cursing at the differences between Emacs and XEmacs.

I realise XEmacs provides better support for Windows, but then I'm no
fan of Windows either!

Stephen

______________________________________________
ESS-help <at> stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help
Permalink | Reply | 0 comments |
headers
Jean Eid | 1 Sep 2005 14:48
Picon
Picon
Favicon

[ESS] file-name completion resolved under Xemacs

Hi Martin, Stephen, and David

It was at the end an xemacs rather than  ESS problem. In particular the
compiled version of comint (comint.elc) in
/usr/share/xemacs21/xemacs-packages/lisp/xemacs-base/comint.elc

I downloaded the version comint.el from

http://tecfa.unige.ch/pub/software/unix/mud-clients/comint.el.emacs19

and poked around a bit in it. After some hours it seems that when I
byte-compile the file it just screws it up for some reason. However, if
instead I (load-file ...) it seems to work ok.

So maybe you can add this to the installation section of ESS README file.
just do not use (require ..) and use (load-file ..) after downloading it.

I do not know why the original comint.elc is having problems. But for now
this seems like the easiest solution.

Jean

______________________________________________
ESS-help <at> stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help
Permalink | Reply | 0 comments |
headers
Rodney Sparapani | 1 Sep 2005 16:49
Picon
Gravatar

Re: [ESS] Xemacs again {was "file name completion again"}


> > In such moments I'm close to proposing to drop all support for
> > Xemacs...   but luckily these moments pass ... so you Xemacs
> > lovers don't have to be afraid yet.
>
>I agree with you there - but I feel a bit more strongly, and my
>moments do not pass!  I think the more people get behind Emacs, the
>sooner XEmacs will become a thing of the past.  I spent a lot of time
>cursing at the differences between Emacs and XEmacs.
>
>I realise XEmacs provides better support for Windows, but then I'm no
>fan of Windows either!
>
>Stephen
>  
>
Well, I would disagree slightly.  I'd say that Emacs is better on Windows
and Mac, but XEmacs rules on Unix.  The problem with Emacs is that you
have to install all of the modes that it doesn't come with.  We've seen that
installation is the back-breaker for many of an ESS user.  However, having
said that, the XEmacs package system is really not good for ESS.  We are
too often fixing bugs, creating new features, etc.  This makes for a painful
patching of the XEmacs package (from one repository to the other, a big
no-no in software development).  First, all of the patches have to be
"reviewed" by the XEmacs developers.  Then, even when the new ESS package
is "released" into the XEmacs package system, it is not really.  New
packages are beta-ed for several weeks if not longer, before release.  So,
my idea is to support XEmacs the same way we support Emacs, i.e. by
hand installation with or without the Makefile.  I've almost got it
working now, so that the Makefile will create an XEmacs package for
(Continue reading)

Permalink | Reply | 2 comments |
headers
Stephen Eglen | 1 Sep 2005 19:50
Picon
Picon
Favicon

Re: [ESS] pop-up-frames and opening windows


hi David,

 > But you should use it nevertheless, because that's the official API.  
 > info-goto-node is not, as developer notes (admittedly hidden in a  
 > comment) where the function is defined:
 > 
 > ;; Go to an Info node specified with a filename-and-nodename string
 > ;; of the sort that is found in pointers in nodes.
 > 
 > ;; Don't autoload this function: the correct entry point for other  
 > packages
 > ;; to use is `info'.  --Stef
 > ;; ;;;###autoload
 > (defun Info-goto-node (nodename &optional fork)

Ok, yes, I think it would be good then if we stuck to the API.

 > If you absolutely insist on splitting the window, here is an option  
 > that might do the job in a more compliant way:
 > 
 > (defun ess-goto-info (node)
 >     "Display node NODE from ess-mode info."
 >     (require 'info)
 >     (let ((pop-up-windows t))
 >         (info (concat "(ess)" node))))

If we add this, does it solve your problem when you have everything in
its own frame?
(Continue reading)

Permalink | Reply | 0 comments |

Gmane