missing the sly counterpart for slime-close-all-parens-in-sexp

[guicho271828]

I miss it!

[svetlyak40wt]

Aren't paredit or lispy modes helps to keep parens balanced?

[joaotavora]

I have a great reluctance in integrating that command in SLY because:

1. That SLIME command is a bag of hacks, I don't know what it does exactly, but its very big and intricate. The kind of thing I avoid in SLY. Is this simpler version enough for most uses? I suspect it won't do some things that the other does, but what?

(defun close-parens-in-sexp (pos)
  (interactive "d")
  (save-excursion
    (ignore-errors (up-list (nth 0 (syntax-ppss pos)) nil t))
    (self-insert-command (nth 0 (syntax-ppss (point))) ?\) )))

2. It doesn't belong in SLY, it belongs in Emacs' lisp-mode. You/we should contribute it there if the usefulness is proved.
3. I believe, like @svetlyak40wt does, that the situation can be dealt differently by using parenthesis-matching tools. However, I dislike these fancy paredit and lispy modes very much because they make you learn new keybindings. If you use M-x electric-pair-mode you don't have to, just type opening parens and closing parens normally.

[svetlyak40wt]

However, I dislike these fancy paredit and lispy modes very much because they make you learn new keybindings.

You miss the magic. Lispy mode is awesome!

[joaotavora]

You miss the magic. Lispy mode is awesome!

I don't want to learn new keybindings, sorry. The most relevant stuff probably already exists in Emacs, maybe you just haven't discovered it... I don't use magit either for the same reason. I program non-lisp languages and often have to type on other people's Emacs.

[guicho271828]

hmm. I will probably fall back to slime because of this. I understand you are very careful about your stuff but unlike a library, this is UI --- messy stuff is always expected because the target is human rather than computers.

[joaotavora]

I will probably fall back to slime because of this

Your call: probably you're not putting SLY's improvements to good use anyway. For example, I saw in your cl-numpy screencast that you could have been using C-r in the REPL, but aren't (great project, by the way)

this is UI

I agree, but why do you think it belongs in SLY and not Emacs?

messy stuff is always expected because the target is human rather than computers.

If you're OK with messy stuff than just use SLIME's definition in SLY, it should work. It has nothing to do with CL connectivity, just parens. Or make a sly-messy contrib. Did you try the code I wrote for you?

Also, this is software. The end target is always humans (or am I mistaken?) and messy software will serve humans poorly.

[guicho271828]

You are missing the point about C-r. If I used C-r the input prompt would not be visible and the watcher will be confused. As a result the presentation is less comprehensive, the message imperfect.

UI library like this sells the experience. My hope was sly is going toward gradually replacing slime and, for that purpose the best presentation is to have all the batteries included experience while maintaining the cleaner, better organized code. You might not be pragmatic or obsessed enough with killing slime (it should be replaced if the code is messy).

I killed Optima by maintaining as much compatibility as possible while maintained cleaner code and better performance. That compatibility costed me some decisions, but it had to be done.

[joaotavora]

You are missing the point about C-r. If I used C-r the input prompt would not be visible and the watcher will be confused. As a result the presentation is less comprehensive, the message imperfect.

I don't understand what you mean. With C-r the REPL input is visible: it behaves quite differently when point is in the REPL. i.e. it does not behave like C-r does in a normal file.

But anyway, if you don't use C-r it, and also don't use the trace dialog, the "copy call to REPL" feature, the stickers, backreferences, etc, then I think it a good decision to go back to slime with all its familiar editing commands.

UI library like this sells the experience. My hope was sly is going toward gradually replacing slime and, for that purpose the best presentation is to have all the batteries included experience while maintaining the cleaner, better organized code.

SLY isn't going to replace any of SLIME's batteries that don't contribute specifically to a CL IDE. I drew this line. There's a grey area there but slime-close-all-parens-in-sexp clearly falls behind it. The stuff that falls behind the line has a name: it's called "cruft" or "bloat", and it's a software maintenance problem.

I'm not saying you shouldn't use that command (actually, I kinda did say that, or I suggested that you could change your habits). But we can add the command: just not to SLY. Did you try the one I gave you? We could add that to Emacs, eventually, where it belongs. Or, if it takes too long, make a contrib. Or if that takes too long, just add to your .emacs.

You might not be pragmatic or obsessed enough with killing slime (it should be replaced if the code is messy).

Indeed, not obsessed with that. Pragmatic yes. We have different views on pragmatism: if you want to quickly "kill" the perceived competition then that pragmatism leads you down a different path than mine.

I killed Optima by maintaining as much compatibility as possible while maintained cleaner code and better performance. That compatibility costed me some decisions, but it had to be done.

Was "killing" Optima, whatever that means, worth those costs?

[guicho271828]

I think I confused C-r with C-c C-r, sorry about that. Just note that I like the new tracing facility, and although I have not experienced with the stickers feature it was what caught my attention and made me try sly after all.

Was "killing" Optima, whatever that means, worth those costs?

Of course. If I don't keep the compatibility, then the new one is not the absolute improvement over the old. It just becomes another "alternative" that contributes to the choice paralysis and the split community. This is all the same as a research paper --- you know, open source projects share many aspects with research --- except for the groundbreaking results, every paper is a solid incremental finding. That's how things improve, and that's how people perceive that things have improved. When people hear "this thing is very good!", they are convinced. But if they hear "this thing is very good! but X is missing", then the impression is very different. The point is this is a mix of technical and social problem of improving the lisp ecosystem we live in. In order to address that, then we need to seriously consider both sides.

[easbarba]

@guicho271828

It just becomes another "alternative" that contributes to the choice paralysis and the split community.

You just describe almost everything on GNU/Linux community software kingdom! :1st_place_medal:

KDE vs Gnome vs XFCE EMACS x VIM x VScode Firefox x Chrome x Opera Ubuntu x Debian x Fedora .....

lol

[joaotavora]

This is all the same as a research paper --- you know, open source projects share many aspects with research --- except for the groundbreaking results, every paper is a solid incremental finding. That's how things improve, and that's how people perceive that things have improved. When people hear "this thing is very good!", t

I say this in all respect, but it's the second time I sense it: you seem to have a one-dimensional view of progress. One thing "replaces" the other. Progress is multi-dimensional, like evolution, where neither humans, horses or amiba are the "tip" of any linear structure, they're just branches in a big tree. And evolution makes ecosystems, and software is an ecosystem.

Perhaps the research culture you participate in is very competitive, with papers "killing" other papers. I hope you can survive it: I like your libraries, they are very intelligent.

But it's a cliché to blame CL's downfall to "choice paralysis". That's wrong: the paralysis lies elsewhere: like you refusing to try the different command that I gave you :wink:. It lies in me and you spending time in this silly argument.

If I don't keep the compatibility, then the new one is not the absolute improvement over the old.

That said, here are a few clichés of my own:

• Few things in life are "absolute".
• Sometimes the costs don't outweigh the benefits. Sometimes they do. I do my own math, and sometimes it doesn't match with yours.

[joaotavora]

By the way, I forgot to mention the main feature that I personally would miss very much in SLY, the flex completions, just M-x package-install RET company-mode and you should be good to go. (Now don't tell me I should rewrite an autocompletion engine in SLY just because SLIME does :wink:).