>>>>> 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
______________________________________________
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help
