Regression in indentation logic

[mrkkrp]

Example:

foo :: Bar -> Baz
foo x = blah x $ \y -> do
^ ^

First caret shows where haskell-mode puts cursor now, the second caret shows where it should be (and it worked until yesterday or so).

[mrkkrp]

Oh, wait, it does not work in one buffer, but works in another identical buffer. WTF. I'm not going to even investigate it, will indent manually.

[gracjan]

Might be something just before this confused the parser. Can you paste also two definitions that are directly before this one?

[mrkkrp]

I mean, even if I create new buffer, enable haskell-mode there, then copy all contents of buffer where it does not work, it won't reproduce. But in original buffer it does not work. I have experienced this a couple of times, and I have no idea what triggers this. Sorry.

[mrkkrp]

Honestly, if you want my opinion, current apporach will never succeed (unless you cover 100% of cases in test suite and probably spend a lot of time hacking it and adjusting).

Have you looked into how Chris Done manages parsing in his Structured Haskell Mode? I believe that for reliable result, some parser on Haskell side should be used (again, what does HLint uses?). You need to run Haskell script (that uses proven lib that can parse Haskell) from lisp, desirably on limited fragment of code (not entire buffer), and then process its results to predict indentation levels. I do not believe Emacs Lisp can parse Haskell reliably.

I planned to build alternative Haskell mode to replace haskell-mode (at least for me) from scratch that would use this idea, because I'm quite pessimistic about haskell-mode, but with this amount of work I need to do right now, I understand that I will be using haskell-mode at least for one more year, so think it makes sense to share ideas with you, you spend considerable amount of time hacking this anyway.

[geraldus]

to predict indentation levels

There is no need to predict them, 'cause this is deterministic. What is required to be predicted is the desired indentation, e.g. where point should go when new-line inserted. And trying to predict things is not quite smart idea I believe. If I'm not mistaken both following definitions are valid Haskell:

user = User 
           { login = "geraldus"
           , realName = "Arthur" }
user = User
    { login = "geraldus"
    , realName = "Arthur" }

So, when user hits RET after User which indentation level should be predicted? There is no way to know until you have some customizable predicates (this was done in form of styles in past) or to implement an algorithm which learns how user indents things and remembers that.

[mrkkrp]

Well, maybe that term is confusing. By prediction I meant just calculation (of coure it's deterministic) of where indentation should be on next line, possibly based on user's preferences.

[mrkkrp]

I'm just telling you a way to make it robust and bug-free. You can continue trying to make your Lisp parser work, of course.

[geraldus]

@mrkkrp hey pal, what are talking about? What you mean by "your parser"? Neither haskell-mode, nor its parser are mine. Calm down, please.

I agree, that parsing Haskell by Haskell is much better. However, I think we should not force users to be dependent on external tools.

GHCi itself could help to solve some problems, but again there are many users who do not use and do not like interactive haskell (and if I'm not mistaken you are one of them).

But even in this case of external parser some indentation problems would persist. For example, indenting function arguments. Even if we know how many arguments function takes, this is no way to predict what user tends to write:

fn1 a b c = undefined
fn2 a b = fn1 a

If I insert newline after last one, there is no way to be accurate on assumption about indentation, because there are two equally valid options:

• I tend to continue writing missing arguments to fn1
• fn2 is a synonym for partially applied fn1 function

This can't be solved even with external parser/validator. Moreover, in first case accurate indentation step can be determined on user coding style only.

[PierreR]

Well I don't quite mind how the parser is written but I find it is a bit of a shame that a simple snippet like this one is already difficult to type (I would argue this style is quite common):

data User = User
  { login :: Text
  , pass :: Text
  } deriving Show

To me, a good indentation mode is my first expectation from a tool such as haskell-mode. That said I am quite aware it is easier to say it than to make it happen ;-)

[mrkkrp]

@geraldus, I'm not quite excited yet to need to calm down. I said “your”, because you're an active contributor, so in this conversation I consider you part of maintainer team.

What you describe can be easily handled via combination of preferences/customization and the fact that there may be several indentation positions and user can cycle through them pressing ↹ Tab. But you need to parse the stuff anyway, properly and reliably, it's the basis for everything else.

[gracjan]

@PierreR: This looks like a bug (or a leftover actually). See #366. Indentation style that aligned expressions after equal sign used to be preferred one, now there is tendency to indent by 2 spaces independent of context. New fashion.

Actually should be rather easy to fix I encourage you to have a look and fix it.

@mrkkrp: I've looked into external parsers and do not see how the available ones can be used for indentation. Having said that if somebody volunteers to take over this part of complexity I would be very grateful.

[gracjan]

Please continue discussion in #1178.

[geraldus]

combination of preferences/customization

Though it seems to be a good way to go, there are a lot of customizations in Haskell mode already which end user never discovers. I believe this is a matter of choice, usually I prefer simplicity in any software preferences, so there is no need to spend hours learning all options I can customize, however sometimes it is required to have an ability of fine-grained customizations. I think that preferences complexity correlates to software complexity, and what we really need is to reduce existing complexity. There is discussion related to indentation #1178, and ideas are welcome.