howl-editor / howl

The Howl Editor
http://howl.io
Other
712 stars 68 forks source link

`editor_reflow_paragraph` should take comments and indentation into account #340

Open esthermations opened 7 years ago

esthermations commented 7 years ago

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.

  1. When filling a line which starts with a language-appropriate one-line comment string (-- 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).
  2. When filling text which is indented by some number of spaces or tabs, those indent characters should be repeated onto the filled lines, so all the text lines up nicely.

When filling this text:

// this is a very very very very very very very very very very very very very very very long comment.

Emacs does this:

// this is a very very very very very very very very very very very very very
// very very long comment.

While Howl does this:

// this is a very very very very very very very very very very very very very
very very long comment.

And when filling this text:

{
    {
        // this is a really really really really really really really really long comment.
    }
}

Emacs does this:

{
    {
        // this is a really really really really really really really
        // really long comment.
    }
}

And Howl does this:

{
    {
        // this is a really really really really really really really really long
comment.
    }
}

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.

ozra commented 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]

shalabhc commented 7 years ago

@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.

ozra commented 7 years ago

Ah, no I was referring to hard wrapping here. Of course, when it comes to code, naturally a formatter needs to be invoked ofc.