コーディング時に厄介なMavericksのテキスト自動置換まとめ
前回紹介したAutomatorを作っている時に、突然AppleScriptがエラーを吐くことがありました。
これぞ、かの悪名高いMavericksのスマート引用符の仕業。しかし、悪名高い割には、日本語のウェブサイトには具体的すぎるトラブル例しか見当たらないようです。そこで、関連する各種機能について、概要をまとめておこうと思います。
以下の内容は、Mac OS X 10.9.3準拠です。
基本と問題点
- OS X Mavericks: 書類のテキストを置き換える
- OS X Mountain Lion: 書類のテキスト、ピクチャ、ムービーをコピーする
- ASCII.jp:Leopardアプリケーションガイド(後編) (2/8)
基本的な内容は、上記のサポートドキュメントに記載されていますが、一部内容が古くなっています。
Mac OS Xには、テキストを自動的に「適切な」体裁に置き換える機能があります。大きく分けると、
- テキストの置換
- スマート引用符/ダッシュ記号
- スマートリンク
- スマートコピー/ペースト
問題は、本当に「適切な」体裁は状況によって異なるということです。
たとえば、大ざっぱには「二重引用符」と表現される記号は、半角のものだけでも、文字コード的には3種類に分かれます。
上記記事でいうところの、「ストレートクォーテーションマーク」「ダブルクォート(左、右)」です。
英文の記述において正しいのは「ダブルクォート(左、右)」ですが、例えばHTMLにおけるaタグのhref属性は、「ストレートクォーテーションマーク」で囲む必要があります。しかし、Mavericksのスマート引用符が働くと、「ストレートクォーテーションマーク」を入力したつもりでも、「ダブルクォート(左、右)」に置き換えられてしまいます。
複雑なオン/オフ切り替え
そこで、要らなきゃ切ればいいだろという話になるのですが、そこが簡単にいかないところなのです。
まず、上記の自動置換機能は、「システムレベル」と「アプリケーションレベル」で個別に設定されます。それぞれの切り替え方法は以下の通りです。
- システムレベル
- システム環境設定 > ユーザ辞書
- 英字入力中にスペルを自動変換
- スマート引用符とスマートダッシュを使用
- システム環境設定 > ユーザ辞書
- アプリケーションレベル(「テキストエディット」の例。アプリケーションによって異なる)
- 編集 > 自動置換
- スマートコピー/ペースト
- スマート引用符
- スマートダッシュ記号
- スマートリンク
- テキストの置換
- (コンテクストメニュー)自動置換
- (「編集 > 自動置換」と同様)
- 編集 > 自動置換
ここで、アプリケーションレベルの設定はシステムレベルの設定に優越します。すなわち、システムレベルで自動置換をオフにしてもムダです。ばかじゃないの。
さらに、アプリケーションレベルの設定はなぜかしょっちゅうリセットされます。ほんとうにいみがわかりませんかんべんしてください。
では、これらの機能は、実際にはどのように振る舞うのでしょうか。
テキストの置換
これは、簡単に言えば「ユーザー辞書(ことえりの辞書)」に基づく自動変換です。「システム環境設定 > ユーザ辞書」に登録されている単語のうち、入力が半角英数のみであるものにおいて機能します。変換が半角英数である必要はありません。
IMEのサジェストのように変換テキストが表示されます。リターンまたはスペースキーで確定、エスケープキーでキャンセルされます。
自分が意図した変換結果にしかならないので、致命的なトラブルにつながることはほとんどないでしょう。ただし、微妙なタイムロスが発生するので、うっとうしいこともあります。
スマート引用符/ダッシュ記号
これらの機能は、キーボードから入力される記号を、「適切な」記号に置換します。スマート引用符の置換先記号は、「システム環境設定 > ユーザ辞書」で設定されます。
置換前の記号に「開始」「閉じ」の区別はありませんが、前方に引用符がある場合、閉じ引用符に置換されます。
特に引用符は、マークアップ/プログラム言語において特殊な意味を持つため、意図せずに置換されるとコードがエラーを起こすことがしばしばあります。そのため、最も厄介だといえます。
スマートリンク
URL などの文字列をクリック可能なリンクに変換します。つまり、置換後のテキストはリッチテキストです。
そのため、コーディング用のアプリケーションで有効であることが少なく、深刻なトラブルにつながることは少ないでしょう。
スマートコピー/ペースト
メール、テキストエディット、メッセージ、スティッキーズなど、多くのアプリケーションでは、単語をペーストしたり削除したりしたときに、スペースを自動的に挿入または削除して適切な間隔を確保することができます。この機能を「スマートコピー/ペースト」といいます。
と書かれていますが、発動条件がよくわかりません。英文のスペースを不自然に増やしたり削除したテキストをコピペしても、何も起こりませんでした。
とりあえず、なにかをコピペしてなにかが起こった場合、この機能を疑ってみてはいかがでしょう。
まとめ
- スマート引用符やばすぎ。
- システム環境設定で殺しても油断するな。アプリケーションレベルで殺さない限り奴らは動き続ける
- 一度殺しても油断するな。奴らは何度でも甦る
Automatorで半角スペースをタブ記号に変換する
承前。
半角スペース×4をタブに変換するワークフローを作成しました。
参考
- macのAutomatorについての質問です。テキストファイルの文章の一部を検索/置換し... - Yahoo!知恵袋
- シェルスクリプトの参考
- のったりでMac: 頑張る小人は発展途上。WriteRoom用Automator
- ペーストをAppleScriptとして実行する方法
ワークフロー概要
- シェルスクリプトで取得したテキストを置換
- クリップボードにコピー
- AppleScriptでペースト(⌘V)を実行
シェルスクリプトコードを以下に記します。
for f in "$@" do echo "$f" | sed -e "s/ / /g" done
Automatorにはペースト(または⌘V)を実行するアクションがありません。しかし、キーボード操作を記録してからAppleScriptとして展開することで、アプリを問わず「⌘Vを押す」操作を実行させることができます。そのスクリプトコードは以下の通りです。
(修正:2014-07-09)
えらく時間がかかるのでdelayおよびtimeoutSecondsを0に。けっこう速くなった。とりあえずちゃんと動いている。
-- ⌘Vを押す delay 0 set timeoutSeconds to 0 set uiScript to "keystroke \"v\" using command down" my doWithTimeout(uiScript, timeoutSeconds) on doWithTimeout(uiScript, timeoutSeconds) set endDate to (current date) + timeoutSeconds repeat try run script "tell application \"System Events\" " & uiScript & " end tell" exit repeat on error errorMessage if ((current date) > endDate) then error "Can not " & uiScript end if end try end repeat end doWithTimeout
Automatorのスクリーンショットは以下の通りです。 (img)(http://cl.ly/WMHS/4Space2TabService3.workflow%202014-07-02%2022-40-50.jpg)
また、ワークフローファイルを以下にリンクします。解凍して「Library/Services」に置くことで利用できます。テキストを選択した状態で、メニューバーまたはコンテクストメニュー内の「サービス」から実行できます。
4Space2Tab.workflow(前バージョン:4Space2Tab.workflow)
注意
なぜか一部アプリで正常に機能しない(1行しかペーストされない)ことがありました。(miなど)
バージョン2(2014-07-09)
もうテキスト選択とかコンテクストメニューから実行とかめんどくさいので、ワークフローに⌘A+⌘Cも含めてみた。
ワークフロー概要
入力なしにして、
- AppleScriptで全文選択(⌘A)を実行
- AppleScriptでコピー(⌘C)を実行(delay1秒)
- クリップボードの内容を取得
- シェルスクリプトで取得したテキストを置換
- クリップボードにコピー
- AppleScriptでペースト(⌘V)を実行
ワークフローファイルは以下。
テキスト未選択状態で、メニューバーの「サービス」から実行できます。「システム環境設定>キーボード>ショートカット」で割り振りしておくと楽です。
さすがに、delayを多少取っておかないと、コピー処理が間に合わず失敗する模様。
nvALTをめぐるタブとソフトタブの混乱
現在、MacのメモアプリとしてnvALTを利用しています。SimplenoteにもDropboxにも同期できて、Markdownも書けて検索も速くて他のアプリにも渡せるすごいアプリです。
ただし、ものすっごく挙動が怪しい点がいくつかあります。中でもかなりどうしようもないのが、Soft Tabs設定にまつわる問題です。
Soft Tabsとは?
MacでもWindowsでも、テキストエディタ等でタブキーを押すと、タブが入力されインデントされます。しかし、諸々の事情により、タブではなく半角スペースでインデントしたい場合があります。そのために、タブキーで半角スペースを入力する機能のことを、一般にSoft Tabsと言います。
多くの場合、Soft Tabs機能を持つアプリでは、挿入される半角スペースの数を指定できます。たとえばMarkdownリストのネストのためにSoft Tabsを利用する場合、半角スペースの数は4個であるべきです。
nvALTにおけるSoft Tabs問題
しかし、nvALTにおいては、Soft Tabsで挿入される半角スペースの数を指定することができません。まあ、それが2個とか4個で固定なら別にいいのですが、実際やってみると、その時の気分で3個とかになります。本当にいい奴なんだけれど、そこだけは本当に理解できない。
さすがにバグだろうと思ってググってはみたものの、全く情報が出てきませんでした。少なくともうちの環境では、nvALTのSoft Tabsは使い物になりません。
まあ、それならそれで使わなければいいんです。nvALTだけの話なら。
TabsとSoft Tabsの混乱
しかし、同じドキュメントを色んなアプリの間でぐるぐるしていると、逆にSoft Tabsしかできない奴がいたり、Tabsじゃないと不具合出す奴がいたりします。
- Byword
- 強制Soft Tabs
- 読み込んだドキュメントのタブを半角スペースに強制変換
- FoldingText
- Soft Tabs不可
- 半角スペースでネストされたリストを正常にハイライトできない
- MarkdownPad2
- タブでネストされたリストを正常にハイライトできない
nvALTを中心にドキュメントをぐるぐる回していると、ドキュメント内でタブと半角スペースが混じったりします。そうすると、リストの表示がガタガタになって大変困ります。
というか、Bywordに渡した覚えもないドキュメントに半角スペースが入ってたりするので、nvALT自体にそういう不具合があるような気も……。
困ったので、とりあえず全部タブに変換できるように、Automatorでサービスを作ってみました。これについては次回。
追記(2014/07/16)
Simplenoteとの同期をやめたら発生しなくなったので、どうやらSimplenote絡みの問題である模様。
Ulysses IIIのファイル名記法と、新規シート作成時に即ファイル名入力できない件について
https://itunes.apple.com/jp/app/ulysses-iii/id623795237?mt=12&uo=4&at=10l8JW&ct=hatenablog
Scrivenerのリッチテキスト編集がいよいよ堪え難く、一度Ulysses IIIを諦める宣言をしておきながらまた試しております。ブログ原稿もUlysses IIIで管理してたり。
メニューバー項目にショートカット割り振ってやるとかなりいい感じになるのですが、そもそもシーと並べ替えがメニューにないので割り振れないのがつらい。あと、タイプライタースクロールが中央固定にできないの。変数とかいらない……。
とまれ。また使い始めたら、改めておやっと思うことがありまして。
外部ソースとファイル名記法
Ulysses IIIはシングルライブラリなので、基本的にファイル名という概念がありません。シートリストでは、「内容」のプレビューが表示されるのみです。
例外は外部ソースを追加した場合です。ここでいう外部ソースとは単にローカルフォルダであり、外部ソースにおける個々のシートはテキストファイルですから、当然ファイル名が存在します。にもかかわらず、Ulysses IIIにはファイル名フィールド自体が存在しません。
じゃあどうするのかというと、1行目にこのようなファイル名記法を入力します。
@: ファイル名
外部ソース・グループにおいて新規シートを作成した場合、当然1行目にこの記法が自動挿入されるのですが、この際、「ファイル名」の部分が選択されません。こんな具合です。**
したがって、ファイル名を入力するには、カーソルを移動する必要があります。そんなばかな。
問い合わせてみた
問い合わせ
外部ソース・グループで新規シートを作成する際、ファイル名の入力をすぐに始められないのが煩わしいです。
ファイル名が選択された状態にしていただけないでしょうか。
返信
Hello,
thanks for the heads-up! This is a bug that we’ll try to fix in the next minor release. Sorry for the inconvenience.
All the best,
Lucas
バグでしたーーーー
次回リリースで修正予定だそうです。ひとあんしん。
Write for Macはまだよちよち歩き
6月5日のリリース以来、ブログ界隈ではなかなかの評判のWrite for Macですが、正直なところ、現状での本格運用は厳しいという結論に至りました。
今回は、このアプリの特長と、現状での欠点についてまとめます。
参考
エディタではなくドキュメント管理アプリである
Writeの最大の特長は、柔軟なライブラリ機能にあります。Mac App Storeのスクリーンショットにもある通り、3ペインの左がライブラリになっています。
そこにはiCloudを始めとする各種クラウドストレージサービスの他、ローカルフォルダも自由に追加することができます。この際、Dropbox内のフォルダなども選択できるので、事実上Dropbox内の複数フォルダをライブラリに統合することができます。少々アクセスは悪いですが、フォルダ内にフォルダを作成して整理することも可能です。
目的別にフォルダを作成してリンクしておけば、ドキュメントの整理に非常に役立ちます。これは、Ulysses IIIに近い運用ですが、クラウドストレージサービスの選択肢が広い点では優っているといえるでしょう。価格が大幅に安いことも無視できません。
さらに、iCloudおよびDropboxの規定フォルダについては、iOS版からもアクセスできます。iOSアプリと統合されており、なおかつDropbox同期が選択できるアプリはそう多くなく、この点では大いに評価できます。
Notebooks for Macとの比較
以前の記事(気付けば迫る割引最終日!リッチなMarkdownエディタ「Notebooks for Mac」 - 豆腐メンタルは崩れない)でも書いた通り、現状私がドキュメント管理に利用しているのはNotebooksです。
Writeと比較してみると、以下のような違いがあります。
機能 | Write | Notebooks |
---|---|---|
ライブラリ | 複数のソース | 固定のフォルダ |
iOS版統合 | iCloud/Dropbox指定フォルダ | (Dropboxの同じフォルダを指定) |
フォルダ表示 | リスト | ツリー |
他のアプリで開く | なし | あり(既定アプリ) |
表示するファイルタイプ選択 | なし | あり |
Writeは複数のソースをリンクできる点が強く、プラットフォーム的です。複数のプロジェクトを同時進行する場合に適します。ブログ原稿の管理などにも良いと思われます。
Notebooksはフォルダツリー機能が強力で、複雑にフォルダ分けしたドキュメント群の管理が容易です。他のアプリとの連携を考えても、単一の巨大プロジェクトに適します。それにしても、タイプライタースクロールが欲しい……。
美しく、見やすいインターフェース
ビジュアルの美しさも評価対象でしょう。単に美しいだけでなく、カスタマイズもかなり柔軟で す。
行間設定が嬉しいですね。また、ライティングモード設定によって、エディタの表示を以下のように選択できます。
ファイル選択時に自動プレビューすることもできるので、自由度は高いといえます。また、「テーマ」でスマートハイライト時の、「CSS」でHTMLプレビュー時の表示を自由にカスタマイズすることができます。
LightPaperなどにも同様の機能はありますが、Writeでは複数のテーマがプリセットされていない代わり、編集へのアクセスが容易であることが評価できます。
ただ、エディタ部分の上下端をグラデーション表示するのは、気持ち悪いからやめて欲しいですね……。Bywordとかもそうだけれど……。
編集機能が貧弱
問題は編集機能の貧弱さです。この点は他のアプリに比べて大幅に劣っており、改善を求めたいところです。せめて、他のアプリへ簡単に渡せればいいのですが。
シンタックス挿入系のショートカットが少ない
Markdownシンタックス(およびHTMLタグ)挿入系のショートカットで、現在実装されているものは以下のとおりです。
- 太字 (⌘B)
- イタリック (⌘I)
- 下線 (⌘U):
U
タグ - 見え消し (⌥⌘`):
del
タグ - リンク (⌥⌘L)
- 画像 (⌥⌘I)
一方、たいていあるのに実装されていないものは以下の通りです。
- 見出し (#)
- リスト (-/*/+)
- リストのインデント
また、地味に気になるのが挿入時の挙動です。テキスト選択していない場合、一般的な挙動は閉じタグ/シンタックスを挿入して間にカーソル移動なのですが、Writeでは単に開始タグ/シンタックスを挿入するのみです。開始タグ/シンタックスは、再度コマンド実行すると挿入されます。
挿入コマンドを2回入力するのと、テキスト入力後にカーソル移動するのと、どっちがいいかは微妙なところですが、慣れない感じではありますね。
リスト編集機能が貧弱
上述の通り、リストのシンタックス挿入コマンドはありません。まあ、オートバレットはあるのでそれはまだいいのですが、インデントができないのがツラい。タブキーインデントもないので、行頭に戻ってタブキーを押す必要があります。
よしんばそうしても、インデントするとオートバレットが死ぬのでひっくり返ります。スマートインデント(インデントの自動挿入)すらなく、普通に普通の改行をしてくれるという。
どうやら、Write的にはリストは入れ子にしないものであるようです。そういえば、iOS版の拡張キーボードにもタブキーないもんな。だから買ってないんだけど。
Markdown(というかMarkdownエディタ)の大きな魅力のひとつは、リストが簡単に書けることではないかと思います。プレーンテキストであるゆえに転用が容易で、HTMLにレンダリングすればすぐウェブ公開もできるという長所は、アウトラインプロセッサにも真似ができないものです。
そこで、リスト作成支援機能がSimplenoteのiOS版以下というのはかなり泣けるものがあります。リストのインデントに対応しない限り、私が本格的に運用することはなさそうです。
テキスト入力関係の不具合
入力時にやたらと画面がチカチカすることがあります。これは、入力部分より下のテキストを、入力のたびに再描画しているのが原因のようです。Rich MDだとシンタックスが出たり消えたり、ハイブリッドでもテキストがフラッシュしたりします。
当然ですが、プレインテキスト表示にしておけば避けられます。
また、日本語入力がどうも怪しく、変なタイミングで英数モードになったりしました。
まとめ
安いなりのUlysses IIIというのが身も蓋もない評価であるかと。論文だの小説だのにはさすがにUlysses IIIでしょうが、軽いブログ書き程度なら充分そうです。
リスト関連だけどうにかしてくれないだろうか。
StackEditによるWordPress Publish時の注意点
上記の記事で書いた通り、目次生成を目的としてStackEditを利用した記事公開を行いました。一応成功はしたのですが、よく見たらWordPress側のソースがひどい有様になっていました。
覚書として、事故ったポイントをまとめることにします。
「more」タグが消される
WordPressでは、以下のような行を記述することで、いわゆる「続きを読む」として、残るコンテンツをトップページなどで非表示にすることができます。(More Tag — Support — WordPress.com)
<!--more-->
<!--more But wait, there's more!-->
ところが、StackEditはPublishの際にこれを必ず削除します。
StackEdit「コメントアウトだから削除しておきますね^^」
いやいや、それはWordPress側で解釈するべきでしょ。ソースは保全してくれないと困るでしょ。
じゃあ、HTMLエンコードしてみたらどうなるのか?
<!--more-->
<!--more But wait, there's more!-->
WordPress側ではこうなります。
<p><!–more–></p>
<p><!--more But wait, there's more!--></p>
ですよねーーーー!!!
というわけで、MoreタグだけはWordPress側で入れる必要があります。別に一回ならいいんですが、StackEditから上書きPublishすると、そのたびに入れ直すハメに陥るので、なかなかメゲます。
文書内にHeading1がないと目次がおかしくなる
わざわざ本文中にタイトルを入れている理由はこれです。
例えば、こんな見出しから[toc]
で目次生成したとしましょう。
## Heading2
### Heading3
StackEditでのプレビューはこんな感じです。
目次自体はちゃんとできるのですが、位置が右にずれています。
この場合、WordPress側で目次部分のソースを抽出すると、こうなっています。
<ul>
<li><ul>
<li><a href="#heading2">Heading2</a><ul>
<li><a href="#heading3-1">Heading3</a></li>
</ul>
</li>
</ul>
</li>
</ul>
内容のないul
タグが生成されていることがわかります。そのため、目次リスト全体がネストされた状態になってしまっています。コード的におぞましいですね。
つまり、StackEditが生成する目次は、H1〜HnのHeading(見出し)項目を含むことを前提としているのです。
手動でWordPress側のソースを修正するか、HTML全体の構造が奇妙になることを受け入れるか。どっちも避けたい二択なんだよなあ。
コードブロック内のMarkdownがレンダリングされる/コードブロック内の改行が削除される(再現せず)
さっき実験したら、なぜか再現しませんでした。昨晩あんなに苦労させられたのはなんだったんだ。
StackEditシステム未だ完成に至らず
という感じです。見出しはともかくとして、Moreタグの件は、作業がStackEdit側で完結しなくなるのでどうにかしてほしいものです。Feedback送っておこう。
「FoldingText 2 概論」の公開と、StackEditによる目次生成
https://itunes.apple.com/jp/app/foldingtext/id540003654?mt=12&uo=4&at=10l8JW&ct=hatenablog
長い戦いだった……
FoldingText2の公開以来取り組んでいた、解説記事をようやく公開できました。
ご覧のとおり、wordpress.comに新規ブログを立ち上げて、そちらで公開する運びとなりました。なぜそんな面倒なことをするハメに陥ったのかというと、死ぬほど長くなったからです。
長文にはリンク付きの目次が必要だ
これまたご覧のとおり、「FoldingText 2 概論」には全ての見出しを網羅した目次(Table of Contents)を付けてあります。自分で書いておいてなんですが、さすがにこの量のテキストをウェブで読むのに、見出しでもなければ筆者でもメゲます。執筆中だって、FoldingTextの見出しフォーカス機能を活用しなければ気が狂うところでした。(と軽く宣伝)
とはいえ、この量の目次を自力で書くのはそれはそれで気が狂う。大方を書き終えたところで、目次をどうやって調達するかという問題が持ち上がったわけです。
はてな記法で目次あるとおもったら、はてなグループ限定だし。(目次記法とは - はてなキーワード)
色々検討したのですが、現実的に満足のいく目次を生成する方法は、StackEditに頼る他ありませんでした。
StackEditによる目次生成
StackEditは、超強力なウェブベースMarkdownエディタです。ブラウザさえあれば環境を問わずに利用できる上、そんじょそこらのローカルアプリを上回る機能を持っています。
ざっと挙げますと……
- 編集系
- オートバレット
- タブキーインデント
- しかも完全な――カーソル位置を問わず実行可能
- スマートハイライト
- ショートカットでのシンタックス追加
- プレビュートグル
- テーマカスタマイズ
- ファイル管理
- 独自のファイルマネージャ
- Dropbox/Google DriveへのSave/Open
- ローカルファイルのSave/Openも可能
- Publishによる外部公開
- 多様な文法対応
といった具合です。なお、一部はβ限定で、UIも整理されているしバグもかなり修正されているので、βの利用を強く推奨します。
上記の通り、StackEditには目次生成機能がありまして、文中に[TOC]
と書いておくと、見出し項目を検出して目次を自動生成し、ページ内リンクも張ってくれます。一瞬です。もうスクリプトで云々とか考えらんない。
なお、編集中のスクリーンショットがこちらです。
Publish
で、まあ、HTML変換してここに貼ろうとか、Evernoteに投げてインポートとか考えないでもなかったのですが。(Evernoteと連携してノベルティをゲット! Evernoteで保存したノートをブログで活用できる「Evernote貼り付け機能」をリリースしました - はてなブログ開発ブログ)
しかし、他の記事と毛色も分量も違うし、今後似たようなの書くたびにやるのはめんどいので、おとなしくStackEditからPublishすることにしたわけです。
最初はTumblrにしようと思ったんですが、なぜか何度やっても弾かれる。短文だと通るので、なんぞ上限でもあるのでしょう。というわけでボツ。
Githubって内容でもないし、BloggerよりはまあWordPressか。
WordPressだと「ブログ!!!」って感じで、ポツーンというかドスーンと単発長文置いてあると変な感じですが、まあ日本語URLも通るしもう考えたくないしそれでいいかとブン投げました。
おや、できた? ってことで、コチョコチョっと「続きを読む」とカテゴリだけ付けて公開。終わってみれば簡単でした。
(実際にはソースの修正にけっこう手間取ることになったのですが。それは別項にて)
コンテンツ管理システムとしてのStackEditの可能性
今回使ってみて、StackEditをハブにしたコンテンツ管理はけっこうイケてるのではないかと思いましたね。
- 執筆ではMarkdownさえ書ければOK
- 下書きはDropboxかなんかに置いておけばOK
- 再度Publishすれば上書き更新可能
- 記事IDを指定すれば既存記事の上書きも可能
- YAML Front Matter使えるので、メタ情報の付与が楽っぽい(WordPressよりjekyllで本格的ブログを作りたくなる、かもしれないまとめ | ゆっくりと…)
別にMarkdown書くだけならWordPressで書いたっていいわけですが、StackEditのほうがエディタとしては上だし、そもそもWordPressの管理画面は煩雑すぎます。ほんとにバリバリ書くならMarsEditなり使ったほうがいいのでしょうが、なんといっても無料だしウェブベースだし、StackEditでのブログライティングも検討の余地はあるのではないでしょうか。