Open noncom opened 9 years ago
Yeah I am looking at paredit for some other feature and it might ignore whitespaces in that occasion.
Yes, I too think that totally removing the spaces and just behaving as in the case 4 of the illistration in the OP is the best thing that can be done here - it feels like the most clean and baseline option.
I confirm that the original paredit keeps the space, therefore:
| (form)|
becomes ( (form))
Hmmm, does it keep only 1 space or as many spaces as there are? (sorry, the github markup does not support multiple spaces in that place, they all collapse into one).
just checked, it keeps all of them.
When I have the following selection in the editor:
|(form)|
and I press(
, then paredit correctly transforms it into((form))
. However, if there are extra spaces included in the selection on either side of the form, then paredit simply does nothing when I press(
:| (form)|
--> press(
-->(form)
incorrect|(form) |
--> press(
-->(form)
incorrect| (form) |
--> press(
-->(form)
incorrect|(form)|
--> press(
-->((form))
correctThe number of spaces can be any (github markdown restricts it to 1 space, but that would be same for any number of spaces). It would probably be the same even for tabs, but, interestingly, not for new lines.
Doing this operation with new-lines puts the parenthesis exactly in the places where selection had its start and end, preserving all the new lines and everything. I wonder if this should be the case with spaces too - preserve the spaces, or not... obviously, preserving more than 1 space is superfluous since there can be justification for preserving 1 space, but not more of them.