lispy-ace-paren errors with Args out of range

[vkz]

Latest lispy-mode from Melpa installed and used with Spacemacs which is run as your vanilla Emacs would - no surprises. After some initial use trying to invoke any lispy-ace-paren commands say with q or a err with Args out of range. Observed in emacs-lisp-mode and clojure-mode. Turning lispy-mode on and off has doesn't fix the issue. Note that it only effects one buffer, lispy-mode continues to work as expected in others until it breaks there as well. Any ideas?

[abo-abo]

Any ideas?

No clue. So it works initially, and then stops working, in Spacemacs. I could have a look if you can reproduce the bug reliably, otherwise there's nothing I can do.

[zilongshanren]

@vkz I also met this issue many times, but I can't reproduce it reliably... BTW, I'm a Spacemacs user.

[vkz]

With debug on error:

Debugger entered--Lisp error: (args-out-of-range 124519 125175)
  avy--find-visible-regions(124519 125175)
  avy--regex-candidates("[([{]" 124519 125175 #[0 "\300 ?\207" [lispy--in-string-or-comment-p] 1 "\n\n(fn)"])
  lispy--avy-do("[([{]" (124519 . 125175) #[0 "\300 ?\207" [lispy--in-string-or-comment-p] 1 "\n\n(fn)"] at)
  lispy-ace-paren(1)
  call-interactively(lispy-ace-paren)
  (cond ((bound-and-true-p view-mode) (View-quit)) ((lispy--edebug-commandp) (call-interactively lispy--edebug-command)) ((region-active-p) (call-interactively (quote lispy-ace-paren))) ((lispy--in-string-or-comment-p) (call-interactively (quote self-insert-command))) ((or (lispy-left-p) (lispy-right-p) (and (lispy-bolp) (looking-at ";"))) (call-interactively (quote lispy-ace-paren))) (t (setq this-command (quote self-insert-command)) (call-interactively (quote self-insert-command))))
  special-lispy-ace-paren()
  call-interactively(special-lispy-ace-paren nil nil)
  command-execute(special-lispy-ace-paren)

I stepped through a bunch of functions with edebug. The only meaningful thing I can say that the error occurs inside avy--find-visible-regions, more specifically narrow-to-region ... line. Far as I can tell the function is re-entered multiple times with the same region and fails to narrow-to-region on one of those re-entrances.

Unfortunately, I don't have enough knowledge to venture meaningful guesses. Does the above help at least a little? I'll say this, Spacemacs ships with avy by default, but lispy.el I installed by adding it to dotspacemacs-additional-packages. Could there be some dependency issue? Say lispy depends on some version of avy that's inconsistent with what Spacemacs ships? Unfortunately, I'm only left to speculate.

[abo-abo]

The issue might be with some package in Spacemacs messing with window or region start/end. How fast could you reproduce this issue? I could fix it if I could reproduce it once.

Otherwise, as I've recommended before to other users, Spacemacs included, you can narrow the problem down by bisecting your Emacs configuration. Disable a few packages, see if the error disappears; if not, disable some more. Avy should work fine with emacs -Q, so the bug is bound to disappear once you disable enough packages. Then tell me the name of the package that causes the problem.

[sooheon]

I've encountered this in clojure as well, I'll try to find reliable repro steps.

[malchmih]

Same here

[vkz]

Update: beginning to think that some package in Spacemacs does mess with regions uncontrollably like @abo-abo suggested.

• seems that when the problem occurs it only effects the bottom of the buffer, so above a certain point lispy-ace-paren continues to work as expected, but breaks for all the forms below that point
• I sometimes observe avy choice characters in other-window even though it's not visiting the same file

I amy try to bisect this at some point but Spacemacs has entirely too much structure, not sure how to perform this cleanly.

[abo-abo]

lispy-ace-paren should only work in the current window. I never noticed this since I have avy-all-windows set to nil.

Please check if this change fixes the bug. It still might be unrelated.

[sooheon]

Another data point, I've had the same args-out-of-range bug happen for avy-goto-line. It only occurs when I call it with a keybinding, not when I call it with M-x.. could there be a lead there? And though in the debugger it says evil-avy-goto-line, both the evil wrapped and original versions of the function work if called with M-x.

[abo-abo]

This update should attempt to fix the error. My guess is that some hook might change the buffer just before avy--find-visible-regions. So e.g. bounds (1 312) are requested, but the temporary buffer is smaller than that.