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