Skip to content


term, ansi-term: error when pressing tab to autocomplete #289

benma opened this Issue · 22 comments

6 participants


Hi there

When yas/minor-mode is activated in a term/ansi-term buffer, pressing tab results in the following error:

term-send-raw: Wrong type argument: characterp, tab.

This is new behavior, introduced by one of the changes in the last couple of weeks. It only occurs when emacs is runs in a window. In the console, everything is working.

As a workaround, I included this in my .emacs:

(add-hook 'term-mode-hook (lambda()
                (yas-minor-mode -1)))

I know of yas--dont-activate but I haven't figured out yet how to use it.

Knowing the code base better, maybe you know right off the bat what might be causing the problem. Otherwise, I will dig into it sometime.


I've reproduced it, and the problem lies in yas-fallback and the way term-mode wants raw strings sent to the process. For some reason, yas-fallback messes with them (though I haven't understood why). One could blameœ term-mode which assumes every position of the result of (this-command-keys) is a character. So you might want to report this to emacs itself and see if they come up with a solution.

autopair-mode does something similar to yasnippet in respect to fallback behaviour (yasnippet is much more convoluted and if you know elisp and want to rewrite that function, I would appreciate it). Anyway, see, since I once apparently managed to get it to work.

Anyway, IMO the sane thing to do here would be to disable yasnippet exactly the way you have done it since yas--dont-activate should not be needed in emacs24.


Okay, thanks. I think it would be good to fix it in yasnippet too, though, because it was working before, and not everyone affected by this should go investigating what has failed their term-mode as I did :)

The changeset that introduced this bug is this one:
commit f28a3df702c62f1b045ea5b57d1344c90ebc9731.

It deals with the tab key, which is now broken in term-mode, though I don't know what it means.


I thought, if you use Emacs 24, perhaps you ought to use new shell-mode.

It better than term or ansi-term too much! so I don't think this is a Big thing.


Thanks for the tip. Why do you think shell-mode is better? I like ansi-term a lot because it is the closest to a normal shell that I can get. All my keys are sent to the shell. For example, hitting C-z in ansi-term will suspend the process run in the term, and not emacs itself.

shell-mode seems like some sort of emacs/shell hybrid.


Emacs 24 , shell-mode is almost the same as Terminal.

not like before version, shell-mode is only a toy, But nowaday, shell-mode
is very familiar with normal Terminal. And I can use so many Emacs convenience.
I suggest you can have a try.

If you like you C-z like a normal terminal, I think you ought to use XFCE Terminal.
use emacs, but use xterm, I can not find any advantage??


I am using Emacs 24, and shell-mode is not even close to ansi-term. It cannot run htop, for example. I just kind of like having a shell inside emacs that behaves like one outside of emacs (which shell-mode does not do).

And I can use so many Emacs convenience.

ansi-term has best of both worlds. With C-c C-j I can switch to line-mode, which lets me use the ansi-term buffer like any other buffer. Switch back to normal terminal mode with C-c C-k.

I could use a shell outside of emacs of course, but I don't want to. Having it in a buffer in emacs is more convenient to me than having it in an external window. So, in what other ways is shell-mode better than ansi-term?

I will give shell-mode try anyway, maybe it is better for certain things.


Beyond terminal modes, this issue also breaks tab in org-mode.


@tdavis, I believe this issue does not apply to org-mode. Can you provide a complete recipe demonstrating it with the latest HEAD?

I've tried, in windows, with emacs 24

emacs.exe -Q -l yasnippet.el -e yas-global-mode -e org-mode    

C-h k TAB
input some org headings
press TAB to hide/show headings
press TAB to indent heading content

@benma I've figured out what causes the problem and am actively working on solving the issue. By the way, I also like term-mode for the reasons you describe. Also also breaks term-mode for the same reason.


Here's what I did:

  1. Opened org file
  2. M-x yas-minor-mode
  3. Press tab

Here's the error:

Debugger entered--Lisp error: (wrong-type-argument stringp [tab])
  call-interactively(yas-expand nil nil)

I have not tried running this with -Q and so forth, only because the traceback doesn't indicate any other elisp is involved.

(Running Emacs 24.1)


The backtrace give no sure indication as to whether or not "other elisp is involved". I don't know if you customized yas--trigger-key, or for that matter, redefined yas--trigger-key-for-fallback (unlikely but possible).

Please run it with -Q I really need to tell if the error is your customization or the default values. Then we can look at interesting parts of your customization, which might be completely legitimate. Also, if possible open this is a new issue.


To: tdavis

Can you define some keybinding hook in org-mode ?

e.g. binding yas/expand with some TAB in org-mode-map?

I have some problem before , because in version 0.7, I binding this key, and in 0.8,
no need do this.


To: benma

Thanks, I will give a try for term-mode.


To: benma

Hi, can you tell me how to change a keybindinig in term-mode ??

I add a term-mode-hook, some function setting is work ok, but
binding setting is not effective. I define binding use term-mode-map

@mattfidler mattfidler added a commit to mattfidler/yasnippet that referenced this issue
@mattfidler mattfidler Should Fix Issue #289 ec2c545

Just wanted to say that yasnippet still breaks the term modes in an emacs -Q.


In the intervening years I bit the bullet and threw away the term modes in favour of eshell.


@tdavis you could have also

(add-hook 'term-mode-hook (lambda () (yas-minor-mode -1)))

@capitaomorte Oh, sure. Unfortunately, yasnippet being busted is far from the only quirk of the term modes. And with a tiling wm I'm a quick key combo away from an actual terminal fitted below whatever Emacs frame I'm in.


Yeah shell-in-emacs solutions were never extremely good, and it's good to be worth something outside emacs, too. Tiling wm's rock, in linux I use stumpwm, wish I could use it in mac osx.


I looked at the code, the problem is yas--keybinding-beyond-yasnippet searches under the translated TAB key when it doesn't find a binding for <tab>, but it doesn't change this-command-keys internal variable to TAB (it's not writable from lisp).

I thought the keys argument to call-interactively would help, but... it doesn't. So this appears unfixable, but another workaround is (define-key yas-minor-mode-map [tab] nil) i.e. remove the <tab> binding for yas-expand, leaving only the TAB binding.


@npostavs, that might help, might I'm also afraid it'll break snippet expansion in emacsen without a window-system, at least that's what I remember <tab> being there for.

I've juu=st checked now, and it seems to work without it, so I wonder why.

According to the comments it's:

;; Apropos the trigger key and the fallback binding:
;; When `yas-minor-mode-map' binds <tab>, that correctly overrides
;; org-mode's <tab>, for example and searching for fallbacks correctly
;; returns `org-cycle'. However, most other modes bind "TAB". TODO,
;; improve this explanation.

So if we (define-key yas-minor-mode-map [tab] nil) we'll get a lot of org-mode bitching. Unless we can convince org-mode to use TAB, too. Or put our hook into org-mode-hook. But that's no good, too.

I can take a look at yas--keybinding-beyond-yasnippet again, otherwise I'd rather leave this unsolved with your workaround @npostavs


that might help, might I'm also afraid it'll break snippet expansion in emacsen without a window-system

Without a window-system Emacs always gets TAB and never <tab>, I think. So <tab> bindings should be irrelevant in this case.

With a window-system bindings of <tab> (e.g. from org-mode) take precedence over TAB bindings, so yeah, it's not really a practical fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.