Using compilation-mode buffers for devtools commands

[atheriel]

At the moment when you use the various ess-r-devtools-* commands, these will run in the linked R session. It makes a lot of sense to me for processes like running tests, building documentation, and running package checks to happen in isolated environments/sessions, and Emacs already has nice tooling for this using compilation-mode. As a bonus, we'd get things like jumping to errors in files automatically, since this is provided by compilation-mode.

Is there any interest in having some sort of flag -- say ess-r-devtools-use-compile -- that would run these commands in a compile buffer instead? I'd be happy to do some of the implementation work, if so. Where it makes sense, we could also ensure that packages are reloaded in the linked session.

[lionel-]

I think that would make sense. Certainly worth some experimenting!

[lionel-]

Also might be nice to have a test command that sources files in tests. At the moment we only have an interface around testthat which is too specific for ESS.

[vspinu]

I actually don't see much added value in this. It would complicate the code for not much benefit.

It makes a lot of sense to me for processes like running tests, building documentation, and running package checks to happen in isolated environments/sessions,

I think the insulation that devtools provide is already pretty good. If we add compilation style package methods it would require adding ways to control which R is selected. I might want to run those in R, R-dev, R old rel etc. With connected R processes this is easy (and will be easier in the future); just re-associate with the inferior in which you want to run the test.

As a bonus, we'd get things like jumping to errors in files automatically, since this is provided by compilation-mode.

Compilation mode is activated in iESS. Error tracking should work better in iESS than in generic compilation mode because it targets R specific errors. Try M-g n/p when you are in a script buffer and get errors.

[lionel-]

I think the insulation that devtools provide is already pretty good.

I'd say there is currently no insulation? It makes sense to run check / tests in a separate process just like RStudio does.

[lionel-]

oops of course R CMD check is run in a separate process, I was thinking about tests.

[vspinu]

I was thinking about tests.

I actually had a recent prototyping use case when I did not want that at all. I was writing a new package and was piling tests on the fly with the help of other packages and add hock utilities.

install and load_all don't make sense in other session because they reload current package. What is left is indeed test and maybe rhub check. The latter could be quite useful actually because it doesn't block the session. But I am not even sure that crayon and progress bars will display correctly in compilation buffers. Those are not intended for interactive use.

So, again, my hunch is that this means too much work for little benefit. At least right now we have a coherent interface, everything is executed in the same place.

[lionel-]

I think you're right to be prudent. Also if compilation occurs in a different process this poses the question of reloading/restoring the relevant interactive sessions, which might not be straightforward.

[atheriel]

I think your caution is reasonable, and to be clear I'm not suggesting we implement this for commands that do not make sense, e.g. load_all(). But I do think it would be nice to have potentially expensive operations (testing, compilation, checking, rhub stuff, etc) run outside of the current session. (I would quite like to continue working while my test suite is running, for example.) It would also faciliate things like running package checks without opening an R session at all, and checking test behaviour in non-interactive mode (although this already happens with check() I believe).

Compilation mode is activated in iESS. Error tracking should work better in iESS than in generic compilation mode because it targets R specific errors. Try M-g n/p when you are in a script buffer and get errors.

I had no idea about this! Perhaps we could get nice compilation-mode features even more easily by leveraging this existing code.

So all things considered, should I try and put together something for submission to ESS? As a reasonable alternative, I can put together a standalone package providing some of this behaviour and put it up on MELPA to see if there is interest.

[atheriel]

(As a side note on the advantage of running tests outside the linked R session: at the moment, when my tests are running neither completion nor eldoc work.)

[lionel-]

I think it's worth experimenting with, if you have the time to work on that. An outside package seems the best fit for this at the moment.

at the moment, when my tests are running neither completion nor eldoc work

Oh yeah I've been bummed not being able to srcref-jump while compiling!

[vspinu]

expensive operations (testing, compilation, checking, rhub stuff, etc)

I think for testing, compilation, checking(?) you won't be touching currently processed files before the task finished anyways. IMO, the real benefit is for rhub stuff which takes long and I often want to run several such operations (usually simultaneously with CMD check).

An outside package seems the best fit for this at the moment.

We can also start with a simple PR and if we find it too heavy handed then converting it to an outside package should be trivial.

If I am not mistaken then the following should be enough: a simple mode inheriting from compilation mode with our error regexressions installed, a display function which would pop up this compilation buffer without covering current buffer or iESS, a custom variable (a list of functions for which to externalize?), small incision in each of the devtools functions for which this functionality makes sens, and finally store current command as process local variable (if my iESS is R-devel, I want to test in R-devel).

Some of the above could be useful in a other places actually (notably the inferior-ess-reload). We could also have a new command (like ess-load-file-batch) which would execute current file outside of ESS session (there is such functionality in ess-sas I believe).