search

commercialhaskell / stack-ide

Stack-based JSON interface to ide-backend
98 stars 23 forks source link

Renamed stack-mode to stack-ide & added docs. #69

Closed lukehoersten closed 8 years ago

lukehoersten commented 8 years ago

This rename is per minor mode conventions. The "-mode" suffix is deprecated for minor modes.

This change in part of the work being done to make stack-ide package-ready.

These are the last few issues in #68

chrisdone commented 8 years ago

Ehh it's probably not the best time to make sweeping changes like this, until it stabilizes.

I'm not sure taking "-mode" out of the name is a good idea, regardless of what anybody thinks about deprecating things, it's a mode and referring to it as stack-mode is the most straight-forward way to engage in conversation about it, besides the fact that it is indeed a mode. Besides, it may (and probably will) expand to beyond the scope of this repository to support stack commands outside of the stack-ide program, such as running builds and tests and uploading, etc.

lukehoersten commented 8 years ago

We can probably get it in melpa without renaming it.

stack-mode still seems misleading though in the same way that it's not clear if a cabal-mode would be a major mode for editing a cabal file or a minor mode for running cabal commands. Either way the current name is generic enough to be confusing in a handful of ways, I agree with @purcell there.

I'll separate my doc changes out into a separate commit.

purcell commented 8 years ago

I'm not sure taking "-mode" out of the name is a good idea, regardless of what anybody thinks about deprecating things, it's a mode and referring to it as stack-mode is the most straight-forward way to engage in conversation about it, besides the fact that it is indeed a mode.

@chrisdone Modes are such a fundamental emacs mechanism that the -mode suffix for libraries is considered redundant. The convention is to use it only for major modes.

A great outcome - if it works out - would be a couple of separate packages which stack-ide would tie together. Code for supporting stack commands would fit nicely in a stack.el or haskell-stack.el library. Ideally any flycheck support would be usable/installable outside of a "stack IDE" infrastructure (there's now a standard stack-ghc checker in the flycheck core, btw).