-
-
Notifications
You must be signed in to change notification settings - Fork 195
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sp-{forward,backward}-sexp should not jump up if there's nothing to jump over #1038
Comments
You are right, this is a "feature" and has been since the very beginning. For some reason I didn't really like the default behaviour. I think it should be possible to tweak the code somewhere to allow what you are proposing though. The function We can't change |
I was going to ask that same question - and found this! Wrt. Could you just define a completely new function like Thanks! |
To jump back to the end, you can call
Similarly There's also
Sure, we just need to keep the current one working as it is in case there are some scripts relying on this behaviour. |
Thanks!
…________________________________
From: Matus Goljer ***@***.***>
Sent: Saturday, May 29, 2021 11:28 AM
To: Fuco1/smartparens ***@***.***>
Cc: joswik ***@***.***>; Comment ***@***.***>
Subject: Re: [Fuco1/smartparens] sp-{forward,backward}-sexp should not jump up if there's nothing to jump over (#1038)
To jump back to the end, you can call sp-backward-down-sexp at the beginning of the sexp:
If the point is inside sexp and there is no down expression to
descend to, jump to the end of current one. If moving forward,
jump to beginning of current one.
Similarly sp-down-sexp will jump to beginning if at the end.
There's also sp-end-of-sexp which does this from any position.
Could you just define a completely new function like sp-forward-parallel-sexp,
so 'If calling `sp-forward-sexp' at point would result in raising a level up' just do nothing?
Sure, we just need to keep the current one working as it is in case there are some scripts relying on this behaviour.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#1038 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AEOHRQS64TW2EKYAKRPJE2DTQDFUXANCNFSM4NYEEBGQ>.
|
Was this ever implemented? Neither |
This option will cause `sp-forward-parallel-sexp` and `sp-backward-parallel-sexp` to raise a `user-error` when hitting the end of the enclosing sexp, rather than looping back to the other end. Fixes Fuco1#1038.
This option will cause `sp-forward-parallel-sexp` and `sp-backward-parallel-sexp` to raise a `user-error` when hitting the end of the enclosing sexp, rather than looping back to the other end. Fixes Fuco1#1038.
Expected behavior
If
sp-{forward,backward}-sexp
(and all their related sister functions) is invoked in a position where there are no more balanced expressions to skip over, it should fail and not move the point. This is what built-in{forward,backward}-sexp
does. Ie.(foo (bar baz|))
→(foo (bar baz|))
=> forward-sexp: Scan error: "Containing expression ends prematurely", 387735, 387736
Admittedly, that's not a particularly helpful message, but the resulting behaviour is exactly as expected.
Actual behavior
It jumps up a level and starts operating on sexps there. This is documented as being so with no way to disable that fallback:
This seems like it was meant as a convenience, but it effectively means the command will never stop doing things until it hits the end of file. That is a big problem because it means I now have to watch it closely and can't rely on it to tell me when I hit the end of the enclosing sexp, which defeats the purpose of having a structured navigation command do the paren matching for me. It's even more of a problem when writing code that uses it, as the result will silently change to something vastly different than what the promise was. In fact, I discovered the "fallback" when creating a keyboard macro to do some ad-hoc reformatting of a long list, as normally I can just hold F4 till it runs out of things to edit, since macros abort whenever a command fails, but with smartparens commands it just started applying the same commands in unrelated parts of the buffer.
As far as I can tell, the behaviour seems to be baked into
sp-get-thing
, so unless I'm mistaken, there's no way for any client code to reliably tell when it's at the end of an enclosed sexp?Environment & version information
smartparens
version: 20200324.2147major-mode
:emacs-lisp-mode
M-x emacs-version
): GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14) of 2020-03-26, modified by DebianThe text was updated successfully, but these errors were encountered: