[ESS] ESS process on Docker containers and enabing Flymake

[Martin Maechler]

>>>>> Dirk Eddelbuettel via ESS-help 
>>>>>     on Fri, 21 Feb 2020 15:01:32 -0600 writes:

    > On 21 February 2020 at 12:50, Alex Branham wrote: | We do
    > just use the package if it's installed. No demanding
    > anywhere.

    > Perfect, thanks for clarifying.

    > Now, given that the package may at times be installed as a
    > side-effect via the Depends: of another package, it might
    > be worth considering if use should also require an opt-in
    > in ~/.emacs.

That's where I agree with you, Dirk,  but typically the
majority of ESS core have disagreed saying they want new features
to be *on* by default, as they would not be seen and used enough
otherwise ... and that's a valid point of view (and matter of taste).

I think we should always have 3 to 4 (of 4) possibilities in
such  2 x 2 situations: 

  flymake_desired (yes/no)  x  lintr_installed (yes/no)

And one should often discuss / consider what happens in "the 4th case":

Here,
1) the user should have a simple customizable option to turn
   flymake on and off  (and AFAIK, we have that option)

2) "3 or 4 options": I'd vote for 3 here, in this sense:
  The first 3 options are obvious: if flymake is off, nothing is
  used (lintr there or not); if flymake is on and lintr is
  installed, things "get activated".
  
  4-th case however: If lintr is not installed and flymake is
  on, I think the user should get a not/message/warning  (once
  per session?) that flymake needs the CRAN R package lintr to
  work sensibly (and not try have flymake work "halfways" with
  code that is typically never used/tested by the developers themselves).
  But then *not* install it automatically -- I think differently in
  spirit than Rstudio which installs all kinds of crafts.. which
  is probably fine for Rstudio and its user base, but I think is
  not ok for ESS and its different user base) 

Martin