Alt key is hijacked after process quit in iESS

[jthaman]

Hi, I have an issue with ESS 18.10 on Windows 10 with Emacs 26.1. It seems that after I quit a running R computation with C-c C-c in an iESS buffer, all subsequent keystrokes are interpreted as if the Alt key is held down. It's very strange. Here is a minimal init.el I was using.

(setq exec-path(append
                '("C:/Program Files/R/R-3.5.2/bin/x64"
)))

(require 'package)
(setq package-enable-at-startup nil)
(setq package-archives
      '(("gnu" . "https://elpa.gnu.org/packages/")
        ("melpa-stable" . "https://stable.melpa.org/packages/")
        ("org" . "https://orgmode.org/elpa/")
        ("melpa" . "https://melpa.org/packages/")))
(package-initialize)
(unless package-archive-contents
  (package-refresh-contents))
(unless (package-installed-p 'use-package)
  (package-refresh-contents)
  (package-install 'use-package))
(require 'use-package)
(setq use-package-always-ensure t)
(setq use-package-verbose t)

;; my packages
(use-package ess
  :pin melpa-stable
  :config
  (defun my-ess-settings ()
    (setq ess-indent-with-fancy-comments nil))
  (add-hook 'ess-mode-hook #'my-ess-settings)
  (setq ess-R-font-lock-keywords
        (quote
         ((ess-R-fl-keyword:keywords . t)
          (ess-R-fl-keyword:constants . t)
          (ess-R-fl-keyword:modifiers . t)
          (ess-R-fl-keyword:fun-defs . t)
          (ess-R-fl-keyword:assign-ops . t)
          (ess-R-fl-keyword:%op% . t)
          (ess-fl-keyword:fun-calls . t)
          (ess-fl-keyword:numbers . t)
          (ess-fl-keyword:operators)
          (ess-fl-keyword:delimiters)
          (ess-fl-keyword:=)
          (ess-R-fl-keyword:F&T))))
  (add-hook 'iESS-mode-hook 'evil-insert-state)
  (setq ess-ask-for-ess-directory nil)
  (setq ess-smart-S-assign-key nil))

(use-package counsel)

(use-package swiper)

(use-package ivy
  :config
  (ivy-mode 1)
  (require 'recentf)
  (setq ivy-height 15)
  (setq ivy-use-virtual-buffers t)
  (setq ivy-use-selectable-prompt t)
  (setq enable-recursive-minibuffers t)
  (setq ivy-wrap t)
  (setq ivy-virtual-abbreviate 'full))

Open a buffer in R-mode and fill it with these contents.

while(1 < 2){
    print("running")
} 

I run the code chunk with C-c C-c and this opens up an R process in an iESS buffer. Switch over to the iESS buffer and kill the running code with C-c C-c. Now Windows 10 starts to act like the Alt key is held down. Not just in emacs, but system-wide. Pressing the Alt key again returns the Alt key to normal.

This only happens on my Windows 10 computer, and it happens every time I C-c C-c in an iESS buffer. No problem like this on Ubuntu.

[jabranham]

Not just in emacs, but system-wide

Are you sure this is an ESS problem? Can you check if it happens in other comint-derived modes? For example, if you have python installed, you could do M-x run-python, and do:

while (1 < 2):
    print("Running")

then see if C-c C-c triggers the same issue.

[jthaman]

Thanks. I did some more digging and actually discovered that the problem may have little to do with ESS or comint. It seems this may be a problem with autohotkey. The issue does not occur when I quit a process while autohotkey is disabled.

[jthaman]

Hi, in case any other Evil+AHK+Emacs users find this issue frustrating, map comint-interrupt-subjob to another key on the inferior ESS mode map. I have

  (general-define-key
   :states 'normal
   :keymaps 'inferior-ess-mode-map
   ":" 'comint-interrupt-subjob)

In my config, which fixes the problem for me. Replace ":" with any single key you don't use in iESS.

[jthaman]

Actually, this may be unrelated to AutoHotkey. I have a new windows computer and am encountering the same issue without using AHK.

[vspinu]

It's not ESS related. Might not even be Emacs related. To me it looks like your Alt key is locked by display or window manager somehow.

[jthaman]

Do you know what it means if my ESS buffer looks like:

(R): ess-dialect=R, buf=JAGM/test.R, start-arg=nil
 current-prefix-arg=nil
(inferior-ess: waiting for process to start (before hook)
(inferior-ess 3): waiting for process after hook(R): inferior-ess-language-start=options(STERM='iESS', str.dendrogram.last="'", editor='emacsclient', show.error.locations=TRUE)
eisabling output delimiter because CMD failed to parseDisabling output delimiter because CMD failed to parseDisabling output delimiter because CMD failed to parseDisabling output delimiter because CMD failed to parseDisabling output delimiter because CMD failed to parseDisabling output delimiter because CMD failed to parse

The output at the end is strange, and might show up when I encounter this issue.

[vspinu]

Do you configure R prompt by any chance? Those errors are from the internal communication with the process. Hard to tell what's going wrong.

[jthaman]

Any tips that I could apply to try to debug the messages?

I don't customize the prompt. I do apply to special fontifications, but that's just theming. I don't touch inferior-ess-primary-prompt or the like.

[vspinu]

Customization of prompt is on the R side with options().

You can insert (message "%s" cmd) inside ess-command just before the above message and see which cmd is triggering it.