[ESS] Emacs finding "R" on Windows {was "Release of ESS 5.3.5"}

[Martin Maechler]

[Excuse for "top-answering"]

Thank you, Rich; excellent you found the problem so quickly!

I think it's a good idea to abstract things along your proposal :

1) Make use of  (defcustom ess-program-files ...) in ess-cust.el

   {I've modified your spelling to a more typical Emacs one ..
   
2) provide a (defun w32-short-file-name  (file)  ....)
   function that works in GNU emacs,
   and maybe made to work in Xemacs.
   I think as proviso, in Xemacs, it should simply return 'file'
   unchanged.

Note that I've also committed an   essd-r.el   which works in Windows
(for me), temporarily reverting to "c:/progra~1/";
the main commit reason is a nicely simplified 
(defun ess-find-rterm .) which now does use ess-r-versions {as a
comment had always said we should}.

Martin


>>>>> "RMH" == Richard M Heiberger <rmh at temple.edu>
>>>>>     on Fri, 24 Aug 2007 13:06:20 -0400 (EDT) writes:

    RMH> I need guidance on the fix.
    RMH> The new statement
    RMH> (getenv "ProgramFiles")
    RMH> in the English locale returns
    RMH> "C:\\Program Files"
    RMH> which has an embedded blank and therefore doesn't work in many emacs commands.
    RMH> That is why I had hard-wired the "c:/progra~1".

    RMH> The embedded blank breaks all sorts of code, specifically in this
    RMH> case ess-r-version-date

    RMH> (ess-r-version-date "c:/Program Files/R/R-2.5.1/bin/Rterm.exe")
    RMH> ("-1" . "c:/Program Files/R/R-2.5.1/bin/Rterm.exe")

    RMH> (getenv "ProgramFiles")
    RMH> "C:\\Program Files"

    RMH> (w32-short-file-name (getenv "ProgramFiles") )
    RMH> "c:/PROGRA~1"

    RMH> (ess-r-version-date (concat (getenv "ProgramFiles") "\\R/R-2.5.1/bin/Rterm.exe"))
    RMH> ("-1" . "C:\\Program Files\\R/R-2.5.1/bin/Rterm.exe")

    RMH> (ess-r-version-date "c:/Progra~1/R/R-2.5.1/bin/Rterm.exe")
    RMH> ("2007-08-01" . "c:/Progra~1/R/R-2.5.1/bin/Rterm.exe")

    RMH> (ess-r-version-date (w32-short-file-name "c:/Program Files/R/R-2.5.1/bin/Rterm.exe"))
    RMH> ("2007-08-01" . "c:/PROGRA~1/R/R-25~1.1/bin/Rterm.exe")

    RMH> (ess-r-version-date (concat (w32-short-file-name (getenv "ProgramFiles")) "\\R/R-
    RMH> 2.5.1/bin/Rterm.exe"))
    RMH> ("2007-08-01" . "c:/PROGRA~1\\R/R-2.5.1/bin/Rterm.exe")


    RMH> The fix is to introduce the w32-short-file-name function.
    RMH> This works correctly in GNU emacs.  I think from past discussion that it
    RMH> doesn't work in Xemacs.

    RMH> I would do it with the definition in ess-cust.el

    RMH> (defcustom ess-ProgramFiles
    RMH> "Safe (no embedded blanks) 8.3 name that works across internationalization."
    RMH> (if ess-microsoft-p
    RMH> (w32-short-file-name (getenv "ProgramFiles"))
    RMH> nil))

    RMH> one possible way to get around the missing function in xemacs is

    RMH> (defcustom ess-ProgramFiles
    RMH> "Safe (no embedded blanks) 8.3 name that works across internationalization."
    RMH> (if ess-microsoft-p
    RMH> (if (featurep 'xemacs)
    RMH> (getenv "ProgramFiles")
    RMH> (w32-short-file-name (getenv "ProgramFiles")))
    RMH> nil))


    RMH> this doesn't fix the xemacs problem.  it is just keeps it from breaking.