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

Error running timer ‘aggressive-indent--indent-if-changed’: (wrong-type-argument timerp nil) on every pointer movement #138

Open
shackra opened this issue May 17, 2020 · 5 comments

Comments

@shackra
Copy link

shackra commented May 17, 2020

in commit 12a64b4 I'm experiencing this bug were after some hours the function aggressive-indent--indent-if-changed begins to fail on every point movement or key stroke, which is annoying.

Error running timer ‘aggressive-indent--indent-if-changed’: (wrong-type-argument timerp nil) [2 times]
When done with this frame, type C-x 5 0
Error running timer ‘aggressive-indent--indent-if-changed’: (wrong-type-argument timerp nil) [22 times]
Mark set
Error running timer ‘aggressive-indent--indent-if-changed’: (wrong-type-argument timerp nil) [36 times]

a workaround is just to re-start emacs.

This is my configuration related to aggresive-indent-mode or where I explicitly do something with the minor mode:

(use-package aggressive-indent
  :diminish aggressive-indent-mode
  :config
  (add-to-list
   'aggressive-indent-dont-indent-if
   '(and (derived-mode-p 'c++-mode)
         (null (string-match "\\([;{}]\\|\\b\\(if\\|for\\|while\\)\\b\\)"
                             (thing-at-point 'line)))))
  (global-aggressive-indent-mode 1)
  (add-to-list 'aggressive-indent-excluded-modes 'html-mode)
  (add-to-list 'aggressive-indent-excluded-modes 'rjsx-mode))

(use-package dockerfile-mode
  :init
  (defun shackra/aggresive-indent-mode-off ()
    (aggressive-indent-mode -1))
  (add-hook 'dockerfile-mode-hook #'shackra/aggresive-indent-mode-off)
  :mode "Dockerfile\\'")
@mfiano
Copy link

mfiano commented May 18, 2020

Yes, I have noticed this too. I have resorted to removing this package. Restarting Emacs multiple times per day is no fun :(

shackra added a commit to shackra/emacs that referenced this issue May 18, 2020
@mkaschenko
Copy link

See the original issue for this problem #137.

The fix by @tsdh works perfectly. At the moment I'm keeping it within my .emacs.
After the package is updated, it could be removed.

(defun aggressive-indent--indent-if-changed (buffer)
  "Indent any region that changed in BUFFER in the last command loop."
  (if (not (buffer-live-p buffer))
      (and aggressive-indent--idle-timer
           (cancel-timer aggressive-indent--idle-timer))
    (with-current-buffer buffer
      (when (and aggressive-indent-mode aggressive-indent--changed-list)
        (save-excursion
          (save-selected-window
            (aggressive-indent--while-no-input
              (aggressive-indent--proccess-changed-list-and-indent))))
        (when (timerp aggressive-indent--idle-timer)
          (cancel-timer aggressive-indent--idle-timer))))))

terlar added a commit to terlar/emacs-config that referenced this issue Jun 20, 2020
Let's try without this, nowadays most modes have a formatter that can be
run instead. And also there was a bug in the code that is yet to be
fixed:

Malabarba/aggressive-indent-mode#138
@seagle0128
Copy link

seagle0128 commented Jul 4, 2020

Same issue here. Please fix it.

I think this fix is more reliable.

(when (timerp aggressive-indent--idle-timer)
          (cancel-timer aggressive-indent--idle-timer))

seagle0128 added a commit to seagle0128/.emacs.d that referenced this issue Jul 4, 2020
@oscarfv
Copy link

oscarfv commented Jul 17, 2020

There is a deeper problem here: if the buffer is killed, we have no access to the timer object, which is stored in a buffer-local variable, so we can't cancel it. Right now my Emacs session have four timers created by a-i-m which respective buffers no longer exists.

To begin with, why we create a repeating timer to cancel it right away on aggressive-indent--indent-if-changed? This seems a leftover from the past where the timer was unique and not buffer-local. So we should create a non-repeating timer, remove the cancel-timers from aggressive-indent--indent-if-changed and the problem described on this issue is gone, along with the leaking timers:

@@ -461,16 +461,13 @@ If BODY finishes, `while-no-input' returns whatever value BODY produced."
 
 (defun aggressive-indent--indent-if-changed (buffer)
   "Indent any region that changed in BUFFER in the last command loop."
-  (if (not (buffer-live-p buffer))
-      (cancel-timer aggressive-indent--idle-timer)
+  (when (buffer-live-p buffer)
     (with-current-buffer buffer
       (when (and aggressive-indent-mode aggressive-indent--changed-list)
         (save-excursion
           (save-selected-window
             (aggressive-indent--while-no-input
-              (aggressive-indent--proccess-changed-list-and-indent))))
-        (when (timerp aggressive-indent--idle-timer)
-          (cancel-timer aggressive-indent--idle-timer))))))
+              (aggressive-indent--proccess-changed-list-and-indent))))))))
 
 (defun aggressive-indent--keep-track-of-changes (l r &rest _)
   "Store the limits (L and R) of each change in the buffer."
@@ -479,7 +476,7 @@ If BODY finishes, `while-no-input' returns whatever value BODY produced."
     (when (timerp aggressive-indent--idle-timer)
       (cancel-timer aggressive-indent--idle-timer))
     (setq aggressive-indent--idle-timer
-          (run-with-idle-timer aggressive-indent-sit-for-time t #'aggressive-indent--indent-if-changed (current-buffer)))))
+          (run-with-idle-timer aggressive-indent-sit-for-time nil #'aggressive-indent--indent-if-changed (current-buffer)))))
 
 (defun aggressive-indent--on-buffer-kill ()

walseb added a commit to walseb/aggressive-indent-mode that referenced this issue Jul 18, 2020
@purcell
Copy link
Contributor

purcell commented Aug 17, 2020

Fixed more fully in #139, though perhaps @oscarfv's fix is preferable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants