@lexi.lambda Thanks you, that explains why the limitation is justified. It surprised me because identifier-binding seems to handle just renaming OK, and just contract-out OK. But not the composition. ¯_(ツ)_/¯

Anyway I spent more time reviewing that defn.rkt code and found some ways to simplify it, and to make it faster (or at least, fail faster).

grr. The elided syntax printing makes paredit-mode crazy. e.g. #<syntax:/path/to/file.rkt:140:10 (module m racket/ba...> is an unbalanced sexpr.

…paredit can’t ignore printed output?

paredit ignores commented regions, but not-ignores everything else I’ve logged quite a few hours with it enabled in Racket REPL, with many varieties of Racket values #<syntax> are the only the only things ever seem to print unbalanced like this It’s not terrible it’s just an annoyance

Before: #<syntax::5253 (module file racket (module a...> file.rkt> Type ( and instead of #<syntax::5253 (module file racket (module a...> file.rkt> () It is: #<syntax::5253 (module file racket (module a...> file.rkt> () :face_with_rolling_eyes:

Because “obviously” we should be indenting the “language” element of a module form. :cry:

Yes I realize this will turn out to be actionable, not in Racket or paredit, but instead in racket-mode i.e. me :slightly_smiling_face:

Is there really no way to tell paredit “hey, this region is output, please do not touch”? It seems weird for (displayln "(") to break the whole buffer.

@lexi.lambda you mean the open paren in the string is being treated as if not in a string?

I don’t use emacs, so I wouldn’t know, but I wasn’t talking about the literal expression (displayln "("), I was talking about its output

oooh. paredit in the repl… yeah. that’s problematic

I don’t have a solution for that and was why I was looking at other alternatives to paredit at one point, but it was still the most solid choice for my work.

paredit admits “Paredit behaves badly if parentheses are unbalanced, so exercise caution when forcing Paredit Mode to be enabled, and consider fixing unbalanced parentheses instead.” So using it in a REPL is, in principle, no guarantees. And if I had a Racket program doing “exotic” displays, I would expect things to break. And I could temporarily disable paredit.

But I’m talking about the printed form of Racket values — what you’d encounter as the result of expressions.

And it just seems weird to me that the only one that regularly emits an unbalanced sexpr, is syntax.

I go literally months with no issues with paredit in the REPL, until I start doing stuff with syntax that gets elided.

Hmm. racket-mode has a racket-pretty-print setting that, when t, uses pretty-print instead of the usual print in the REPL.

Maybe I should just tweak that to be a pretty-print with an exception for syntax.

With the multi-line indentation of pretty-print, but preserving syntax info unlike syntax->datum.

And/or, to answer your question/suggestion @lexi.lambda, there is probably some way for racket-mode to put program output into the REPL in a distinguished way that paredit will ignore.

I think your assertion that only syntax will print that way is wrong. The default value for error-value->string-handler also truncates using ... and makes no attempt to maintain matched parentheses. Therefore, you get results like this: > (raise-argument-error 'foo "bar?" (make-list 100 #f)) foo: contract violation expected: bar? given: '(#f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f...

That can happen regularly in syntax errors, since they can print s-expression versions of syntax objects.

Oh, actually racket-mode follows xrepl’s example in this regard and displays errors and other “notifications” as comments.

> (raise-argument-error 'foo "bar?" (make-list 100 #f))
; foo: contract violation
;   expected: bar?
;   given: '(#f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f...

Ah, that does sidestep the problem.

But display output from your program, won’t be commented like that.

I could try to wrangle it into the Emac buffer distinguished some other way, that paredit would ignore.

I’m sure it’s possible somehow. After all, this is emacs. The only question is how many kludges and sacrificial victims are required.

I just feel like printed values by read-eval-print-loop should be balanced sexprs because reasons. :slightly_smiling_face:

For what it’s worth, ~.a and friends will also truncate with ..., but I don’t know that those are actually used very much.

(And ~e uses error-value->string-handler directly.)

I think the printed result of ~.a and friends are strings? i.e. "1234..." is a balanced sexpr.

Right, but if you wrote (printf "~.a" x), then you’d get it without the quotes.

I’m distinguishing values printed in a REPL (the result of that would be void which prints nothing) from arbitrary output a program can make.

But anyway, I’m sure you’re right there are other exceptions besides syntax.

syntax is the one that happens to me enough to be annoying, so I’m going on way too much about it here, sorry.

print-syntax-width can at least control — with +inf.0 even eliminate — the elision: https://docs.racket-lang.org/reference/Writing.html#(def._((quote._~23~25kernel)._print-syntax-width))