Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ESS layer help.start makes inferior ess read-only #5395

Closed
izahn opened this issue Mar 7, 2016 · 6 comments
Closed

ESS layer help.start makes inferior ess read-only #5395

izahn opened this issue Mar 7, 2016 · 6 comments
Labels

Comments

@izahn
Copy link
Contributor

izahn commented Mar 7, 2016

Description

Starting an R repl and opening the help system in a browser makes the inferior-ess buffer read-only.

Reproduction guide

  • Start Emacs
  • SPC a' R <ret> to start an R repl (requires ess layer)
  • At the R prompt type help.start() to launch R help in a browser
  • Click on a link in the browser, e.g., "Packages".

Observed behaviour:
In the inferior ess buffer I see

> help.start()
starting httpd help server ... done
If the browser launched by '/usr/bin/xdg-open' is already running, it
    is *not* restarted, and you must switch to its window.
Otherwise, be patient ...
> 
Making 'packages.html' ... done

(which is expected), but further input is impossible. Any attempt to type in the inferior ess buffer results in Text is read-only being echoed in the minibuffer.

Expected behaviour:
The R repl should be usable after starting the help system in R.

System Info

  • OS: gnu/linux
  • Emacs: 24.5.1
  • Spacemacs: 0.105.13
  • Spacemacs branch: develop (rev. 895455d)
  • Graphic display: t
  • Distribution: spacemacs
  • Editing style: hybrid
  • Completion: ivy
  • Layers:
(spacemacs-ivy auto-completion command-log emacs-lisp ess octave python sql latex git markdown org pdf-tools pandoc
               (shell :variables shell-default-height 35 shell-default-position 'bottom shell-default-shell 'multi-term)
               (mu4e :variables mu4e-headers-include-related t mu4e-headers-skip-duplicates t mu4e-headers-fields
                     '((:human-date . 12)
                       (:flags . 6)
                       (:mailing-list . 10)
                       (:from-or-to . 22)
                       (:thread-subject))))
(spacemacs-ivy auto-completion command-log emacs-lisp ess octave python sql latex git markdown org pdf-tools pandoc
               (shell :variables shell-default-height 35 shell-default-position 'bottom shell-default-shell 'multi-term)
               (mu4e :variables mu4e-headers-include-related t mu4e-headers-skip-duplicates t mu4e-headers-fields
                     '((:human-date . 12)
                       (:flags . 6)
                       (:mailing-list . 10)
                       (:from-or-to . 22)
                       (:thread-subject))))

Backtrace

No error is triggered, so no backtrace.

@izahn
Copy link
Contributor Author

izahn commented Mar 7, 2016

I can also reproduce this on the latest released version of spacemacs, i.e.,

System Info

  • OS: gnu/linux
  • Emacs: 24.5.1
  • Spacemacs: 0.105.13
  • Spacemacs branch: master (rev. 2c3e6b4)
  • Graphic display: t
  • Distribution: spacemacs
  • Editing style: hybrid
  • Completion: helm
  • Layers:
(spacemacs-ivy auto-completion command-log emacs-lisp ess octave python sql latex git markdown org pdf-tools pandoc
               (shell :variables shell-default-height 35 shell-default-position 'bottom shell-default-shell 'multi-term)
               (mu4e :variables mu4e-headers-include-related t mu4e-headers-skip-duplicates t mu4e-headers-fields
                     '((:human-date . 12)
                       (:flags . 6)
                       (:mailing-list . 10)
                       (:from-or-to . 22)
                       (:thread-subject))))

@izahn
Copy link
Contributor Author

izahn commented Mar 7, 2016

OK, I've narrowed it down to an interaction with the shell layer. Without the shell layer enabled it works fine, with the shell layer enabled I have this problem. Digging in to the shell layer code now.

@izahn
Copy link
Contributor Author

izahn commented Mar 7, 2016

The shell layer sets comint-prompt-read-only to a non-nil value, which is enough to reproduce the problem after loading ess-site after starting with emacs -q. I've reported this upstream at emacs-ess/ESS#300 but will leave this open pending a response from the ESS developers.

@StreakyCobra
Copy link
Contributor

👍 :-)

@jackkamm
Copy link
Contributor

This same issue make it impossible to kill a shinyApp() running in ESS -- trying to send the kill signal with C-c C-c just results in the message Text is read-only in the minibuffer. The line (setq comint-prompt-read-only t) that @izahn identified in the shell layer causes the problem.

There is a solution in a comment on the corresponding issue page for ESS (emacs-ess/ESS#300 (comment)), to add the following toinferior-ess-mode-hook:

(setq-local comint-use-prompt-regexp nil)
(setq-local inhibit-field-text-motion nil)

I will submit this as a PR to the ess layer.

@github-actions
Copy link

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!

@github-actions github-actions bot added the stale marked as a stale issue/pr (usually by a bot) label Feb 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Upstream bugs
Reported, waiting
Development

No branches or pull requests

4 participants