spacemacs
spacemacs copied to clipboard
Problem with starting R process by C+n or C+b from within R mode
Description :octocat:
Problem with starting R process by C+n or C+b from within R mode
Reproduction guide :beetle:
- Start Emacs
- Open an R file
- C-c C-n or C-c C-b
Observed behaviour: :eyes: :broken_heart: Receive message "wrong-type-argument window-live-p nil"
Expected behaviour: :heart: :smile: Expect an R session to be started in a new buffer
System Info :computer:
- OS: darwin
- Emacs: 27.2
- Spacemacs: 0.300.0
- Spacemacs branch: develop (rev. 663cfc5ba)
- Graphic display: t
- Distribution: spacemacs
- Editing style: emacs
- Completion: helm
- Layers:
(ruby ivy
(markdown :variables markdown-live-preview-engine 'vmd markdown-command "pandoc")
outshine yaml csv html syntax-checking
(lsp :variables lsp-navigation 'both lsp-modeline-diagnostics-enable t lsp-ui-sideline-show-hover t lsp-ui-sidine-symbol t lsp-enable-imenu t lsp-ui-flycheck-enable t lsp-lens-enable t lsp-ui-sideline-enable nil lsp-ui-doc-enable nil lsp-ui-doc-display nil lsp-headerline-breadcrumb-enable nil lsp-log-max nil lsp-enable-on-type-formatting nil lsp-enable-symbol-highlighting nil lsp-enable-indentation nil lsp-ui-flycheck-live-reporting nil lsp-before-save-edits nil)
(dap :variables dap-auto-configure-features
'(sessions locals controls tooltip)
dap-enable-mouse-support t)
git github
(treemacs :variables treemacs-use-follow-mode t treemacs-use-filewatch-mode t treemacs-use-git-mode 'simple treemacs-lock-width nil)
(org :variables org-enable-github-support t org-enable-reveal-js-support t)
(shell :variables shell-default-height 30 shell-default-position 'bottom)
(spell-checking :variables ispell-program-name "aspell")
(ess :variables ess-r-backend 'lsp ess-default-style 'OWN ess-eval-visibly-p nil ess-use-flymake nil ess-assign-key "\255")
(latex :variables latex-build-command "LaTeX" latex-backend 'lsp latex-enable-folding t latex-refresh-preview nil)
bibtex themes-megapack spacemacs-layouts major-modes
(helm :variables helm-ff-lynx-style-map t helm-imenu-lynx-style-map t)
c-c++ ipython-notebook
(python :variables python-backend 'lsp python-lsp-server 'mspyls python-indent-offset 4 python-fill-column 99 python-pipenv-activate t python-test-runner 'pytest python-formatter 'yapf)
(javascript :variables node-add-modules-path t javascript-backend 'lsp javascript-fmt-tool 'prettier))
- System configuration features:
Backtrace :paw_prints:
Debugger entered--Lisp error: (wrong-type-argument window-live-p nil)
#<subr select-window>(nil nil)
ad-Advice-select-window(#<subr select-window> nil)
apply(ad-Advice-select-window #<subr select-window> nil)
select-window(nil)
helm-internal((((name . "run-ess-r") (header-name . #f(compiled-function (name) #<bytecode 0x1fe74ef54011>)) run-ess-r(nil)
R()
ess-start-process-specific("S" "R")
ess-request-a-process("Process to use: " no-switch nil)
ess-force-buffer-current()
ess-eval-region-or-line-visibly-and-step()
funcall-interactively(ess-eval-region-or-line-visibly-and-step)
call-interactively(ess-eval-region-or-line-visibly-and-step nil nil)
command-execute(ess-eval-region-or-line-visibly-and-step)
@olssol Neither C-n nor C-b is the binding to open a new process. C-n: evil-mc-make-and-goto-next-match C-b: evil-scroll-page-up
@olssol Neither C-n nor C-b is the binding to open a new process. C-n: evil-mc-make-and-goto-next-match C-b: evil-scroll-page-up
Thank you. Please see the updated issue.
Confirmed.
It's working okay in vanilla Emacs.
It's working okay in vanilla Emacs.
Seems like a problem with helm, but I am not certain. Can you advise what I should try or where I should report the issue?
@olssol
Before evaluating anything, can you try
SPC ' to start an R process first.
Then both key bindings seem to work.
This is indeed an issue with the way that helm and ess interact. In brief, when trying to spawn a new process, ess inhibits the creation of new windows, but when ess tries to figure out what you want your initial working directory to be, helm swoops in to provide completion but it tries to do so in a new window (which is not allowed), and thus you get a problem. It's discussed at more length here, where I also propose a simple workaround. That issue is "closed" although AFAICT, the specific helm + ess interaction issue is not resolved.
I think it could be fixed upstream (in probably a somewhat hacky way) in either helm or ess, but I haven't found the time to dive in to try to fix either, in part because the approach @lebensterben proposes (just start an R process first using SPC m ') is essentially muscle-memory to me by now.
I have opened emacs-ess/ESS#1183 upstream which will hopefully resolve this.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!
Fixed upstream, so this issue can be closed