Closed r2evans closed 1 year ago
This is strange. I never experience anything like that, even though I also spend a lot of time in debugger. There is a queue indeed. Internally we accumulate the content coming from from the process in an separate buffer and flush it in batches. This is much faster than piping it as it comes. Something might be broken with that mechanism for you.
Flushing happens whenever the process is ready (here). That means whenever >
prompt is detected. Have you changed your prompt regexp by any chance?
No intentional change to the prompts:
> options("prompt", "continue")
$prompt
[1] "> "
$continue
[1] "+ "
In elisp, inferior-ess-primary-prompt
is "> "
everywhere; and inferior-ess-secondary-prompt
is "+ "
in R inferior process and ESS[R]
buffers, and nil
elsewhere (e.g., *scratch*
).
I'm not certain how to use that section of flushing code. Sorry for my elisp non-proficency, is there a way I can manually flush or clear that buffer?
BTW, I should have included this earlier: Windows 11 running:
GNU Emacs 27.2 (build 1, x86_64-w64-mingw32) of 2021-03-26
ess-version: 18.10.3snapshot [elpa: 20211231.1746] (loaded from c:/Users/r2/.emacs.d/elpa/ess-20211231.1746/)
I showed the code just for the sake of pointing that it's very simple, whenever we see prompt we flush. Nothing you can do directly with the flushing buffer. So the situation like you describe is really strange.
A little more context: the "phantom output" occurs when my cursor is inside a function for which I suspect ESS is doing a lookup. For instance, when the phantom-output is turned on, then when my cursor _
is outside all parens,
func(1, 2, 3) _
nothing happens. When it is inside a function I've "seen" recently,
nrow( _
nothing happens. When it is inside a function I've not looked at (recently?),
someNewFunction( _
then the phantom output is dumped to the console. It does not matter if someNewFunction
exists or not. (This is also triggered with glm( _
, which I have not used yet during this R session.)
I don't know if that provides any helpful context. Thanks!
Something is eating your output (or output of internal communication). Are you on the most recent ESS? What is the value of ess--command-default-timeout
?
Does it help if you increase your (setq read-process-output-max (* 1024 1024))
?
emacs-version
; GNU Emacs 27.2 (build 1, x86_64-w64-mingw32) of 2021-03-26
ess-version
; ess-version: 18.10.3snapshot [elpa: 20211231.1746] (loaded from c:/Users/r2/.emacs.d/elpa/ess-20211231.1746/)
ess--command-default-timeout
; 2305843009213693951 (#o177777777777777777777, #x1fffffffffffffff)
read-process-output-max
; 4096
I'll try (setq read-process-output-max (* 1024 1024))
for a while and report back. Thank you @vspinu!
That's a quick "nope", unfortunately. still doing it.
If it matters, the specific configs for my ESS.
~/.emacs.d/init
~/.emacs.d/lisp/my-ess.el
(autoloaded)More details, not sure if it is just muddying or helpful.
I'm currently in a debugging browser
at the moment, stepping through one of my functions. Normally, I C-c C-r
regions. When I haven't done anything to trigger the phantom output, things work fine.
If my editing buffer is just
if (FALSE) {
QUUX <- mtcars[1:2,]
QUUX[1:2,]
}
and my R buffer starts as:
Browse[2]>
then:
C-c C-n
the two lines, works just fine;
Browse[2]> QUUX <- mtcars[1:2,]
Browse[2]> QUUX[1:2,]
mpg cyl disp hp drat wt qsec vs am gear carb
Mazda RX4 21 6 160 110 3.9 2.620 16.46 0 1 4 4
Mazda RX4 Wag 21 6 160 110 3.9 2.875 17.02 0 1 4 4
Move around quickly (do not allow the 'pause' to trigger a phantom output), highlight QUUX
, and C-u C-c C-r
, it works:
Browse[2]> QUUX
mpg cyl disp hp drat wt qsec vs am gear carb
Mazda RX4 21 6 160 110 3.9 2.620 16.46 0 1 4 4
Mazda RX4 Wag 21 6 160 110 3.9 2.875 17.02 0 1 4 4
Move around more slowly, trigger the phantom output, highlight QUUX
and C-u C-c C-r
:
Browse[2]> [1] 6
> > QUUX
Error in eval(ei, envir) (from ...#1) : object 'QUUX' not found
If I go to the R buffer, hit <Enter>
, it returns to Browse[2] >
at which time QUUX
works fine, as it does when done from the file buffer.
The phantom output injecting into today's session is [1] 6\n>
. I think I know when it started and perhaps the code that corresponds to that output, but it was innocuous (I think literally highlight nrow(df)
and C-c C-r
), and nothing I recall doing at the time included some arbitrary "oops" mis-type or accidentally activating some other keybinding.
Hello I have experienced similar issues. Is it related to this post on so?
I'll check, thank you @DJJ88. (I haven't been able to trigger the problem by changing comint-process-echoes
(as already commented in that SO issue) nor with (completion-at-point)
, but I'll give those a try the next time it triggers.)
I can confirm that the errant output is occurring when (completion-at-point)
is called manually (with the cursor inside a function call). When it is happening,
completion-at-point-functions
; (ess-roxy-complete-tag ess-filename-completion ess-r-package-completion ess-r-object-completion t)
which is unchanged from when the problem is not occurring.
Of those, only ess-r-object-completion
is doing anything during the problem, and it appears to be returning something reasonable:
(ess-r-object-completion) ; while the cursor is within a defined function
; (72036 72036 ("which = "))
(ess-r-object-completion) ; while not within a defined function
; nil
That doesn't seem to help narrow it down at all, unfortunately.
Since you can consistently reproduce, an ess-elisp-trace-mode
output taken during the reprex might be useful.
Hi All,
I just wanted to add a "me too" here, with perhaps an additional couple of data points.
First, I am on macOS, using the Emacs binary builds from https://emacsformacosx.com/builds.
I get this behavior, of repeating prior output, without using the R debugger, and that it is dependent upon using Emacs 27. If I revert to Emacs 26, I do not seem to get this same behavior.
Thus, I am using Emacs 26, as the Emacs 27 behavior is rather annoying.
My recollection is that there were a few threads on ESS-help last year with some Emacs 27 specific behaviors affecting output in the R session frame, with extra blank/prompt lines and similar types of behaviors manifesting themselves, suggesting some kind of nuanced incompatibility with Emacs 27.
@lionel- I recognize that ess-elisp-trace-mode
is supposed to do something, but it just returns t
and does not appear to do much more. I'm guessing it's saving logs somewhere but I can't find anything.
(Not sure why it didn't work when I used it four days ago ... arg. What a week.)
I tried to cut this to just a few seconds, incurring one such "phantom output", but I know there's a lot of extra stuff there. Since I'm not confident removing extra, I've kept all of it there. I apologize for the volume. Thank you in advance if/when you are able to look through it.
ess-elisp-trace-mode
Another, in case it helps.
ess-elisp-trace-mode
Any thoughts? This is plaguing me daily. Is there something else in logs that can help?
For some context, it is more than cosmetic: when the phantom text is on the console, expressions evaluated in a different buffer into R via C-c C-r
or the like will fail. Conversely, if it starts while I'm debugging a function in a different buffer (loaded via devtools::load_all
, then whenever the phantom text appears, emacs switches to that other buffer at the line of where the phantom error started. This is massively disrupting while editing files interactively with the R inferior buffer.
It appears to be triggered whenever I'm in a function that ESS is looking to inform me of its arguments. For instance, in this current version of h*ll, I can place my cursor inside abs(_
and see abs: x=
in the mini-buffer; if I place my cursor inside of ggplot(_
, I see ggplot: data=NULL, ...
, sfsg. If I look inside a function from a package that sessioninfo::session_info()
reports as local
or <NA>
, though, it triggers back to the previously-debugged buffer, yanking me away from my current purpose.
~Possible clue: this jumping-around occurs if the cursor is in an incomplete expression. That is, in my examples above, I used abs(_
literally, meaning there is no close-paren. For the ones that triggered me to jump buffers, no problem occurs if I pre-type the ()
and then go back into the parens to look at arguments, etc.~
~So it appears that this has to do with ESS trying to parse the expression at the current point/cursor, and that expression is incomplete/bad.~
~Does that help? Perhaps I'll try to find some magic-parens so that I can at least confirm this symptom and prevent it from plaguing me all the time.~
Scratch that.
Looks like it is eldoc. Does invoking .ess_funargs("abc")
fro a problematic package adn function?
If I look inside a function from a package that
You mean when you debug a function from such a package?
sessioninfo::session_info() reports as local or
Looks like you can reproduce the issue now. Can you describe the steps a bit more clearly. Maybe I could reproduce on my end.
When debugging inside "local" packages I see no issues on my side. So there must be something else what is different.
I haven't seen this in a looooong time, thanks for ESS!
I cannot produce a reproducible issue here, I'm hoping you can help me identify which recurring ESS task is doing this.
I spend a lot of time in
Browse[2]>
(or deeper), often using it for writing my R functions the first time. Infrequently (I cannot find the exact trigger), something I do causes the last command I evaluate causes that command to be re-evaluated in the R inferior buffer whenever I switch from R to the code.For instance, I'm currently working in the debugger, and in the inferior buffer itself I type in
Now something I do (in the following 5 seconds to 5 minutes, I don't recall in this case) causes that output to be re-inserted into the inferior process repeated. Some things that cause it to be inserted:
auto-complete variables (poorly), perhaps typing in
head(abc
and hittingTab
(where there are no arguments or variables that start withabc
:switching to the left of the two split windows; after a 1-second pause, the inferior process has that
c2 c4 c10 ..
output re-printedsometimes, an error on the console causes it to reprint (not certain this is consistent)
exiting out of the debugger does not fix things!
I have found no key-combination (mistyped or deliberate) that triggers into this state, and nothing that gets me out of it. My only recourse is to restart R completely (not something I relish doing often).
I see nothing in
*Messages*
, nor any other consistent emacs errors/warnings/beeps.Is there some queue of pending ESS actions or somewhere I can look to see if there is something pending that shouldn't?
(You know I prefer reproducible issues, I've been toiling with finding reproducibility in this for weeks ...)