lspitzner/a-sublime-haskell-setup.md

## a-sublime-haskell-setup.md

      
    Raw
  

              a-sublime-haskell-setup.md
            
          
    my sublime setup for haskell includes:

SublimeHaskell, but with most features disabled. mostly for syntax highlighting.
(as was pointed out, it is sufficient to grab the *theme file and omit the rest of the plugin. And even that is optional.)
for auto-formatting:

this (slightly modified) external-command plugin: https://github.com/lspitzner/SublimeExternalCommand
brittany (installed so that is on path)
the below keybind (you can open the user keybindings in sublime and merge the below)
you can either select some function and reformat that by pressing f9, or select nothing (whole file gets formatted)


for quick compilation feedback:

ghcid, invoked via some minimal bash script "run-ghcid": ghcid -o=ghcid.txt -c"cabal new-repl $@"
which is used e.g. ./run-ghcid lib:myproject
ghcid is running in the background and continuously updates ghcid.txt, which we will tell sublime to read.
the below sublime "build system", placed where your sublime installation has those (.config/sublime-text-3/Packages/User/)
save your sublime project (at the root of your project) so that script looks for the ghcid.txt in the right place
select the "haskell-ghcid" as the "build system" and voila, ctrl-b gives compiler output and allows to
jump-to-error via f4
remember to enable -Wall and -Werror with your cabal/stack/whatever setup
ctrl-b does not actually trigger re-compilation, but loads the current ghcid output.
this is bad (if ghcid has not yet finished you can see old state and have to press ctrl-b again)
(but ghcid is rather quick in general, especially compared to any no-ghci-based compilation)
but also good (you can press ctrl-b whenever you want, and see the compilation output again instantly)
(rarely either sublime-text or ghcid get confused about file handles being simultanenously read and re-written
and hick up. deleting ghcid.txt solves this, in my experience.)
ghcid can eat up a good chunk of memory. something in the order of maybe 100MB per 1k loc.
If you keep ghcid running in background all time, and separately run compilations with optimizations as well
from time to time, i'd recommend at least 16GB of ram. (depends on your project size of course.)
i rarely, but repeatedly, experience some (sublime?) bug that manifests in sublime ignoring the first n bytes
of the ghcid.txt file. i think it comes down to some encoding problem, but i have not really investigated.


## haskell-ghcid.sublime-build
{
  "working_dir": "${project_path:${folder}}",
  "cmd": ["echo ${project_path:${folder}}; cat ghcid.txt"],
  "shell": true,
  "file_regex": "^(\\S*?):(?|(\\d+):(\\d+)(?:-\\d+)?|\\((\\d+),(\\d+)\\)-\\(\\d+,\\d+\\)):([^\n]*)"
}

## run-ghcid.sh
#!/bin/bash
CABALPKGNAME=myproject # if you don't set this, reloading on .cabal changes does not work.
ghcid -o=ghcid.txt -c"cabal new-repl --restart "./$CABALPKGNAME.cabal" $@"

## sublime-keybind.txt
[
  {
    "keys": ["f9"],
    "command": "filter_through_command",
    "args": { "cmdline": "brittany" }
  }
]
	{
	"working_dir": "${project_path:${folder}}",
	"cmd": ["echo ${project_path:${folder}}; cat ghcid.txt"],
	"shell": true,
	"file_regex": "^(\\S?):(?\|(\\d+):(\\d+)(?:-\\d+)?\|\\((\\d+),(\\d+)\\)-\\(\\d+,\\d+\\)):([^\n])"
	}
	#!/bin/bash
	CABALPKGNAME=myproject # if you don't set this, reloading on .cabal changes does not work.
	ghcid -o=ghcid.txt -c"cabal new-repl --restart "./$CABALPKGNAME.cabal" $@"
	[
	{
	"keys": ["f9"],
	"command": "filter_through_command",
	"args": { "cmdline": "brittany" }
	}
	]