<commit_before>*SublimeHaskell* 2.1.5
======================

SublimeHaskell 2.1.x is a release tree for minor enhancements and fixes to newly identified (and resolved) issues.

## In this release

**Fix REPL support**: REPL support was supported solely via `cabal repl` and the code supporting Haskell REPLs itself needed re-evaluation. All execution wrappers are now supported: `cabal repl`, `cabal new-repl` and `stack repl`. *NOTE: The `haskell_build_tool` setting determines which execution wrapper is used. `haskell_build_tool` can be a project-specific setting, not just a default or user preference. See below in Release 2.1.3.*

**Fix status line issues**: There was a long standing bug with SublimeHaskell's use and manipulation of the status line, which is now corrected. The main manifestation was a thread that repeatedly updated the status line every 0.2 seconds (although it wasn't perceivable because there wasn't any flicker.) This fix should cut down in CPU and thread usage.
<commit_msg>more message frobbing.<commit_after>*SublimeHaskell* 2.1.5
======================

SublimeHaskell 2.1.x is a release tree for minor enhancements and fixes to newly identified (and resolved) issues.

__RESTART SublimeText AFTER EACH UPDATE!!__ This ensures that stale versions of internal *SublimeHaskell* Python modules don't cause problems when *PackageControl* reloads the plugin. *SublimeHaskell* does not (and cannot) forcibly reload its own internal modules.

## In this release

**Fix REPL support**: REPL support was supported solely via `cabal repl` and the code supporting Haskell REPLs itself needed re-evaluation. All execution wrappers are now supported: `cabal repl`, `cabal new-repl` and `stack repl`.

*NOTE: The `haskell_build_tool` setting determines which execution wrapper is used. `haskell_build_tool` can be a project-specific setting, not just a default or user preference. See below in Release 2.1.3.*

**Fix status line issues**: There was a long standing bug with SublimeHaskell's use and manipulation of the status line. The main manifestation was a thread that repeatedly updated the status line every 0.2 seconds -- it wasn't always perceivable because there wasn't any noticeable flicker. This fix should cut down in CPU and thread usage that this issue may have caused.

{'fraction_non_alphanumeric': 0.0784908933217693, 'fraction_numerical': 0.008673026886383347, 'mean_word_length': 5.103174603174603, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1952281', 'n_tokens_mistral': 638, 'n_tokens_neox': 580, 'n_words': 320}