R devel - Dec 2024 - Is it advisable/possible to default on Linux to an EDITOR that actually exists?

It looks like R has defaulted to using 'vi' for file.edit() (via
EDITOR since ~24 years ago[1][2].

These days I think it is much more common to write code from
lightweight environments, e.g. Docker files which strip all
unnecessary commands. On such machines, it is not safe to assume 'vi'
is installed, and it's not uncommon to encounter an issue like I did
again today[3] where you or some other tool call file.edit() directly
or implicitly and hit a clunky error.

Is there something better to do here? A "standard" Linux distribution
will come with vi, emacs, nano, probably many others. Should
`file.edit()` iterate over an ordered list to find the first that
exists? Should it at least error if
(!nzchar(Sys.which(Sys.getenv("EDITOR"))))?

Mike C

PS I do see some somewhat recent discussion[4] on EDITOR but it
focuses on the EDITOR default in non-interactive() sessions.

[1]
https://github.com/r-devel/r-svn/commit/b294ee2cef3d9292d578b062b80d59f372cf34b2#diff-1cbaac4768fd110525ba9086cb7a684aaf2c6555389c5446c913effbfec90c85
[2]
https://github.com/r-devel/r-svn/blob/71a2e968f4453858aadc1531a3774c011a6f9f49/doc/NEWS.0#L140-L141
[3] https://github.com/r-lib/usethis/pull/2088
[4] https://stat.ethz.ch/pipermail/r-devel/2023-July/082720.html

Michael,

This looks rather like a 'compile-time versus run-time' question to me.
If
you look at etc/Renviron.in in the R sources you see a number of choices,
some of them with configure-time determined values (which I tend to override
with values for the Debian package).

For 'EDIT' it is

   ## Default editor
   EDITOR=${EDITOR-${VISUAL-vi}}

giving us two env vars to override eg in 'degenerate' situations such as
the
forcefully minimized docker setup without other commands.

Otherwise, a generalization that would be possible might be to do something
similar to 'R CMD javareconf' to allow a later run-time call to affect
the
encoded values---which would then be read at startup.  On the other hand,
environment variables already give customization so ...

Linux distributions can also have their mechanism. For example, Debian has
/etc/alternatives which for 'editor' defaults to nano even when vi,
emacs,
mg, atom, code, ... are installed.  So you could also have the environment
variable EDITOR point to a script you control which then runs over possible
alternatives.

As for the conjecture 'it is much more common to write code from ...'  I
would love to see some empirics across a properly surveyed R user base. The
love of some power users for codespaces / devcontainers notwithstanding,
'the
most common' environment for writing R code is likely still what it always
was, a single windows desktop.

Anyway, thanks for raising this. I can look into making the Debian (and hence
Ubuntu) package switch to 'editor' over the vi fallback. 

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

Michael,

vi is the only editor that is part of the POSIX standard. Embedded systems have
built-in support only for vi (e.g., busybox) so if a system has any editor
support at all it is  most likely to be vi - it is ubiquitous which is why
it's the most logical default. (FWIW no distributions I know come with emacs
by default because it's too heavy, but all come with vi).

If you use stripped-down images (obviously no longer standards-compliant) then
you don't have any editor so it's moot. If you have preference for
another editor then you should set EDITOR or VISUAL - it's just a default
when neither the system nor user doesn't declare their preference. I
don't think R should be fishing for random programs that may or may not be
editors at run-time.

Cheers,
Simon

> On Dec 11, 2024, at 5:08 AM, Michael Chirico <michaelchirico4 at
gmail.com> wrote:
> 
> It looks like R has defaulted to using 'vi' for file.edit() (via
> EDITOR since ~24 years ago[1][2].
> 
> These days I think it is much more common to write code from
> lightweight environments, e.g. Docker files which strip all
> unnecessary commands. On such machines, it is not safe to assume
'vi'
> is installed, and it's not uncommon to encounter an issue like I did
> again today[3] where you or some other tool call file.edit() directly
> or implicitly and hit a clunky error.
> 
> Is there something better to do here? A "standard" Linux
distribution
> will come with vi, emacs, nano, probably many others. Should
> `file.edit()` iterate over an ordered list to find the first that
> exists? Should it at least error if
> (!nzchar(Sys.which(Sys.getenv("EDITOR"))))?
> 
> Mike C
> 
> PS I do see some somewhat recent discussion[4] on EDITOR but it
> focuses on the EDITOR default in non-interactive() sessions.
> 
> [1]
https://github.com/r-devel/r-svn/commit/b294ee2cef3d9292d578b062b80d59f372cf34b2#diff-1cbaac4768fd110525ba9086cb7a684aaf2c6555389c5446c913effbfec90c85
> [2]
https://github.com/r-devel/r-svn/blob/71a2e968f4453858aadc1531a3774c011a6f9f49/doc/NEWS.0#L140-L141
> [3] https://github.com/r-lib/usethis/pull/2088
> [4] https://stat.ethz.ch/pipermail/r-devel/2023-July/082720.html
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>