Skip to content

Update haskell-indentation-indent-line #1175

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from
Closed

Update haskell-indentation-indent-line #1175

wants to merge 2 commits into from

Conversation

fice-t
Copy link
Contributor

@fice-t fice-t commented Feb 22, 2016

Two changes:

  1. Some Evil commands are now treated differently to achieve expected
    behaviour.
  2. Pressing TAB at the final indent location now starts to move to the
    previous indent position instead of relying on the reindent function to
    start this process.

Fixes #896

Two changes:

1. Some Evil commands are now treated differently to achieve expected
behaviour.

2. Pressing TAB at the final indent location now starts to move to the
previous indent position instead of relying on the reindent function to
start this process.
@gracjan
Copy link
Contributor

gracjan commented Feb 22, 2016

Hmm, I have bad feelings about this. I'm unable to follow the logic neither in the code nor in the test.

  1. Hardcoding evil commands is super fragile. Can't we have logic that works properly without this?
  2. Can the test be more declarative? I would like to see more tests written in a more declarative manner, for example as a list of tuples: (COMMAND-TO-EXECUTE WHERE-SHOULD-INDENT-END), like this:
    '((indent-right 7)
      (indent-left 12) 
       ...)

That way it would be easier to create more than one scenario.

@fice-t
Copy link
Contributor Author

fice-t commented Feb 23, 2016

The cycle logic is that haskell-indentation-indent-line, on the last tab indent position, moves to the 2nd last indent position (if it exists) on the very first invocation. Before, it only moved on the 2nd call as then it passes control to haskell-indentation-indent-line-repeat.

  1. Certainly it's fragile (the this-command part), but I don't really see an obvious better way. We could just set indent-line-function to a new function that does it how Evil commands expect and then bind TAB directly to the old haskell-indentation-indent-line. Might not be the best thing to do though.
  2. I suppose. Actually, I think all the test needs is a way to vary the input. So just the source text would be provided.

@geraldus
Copy link
Contributor

Will electric-indent-functions hook be helpful in our case? Looks like haskell-mode totally ignores this.

electric-indent-functions is a variable defined in ‘electric.el’.
Its value is nil

This variable may be risky if used as a file-local variable.

Documentation:
Special hook run to decide whether to auto-indent.
Each function is called with one argument (the inserted char), with
point right after that char, and it should return t to cause indentation,
‘no-indent’ to prevent indentation or nil to let other functions decide.


electric-indent-mode is an interactive compiled Lisp function in ‘electric.el’.

(electric-indent-mode &optional ARG)

Toggle on-the-fly reindentation (Electric Indent mode).
With a prefix argument ARG, enable Electric Indent mode if ARG is
positive, and disable it otherwise. If called from Lisp, enable
the mode if ARG is omitted or nil.

When enabled, this reindents whenever the hook ‘electric-indent-functions’
returns non-nil, or if you insert a character from ‘electric-indent-chars’.

This is a global minor mode. To toggle the mode in a single buffer,
use ‘electric-indent-local-mode’.

@gracjan
Copy link
Contributor

gracjan commented Feb 23, 2016

O! Nice find!

Maybe we will be able to pacify electric-indent-mode so it works when RET is pressed (or evil-open-below).

@gracjan
Copy link
Contributor

gracjan commented Feb 23, 2016

@geraldus: Your comment is priceless for #1133.

@geraldus
Copy link
Contributor

Glad to be helpful! ☀️

@gracjan
Copy link
Contributor

gracjan commented Apr 9, 2016

I'm closing this without merging because I think that #1265 is fundamentally better idea.

Thanks for trying, this pr really helped to get the thinking going.

@gracjan gracjan closed this Apr 9, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants