細かい表現の修正

Author: igrep

preprocessed-site/posts/2019/strip-ansi-escape.md

@@ -38,16 +38,16 @@ ghci> stripAnsiEscapeCodes "\x001B[4mhello\x001B[0m"
 
 通常我々がANSIエスケープコードを扱うときは、**ユーザーのために**端末に文字列を分かりやすく表示したいときで、それをプログラムで再利用することは想定していません。  
 そのためANSIエスケープコードを出力できるアプリケーションは、大抵の場合出力しないよう設定できる<small>（あるいは、出力先がttyでないことを検出して出力しない）</small>ようになっています。  
-なので、プログラムがANSIエスケープコードの混ざった文字列を扱わざるを得ない、という事態は、何かがおかしい事態だと考えるべきとも言えるでしょう。
+なので、プログラムがANSIエスケープコードの混ざった文字列を扱わざるを得ない、という事態は、何かがおかしい事態だと言えるでしょう。
 
 一体どういう事態なのかというと、それは私がずっと開発中の、対話的Haskell入門コンテンツ --- [「失敗しながら学ぶHaskell入門」](https://github.com/haskell-jp/makeMistakesToLearnHaskell) --- で出遭った事態でした。  
 「失敗しながら学ぶHaskell入門」（以下、英語名を略して「mmlh」と呼びます）では、ユーザーが書いたHaskellのソースコードを受け取って、GHCにコンパイルさせることで、型エラーなどのエラーメッセージを取得しています。  
 当初からmmlhはそれを簡単にパースしてユーザーへのヒントを出すのに使ったり、ユーザーにそのまま表示したりするのに使うため、`-fdiagnostics-color=always`というオプションをGHCに渡していました。  
-これは、エラーメッセージにANSIエスケープコードを混ぜて色を着けるようになったGHC 8.2から導入されたオプションで、「エラーメッセージに必ず<small>（ANSIエスケープコードを使って）</small>色を着ける」というものです。  
+これは、エラーメッセージに色を着けるようになったGHC 8.2から導入されたオプションで、「エラーメッセージに必ず<small>（ANSIエスケープコードを使って）</small>色を着ける」というものです。  
 GHCが出すエラーメッセージを「簡単にパース」しつつ「ユーザーにそのまま表示」する、という2つの要件を満たすためには、このオプションを利用して、強制的にエラーメッセージに色を着ける必要がありました。
 
-さらに最近、GHCが出したエラーメッセージをファイルに保存して、[GitHubで閲覧できるようにする](https://github.com/haskell-jp/makeMistakesToLearnHaskell/issues/101)<small>（正確には、閲覧して各行にコメントできるようにする）</small>、という機能も追加したため、ANSIエスケープコードを取り除かざるを得なくなってしまいました。  
-というのも、`-fdiagnostics-color=always`を有効にしている限り、GHCは必ずANSIエスケープコードをエラーメッセージに混ぜるので、ファイルに保存してGitHub上で表示する際、下記のように余計な文字として混ざってしまい、エラーメッセージが読みづらくなってしまうのです。
+さらに最近、GHCが出したエラーメッセージをファイルに保存して、[GitHubで閲覧できるようにする](https://github.com/haskell-jp/makeMistakesToLearnHaskell/issues/101)<small>（正確には、閲覧して各行にコメントできるようにする）</small>、という機能も追加した結果、ANSIエスケープコードを取り除かざるを得なくなってしまったのです。  
+というのも、`-fdiagnostics-color=always`を有効にしている限り、GHCは必ずANSIエスケープコードをエラーメッセージに混ぜるので、ファイルに保存してGitHub上で表示する際、下記のように余計な文字として混ざってしまい、エラーメッセージが読みづらくなってしまうためです。
 
 ```
 �[;1m16.hs:19:18: �[;1m�[31merror:�[0m�[0m�[;1m�[0m�[0m�[;1m