sometimes eats trailing parens when used with js3mode

[jmarca]

I am using autopair with js3mode

When I type the following, I don't get what I expect:

What I type:

it('should just work')

that is fine. but then when I add the callback function argument:

it('should just work',function()

notice, I've only typed the opening parenthesis after function, and it did not echo the closing parenthesis. Then, when I finish defining the function like so, and type the closing parenthesis, I get:

it('should just work',function(done){

}

The second parenthesis is gone, and should be outside of the closing brace.

This is just a conflict of some sort with js3 mode, as far as I can tell. When I type the same stuff in, say, a markdown file, I get:

it('should just work',function(done){

})

Again, notice the second parenthesis isn't gone, but is outside of the brace.

Thanks

[joaotavora]

I can't reproduce this. I installed js3-mode, even though it's a third party package for which autopair gives no guarantees, and I get the same as you get in markdown-mode, i.e. perfectly balanced braces, curly, and quotes. You must have something conflicting in your .emacs or your configuration, but you provided no information that allows me to faithfully reproduce your environment, such as emacs versions, minimal .emacs snippet, versions involved, etc. So closing until you do that.

[jmarca]

Fair enough.

I'll keep trying. Sorry for the noise.

James

This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

[joaotavora]

No need to apologize, just put your .emacs to the side and relaunch emacs (alternatively, launch with emacs -Q). Then do just this

(add-to-list 'load-path "path/to/js3-mode")
(add-to-list 'load-path "path/to/autopair")
(require 'autopair)
(require 'js3-mode)
(autopair-global-mode)
(find-file "z:/tmp/something.js")

Then try your original example, which was clear enough. If you still get breakage tell me, otherwise the problem lies elsewhere in your .emacs. I can help you track it down. BTW in emacs-24.4 there is electric-pair-mode which I recommend over autopair.

[jmarca]

Yep, you are absolutely correct. Moving my .emacs.d aside and doing the simplest possible as you described shows that there is no conflict, but rather something else in my horribly crufty .emacs.d/ is broken.

(That's the problem with gradually adding new features over the years and then discovering packages and melpa and all that good stuff about a year ago and just grafting the whole thing together.)

So autopair is working fine with js3-mode on: "GNU Emacs 24.3.1 (x86_64-slackware-linux-gnu, GTK+ Version 2.24.17) of 2013-04-23 on hive64"

I will clean up my init mess and try to figure out where the problem is.

Thanks

[jmarca]

Okay, I take that back.

I just realized I wasn't testing with js3 mode, but rather with javascript mode

When started emacs -Q and then did this:

(add-to-list 'load-path "~/.emacs.d/elpa/js3-mode-20130904.1444/")
(add-to-list 'load-path "~/.emacs.d/elpa/autopair-20140311.1211/")
(require 'autopair)
(require 'js3-mode)
(autopair-global-mode)
(autoload 'js3-mode "js3-mode" nil t)
(add-to-list 'auto-mode-alist '("\\.js$" . js3-mode))

and then edit some file, test.js, I get some strangeness:

when I type the following, it is fine:

describe('it should',function)

but then when I open the parenthesis after the function, the auto-close fails, and the close parenthesis eats the auto-generated close, as follows:

describe('the first test',function(){

}
// missing the close parenthesis in the line above here

But then, strangely, if I keep typing, nested stuff works okay:

describe('the first test',function(){
  it('should work',function(done){
     // the close parens works fine here
  })
  it('should call synchronous code',function(){
     // and it also works fine here
  })
}
// but this final close parens was eaten way up above

More strangeness, if I first fix the missing close parens, so I have:

describe('the first test',function(){

})

and then I type inside the syntactically correct call, then autopair seems to shut down:

describe('the first test',function(){
  it('should work fine',function(done){
})

In that snippet, the first open parenthesis after it( failed to create a paired close parens; the quotes autopaired fine; the open parenthesis after function( triggered a paired close parens fine; the open brace failed to autopair a closing brace.

As you suggested, I will try to use electric-pair-mode, but I wanted to feed more bug reports if this is useful to you.

Thanks, James

[joaotavora]

It is useful, let me reopen it and I'll have a look soon.

[jmarca]

Just noticed something. I think it is related to the syntax highlighting of js3-mode, perhaps some sort of fight with which process gets to parse the text first?

I was just writing some tests and had a typo:

describe('fix component names',function(){

    it('should fix wim names with a direction',function(done){
        var fixed = fix_component_names('south',['wimid_27'])
        fixed[0].should.eql('wim.27.S')
        return done()
    })
    if('should fix')

})

The open parenthesis after "if" auto-generated the close parenthesis. Without the typo, properly using "it" not "if", then I don't get the close parentheisis:

describe('fix component names',function(){

    it('should fix wim names with a direction',function(done){
        var fixed = fix_component_names('south',['wimid_27'])
        fixed[0].should.eql('wim.27.S')
        return done()
    })
    it('should '

})

After typing the "if" it is highlighted red, as a syntax error (if without the condition). Type the open parens, and the close shows up.

After typing the "it", it is plain white (no syntax highlighting). Type the open parens, and it doesn't close.

So maybe after the syntax error, the JS3-mode parser switches off, allowing the autopair parser to get in there first? Whereas when the "it" is written, the JS3 parser is still watching the text to decide how to color it, thus conflicting with the autopair parser??

Note this is in my regular working emacs setup, not in the "cleanroom" version.