Extra paren when expanding snippets with yas-hippie-try-expand

[tuhdo]

This does not happen with yas-expand. But it happens with yas-hippie-try-expand for people who want to combine yas with hippie-expand.

[Fuco1]

Is this worth spending time on from our side?

[bmag]

I have also encountered this bug. However, it's not only with yas-hippie-try-expand, but happens also with try-expand-list and try-expand-line.

To reproduce:

• 1. start emacs: emacs -Q -L /path/to/dash/directory -L /path/to/smartparens/directory
• 2. in scratch buffer, paste this code and evaluate buffer:

(require 'smartparens-config)
(require 'hippie-exp)
(global-set-key (kbd "M-/") #'hippie-expand)
(smartparens-mode)
(setq hippie-expand-try-functions-list '(try-expand-list))

• 3. type "(setq", so the buffer looks like this: ("|" is the cursor, smartparens inserted a closing ")" as expected)

(require 'smartparens-config)
(require 'hippie-exp)
(global-set-key (kbd "M-/") #'hippie-expand)
(smartparens-mode)
(setq hippie-expand-try-functions-list '(try-expand-list))
(setq|)

• 4. now press M-/. hippie-expand completed the entire line from above, including ")", so now you have an extra ")" :cry:

(require 'smartparens-config)
(require 'hippie-exp)
(global-set-key (kbd "M-/") #'hippie-expand)
(smartparens-mode)
(setq hippie-expand-try-functions-list '(try-expand-list))
(setq hippie-expand-try-functions-list '(try-expand-list))|)

This also happens with smartparens-strict-mode enabled. In some situations hippie-exapnd is very useful, I'd be happy if this can be solved.

[Fuco1]

That definitely sounds annoying, but I don't see any way this could be fixed without modifying hippie expand.

[Wilfred]

I'm not sure this is something that smartparens can help with. smartparens-strict-mode overrides various edit commands to ensure you have the right number of parens. It can't promise to prevent arbitrary elisp from inserting unbalanced parens.

Presumably the hippie-expand issue shown above still occurs without smartparens-strict-mode?

[bmag]

@Fuco1 I was afraid that's the case, but I understand.

@Wilfred yes

By the way, while looking at smartparens' code I found this piece of, and I couldn't understand why it is needed. Could you enlighten me? (I'm sorry if I'm being annoying)

(defadvice hippie-expand (after sp-auto-complete-advice activate)
  (when smartparens-mode
    (sp-insert-pair)))

[Fuco1]

When you have a pair which is multiple characters and you tab-complete it this will make sure the ending is inserted as well. Maybe hippie expand changed its logic and this now causes problems, I don't know.

[xelibrion]

Just encountered the same issue - it actually breaks yas-template expansions and makes it impossible to navigate within the template.

[npostavs]

Hi, yasnippet maintainer here, coming from joaotavora/yasnippet#785, it seems to me that the problem is that smartparens doesn't handle any hippie expansion that inserts balanced pairs (due to yasnippet internals, the results are more "catastrophic" when a snippet is hippie-expanded compared to the minor annoyance with other kinds of expansion).

Looking at ac1da65d0df30fcd62cb90798431c53750d2966e where the advice was introduced, it seems there was initially some code to check what hippie-expand inserted:

(defadvice hippie-expand (after sp-auto-complete-advice activate)
  (when smartparens-mode
    (setq sp-recent-keys (reverse (split-string (buffer-substring-no-properties he-string-beg he-string-end) "")))
    (sp-insert-pair)))

but the (setq sp-recent-keys ...) has been removed since then. Perhaps it didn't work right, but some analysis of the text between he-string-beg and he-string-end is needed.

[Fuco1]

Thanks for the analysis, I think we might be able to check if yasnippet expand was triggered and choose what to do based on that. I'll put this on the roadmap for the next release.

[npostavs]

check if yasnippet expand was triggered and choose what to do based on that

I posted advice doing that here: https://github.com/joaotavora/yasnippet/issues/785#issuecomment-285437447

Wouldn't it be better to search for the closing pair though? That would fix non-yasnippet expansions as well.