sp-forward-slurp-sexp pushes colon out of expression in JSON

[xelibrion]

Let's say I want to wrap must_not clause inside of another JSON field.

{
  "query": {
    "bool": {
      "must_not": {
        "exists": {
          "field": "foo"
        }
      }
    }
  }
}

So here I wrap field name in curly brackets, hoping to slurp the field value in.

{
  "query": {
    "bool": {
	{"must_not"}: {
        "exists": {
          "field": "foo"
        }
      }
    }
  }
}

I execute sp-forward-slurp-sexp command, but this is not what I would expect. The JSON is invalid now, as the colon between field name must_not and it's value got pushed out of expression.

{
  "query": {
    "bool": {
	{"must_not" {
            "exists": {
		"field": "foo"
            }
	}}:
    }
  }
}

Is there a configuration parameter that can fix this?

[xelibrion]

@Fuco1 this might not be related to specific mode, just had similar behaviour with fundamental-mode

So I wanted to wrap these in [], so it would be a valid list in Python, but did it in scratch buffer, where I had fundamental-mode enabled (instead of lisp-mode):

'ESRI_Imagery_World_2D',
'ESRI_StreetMap_World_2D',
'I3_Imagery_Prime_World'

Here I wrap expression, which works as expected

['ESRI_Imagery_World_2D'],
'ESRI_StreetMap_World_2D',
'I3_Imagery_Prime_World'

After the first slurp, the comma gets pushed out

['ESRI_Imagery_World_2D'
'ESRI_StreetMap_World_2D',],
'I3_Imagery_Prime_World'

The second comma is left intact though.

['ESRI_Imagery_World_2D'
'ESRI_StreetMap_World_2D',
'I3_Imagery_Prime_World'],

And everything works as you would expect in python-mode.

[Fuco1]

Well, fundamental mode is kind of "stupid" in a sense it has barely any config. It works in python because smartparens has it configured.

I think this is js-mode issue with syntax classes. We have some hacks to work round it, it mostly has to do with properly configuring what is a prefix/suffix.

The second comma was not left intact, it traveled with the ] to the end. The one before ] was not considered to be a "suffix" and so did not enter into the computation.

The "suffix" feature is an issue in languages where e.g. ; is a statement delimiter and it has to travel with } and similar. I'm not using JS at the moment so SP has no config for it :/

[arichiardi]

The same happens to me when trying to slurp from:

const ReadFileOptions = {flag:}constants.O_RDONLY | constants.O_NONBLOCK;

All the way down:

• const ReadFileOptions = {flag:}constants.O_RDONLY | constants.O_NONBLOCK;
• const ReadFileOptions = {flag:constants.}O_RDONLY | constants.O_NONBLOCK;
• const ReadFileOptions = {flag:constants.O_RDONLY | constants.}O_NONBLOCK;
• const ReadFileOptions = {flag:constants.O_RDONLY | constants.O_NONBLOCK;}

Is there anything I can do for improving the situation?

[Fuco1]

@arichiardi Isn't yours a sort of inverse problem? I suppose what you expect is to end with the ; outside the block.

Things probably need to be configured such that the ; is not a suffix in general and only when attached to the ) or } pair. This involves setting sp-sexp-suffix and then using sp-local-pair on each of the required pairs with a regexp matching suffixes that have to travel along with the closing delimiter.

The API should be fairly straight forward and there are examples around so it would be awesome if you looked into it and tinkered a bit :) If you take up the challenge and get stuck don't be afraid to ask! I'll add some docs on the things which would be unclear.

[arichiardi]

@Fuco1 yeah it looks like it is a bit different, but isn't smartparens-javascript setting sp-sexp-suffix to nothing exactly for doing this?

[Fuco1]

@arichiardi In js2-mode and js-mode as well the result I get is

const ReadFileOptions = {flag:constants.O_RDONLY | constants.O_NONBLOCK};

What version of Emacs do you use? When you place the cursor over ; and hit C-u C-x = what does the syntax row say?

I use Emacs 24.5 and SP master.

[arichiardi]

@Fuco1 I am in typescript.el and tide, use version 24.5, a bit behind master by a few commits.
That shows: syntax: . which means: punctuation

[Fuco1]

Right. In smartparens there is no mode inheritance, so even if typescript-mode inherits from js-mode (I don't know, does it?) the settings will not be inherited. So we probably just need to add the mode to the list in smartparens-javascript.el and it should work. Would you care to try that and report back?

[arichiardi]

Sure I can try.

EDIT: it worked! -> #748

[Fuco1]

Turns out js-mode provides js feature not js-mode, so our "eval after load" statement was broken.

The OP's problem was fixed all along but the config simply did not load for them :D /shrug

[xelibrion]

@Fuco1 thanks mate! I'll update the version and check it out.