Re: [ESS] Can't find documentation for function
Hi, Did you type: library(mypac) first, before trying ?foo? The behavior suggests that the package is not currently loaded in the search path, hence the error. When you use ?mypac::foo, that explicitly tells R that you want the help for the function which is located in mypac and looks for the file there. Without the package prefix, it only looks in the current search path, and thus does not find the package there. Regards, Marc Schwartz On September 18, 2022 at 4:54:05 AM, Haris Fawad via ESS-help (ess-help@r-project.org (mailto:ess-help@r-project.org)) wrote: > Hi, > > I get the following error when I try to open the help file on a function > 'mypac::foo'. > > "ess-r-help--build-help-command--unqualified: Can’t find documentation for > ‘foo’". > > I get the error when I type '?foo', but not when I type '?mypac::foo'. > Indeed, the file 'man/foo.Rd' exists, after I run 'devtools::document()'. > > I don't get the error when I request documentation for a standard > R-function, such as '?sum'. > > [[alternative HTML version deleted]] > > __ > 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] [External] Emacs 28.1 Released
Hi, Vincent, you might want to connect with David Caldwell on the issues that you are facing. I noted that on this page: https://emacsformacosx.com/about he notes that there are changes to the app launcher that may be relevant to what you are experiencing. Whether there is an intentional change in behavior, or possible bug, may be something to evaluate. If people find value in your distributions, given ease of use considerations, it seems to be worthwhile to continue to support them. For Rich, note that since last month, with the Emacs 2.7.2 release, the macOS Emacs binaries from David Caldwell are universal, supporting Apple silicon. More generally, for some time, even with Emacs 26.x, I had been using the melpa based ESS code, rather than the 18.10.2 release code, along with some tweaks in my .emacs to try to workaround some of the ESS issues that became evident with Emacs 27.x. ESS 18.10.2 is now over 3 years old, which is circa Emacs 26.1. Regards, Marc On April 8, 2022 at 11:44:50 AM, Richard M. Heiberger via ESS-help (ess-help@r-project.org (mailto:ess-help@r-project.org)) wrote: > Thank you Vincent for your distribution. Please keep it up. > > I used to do my own setup until xxx time ago and have used yours (both > Windows and Mac) since. > I override your some of your personalizations with my own preferences and it > works. > > When I switched my Mac to the M1 last year I had some difficulties with the > Rosetta emulation of Emacs itself, > so Simon Urbanek was kind enough to give me a native compilation of Emacs for > the M1. > I substituted that into what was otherwise your distribution and have been > quite happy. > > For the future, I am very happy not to deal directly with the issues you > mention in this email. > > Rich > > > > On Apr 08, 2022, at 11:11, Vincent Goulet via ESS-help wrote: > > > > Hi, > > > > Thanks Marc (and Richard L through GitLab) for the heads up. > > > > I tried building my Emacs distribution (on macOS) and stumbled on a weird > > problem: the 'site-lisp' directory within the application (e.g. > > /Applications/Emacs/Emacs.app/Contents/Resources/site-lisp) is not included > > in 'load-path' by default. Since this is where I bundle extensions, they > > are not recognized by Emacs. Perhaps the issue is upstream with David > > Caldwell's compilation; I'll have to check. I haven't yet taken the time to > > check on Windows. > > > > That said, ESS 18.10.2 does not compile with Emacs 28.1. It appears it is > > time to move forward to the development version of ESS. Those, like me, who > > prefer the good ol' stable ESS 18.10 are otherwise stuck on Emacs 27.x. ;-) > > > > Over the past few years, Emacs has moved consistently towards the ELPA > > package management system. Pretty much anyone able to use Emacs should now > > be able to install extensions easily. Org has deprecated the .zip > > distribution. Same for ESS de facto, at least currently. This leads me to > > question whether maintaining my distribution remains that much useful. Any > > thoughts? > > > > (For anyone not familiar, my Emacs distributions for macOS and Windows are > > stock GNU Emacs with ESS, AUCTeX, Org and some very minor configuration; > > see > > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fvigou3.gitlab.io%2Femacs-modified-macos=04%7C01%7Crmh%40temple.edu%7C718cb9b549244b1b20d008da197217ac%7C716e81efb52244738e3110bd02ccf6e5%7C0%7C0%7C637850275076056275%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=x2oucqjMgwCXDoZYZ694p%2F1WqIpY6g9nXmwr%2FrZRNB0%3D=0; > > > > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fvigou3.gitlab.io%2Femacs-modified-windows=04%7C01%7Crmh%40temple.edu%7C718cb9b549244b1b20d008da197217ac%7C716e81efb52244738e3110bd02ccf6e5%7C0%7C0%7C637850275076056275%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=vxCP4GVkm%2BiQVxEtx5RnJ7vGGzI%2BVQYa2oQNU8pzIvI%3D=0.) > > > > Best, > > > > v. > > > > Vincent Goulet > > Professeur titulaire > > École d'actuariat, Université Laval __ ESS-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/ess-help
[ESS] New Emacs 27.2 Released for macOS. Now Includes Apple Silicon support.
Hi All, Just an FYI that over the past few days, there were apparently some releases of Emacs 27.2 for macOS from: https://emacsformacosx.com The latest version is 27.2-2. These are the first releases since the 27.1 releases last August. The notes for the latest release from: https://emacsformacosx.com/about "Emacs builds as of 2021-03-26 include arm64 support (native Apple Silicon binaries). This includes the 27.2-1 release. Also starting now, gnutls, jansson, libffi and their dependencies are not built with Homebrew--it kept breaking old builds, and moving the "unsupported" bar forward much quickly than I wanted to. Now I have tighter control over the dependency build process at the expense of having to maintain a bunch of custom code to download, configure and make them." Regards, Marc Schwartz __ ESS-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/ess-help
Re: [ESS] ESS M-x R failing in a Windows installation
[Re-sending, as my prior reply seems to have been problematic] Hi, While not a Windows user, I am on macOS, I might point out the R Windows FAQ: https://cran.r-project.org/bin/windows/base/rw-FAQ.html which has a section on installation and customization. The relevant reference for the current version of R (4.0.4) and the registry is here: https://cran.r-project.org/bin/windows/base/rw-FAQ.html#Does-R-use-the-Registry_003f Note, that saving the version information to the registry is an optional part of the Windows install process. So, the presence of the registry keys is not guaranteed. There may be other relevant FAQ entries as well. Regards, Marc Schwartz Sparapani, Rodney via ESS-help wrote on 3/10/21 1:28 PM: Hi Gang: Just to follow-up on my own post. I see that the Windows Registry was discussed here in June of 2012 and March of 2013 (not 2004 which was my initial guess). But, whether that even exists in modern Windows, IDK! Here are the most relevant snippets… On 06/15/2012 12:06 PM, Rodney Sparapani wrote: Hi Paul: Very nice thoughts. I'm just going to react to this part which seems to be the most straightforward. I think you can call this from elisp. But, the problem with this code is that it doesn't work, does it? Here's what I get on Windows XP: H:\>reg query hklm\software\R-core\R /v InstallPath Error: The system was unable to find the specified registry key or value H:\>reg query hklm\software\wow6432Node\r-core\r /v InstallPath Error: The system was unable to find the specified registry key or value What do you see? Rodney Oh, hang on. For me, I need H:\>reg query hkcu\software\R-core\R /v InstallPath ! REG.EXE VERSION 3.0 HKEY_CURRENT_USER\software\R-core\R InstallPath REG_SZ C:\Documents and Settings\rsparapa.MCWCORP\My Documents\R\R-2.14.2 Ok, I think I see what is going on. You need to check each ROOTKEY [ HKLM | HKCU | HKCR | HKU | HKCC ] REG QUERY KeyName [/v ValueName | /ve] [/s] KeyName[\Machine\]FullKey Machine - Name of remote machine, omitting defaults to the current machine Only HKLM and HKU are available on remote machines FullKey - in the form of ROOTKEY\SubKey name ROOTKEY [ HKLM | HKCU | HKCR | HKU | HKCC ] SubKey - The full name of a registry key under the selected ROOTKEY /v query for a specific registry key ValueName - The name, under the selected Key, to query if omitted, all values under the Key are queried /ve query for the default value or empty value name /s queries all subkeys and values So, that code is incomplete. But, it could easily be adapted. Rodney On 03/28/2013 01:42 PM, Ross Boylan wrote: BTW, the path is available in the registry at HKEY_CURRENT_USER\Software\R-core\R\2.15.3 under InstallPath. There is also an entry that uses \R32\ instead of \R\ in the registry tree. Something like this has been suggested before (for example, see the discussion from June 15th). There are a few problems here: 1) Generally, ESS developers are not cracker-jack Windows developers. 2) There have been MAJOR changes in Windows especially 7 and 8 which may (or may not) be at issue here; for example, multi-user installs of ESS require omniscience. 3) it is not obvious to me why we need to search both the HKLM and HKCU root keys (and perhaps others as well?!?). So, I don't see this suggestion being acted on UNLESS there is a Windows developer lurking out there who wants to work on ESS. But, thanks anyways ;o) -- Rodney Sparapani, Associate Professor of Biostatistics Chair ISBA Section on Biostatistics and Pharmaceutical Statistics Institute for Health and Equity, Division of Biostatistics Medical College of Wisconsin, Milwaukee Campus [[alternative HTML version deleted]] __ 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] ESS M-x R failing in a Windows installation
__ ESS-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/ess-help
Re: [ESS] how to change default emacs behavior, upon running R code, from 2 side-by-by side frames to top-and-bottom frames?
Hi,
FWIW, I had the same issue at some point in the past, and I have the following
in my .emacs to change the behavior:
(add-to-list 'display-buffer-alist '("*R" (display-buffer-reuse-window
display-buffer-at-bottom)
(window-width . 0.5) (reusable-frames . nil)))
That was provided here on the list some time ago, and perhaps there is a more
recent incantation, if things have changed since then.
Regards,
Marc Schwartz
> On Nov 10, 2020, at 8:37 AM, Tyler Smith via ESS-help
> wrote:
>
> Christopher W. Ryan via ESS-help writes:
>
>> When I execute a line of R code, the R buffer opens up as expected, but
>> it opens in a frame adjacent to the frame containing my source buffer. I
>> would like it to open the R buffer as a frame below my source code,
>> rather than adjacent to it.Â
>>
>> How can I change the behavior from side-side frames to top-bottom frames?
>
> In base Emacs, this is controlled by the variables `split-height-threshold`
> and `split-width-threshold`. Setting split-height-threshold to a lower value
> (default is 80), and the width threshold to a higher value, will prioritize
> splitting top/bottom over right/left.
>
> The info node for this is: (emacs) Window Choice
>
> Best,
>
> Tyler
>
> --
> Tyler Smith
> plantarum.ca
>
> __
> 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] ess-eval-region Does Not Echo Highlighted Code Into the R Buffer?
Hi Martin, Thanks for your additional comments. Perhaps my use case is in the minority, but after almost 20 years of using R, primarily with Emacs/ESS on Windows, Linux and macOS over that time frame, I never found the prior default behavior to be an issue for me. Thus, I had no motivation to modify it. That being said, I fully understand the differing views that have led to the recent change in the default. Regards, Marc > On May 21, 2020, at 9:41 AM, Martin Maechler > wrote: > > I've also had 'nowait as my personal default for many years.I > find it also more appropriate when showing ESS to others, e.g. when > teaching etc. > > Very importantly in practice: Keep in mind that prefixing i.e. C-u > <...> switches to visible (momentarily) which is also handy when > demo-ing, teaching, ... > > Martin > > On Wed, May 20, 2020 at 2:01 PM Marc Schwartz via ESS-help > wrote: >> >> Hi Alex, >> >> Thanks for the clarification. Given that information, I found the related >> issue report on Github: >> >> https://github.com/emacs-ess/ESS/issues/998 >> >> reviewed the discussion there and ultimately, found the related commit. >> >> I have modified the value to 'nowait for now, which seems to be a compromise >> of sorts, given the issues raised. >> >> Thanks, >> >> Marc >> >> >>> On May 19, 2020, at 6:05 PM, Alex Branham wrote: >>> >>> The default value of ess-eval-visibly recently changed. You probably want >>> to customize it to t or nowait. >>> >>> Alex >>> >>> On Tue, May 19, 2020, 5:08 PM Marc Schwartz via ESS-help >>> wrote: >>> Hi, >>> >>> A clarification, that when I do run the command, on a *single* line in the >>> R buffer, I am getting '>' characters for each line of R code in the region >>> passed, and I get '+' characters if there is a multiline region of code >>> passed. >>> >>> Thus, I might see the following single lines of output in the R buffer, as >>> examples: >>> >>>>>>> >>> >>> or >>> >>>>>>> +>> >>> >>> after the command is run on a region of R code. >>> >>> Regards, >>> >>> Marc >>> >>> >>>> On May 19, 2020, at 4:51 PM, Marc Schwartz wrote: >>>> >>>> Hi All, >>>> >>>> I just updated my ESS/Polymode installation today via melpa, and unless I >>>> am missing something, I noticed that the use of ess-eval-region via "C-c >>>> C-r" does not seem to echo the highlighted R code region into the R >>>> buffer, which it had been doing until now. >>>> >>>> The code does execute, confirmed when I check for the resultant object. >>>> >>>> Am I missing new behavior, or perhaps a setting that changed someplace, or >>>> that I introduced a conflict with the updates today? >>>> >>>> Thanks, >>>> >>>> Marc Schwartz >>>> >>> >>> __ >>> 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 > > > > -- > Martin https://stat.ethz.ch/~maechler > Seminar für Statistik, ETH Zürich HG G 16 Rämistrasse 101 > CH-8092 Zurich, SWITZERLAND > phone: +41-44-632-3408 fax: ...-1228 <>< __ ESS-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/ess-help
Re: [ESS] ess-eval-region Does Not Echo Highlighted Code Into the R Buffer?
Hi Alex, Thanks for the clarification. Given that information, I found the related issue report on Github: https://github.com/emacs-ess/ESS/issues/998 reviewed the discussion there and ultimately, found the related commit. I have modified the value to 'nowait for now, which seems to be a compromise of sorts, given the issues raised. Thanks, Marc > On May 19, 2020, at 6:05 PM, Alex Branham wrote: > > The default value of ess-eval-visibly recently changed. You probably want to > customize it to t or nowait. > > Alex > > On Tue, May 19, 2020, 5:08 PM Marc Schwartz via ESS-help > wrote: > Hi, > > A clarification, that when I do run the command, on a *single* line in the R > buffer, I am getting '>' characters for each line of R code in the region > passed, and I get '+' characters if there is a multiline region of code > passed. > > Thus, I might see the following single lines of output in the R buffer, as > examples: > > >>>> > > or > > >>>>+>> > > after the command is run on a region of R code. > > Regards, > > Marc > > > > On May 19, 2020, at 4:51 PM, Marc Schwartz wrote: > > > > Hi All, > > > > I just updated my ESS/Polymode installation today via melpa, and unless I > > am missing something, I noticed that the use of ess-eval-region via "C-c > > C-r" does not seem to echo the highlighted R code region into the R buffer, > > which it had been doing until now. > > > > The code does execute, confirmed when I check for the resultant object. > > > > Am I missing new behavior, or perhaps a setting that changed someplace, or > > that I introduced a conflict with the updates today? > > > > Thanks, > > > > Marc Schwartz > > > > __ > 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] ess-eval-region Does Not Echo Highlighted Code Into the R Buffer?
Hi, A clarification, that when I do run the command, on a *single* line in the R buffer, I am getting '>' characters for each line of R code in the region passed, and I get '+' characters if there is a multiline region of code passed. Thus, I might see the following single lines of output in the R buffer, as examples: or +>> after the command is run on a region of R code. Regards, Marc > On May 19, 2020, at 4:51 PM, Marc Schwartz wrote: > > Hi All, > > I just updated my ESS/Polymode installation today via melpa, and unless I am > missing something, I noticed that the use of ess-eval-region via "C-c C-r" > does not seem to echo the highlighted R code region into the R buffer, which > it had been doing until now. > > The code does execute, confirmed when I check for the resultant object. > > Am I missing new behavior, or perhaps a setting that changed someplace, or > that I introduced a conflict with the updates today? > > Thanks, > > Marc Schwartz > __ ESS-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/ess-help
[ESS] ess-eval-region Does Not Echo Highlighted Code Into the R Buffer?
Hi All, I just updated my ESS/Polymode installation today via melpa, and unless I am missing something, I noticed that the use of ess-eval-region via "C-c C-r" does not seem to echo the highlighted R code region into the R buffer, which it had been doing until now. The code does execute, confirmed when I check for the resultant object. Am I missing new behavior, or perhaps a setting that changed someplace, or that I introduced a conflict with the updates today? Thanks, Marc Schwartz __ ESS-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/ess-help
Re: [ESS] ESS+Polymode Questions
Note: Re-sending my reply below, as I noted that even though I did reply-all, the ESS list was not included in the reply... Apologies. Marc > On Mar 13, 2019, at 6:12 AM, Vitalie Spinu wrote: > > > >>> On Thu, Mar 07 2019 12:17, Marc Schwartz via ESS-help wrote: >>>> >>>> that defines the boundary of an R chunk is bolded in black instead of red. >>>> I >>>> Googled for polymode colors but did not see anything obvious, so was >>>> wondering if someone can point me to the fontlock settings for the above to >>>> change it from black to red. Red stands out better for my aging eyes... >>> >>> Usually M-x describe-face defaults to the face under point, perhaps >>> that's what you need? > >> It just shows the default 'bold', not a specific font-lock face. > > There is no global customization entry for this as yet. > > For now you can alter the default value of the class: > > (with-eval-after-load "polymode" > (oset-default 'pm-inner-chunkmode :head-adjust-face font-lock-warning-face)) > > Or if you with to customize specific innermodes: > > (oset pm-inner/noweb :head-adjust-face font-lock-string-face) > > Vitalie Hi Vitalie, Thanks for the above. I have not had a chance to work on the incantation in my .emacs file to get the above to work yet, but have an additional question, and since it is related to the original topic, hopefully will be ok to keep in this thread. Is there a way to disable the automatic displaying of the .tex file that results from the Sweave processing of a .Rnw file, which occurs in a new frame once Sweave is completed. I rarely inspect the .tex file, unless there is an error, and in the case of very large .tex files, this extra step can result in a decent delay before Emacs comes back. If you need more information, please let me know. Thanks, Marc [[alternative HTML version deleted]] __ ESS-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/ess-help
Re: [ESS] ESS+Polymode Questions
> On Mar 7, 2019, at 12:51 PM, Alex Branham wrote:
>
>
> On Thu 07 Mar 2019 at 11:17, Marc Schwartz wrote:
>
>>> (add-to-list 'display-buffer '("*R" (display-buffer-reuse-window
>>> display-buffer-at-bottom)
>^ should be 'display-buffer-alist
>>> (window-width . 0.5) (reusable-frames . nil)))
>>
>> Symbol's value as variable is void: display-buffer
>
> Sorry, see edit above.
No problem. That resolved the issue. Thanks!
I'll just need to get into the habit of starting R, rather than splitting the
frame first and then starting R.
>
>> Is there any indication as to a time frame for a new release of lintr to
>> CRAN?
>
> There's an open issue about this on the lintr github. There's some
> performance regression that Jim wants to fix before releasing the new
> version. Volunteers are welcome, I'm sure.
Ok, I'll take a look to see if I can offer anything of value there.
Any other thoughts on the font face issue?
Marc
>
> Alex
__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help
Re: [ESS] ESS+Polymode Questions
Hi Alex,
Thanks for your reply. Responses inline below.
Marc
> On Mar 7, 2019, at 10:24 AM, Alex Branham wrote:
>
>
> On Wed 06 Mar 2019 at 18:53, Marc Schwartz via ESS-help
> wrote:
>
>> Three questions:
>>
>> 1. While the syntax highlighting seems to be generally preserved in terms of
>> fonts and colors from ESS and auctex, the following text:
>>
>> <>=
>>
>> @
>>
>> that defines the boundary of an R chunk is bolded in black instead of red. I
>> Googled for polymode colors but did not see anything obvious, so was
>> wondering if someone can point me to the fontlock settings for the above to
>> change it from black to red. Red stands out better for my aging eyes...
>
> Usually M-x describe-face defaults to the face under point, perhaps
> that's what you need?
It just shows the default 'bold', not a specific font-lock face.
If I revert to the old ESS configuration, so that polymode is disabled, the
face appears to be a combination of:
font-lock-keyword-face
which is actually Purple and colors the text within the '<<' and the '>>=='
and
font-lock-constant-face
which is red and colors the boundary symbols above as well as the '@'.
I tried to explicitly specify those in my .emacs in the custom-set-faces
section with:
'(font-lock-constant-face class color) (background light)) (:foreground
"Red"
'(font-lock-keyword-face class color) (background light)) (:foreground
"Purple"
however, they appear to be ignored when polymode is active.
Any workarounds?
>
>> 2. When starting an R session (M-x R), the new R buffer opens in a new frame
>> to the right of the current frame, rather than in the current frame, as was
>> the case with ESS. Is there a way to change this behavior so that it opens
>> in the current frame? I generally work with my R/Rnw files in the top frame
>> and the R session in the lower frame, so this is a quirk that I would like
>> to change, if possible.
>
> This is probably a result of ESS respecting `display-buffer'. If you
> want R to start in a window below your current buffer, use something
> like this:
>
> (add-to-list 'display-buffer '("*R" (display-buffer-reuse-window
> display-buffer-at-bottom)
> (window-width . 0.5) (reusable-frames . nil)))
>
> Let me know if that doesn't do what you want.
I get the following error message:
Symbol's value as variable is void: display-buffer
>
>> 3. After opening a Rnw file and starting an R session, I get the following
>> message in the flymake log buffer:
>>
>> Warning [flymake FileName.Rnw[R]]: Disabling backend
>> flymake-proc-legacy-flymake because (error Can’t find a suitable init
>> function)
>> Error [ess-r-flymake *ess-r-flymake*]: Need ‘lintr‘ version > v1.0.3
>>
>> I do have lintr version 1.0.3 installed from CRAN and, based upon a Google
>> search, I have the following in my .emacs:
>>
>> (remove-hook 'flymake-diagnostic-functions 'flymake-proc-legacy-flymake)
>>
>> prior to both ESS and polymode being loaded.
>>
>> Is this a temporary situation pending a yet to be released version of lintr,
>> or is there something else going on here?
>
> Yes, we rely on lintr features not yet released on CRAN. You can get the
> development version with devtools::install_github("jimhester/lintr").
OK, thanks on that. I installed the development version from Github and that
seems to have resolved the issue.
Is there any indication as to a time frame for a new release of lintr to CRAN?
Thanks,
Marc
>
> Thanks,
> Alex
__
ESS-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/ess-help
[ESS] ESS+Polymode Questions
Hi All, So I finally made the jump to polymode. Still getting use to the changes after having used ESS for circa 15 years or so on Windows, Linux and OSX/macOS. Thanks to those involved in developing and maintaining polymode. Three questions: 1. While the syntax highlighting seems to be generally preserved in terms of fonts and colors from ESS and auctex, the following text: <>= @ that defines the boundary of an R chunk is bolded in black instead of red. I Googled for polymode colors but did not see anything obvious, so was wondering if someone can point me to the fontlock settings for the above to change it from black to red. Red stands out better for my aging eyes... 2. When starting an R session (M-x R), the new R buffer opens in a new frame to the right of the current frame, rather than in the current frame, as was the case with ESS. Is there a way to change this behavior so that it opens in the current frame? I generally work with my R/Rnw files in the top frame and the R session in the lower frame, so this is a quirk that I would like to change, if possible. 3. After opening a Rnw file and starting an R session, I get the following message in the flymake log buffer: Warning [flymake FileName.Rnw[R]]: Disabling backend flymake-proc-legacy-flymake because (error Can’t find a suitable init function) Error [ess-r-flymake *ess-r-flymake*]: Need ‘lintr‘ version > v1.0.3 I do have lintr version 1.0.3 installed from CRAN and, based upon a Google search, I have the following in my .emacs: (remove-hook 'flymake-diagnostic-functions 'flymake-proc-legacy-flymake) prior to both ESS and polymode being loaded. Is this a temporary situation pending a yet to be released version of lintr, or is there something else going on here? Thanks! Marc Schwartz __ ESS-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/ess-help
