M-q does not work well for block comments

[jstolarek]

Say I have a comment like this:

--   1. a bullet and lots of text in it so
--      that it spans several lines blah
--    blah blah blah

If I press M-q on the second line of the comment all lines in bullet (1) get indented like this:

--   1. a bullet and lots of text in it so
--      that it spans several lines blah
--      blah blah blah

However, if I convert that comment to block comment:

{-
   1. a bullet and lots of text in it so
      that it spans several lines blah
    blah blah blah
-}

and hit M-q on the second line of a comment it will reformat without indentation:

{-
   1. a bullet and lots of text in it so
that it spans several lines blah
blah blah blah
-}

This is mostly annoying and practically renders M-q unusable for block comments. And given that GHC's Notes are by convention kept in block comments this becomes a real pain.

[purcell]

Does #387 fix this for you?

[jstolarek]

Description suggests so. I can't try it out at the moment - I'm in the middle of hacking session. Will try it out later and report back.

[gracjan]

@jstolarek, are you able to check this one out again? Is the problem still persisting?

[jstolarek]

Oh dear. I totally forgot about this one. Sorry.

I'll try to check this sometime next week. That's the soonest I can get too it.

[jstolarek]

If I understand correctly both #387 and #441 are merged into master. I updated haskell-mode from Melpa to version 20150121.1531 but I see no changes in behaviour.

[jstolarek]

As a side note: after the update I see one regression regarding comments. If I have a bullet list in a line comment like this:

-- This data type represent the return signature of a type family. Possible
-- values:
--
--  * NoSig - the user supplied no return signature:
--       type family Id a where ...

then all lines before the star are rendered in red (colour of normal comments) and everything after the line with a star it is rendered in green (colour of haddock comments).

[gracjan]

Ugh, font-lock is complicated and in dire need of fixes.

[gracjan]

Same as #225.