Repository navigation
calling handlers from .Rprofile don't persist in session #6892
Description
System details:
Positron and OS details:
Positron Version: 2025.03.0 (Universal) build 116
Code - OSS Version: 1.96.0
Commit: 7f0f938
Date: 2025-03-01T18:51:44.014Z
Electron: 32.2.6
Chromium: 128.0.6613.186
Node.js: 20.18.1
V8: 12.8.374.38-electron.0
OS: Darwin arm64 24.3.0
Interpreter details:
R 4.4.1 or Python 3.11.6
Describe the issue:
If I set calling handlers in my .Rprofile, they aren't applied in my console.
Steps to reproduce the issue:
- Run
usethis::edit_r_profile()in the R console - Add
globalCallingHandlers(error = function(e) stop("Caught that!"))to the end of the file - Restart R
- Run R code that errors, e.g.
sum(1, "n") - Observe that the calling handler isn't applied, e.g.
Error in sum(): ! invalid 'type' (character) of argumentrather thanCaught that!
Expected or desired behavior:
I would have expected that calling handlers set in .Rprofile are applied in the session. e.g. if I start RStudio with the same .Rprofile, I see:
sum(1, "n")
#> Error in h(simpleError(msg, call)) : Caught that!Were there any error messages in the UI, Output panel, or Developer Tools console?
No error messages in the UI. The developer tools console is quite busy but they all seem related to specific extensions, so I won't paste that here.
Activity
jmcphers commentedon Mar 20, 2025
Ark currently does its own execution of
.Rprofileafter startup instead of letting R take care of running it. This helps address a number of startup issues but also results in a few behavioral differences (see also #6344, #6417).My guess is that to resolve this issue we'll need to do some fancy footwork to evaluate
.Rprofileat the top level instead of executing it inside a nested/source context.DavisVaughan commentedon Mar 20, 2025
We have our own
globalCallingHandlers()forerror- that's how we can display errors in a custom way in the Positron console (i.e. with collapsible traceback and what not).That said, we tried to be somewhat careful about this. If I do as you say and run
globalCallingHandlers()in the console, i see both your handler and our handler on the "stack" of handlers and it does like like yours is first (meaning it should run first, then let ours run).It seems to work correctly when
globalCallingHandlers(error = function(e) stop("Caught that!"))is called directly in the console but not when its set from the Rprofile even though both situations "look" the same when you printglobalCallingHandlers(), weird.HenrikBengtsson commentedon Sep 19, 2025
I reported a duplicate version of this y'day in #9480. It's a blocker for setting
progressr::handlers(global = TRUE)in Rprofile, which registers a global calling handler. As shown in #9480, a manual workaround is to re-register the calling handlers at the prompt:globalCallingHandlers(globalCallingHandlers(NULL))HenrikBengtsson commentedon Oct 9, 2026
Has there been any progress on this?