Double quote behavior inconsistent

[jgarvin]

Emacs 24.4, running with -Q, loading just dash and smartparens-config. You can get 3 different behaviors when you write a double quote:

1. Write a double quote, then do so a second time without inserting any other characters into the buffer. The first time you press double quote, you get "|". The second time you get "\"|\"". Almost certainly not what you want.
2. Write a double quote. then write a word without spaces, then another double quote. The first time you get "|", then you add your word, "hello|", then you press the second quote, and it closes the string, "hello"|. This is the behavior I would always expect and the one consistent with how parenthesis behave.
3. Write a double quote, then write two words with a space between them, then another quote. "|" -> "hello world|" -> "hello world\"|\"", similar to the first behavior. Almost certainly not what you want.

[Fuco1]

Agreed, I should probably make the defaults better. For me, all three cases behave as 2, which is probably what you would always want.

Or this is a 24.4 introduced regression. I haven't updated yet. If you have 24.3 or some older version, could you please check if the behaviour is the same?

[jgarvin]

The other emacs I have installed is 23.4.1. This version acts differently but still not right. Scenario 1 is the same. Scenario 2 and 3 are swapped -- now it requires a space to work, and if you don't provide one will try to nest the quotes.

I should add in this version I have to include my own copy of cl-lib 0.3, and it complains about lexical binding when it works correctly in Scenario 3 but gives no error in Scenarios 1 or 2. Those errors are what made me decide to bother installing 24.4 ;p

Edit: should add all my testing is in the emacs scratch buffer, though I've seen the same behavior in python buffers.

[dpathakj]

On GNU Emacs 24.3.1 with just smartparens.el and dash.el I've seen (1) and (2) but not (3). (1) seems like a bug--if you don't see it, do you know what configuration of yours is fixing it?

[sooheon]

The three cases behave as 2 for me on 24.4, but there is a fourth:

Write a double quote, write any number of characters, delete any number of characters, write a double quote again. For example, a double quote, followed by helloo, followed by a single delete and a closing quote results in the following: "hello\"|\""

In other words, the normal use case of seamlessly closing a double quote by typing another " is disrupted should you make any edits that require delete.

[jgarvin]

@sooheon are you using -Q?

[sooheon]

@jgarvin It turns out the behaviour I was seeing after backspacing within a pair was determined by sp-cancel-autoskip-on-backward-movement. Setting this to nil solved my issue.

[mpontus]

With or without escaping, auto-skip currently doesn't apply to empty strings in single and doublequotes.

[sooheon]

I see the same behaviour as @MyEffort with 24.4.1 and the latest melpa smartparens.

[Fuco1]

The issue with double quotes is now fixed in fa4fb22. Single quotes still behave somewhat odd (at least in python and php modes). I'm on it right now.

[Fuco1]

Could any of you please verify that the problems are gone?

[sooheon]

These specific problems are gone, but a new bug is here. Values of sp-cancel-autoskip-on-backward-movement t and sp-autoskip-closing-pair 'always are not respected.

With those two variables set, try the following:

1. type "hello world"
2. M-b back to middle space, and delete it, leaving "hello|world"
3. Press "

This will split the string, while the above settings means you should get sp-up-sexp, i.e. autoskip closing pair.

[Fuco1]

Hm, I don't think it ever worked with quotes. Which is not to say it shouldn't.