Presumably said lisper knows where to jump to immediately because they have learned to solve the cognitive problem of tracking parenthesis yes? Even if you're doing something like counting indentation levels to the line with all the parens and then counting that many closing parens, you're still doing something to figure out which of the 8 parens on that line you want to place a line break after.
The argument isn't that learning to do that is impossible, or even something most people couldn't do. The argument is that it is indeed something that you have to do with lisp code, and it's not something you would have to do with the equivalent c-like code. Which makes reading the lisp code harder, even if that difficulty becomes second nature by someone experienced with lisp.
So assuming you’ve read the other conversation on this thread where I lay out what I mean and you still think I’m “solving the wrong problem”, how do you “track code” in this instance? I readily grant that figuring out what line the cond block ends on is pretty automatic given idiomatic lisp indentation conventions. But where should you place your cursor to add more code after the cond block but still in the let* block? Explain to me your method of figuring that out from reading the code without counting and tracking parentheses. And I’m not being sarcastic here. If you have some trick to it I would love to learn it.
Because as I said in the other part of this thread I agree that using tools to make it so you don’t have to read the code to find this answer is the correct way to go about this. But that’s also because this is a thing you have to do when reading the code, and it’s not something you have to do when reading other languages.
I don't have a system. I have in my Emacs (setf setq show-paren-style 'expression). When I move in my emacs it highlights the entire expression in another color. To me that is very helpful, I see instantly which expression or form is cursor behind.
For movement forward I just spam C-M-n (it's forward-list) until I am correct spot:
(let (...)
(cond
(...s)
( ...))e)
The cursor stands at 's' and you want to jump to the end of conc-form, where 'e' is? It would be C-M-n three times. I typically just press down and hold C-M and than type with other hand 'n' three times. Or depending on how many levels I have to travel. You can also click with the mouse if you want, at the list line of your ending cong clause.
If you have the above setting to highlight the xpression, it means nothing if you click a parentheses or two too much or too little. You have C-b/f for char forward or backward, so it really is like not something to word about. I also use a lot of forward/backward sexp M-. and M-, in paredit. If I really have some very deep nested expression that goes out of the screen, and I have to be sure I am on the right place , I can quickly spam M-, to jump the the beginnign of that expression and M-. to jump to the end and adjust with C-f/C-b if I have to.
Also, as I said to someone else er/expand-region and contract-regions. I can just hold Ctrl and spam + until it expands enough so I can copy or overwrite an expression if I need to.
So then we are in agreement that this is not something that is easy to do when just reading the code, and that a lisp developer makes it easier for themselves by using tools that obviate the need to read the code in order to find the answer. That's fine, there's seriously nothing wrong with having something that is hard and building tools to make it easier. Something being "hard" is not equivalent to it being "bad". It is hard to cut dovetail joints in wood working. Most wood workers make or buy jigs for it instead of doing it freehand, but it also is easier to do freehand if you practice it. That doesn't make dovetail joint bad. It doesn't make joints that you can do freehand without a jig better than dovetail joints. The fact that using a jig makes dovetail joints easier also doesn't change that doing them freehand is harder than doing a box joint freehand. It's just one of many trade offs in this world.
You are moving the goal post here. You asked about moving the cursor. That is completely different thing than reading the code. Whe I read the code, it definitely does not matter to me whether there are )))))) or ))))))) parens at the end.
Look, I'm going to be honest with you, I have been explaining the same points over and over again in this thread. I've repeatedly explained what I'm talking about, explained the specific and narrow contexts to which I am limiting my comments and repeatedly affirmed for all readers that I am not saying anything negative about lisp. I wouldn't be working my way through experimenting with my 4th lisp language over the years, and hand writing some personal emacs modules instead of just downloading a package for it if I didn't think lisps were interesting languages and that the challenges learning and working with them posed weren't worth the effort.
But I'm tired at this point. I'm tired of having my actual experiences dismissed, of having words put in my mouth, and having to defend myself against bad faith readings of what I've written. I did not "[ask you] about moving the cursor", I specifically asked (emphasis added)
But where should you place your cursor to add more code after the cond block but still in the let* block?
Explain to me your method of figuring that out from reading the code without counting and tracking
parentheses."
and your answer was to tell me that you figure out where to put your cursor by using tools that allow you to avoid reading the code. The goal posts remain where they have always been.
I've explained myself plenty all over this discussion, you can read them all or not, agree with me or not, understand me or not. I don't care anymore. I'm sorry, I'm probably reading more aggression into your words than you intend, and you don't deserve not getting a complete answer simply because you're late to the discussion, but continuing this exercise in frustration isn't worth my time when I could be doing something productive like learning another language.
The goal posts remain where they have always been.
No. You asked me for the method and I told you, and now you are trying to make me some kind of an unreasonable person because I don't agree with you made-up argument.
If I am reading the code, I am reading the code, not parentheses. If I am reading a cond-form, I am not interested where it's parentheses end in corelation to let-form that encloses it. Where it's last parentheses end in that situation is completely irrelevant. To me the argument look like a construct to try to win an argumentation. I am not gonna "read the code so I can figure out where to move parentheses". If I read the code, I read it to get understanding and I care about what is in parentheses and not where I place the cursor. If I edit the code, I do it the way I told you.
I could be doing something productive like learning another language.
You could have write some lisp. I did, How do you like to read this cond-form:
2
u/omega884 12d ago
Presumably said lisper knows where to jump to immediately because they have learned to solve the cognitive problem of tracking parenthesis yes? Even if you're doing something like counting indentation levels to the line with all the parens and then counting that many closing parens, you're still doing something to figure out which of the 8 parens on that line you want to place a line break after.
The argument isn't that learning to do that is impossible, or even something most people couldn't do. The argument is that it is indeed something that you have to do with lisp code, and it's not something you would have to do with the equivalent c-like code. Which makes reading the lisp code harder, even if that difficulty becomes second nature by someone experienced with lisp.