Skip to content
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

Closed
PEZ opened this issue Dec 14, 2019 · 10 comments
Closed

[DiSCUSSION] Paredit and unbalanced forms #524

PEZ opened this issue Dec 14, 2019 · 10 comments
Labels
paredit Paredit and structural editing under discussion

Comments

@PEZ
Copy link
Collaborator

PEZ commented Dec 14, 2019

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):

|[ ) ] =forward-sexpr=> [ ) ]| =backward-sexpr=> |[ ) ]
|[ ( ] =forward-sexpr=> [ ( ]| =backward-sexpr=> |[ ( ]

But what current Calva Paredit does is this:

|[ ) ] =forward-sexpr=> [ )| ] =backward-sexpr=> |[ ) ]
|[ ( ] =forward-sexpr=> |[ ( ]

There is a bit more order to this madness, than that example indicates because there is also this current behaviour:

[ ) ]| =backward-sexpr=> [ ) ]|
[ ( ]| =backward-sexpr=> [ |( ] =forward-sexpr=> [ ( ]|

But it is still madness, IMO. I think it should behave like so (the first example repeated for your convenience:

|[ ) ] =forward-sexpr=> [ ) ]| =backward-sexpr=> |[ ) ]
|[ ( ] =forward-sexpr=> [ ( ]| =backward-sexpr=> |[ ( ]

[ |) ] =forward-sexpr=> [ |) ]
[ |( ] =forward-sexpr=> [ |( ]

[ )| ] =forward-sexpr=> [ )| ]
[ (| ] =forward-sexpr=> [ (| ]

I think it could be phrased as:

  1. If there is a balancing bracket, it should be treated as a sexpr, regardless of unbalance within the sexpr.
  2. If there is no balancing bracket, it should not be treated as a sexpr.

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.

@PEZ PEZ added under discussion paredit Paredit and structural editing labels Dec 14, 2019
@RobertARandolph
Copy link

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.

@PEZ
Copy link
Collaborator Author

PEZ commented Dec 14, 2019

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?

@RobertARandolph
Copy link

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.

@PEZ
Copy link
Collaborator Author

PEZ commented Dec 14, 2019

😄 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.)

@RobertARandolph
Copy link

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?

@PEZ
Copy link
Collaborator Author

PEZ commented Dec 14, 2019

What would ignore unbalanced parens mean, in terms of navigation?

@RobertARandolph
Copy link

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 :)

@PEZ
Copy link
Collaborator Author

PEZ commented Dec 15, 2019

Essentially treat it as whitespace?

@RobertARandolph
Copy link

Essentially treat it as whitespace?

That's the idea, yes.

@bpringe
Copy link
Member

bpringe commented Dec 20, 2019

Treating unbalanced parens as whitespace, or otherwise ignoring them seems like the best approach.

@PEZ PEZ closed this as completed in 5ea99c5 Feb 28, 2020
PEZ added a commit that referenced this issue Mar 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
paredit Paredit and structural editing under discussion
Projects
None yet
Development

No branches or pull requests

3 participants