Re: [ESS] How can one tell rlang not to mess up R session in ESS ?
On Tue, 14 Nov 2023 at 11:46, Dirk Eddelbuettel via ESS-help
wrote:
>
>
> On 14 November 2023 at 17:22, Lionel Henry wrote:
> | Worth noting I'm using `xterm-color` instead of `ansi-color` in my
> | comint buffers. IIRC the latter (which is builtin) didn't support some
> | features. Not sure if that could explain the bad behaviour you've
> | observed.
>
> I was also thinking cli could take advantage of TERM. In ESS under x11 and on
> the terminal I seem to see
>
> > Sys.getenv("TERM")
> [1] "dumb"
> >
>
> so I guess ESS (or Emacs?) overrides because I otherwise settled on TERM and
> BYOBY_TERM as screen-256color which is decent setting for Nord.
>
> Back to rlang and cli messing up sessions they maybe should leave alone:
> would the team consider not asking the user to set NO_COLOR and rather
> inspect the terminal info and refraining from damaging working setups?
Not that I know a lot about this, but...
Despite Sys.getenv("TERM") being "dumb", Emacs can actually handle
ANSI color codes, and, e.g., I get a nice red cross sign with
> cli::cli_alert_danger("stop")
✖ stop
(which is no longer red when I copy-and-paste).
Are you suggesting that we should not be getting that by default? I
know I can still probably force it by setting options(cli.ansi = TRUE,
cli.num_colors = 256) etc.
Best,
-Deepayan
>
> Best, Dirk
>
> --
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
> __
> ESS-help@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/ess-help
__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help
Re: [ESS] [OT] Best Practices Emacs / ESS Mini-Webinars
On Sat, Jan 2, 2021 at 1:51 AM Stephen Bond wrote: > > Happy New Year, > > I wrote a short draft of installing ESS through melpa as I favor Prof. > Sarkar's suggestion to have a readable version: > https://boring2004.blogspot.com/2021/01/ess.html > This is not editable, but we are still waiting for the final tool. > I hope I am saving some time for the more advanced Emacs/Lisp people; > let me know if I should stay quiet. > > Melpa should be the preferred option as installing by double clicking > on an executable is the RStudio way of doing things and does not lead > to learning Emacs. This looks great. A couple of suggestions along the same lines as Greg, with the view of giving alternatives to those who prefer typing: In step 2, follow "Evaluate last S-expression from Emacs-Lisp menu" with "(keyboard shortcut C-x C-e, or M-x eval-last-sexp)" For steps 3 and 4, point to https://polymode.github.io/installation/ for other alternatives. [Where I suppose (unless (package-installed-p 'polymode) (package-install 'poly-markdown)) is a typo and should be (unless (package-installed-p 'poly-markdown) (package-install 'poly-markdown)) instead?] 3. You define (rmd-mode) but don't use it. I assume it is to change mode explicitly; is it ever useful? You should explain why it could be. BTW, an explicit (require 'ess-site) does not seem to be required (at least for Emacs 27.1). Not sure why. Best, -Deepayan > Cheers > Stephen > > > On Tue, 2020-12-29 at 19:47 +0530, Deepayan Sarkar wrote: > > On Tue, Dec 29, 2020 at 4:07 AM Dirk Eddelbuettel via ESS-help > > wrote: > > > > > > Hi Stephen, > > > > > > On 28 December 2020 at 16:23, Stephen Bond wrote: > > > > I have been struggling with trying to follow the steps in > > > > https://r-pkgs.org/ and the best thing would be to have a similar > > > > online book showing the steps with ESS. the Hadley book is > > > > chained to > > > > RStudio and they assume everybody uses RStudio, so many examples > > > > do not > > > > work as expected when run inside ESS/emacs. there is also some > > > > > > Let's step back. Some of us have been building packages for longer > > > than > > > either the book or RStudio existed. The canonical reference is > > > still WRE. > > > > > > FWIW I distilled (short) command-line wrappers off it too, so I use > > >build.r # create a tar.gz > > >rcc.r# check the tar.gz (using rcmdcheck::rcmdcheck) > > >check.r # check the tar.gz (more like R CMD check) > > >install.r# install it > > > and so on _all the time_ often in a bash shell / tmux session. The > > > command > > > are also all callable from Emacs/ESS as commands and e.g. I always > > > do > > > compile-command (i.e. C-x C-c, then calling render.r) to process > > > markdown. > > > For package building many other people also use devtools; I > > > understand that > > > is now integrated with ESS and would be new to me too. There are > > > (as always) > > > many ways to go about this. > > > > > > > completely undocumented menus like (Select package for > > > > evaluation) not > > > > mentioned on the official ESS page: > > > > https://ess.r-project.org/Manual/ess.html > > > > I am willing to help and donate time if you can start with such > > > > an > > > > online book. > > > > > > AFAIK nobody promised a book. We suggest(ed) and still work on a > > > series of > > > *short* and *focused* intros to topics. The current list is at > > > http://collabedit.com/537yq > > > > > > Package building is but one topic, but it would be great if you > > > could help > > > with this. > > > > > > > Cheers, really happy this may be happening. > > > > > > Yes. Let's see if we can pull this off. > > > > I'm hoping to learn a lot from this. > > > > Although it's not the immediate goal, I think it would be good to > > eventually have a readable version of the topics covered in the > > webinars, sort of in-between a book and the docs. I will be happy to > > help with that effort. > > > > Best, > > -Deepayan > > > > > Dirk > > > > > > -- > > > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > > > > > __ > > > ESS-help@r-project.org mailing list > > > https://stat.ethz.ch/mailman/listinfo/ess-help > __ ESS-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/ess-help
Re: [ESS] [OT] Best Practices Emacs / ESS Mini-Webinars
On Tue, Dec 29, 2020 at 4:07 AM Dirk Eddelbuettel via ESS-help wrote: > > > Hi Stephen, > > On 28 December 2020 at 16:23, Stephen Bond wrote: > | I have been struggling with trying to follow the steps in > | https://r-pkgs.org/ and the best thing would be to have a similar > | online book showing the steps with ESS. the Hadley book is chained to > | RStudio and they assume everybody uses RStudio, so many examples do not > | work as expected when run inside ESS/emacs. there is also some > > Let's step back. Some of us have been building packages for longer than > either the book or RStudio existed. The canonical reference is still WRE. > > FWIW I distilled (short) command-line wrappers off it too, so I use >build.r # create a tar.gz >rcc.r# check the tar.gz (using rcmdcheck::rcmdcheck) >check.r # check the tar.gz (more like R CMD check) >install.r# install it > and so on _all the time_ often in a bash shell / tmux session. The command > are also all callable from Emacs/ESS as commands and e.g. I always do > compile-command (i.e. C-x C-c, then calling render.r) to process markdown. > For package building many other people also use devtools; I understand that > is now integrated with ESS and would be new to me too. There are (as always) > many ways to go about this. > > | completely undocumented menus like (Select package for evaluation) not > | mentioned on the official ESS page: > | https://ess.r-project.org/Manual/ess.html > | I am willing to help and donate time if you can start with such an > | online book. > > AFAIK nobody promised a book. We suggest(ed) and still work on a series of > *short* and *focused* intros to topics. The current list is at > http://collabedit.com/537yq > > Package building is but one topic, but it would be great if you could help > with this. > > | Cheers, really happy this may be happening. > > Yes. Let's see if we can pull this off. I'm hoping to learn a lot from this. Although it's not the immediate goal, I think it would be good to eventually have a readable version of the topics covered in the webinars, sort of in-between a book and the docs. I will be happy to help with that effort. Best, -Deepayan > Dirk > > -- > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > __ > ESS-help@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/ess-help __ ESS-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/ess-help
[ESS] Support for more R completion features in ESS
Dear All,
Background: Some new experimental completion facilities in R cannot be
currently used in ESS. I was able to come up with small hacks to
enable them, but in the case of company-mode I needed to disable
caching, which is probably not a good idea. I was wondering if it
would make sense to at least have the option of activating these
features through a user-customizable variable.
New completion features:
1. The first one has been around for a while, and is activated by setting
rc.settings(fuzzy = TRUE)
This offers completions like
getany -> getAnywhere
library_dynam -> library.dynam
This is not "fuzzy" completion in the sense used in the Emacs world,
but rather what company-mode refers to as non-prefix completion. The
first example can be made to work (for both built-in completion and
company-mode) by simply setting
(setq completion-ignore-case t)
The second one is (I think) not possible at all with the built-in
completion, but is in principle supported by company-mode.
2. The other new feature, potentially much more useful, is the
possibility of allowing user-provided completion functions to
supplement the built-in completions provided by R. This requires a
very recent R-devel (>= r79644). A simple prototype showing how this
feature might be useful is available here:
https://raw.githubusercontent.com/deepayan/misc/master/experiments/custom-completions.R
After sourcing this file, the following completions should work with
the readline interface:
(a) with(faithful, erup -> eruptions
(b) with(faithful, mean(erup -> eruptions
(c) faithful |> transform(wroot = sqrt(waiting)) |> with(wro -> wroot
Changes required in ESS:
1. The "default" completion, which is what I use most of the time,
actually needs very little change. It already supports (a), and (b)
and (c) will work with the following change here:
https://github.com/emacs-ess/ESS/blob/master/lisp/ess-r-completion.el#L151
- (let* ((funstart (cdr (ess--fn-name-start)))
- (completions (ess-r-get-rcompletions funstart))
+ (let* ((completions (ess-r-get-rcompletions))
(essentially let R figure out the starting point).
This should have minimal performance impact.
2. company-mode
This is too complicated for me to understand in any depth, but a
minimal change that seems to support both user-supplied completion as
well as non-prefix completion is in the company-R-objects backend:
https://github.com/emacs-ess/ESS/blob/master/lisp/ess-r-completion.el#L359
(candidates (let ((proc (ess-get-next-available-process)))
(when proc
-(with-current-buffer (process-buffer proc)
- (all-completions arg
(ess--get-cached-completions arg))
+(cdr (ess-r-get-rcompletions)
Obviously this is not a good idea always, but maybe this behaviour
could be customizable (with a proper implementation).
Apart from not using the cache, this is also doing something weird at
the beginning of a function. Compare trying to complete:
with(faithful, mean(wait
with(faithful, mean(
with the cursor just after "mean(" in both cases.
But I don't think this is due to my change. Even without the change, I
get a bunch of spurious completions that seem to come from my TAGS
file.
Regards,
-Deepayan
__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help
