Invoke hasktags more directly and asynchronously

[gracjan]

Currently invoking hasktags goes via haskell-process, that is a roundabout way of doing it.

Invoke hasktags without the need for haskell-process.

Issue lifted from discussion in #891 and in #963.

Pinging @code-crimes and @MichaelXavier.

[bergey]

I've started looking at this. Two questions:

1. Would it be ok to depend on async.el? For haskell-tags-on-save I'd like to call hasktags asyncronously, but I'd like to keep supporting and-then-find-this-tag.
2. Is there a test case that shows why we need the find command? In my tests hasktags does a better job indexing all the Haskell files and ignoring all the build & backup files without the find.

[gracjan]

1. I would prefer the blocking version first. Dependencies are inherently tricky on Emacs.
2. Later on the equivalent of a single function async-start-process can be pulled in verbatim.
3. I guess hasktags used to need find, this seems to be no longer the case. Although it needs to be checked if huge directories like '.git' or '.svn' or '.darcs' are ignored as they should be.

[bergey]

Are dependencies really that bad these days? Or do you mean that you still support emacs-23? I dislike to maintain inline copies of something so generic as async-start-process.

[gracjan]

I'd rather have inline copy for now, thanks.

[geraldus]

Other question, should be generated tags table visited automatically? Recently Emacs start to ask me almost every time I call magit-status something like this "TAGS was updates, visit new file?", and it annoys me (I'm not certain but I think this is started after projectile installation).

[geraldus]

Before calling hasktags should we make some .cabal file lookup first?

[MichaelXavier]

@geraldus I'm not sure if this will solve your case but you may want to set tags-revert-without-query to t.

[geraldus]

@MichaelXavier thanks, I'll give it a try.

[geraldus]

So, what is the plan? Should we try to look up cabal file first going upward for some fixed depth? If this is a case, should we:
a) parse cabal file to check if current file is listed as module in any project section
b) cache cabal file location somehow?

[gracjan]

haskell-cabal.el already has this functionality.

This issue is about implementing exactly same functionality as right now, just in a more direct manner. So:

1. Find .cabal file going upwards in directories.
2. Execute hasktags there.

That is all.

[gracjan]

The merge in #1204 has broken hasktags invocation from inside ghci:

-> :cd /Users/gracjan/Sources/haskell-mode/
<- �
-> cd /Users/gracjan/Sources/haskell-mode/ && find . -type d \( -path ./.git -o -path ./.svn -o -path ./_darcs -o -path ./.stack-work -o -path ./dist -o -path ./.cabal-sandbox \) -prune -o -type f \( -name '*.hs' -or -name '*.lhs' -or -name '*.hsc' \) -not \( -name '#*' -or -name '.*' \) -print0 | xargs -0 hasktags -e -x
<- 
   <interactive>:6:41-42: parse error on input ‘&&’

Note that instead of doing :!cd it tries to do plain cd.

[gracjan]

We can either fix this, or kill it. It was merged Mar 21 and so far nobody reported any issues. Is anybody using this functionality at all?

[zmwangx]

Is anybody using this functionality at all?

I would love to use this, but given the current state of haskell-mode-jump-to-def, which requires haskell-session and even then doesn't always work (I never looked into what was wrong), I haven't been able to incorporate this into my workflow.

[gracjan]

Note that hasktags may take annoying while to finish, so it should run in the background. This also requires some locking and deferring mechanism so that no two hasktags run at the same time but also last hasktags is triggered by last change.

See: syl20bnr/spacemacs#6294