fill-paragraph is completely broken in literate-haskell-mode

[raxod502]

Consider the following text in test.lhs:

Every expression in Haskell has a type which is determined at compile
time. All the types composed together by function application have to
match up. If they don't, the program will be rejected by the
compiler. Types become not only a form of guarantee, but a language
for expressing the construction of programs.

Running emacs -Q, I load the latest revision of haskell-mode (d71cca7) and press M-q with point on the second line of the file. Result:

Every expression in Haskell has a type which is determined at compile
 time. All the types composed together by function application have to
 match up. If they don't, the program will be rejected by the
 compiler. Types become not only a form of guarantee, but a language
 for expressing the construction of programs.

Pressing M-q multiple times gets me to something like this:

Every expression in Haskell has a type which is determined at compile
             time. All the types composed together by function
             application have to match up. If they don't, the program
             will be rejected by the compiler. Types become not only a
             form of guarantee, but a language for expressing the
             construction of programs.

What??

---

Emacs version: 26.1-rc1 installed from Homebrew
Operating system: macOS 10.11.6

[raxod502]

This is because back-to-indentation is also completely broken. With point anywhere on line 2 of the text,

Every expression in Haskell has a type which is determined at compile
 time. All the types composed together by function application have to
 match up. If they don't, the program will be rejected by the
 compiler. Types become not only a form of guarantee, but a language
 for expressing the construction of programs.

Pressing M-m moves point to column 0 when it should instead move to column 1.

[raxod502]

REALLY nasty hack to make M-x fill-paragraph work:

(defun radian-advice-haskell-fix-back-to-indentation (back-to-indentation)
  "Fix `back-to-indentation' in `literate-haskell-mode'.
Otherwise, it just moves point to column 0, which is wrong. This
is an `:around' advice for `back-to-indentation'."
  (if (derived-mode-p 'literate-haskell-mode)
      (progn
        (beginning-of-line 1)
        (when-let ((c (char-after)))
          (when (= c ? )
            (forward-char)))
        (skip-syntax-forward " " (line-end-position))
        (backward-prefix-chars))
    (funcall back-to-indentation)))

(advice-add #'back-to-indentation :around
            #'radian-advice-haskell-fix-back-to-indentation)

[david-christiansen]

back-to-indentation uses (skip-syntax-forward " " (line-end-position)), so it looks like something's up with the way that literate-haskell-mode sets syntax classes.

The syntax class for the first character on a non-> line in literate-haskell-mode is set by the syntax-table text property, which gets set to (11), corresponding to "comment start". This shouldn't match " ", so I suspect a bug in Emacs, but the function is in C and is hairier than I have energy to dig into right now.

I just figured that someone who wants to look at this might find it handy to avoid redoing the sleuthing that I just put in.

[goose121]

It appears that that syntax is set by the function haskell-syntax-propertize, which unconditionally sets the first character on a literate comment line to the comment start syntax. This has multiple problems: firstly, it breaks back-to-indentation which causes the issue under discussion, and secondly, it confuses auto-fill-mode, which will insert that first character at the beginning of the next line when filling (this seems to persist even after auto-fill-mode is turned off, and can be fixed by toggling literate-haskell-mode).

A solution to the first issue is to only mark the first non-whitespace character on a line as having comment syntax, adjusting the check for the previous line's commented-ness earlier in haskell-syntax-propertize to compensate. This requires minimal changes, consisting only of inserting a couple of back-to-indentation calls wrapped in save-excursion, but it doesn't fix the second issue, which seems like it might be more complicated, as it could require changing how haskell-syntax-propertize recognizes whether or not it's in a latex code block.

[siraben]

Any updates on this?

[purcell]

Any updates on this?

Sounds like @goose121 might be in a position to contribute a patch?