Open esthermations opened 7 years ago
I'd like to add the note that: it could be interesting to have a setting to wrap comments only, or wrap code (semantically) only, ant not comments. Or both obviously.
The idea for allowing only comments to go past 72 / 80 / whatever, is to rely on tooltip'ing full comments.
I think there are valid reasons for both behaviours. More configurability = more awesomeness.
[ed: obviously, hard-wrapping one-line comments without prefixing them with the right token is a bug]
@ozra are you talking about line wrapping feature (which doesn't modify the text at all, only the displayed lines)? This bug is about reflow-paragraph which injects newlines into the text. I rarely use reflow -paragraph for actual code - it's mainly for large chunks of text such as comments or md files.
Separately, I do think your suggestion of line wrap for code only is interesting.
Ah, no I was referring to hard wrapping here. Of course, when it comes to code, naturally a formatter needs to be invoked ofc.
The
editor_reflow_paragraph
seems to be an analogue to Emacs'fill-paragraph
. There are a few cases where it could be improved to be more similar.--
for Lua,//
for C, etc), that comment string should be repeated on every line the text gets filled onto (so all the text stays as comments).When filling this text:
Emacs does this:
While Howl does this:
And when filling this text:
Emacs does this:
And Howl does this:
Obviously in both cases, Howl's fill behaviour is less convenient and always requires extra work to get it the way you want.
Also note that in the last example, Howl's filled comment is longer than Emacs', and actually goes past the 80 column limit. If I were to guess, I'd say that's because it assumes tab characters are 1 space wide, but I'm not sure.