-
-
Notifications
You must be signed in to change notification settings - Fork 222
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
[DiSCUSSION] Paredit and unbalanced forms #524
Comments
I think the issue is that we're talking about sexps here, and that doesn't necessarily have anything to do with parens. If you want to have consistent behaviour then calva's paredit should have a forward/backward-paren and a forward/backward-sexp that work as the name indicates. It's really useful to have a forward/backward-paren for navigating code (especially combined with up/down-sexp commands), and it's one of the things I've missed most from my emacs config. |
I think maybe you'll find those as forward/backward list in Calva. Let me know if you lack anything here: https://calva.readthedocs.io/en/latest/paredit.html I agree that sexps do not necessarily have anything to do with parens, but the discussion here is about unbalances, which makes it about parens, right? |
Yes, but your example used sexp commands :) If it was about the list commands then paren balance matters. It seems that this is about if a single unbalanced paren is a sexp, or if it's not. |
😄 Yeah, I focused on the sexps movements because they are the more primitive. Internally in Calva they are used for moving forward/backward, up/down lists, for instance. I think you are right in how the question could be phrased. Not sure if it is the whole question, I need to think a bit more on it... But, at least, if we answer yes, unbalanced parens are sexps, then we would get a consistent behaviour, compatible with the first part of my suggestion, but not the latter. If they are not sexps, then, in theory, we would get the behaviour I suggest. But technically I think I would run into problems implementing it. (Because I move sexp, by sexp to find the matching paren of a sexp, if that makes any sense.) |
Perhaps another way to look at it: what situations are unbalanced parens coming up where sexp navigation makes sense? If I see unbalanced parens then that means I did something "wrong", and I'm probably looking to fix it. So the behaviour that gets me to the unbalanced paren is the optimal behaviour? It could also mean that some sort of option for 'paredit ignore unbalanced paren' would be an option to consider. That would allow the user to navigate naturally to the erroneous location. Personally this is the behaviour that I prefer (and how I had my old emacs setup after A LOT of work). I suspect it'd be equally difficult for calva paredit? |
What would ignore unbalanced parens mean, in terms of navigation? |
Any character identified as an unbalanced paren is invisible to navigation commands. That would mean there's no way to place the cursor after an unbalanced paren, but only after the thing before it, or before the thing after it. It cleans up the issue of unbalanced paren navigation without relying on another extra layer of rules. An unbalanced paren doesn't exist to anything except the delete key. Just an idea :) |
Essentially treat it as whitespace? |
That's the idea, yes. |
Treating unbalanced parens as whitespace, or otherwise ignoring them seems like the best approach. |
When dealing with unbalanced forms it is a bit unclear if the Paredit commands work correctly or not. In a sense, all bets are off when there is unbalance in the force. The center will not hold.
Be that as it may, I think the current behaviour can be improved. Take these two examples:
My intuition is that if the cursor is at the start of either line, and I perform Forward Sexpr the cursor should end up at the end. And vice versa for Backward Secpr, Like so (I hope the notation makes sense to you):
But what current Calva Paredit does is this:
There is a bit more order to this madness, than that example indicates because there is also this current behaviour:
But it is still madness, IMO. I think it should behave like so (the first example repeated for your convenience:
I think it could be phrased as:
Would you agree?
I'm not sure if it will be worth it trying to fix it so that it behaves like this. (Beacause I suspect it might be a bit of a can or worms). But I'd like to get a grasp of it and take a conscious decision, because forward and backward sexpr are Paredit primitives and will influence a lot of other Paredit behaviour. For instance Strict Mode backspace/delete, which won't let you delete either of:
I encourage you to try.
Please chip in with your views and your examples of unbalances where you see there is a correct behaviour. If you know how other Paredit implementations behave, please share. Right or wrong, there could be a value to just doing it the same way. Even if I would prefer to really dig up some truth and implement that. Truth is the highest currency of all in my book.
The text was updated successfully, but these errors were encountered: