Emacs freezes

[dbitouze]

Hi,

since I recently activated Company, I'm very often facing Emacs freezes, with the following error message:

┌──── │ Company: Front-end company-pseudo-tooltip-unless-just-one-frontend error: "Args out of range: 0,17" on command post-command └────

in the minibuffer. Sometimes, I can continue to work after 5 minutes or so and, in such a case, I can see the preceding error message repeated over and over again in the Messages buffer. Similar bug was reported 5 years ago here:

┌──── │ https://bugs.launchpad.net/nxhtml/+bug/447037 └────

I noticed this problem arises only when I'm writing emails in gnus with `Message' as major mode and the following minor modes (excerpt of C-h m):

┌──── │ Enabled minor modes: Abbrev Annoying-Arrows Auto-Composition Auto-Compression │ Auto-Encryption Auto-Fill Auto-Image-File Blink-Cursor Column-Number │ Delete-Selection Desktop-Save Diff-Auto-Refine Diff-Hl Fancy-Narrow │ File-Name-Shadow Flyspell Font-Lock Global-Annoying-Arrows │ Global-Auto-Highlight-Symbol Global-Auto-Revert Global-Color-Identifiers │ Global-Company Global-Diff-Hl Global-Flycheck Global-Font-Lock Global-Hl-Line │ Global-Undo-Tree Gnus-Message-Citation Google-This Guide-Key Line-Number │ Menu-Bar Mml Mouse-Wheel Orgstruct Orgtbl Recentf Shell-Dirtrack Show-Paren │ Transient-Mark Undo-Tree Which-Function Whitespace Yas Yas-Global └────

Context:

• GNU Emacs 24.3.1 (i686-pc-linux-gnu, GTK+ Version 3.6.4)
• company 20140930.712

[dgutov]

Please try applying this patch:

diff --git a/company.el b/company.el
index e6244d8..e7b3b3b 100644
--- a/company.el
+++ b/company.el
@@ -1029,7 +1029,7 @@ can retrieve meta-data for them."

 (defun company-call-frontends (command)
   (dolist (frontend company-frontends)
-    (condition-case err
+    (condition-case-unless-debug err
         (funcall frontend command)
       (error (error "Company: Front-end %s error \"%s\" on command %s"
                     frontend (error-message-string err) command)))))
@@ -1528,7 +1528,7 @@ from the rest of the back-ends in the group, if any, will be left at the end."
     (company-abort)
     (setq this-command 'company-abort))
   (unless (company-keep this-command)
-    (condition-case err
+    (condition-case-unless-debug err
         (progn
           (unless (equal (point) company-point)
             (let (company-idle-delay) ; Against misbehavior while debugging.

Then do M-x eval-buffer in company.el and M-x toggle-debug-on-error. When you trigger the error again, please post the backtrace.

Similar bug was reported 5 years ago here:

It's not particularly similar, no.

[dbitouze]

After the error:

Company: An error occurred in post-command
Company: Front-end company-pseudo-tooltip-unless-just-one-frontend error "Args out of range: 0, 14" on command post-command

repeated almost 300 times, here is the Backtrace:

Debugger entered--Lisp error: (error "No such part")
  signal(error ("No such part"))
  error("No such part")
  gnus-article-view-part(nil)
  call-interactively(gnus-article-view-part nil nil)

[dgutov]

This is a backtrace for Gnus, not for Company. Have you applied the patch and re-evaluated the changed function definitions like I described?

[dbitouze]

Le 04/10/14 à 11h12, Dmitry Gutov notifications@github.com a écrit :

This is a backtrace for Gnus, not for Company.

Sorry.

Have you applied the patch and re-evaluated the changed function definitions like I described?

I must admit that's the first time I try to apply a patch. I proceed thanks to `M-x epatch' and I guessed I managed because I could find the new strings, e.g.:

┌──── │ (error (error "Company: Front-end %s error \"%s\" on command %s" └────

in the company.el file I saved. Then I ran M-x eval-buffer' in company.el andM-x toggle-debug-on-error'.

Is there a way to check I properly did what you described?

Denis

[dgutov]

I must admit that's the first time I try to apply a patch.

Thanks for trying anyway. I'll just pushed this change to master.

I could find the new strings

This is not a new string. Like the syntax highlighting in the code box above hints, I've replaced a few instances of condition-case with condition-case-unless-debug.

Unfortunately, it seems like it only pops the backtrace properly in this case in the pretest version of Emacs (just tried it in 24.3, didn't work). So I'm afraid you'll have to either install it, or try to reproduce the error step-by-step, starting with emacs -Q.

[dbitouze]

I could find the new strings

This is not a new string. Like the syntax highlighting in the code box above hints, I've replaced a few instances of condition-case with condition-case-unless-debug`.

Oooops, sorry: I read too fast. Indeed, the patch wasn't applied properly as condition-case-unless-debug is missing.

Unfortunately, it seems like it only pops the backtrace properly in this case in the pretest version of Emacs (just tried it in 24.3, didn't work). So I'm afraid you'll have to either install it,

I'll try to find to do so.

or try to reproduce the error step-by-step, starting with emacs -Q.

I guess that's quite impossible because I'm loading the huge emacs-leuven configuration file :)

[dgutov]

because I'm loading the huge emacs-leuven configuration file :)

Interesting. @fniessen, have you been seeing similar errors?

[fniessen]

Interesting, yes ;-) But, no, I don't have seen this error yet. I'd be interested to better understand how it comes up, though.

[dbitouze]

Maybe I should mention that, usually, I'm running two emacs instances: a default one (emacs &) and another devoted to gnus (emacs -f gnus &). And the problem arises in the latter one.

[fniessen]

I just got the same message when typing "po" (I wanted to type "pour") in an email... Emacs did not freeze, though it waited a couple of seconds before displaying the characters I already had typed, hence displaying "pour".

Trying to retype "pour" somewhere else allows me to reproduce the problem.

Just typing "po" somewhere else blocks Emacs for the same number of seconds (5 or so), then displays the menu with all possible candidates (words beginning with "po").

It does not occur with other words, so it seems to be dependent on my buffer's contents?

[dgutov]

It does not occur with other words, so it seems to be dependent on my buffer's contents?

Guess so.

So, you see the error in messages? You're using the Emacs pretest, right? Can you toggle-debug-on-error and post the backtrace?

[fniessen]

Yes, I'm using Emacs 24.3.94.1.

Though, I don't get a backtrace: see my video capture at http://screencast.com/t/og59EL5IN8TR.

What else can I do?

Note that, up to now, it's only with the one and same prefix "po" (be it for "pour" or "possibilité" or ...). As soon as those 2 letters are typed, I do experience the problem... in all mails I write. So, it seems more related to a specific source than to the current contents of the buffer...

[dgutov]

Though, I don't get a backtrace

Do you have the latest Company installed, from MELPA?

[fniessen]

I do have company-20140930.712. Do you want me to update?

[dgutov]

Yep!

[fniessen]

Updated, and Emacs restarted. Though, now, I can't reproduce the problem anymore... See http://screencast.com/t/0cmhhyANpDs.

[dgutov]

This could be a good news, but it's probably because you have a clean session. There probably was something in other buffers, in the old session, that was triggering the problem.

[fniessen]

I'll tell you ASA I can reproduce it.

Does the problem ring a bell to you?

[dgutov]

Not really.

As a wild guess, since you write in French, it could be related to accents or multiple width characters, or something like that. So if you ever use those in words starting with po, that might help reproduce it.

[fniessen]

Got in now in a buffer in English, under Emacs 24.3.94.1, with company-20141005.619.

You seem right about French characters (in the list of candidates):

Debugger entered--Lisp error: (args-out-of-range 0 16) add-text-properties(0 16 (face company-tooltip mouse-face company-tooltip-mouse) " avalis\351e 7 ") company-fill-propertize("avalis\351e" nil 12 nil " " " 7 ") company--create-lines(0 10) company-pseudo-tooltip-show(12 0 0) company-pseudo-tooltip-show-at-point(201 2) company-pseudo-tooltip-frontend(post-command) company-pseudo-tooltip-unless-just-one-frontend(post-command)

[dgutov]

Great! Thanks, that makes it easy to reproduce. In short, the problem is triggered by unprintable characters from some hidden buffer probably created by Gnus for its own reasons.

To be thorough, could you next time this happens also look up which buffer the word comes from? Here's a function:

(require 'cl)

(defun find-word-buffers (word)
  (loop for buffer in (buffer-list)
        when (with-current-buffer buffer
               (save-excursion
                 (goto-char (point-min))
                 (let (case-fold-search)
                   (search-forward word nil t))))
        collect buffer))

Using the word from the backtrace you posted, you'd call it like this: M-: (find-word-buffers "avalis\351e").

[dgutov]

Never wind, actually. For some reason, this still doesn't find sources of some completions.

[dgutov]

That should do it, thanks all.

company-dabbrev doesn't look in hidden buffers anymore, but when some other backend does, we should handle unprintable chars without exploding.

[fniessen]

Aren't you changing the semantics there? Maybe I'm just influenced by the names used in hippie-expand (dabbrev-all-buffers for all buffers, dabbrev for the current buffer, and dabbrev-visible for the visible part of all buffers).

And, when you say, "we should handle unprintable chars without exploding", you mean that's part of the fix, right?

[dgutov]

Aren't you changing the semantics there?

Yes, a bit. I thought of making this configurable, but first I'd like to see someone who actually wants to include all "uninteresting" buffers. If they want something a bit different, the configuration mechanism will have to work a bit differently as well.

So I probably should just update the docstring, for the time being.

dabbrev-all-buffers

It doesn't actually use all buffers; at least, not by default. Check out that function's implementation: it consults different vars, including hippie-expand-ignore-buffers.

when you say, "we should handle unprintable chars without exploding", you mean that's part of the fix, right?

Yep. First commit among the two referencing this issue.