Skip to content
This repository has been archived by the owner on Apr 25, 2020. It is now read-only.

add elispPath command to bootstrap elisp code from ghc-mod installation #492

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

etrepum
Copy link

@etrepum etrepum commented Jun 4, 2015

Per #358 this adds an elispPath command which prints out the elisp directory in the ghc-mod installation. Adds a separate elisp-bootstrap directory with elisp code to call ghc-mod with elispPath and load the real code.

I don't really know what I'm doing in elisp but this worked for me. Here's what is in my initialization for emacs:

(add-to-list 'load-path "~/src/ghc-mod/elisp-bootstrap")
(load "ghc-mod")
(add-hook 'haskell-mode-hook (lambda () (ghc-bootstrap)))
(add-hook 'haskell-mode-hook 'turn-on-haskell-indentation)

Presumably you'd be able to take the elisp-boostrap dir and upload it to MELPA which would work for all future versions of ghc-mod. Possible enhancements would include better error reporting, in particular if ghc-mod isn't found then it should tell the user to install ghc-mod and ensure that it's on the PATH.

@DanielG
Copy link
Owner

DanielG commented Jun 4, 2015

If we want this to land on MELPA we have to move it to elisp/ or change this: https://github.com/milkypostman/melpa/blob/master/recipes/ghc. MELPA just pulls the package from git so it'll update as soon as we merge this.

@etrepum
Copy link
Author

etrepum commented Jun 4, 2015

Another improvement would be to check to make sure that ghc-mod understands the elispPath command. Having an old version would be essentially the same error as not having it installed at all, but it would be helpful if it mentioned that an old, incompatible, version was found.

@etrepum
Copy link
Author

etrepum commented Jun 4, 2015

Perhaps then we would move the current elisp code out of elisp/ and move the bootstrap code into there.

@DanielG
Copy link
Owner

DanielG commented Jun 4, 2015

What's up with that Makefile? Is that a template you got from somewhere?

@etrepum
Copy link
Author

etrepum commented Jun 4, 2015

I got it from the elisp dir

@DanielG
Copy link
Owner

DanielG commented Jun 4, 2015

Oh rite xD, I could swear I've never seen that thing before. I'm not really sure why we need that especially the archive and bump targets seem dated.

@etrepum
Copy link
Author

etrepum commented Jun 4, 2015

I just added some stuff to deal with versions and ./scripts/bump.sh. Not sure if it works because I don't have GNU sed or tac here right now (on OS X).

"*The command name of \"ghc-mod\"")
(defvar ghc-bootstrapped nil)

(defun ghc-bootstrap ()
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just prefix all symbols with ghc-mod instead of ghc I'd like to move away from the elisp package being called ghc, might as well start now.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good plan, I'll do that when I get back from lunch.

@DanielG
Copy link
Owner

DanielG commented Jun 4, 2015

You know I'm not so sure I like the approach. If we go with this we'll be stuck with people having (ghc-bootstrap) in their init files forever. Our current entrypoint (ghc-init) is bad enough I'd much rather have it be (ghc-mod-mode) as with just about every other Emacs minor mode but that's complicated by the fact that we can't currently undo all of ghc-init's effects :/

Anyways since we're already stuck with (ghc-init) you might as well rename ghc-bootstrap -> ghc-init so then people won't have to change anything in their emacs init, you'd just have to install the new version of the ghc package and it would just work. So we don't get name conflicts we should rename ghc-init in elisp/ to something else.

@DanielG
Copy link
Owner

DanielG commented Jun 4, 2015

Also have a look at this (master...DanielG:dev-elisp-simple) branch I started doing some cleanup ages ago maybe you can base this on that branch. Dunno if it's useful though.

@etrepum
Copy link
Author

etrepum commented Jun 4, 2015

One problem at a time I guess? We could do something like this now, and work on isolating the effects and such for ghc-mod-mode later.

Renaming things sound fine to me. Should we still rename ghc-init to ghc-mod-init and have an alias of ghc-init for backwards compatibility?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants