Any way to automatically limit comment line width in racket files to a certain value?

[amosnier]

Assuming a very long comment line in a racket file, like:

; This is a very long line, is there some kind of automatic tool that would chop this to chunks of a reasonable length for me?

I would assume running raco fmt on such a file would chop the comment to chunks of 80 characters (the default raco fmt line width), but that does not seem to happen, although other formatting is taken care of. Any way to get such auto-formatting? I am running racket 8.8.

[sorawee]

The answer is currently no. The problem is that I don't know how to break comments up.

• We could try to break them exactly at the line width limit, but that could split a word like "Racket" into "Ra" and "cket", which I think is undesirable.
• We could try to break them while respecting the word boundaries, but the comments could be an ASCII art like this (which is kinda common in some Racket code base). Breaking them would make them unreadable.

[amosnier]

Thanks for the quick answer. Understood.

[Metaxal]

If you're happy with a semi-automated version and you're using DrRacket, Alex Harsanyi wrote a quickscript to justify text in comments:

https://github.com/Quickscript-Competiton/July2020entries/blob/master/scripts/format-selection.rkt

It's part of the quickscript-competition-2020 package:
https://pkgs.racket-lang.org/package/quickscript-competition-2020

[amosnier]

Thanks @Metaxal. My editor is Vim, which happens to have a fairly well working all-round solution for re-flowing comments. Unfortunately, vim-racket shortcuts it by redefining formatprg. I tried to just manually redefine equalprg to raco fmt instead of using vim-racket, but it seems that if raco fmt finds an error in my code, like a non-closed parenthesis, it will print an error message instead of the filtered code to standard out. Or maybe to standard error, I'm not sure, but I could not see my code in standard out, which would make raco fmt unusable as a default formatting filter in an editor.

For now, I'm using smcindent as equalprg, and that works well enough for me. But if I am missing something obvious, I am all ears.

Other than that, I am using Racket as an interpreter for IEEE Scheme (working though SICP), and I really love the fact the the Racket community maintains such an interpreter. This is extremely valuable!

[sorawee]

Ah, that should be fixed then.

[amosnier]

@sorawee, since you are so kindly reopening, let me try to reproduce the error case I am describing with a minimal example:

$ raco fmt
4
4

Please note that after the first 4, I press <return> and <ctrl-d>. raco fmt then outputs my unchanged input, which is what I expect. On the other hand:

$ raco fmt
(define
1:1:0: expected a ) to close (
context...:
/usr/local/share/racket/collects/syntax/readerr.rkt:15:2: -raise-read-error
.../match/compiler.rkt:559:40: f123
/home/alain/.local/share/racket/8.8/pkgs/fmt/read.rkt:123:0: read-top
/home/alain/.local/share/racket/8.8/pkgs/fmt/main.rkt:27:0: program-format
/home/alain/.local/share/racket/8.8/pkgs/fmt/raco.rkt:115:0
body of "/home/alain/.local/share/racket/8.8/pkgs/fmt/raco.rkt"
/usr/local/share/racket/collects/raco/raco.rkt:41:0
body of "/usr/local/share/racket/collects/raco/raco.rkt"
body of "/usr/local/share/racket/collects/raco/main.rkt"

That is when pressing <return> and <ctrl-d> after (define. There my input is gone, which might be intended, but makes the program unusable as a filter, as far as I know.

[jackfirth]

@sorawee You could only add line breaks to comments, and never remove them. So comments that are too long get split, but lots of short comment lines don't get merged. That would preserve ASCII art unless the art is too wide, which seems like a reasonable compromise.

[amosnier]

When it comes to output issue when the input has an error (should that be moved to a separate issue?), I can confirm two things:

1. The error message is sent to standard error.
2. In case of error, raco fmt returns, as would be expected, a non-zero value (one, in practice), at least in the cases I have tested.

So, in fact, the situation is a little frustrating because it would be really easy to work around the issue of non-usability as a formatting filter if only the program would output the entire input to standard out (or the actual file if -i is selected) in case of error. Then, using it as a filter would be as easy as adding 2> /dev/null to the command line.

Unless there is a solution for this in the short term, my plan is to write a Bash script that basically will do what I describe above, based on the raco fmt output. Since it returns a non-zero value in case of error, that should be feasible. I could of course try to solve the issue myself in this repository, as an alternative. I guess that would be working in Racket? Not sure whether I'm up to it right now. When it comes to Lisps, I just have a little experience of Lisp and Scheme, and none of Racket.

The comment issue is actually less crucial for me, since I can rely on Vim for that.