R SIG Debian - Dec 2021 - Open a text file with vi/vim in another Terminal

To Dirk and Ivan,

Thank you for your suggestions. Let's give more details. The idea is to 
insert the code in a function and then in a (private) package. We have 
to rely on the default editors provided by the OS to R and cannot invent 
a new editor, as R CMD check could fail on exotic platforms. We cannot 
assume that Geany, even nano, is available everywhere. Something like:

switch(Sys.info()[["sysname"]],
   "Windows" = switch(type,
     "pager"  = file.show(filename, header = filename, title =
"Pager"),
     "editor" = file.edit(filename, title = filename, fileEncoding =
""),
     shell.exec(filename)
     ),
   "Darwin"  =  switch(type,
     "pager"  = file.show(filename, header = filename, title =
"Pager"),
     #?"editor" = system2(getOption("editor"), filename,
wait = FALSE),
     system2("open", filename, wait = FALSE)
     ),
   switch(type,
     "pager" = file.show(filename, header = filename, title =
"Pager"),
     #?"editor" = system2(getOption("editor"), filename,
wait = FALSE),
     system2("xdg-open", filename, wait = FALSE)
     )
)

The instruction for the pager

   file.show(filename, header = filename, title = "Pager")

launchs the pager on Windows, Debian and macOS and it works fine on 
these 3 platforms. On Debian, it is within the R console and it 
terminates properly and gives the hand back to R.

The instruction for the text editor

  system2(getOption("editor"), fileREP, wait = FALSE)

works fine on Windows (it opens Notepad.exe, or Notepad++.exe in my 
Rprofile.site) but not on Unix. I assumed there was something similar on 
Unix (You have understood that I am not a Unix specialist). R includes a 
few library statically compiled. Could R incorporate a decent text 
editor on Unix Oses?


Dirk, I will watch your videos. Thank you for these links. I discover them.

Patrice



Le 17/12/2021 ? 20:20, Dirk Eddelbuettel a ?crit :
Patrice,
Also: if you are on a terminal, have you discovered tmux / byobu yet to 
multiplex? It is fairly magic as you can just open as many 'sessions 
with the outer sessions', the sessions persist and many more advantages. 
  I talked a little about this (with short videos) last year
    https://dirk.eddelbuettel.com/blog/code/t4/
in episodes 4, 5 and 6.
Dirk


Le 17/12/2021 ? 19:46, Ivan Krylov a ?crit :
    system2(getOption("editor"), fileREP, wait = FALSE)
Starting a new terminal is somewhat hard, but the shortest path to
getting this particular command working would be options(editor 'gvim').
It's almost like Vim in a terminal, plus a few features useful
in a windowed interface.
Note that gvim backgrounds itself by default, so this would break
edit() and file.edit(): since the GVim process started by R terminates
almost immediately after spawning a child to do the rest of the work, R
decides that the editing session is done. Unfortunately, it's hard to
make R's edit() pass the -f flag to gvim to prevent it from doing that,
but a trivial shell script wrapper could be used for that purpose:
 > #!/bin/sh
 > exec gvim -f "$@"

On 17 December 2021 at 21:13, Patrice Kiener wrote:
| Thank you for your suggestions. Let's give more details. The idea is to 
| insert the code in a function and then in a (private) package. We have 
| to rely on the default editors provided by the OS to R and cannot invent 
| a new editor, as R CMD check could fail on exotic platforms. We cannot 
| assume that Geany, even nano, is available everywhere.

But you can (and likely: should !!) test for their presence via
Sys.which(prog):

    > Sys.which("vi")
               vi 
    "/usr/bin/vi" 
    > Sys.which("notExisting")
    notExisting 
             "" 
    > 

In short, you have no guarantee that what is EDITOR is actually sane!

| The instruction for the text editor
| 
|   system2(getOption("editor"), fileREP, wait = FALSE)
| 
| works fine on Windows (it opens Notepad.exe, or Notepad++.exe in my 
| Rprofile.site) but not on Unix. I assumed there was something similar on 
| Unix (You have understood that I am not a Unix specialist). R includes a 

As Ivan was hinted this gets more complicated with apps being launched
synchronousy or asynchronously.

What you are after is actually a hard problem, portably, across OSs.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

On Fri, 17 Dec 2021 21:13:12 +0100
Patrice Kiener <patrice.kiener at inmodelia.com> wrote:
> The instruction for the text editor
> 
>   system2(getOption("editor"), fileREP, wait = FALSE)
> 
> works fine on Windows (it opens Notepad.exe, or Notepad++.exe in my 
> Rprofile.site) but not on Unix. 
"A file.edit() but with the editor running in parallel with the R
session" is a hard problem.

Suppose that the user is running an R session on a server without a
graphical display over remote command line. The user is probably
running a graphical session with different windows, but R is unaware of
it; it's only got one text terminal. What should our hypothetical
file.edit.in.background() do in this case? It's fair to
stopifnot(interactive()), but this counts as an interactive session. In
theory, R could bundle a terminal multiplexer like tmux, split the
terminal window in half and emulate a smaller terminal for the editor
to run in, but there's no such functionality (or plans to implement it).

On Debian, there's the /usr/bin/x-terminal-emulator symlink (typically
present, but not 100% guaranteed to exist) pointing to _a_ graphical
terminal emulator (if you can assume a running graphical session), but
different terminal emulators take subtly different options to run
command lines inside them. For example, xterm runs the rest of the
command line after -e, while xfce4-terminal takes only one argument to
-e but the rest of the command line after -x. The result is that you
can't reliably pass arguments to the command you intend to launch. This
*could* be worked around by writing a temporary shell script in /tmp,
but the resulting solution accumulates too many moving parts to inspire
any confidence and doesn't work on other distros or macOS.

Besides, the user could plausibly prefer a text editor with a GUI when
running a graphical session. Can you ask your users to specify an
editor to run in the background? They could say it's 'emacs',
c('xterm',
'-e', 'joe'), c('xfce4-terminal', '-x',
'ed') or anything else.

What do you intend to do with the file being edited by the user?
Perhaps there's some other way to achieve the goal.

(Not sure whether it's a better question for R-help or R-pkg-devel.)

-- 
Best regards,
Ivan