最終更新: 2012-11-01T13:41+0900
説明が面倒なのと誰も知りたくないだろうから適当に、備忘のためだけに。
%{literal} の literal部分で \{ や \} を使う人間がいるとは思わなかった。(違う種類の括弧を使えばいいじゃない。開閉の釣り合いがとれてれば同じ種類の括弧でもエスケープ不要だし)だのに Ruby1.9の rake.rbにこんなパターンが……
%r{[*?\[\{]}
%r{余分な開き括弧{。間違いはインタープリタを通す前から目立つように}
2のは Rubyインタープリタに対するエスケープ、と同時に正規表現パターンとしてのエスケープですよ。%r[\[] と /\[/ が同じパターンになって、%r[[] がRubyのシンタックスエラー、/[/ がパターンのコンパイルエラーになるんだから。(ruby 1.8.7 (2010-01-10 patchlevel 249) [i386-mswin32] / ruby 1.9.1p0 (2009-01-30 revision 21907) [i386-mswin32])
最終更新: 2010-04-08T22:28+0900
参照(説明の丸投げ)> 萌ディタの Lex 周り - miau's blog?
SHJSと萌ディタ、共通の泣き所。そもそも論を言えば、入力に対応した stateを一つ一つ定義していけば対応できなくもないし、Rubyの括弧を使った %記法、%r(pattern)flag のようなものでは括弧に分類される文字種が 4つしかなかったために実際そうしたのだが、非英数1バイト文字や識別子が使えるとなると状態数があっという間にふくれあがってしまう。
SHJSの場合は、JavaScriptであることと eval()で評価されることを利用して、ネイティブの RegExpオブジェクトの代わりに execメソッドと lastIndexプロパティを定義したオブジェクトを登録することで抜け道を用意できるように感じたが、どんな形で特定のキャプチャを参照するのか決めかねた。
今日試しにダウンロードしてみた K2Editorではヒアドキュメントの色分けが可能なようだ。配布パッケージに含まれる Ruby.txtと K2Editor.chmによると書式はこう。
・<<(["'`]?)(\w+)\1 .... ^$2$
ヒアドキュメント１。後ろのディスクリプターは行内に唯一でなければ
ならない。
右側の検索文字列には、後方参照が使えます。 左側で()でくくってグルーピングしたマッチ文字列を、 右側の検索文字列の中で取得できます。
取得するには、 K2Editorの置換機構の 後方参照と同じように、$1,$2などを使います。
\1、\2でなくて $1、$2だから、右側のパターンは左側のパターンマッチングが終わった後で、置換されてからコンパイルされるのかも。
SHJS(と萌ディタ)にあてはめた場合、$1、$2がどのマッチングのキャプチャを指しているのかが明らかではない。というところで二の足を踏んでいる次第。
formatted_text = <<TEXT.strip.gsub(/\t/, " "*8) TEXT
texts = [<<TEXT1, <<TEXT2] TEXT1 TEXT2
こんなんどうする？
最終更新: 2019-12-01T02:10+0900
20090525に書いたことをやってみた。sh_ruby.jsは巨大なのでとりあえず 0.6/sh_main.js と 0.6/lang/sh_javascript.js (lang/sh_javascript.js) だけ。どちらの sh_javascript.jsも、バックトラックのないノーマル sh_main.jsと組み合わせることもできるつもり(2種類の langファイルをメンテナンスするのは面倒くさいもんね)。0.6/sh_main.jsが自分でも見直したくないソースになっているのは否定できない(だからおおっぴらにリンクしていない)。そういう人間はこう言うのです。「動いたもんが勝ち」
"正しい\ 文字列(ECMAScript 5th ed.の場合)"
"不正な 文字列(ですらない)"
/* 正しい
コメント */
/* 閉じていない
コメント？
ノーマル、バージョン 0.6の SHJSと違うのは、一つの正規表現で始まりから終わりまでマッチングできない対象(複数行にまたがるものとか)に対して、最初の文字「"」や「/*」を見て、文字列だ、コメントだ、と決めてかかった結果を後で修正できること。
「/*」があった。ここからコメントらしい。「*/」が見つからない。やっぱりコメントではない。という判断が改行をまたいでできる。
NOTE 文字 LineTerminator は、それにバックスラッシュ \ を先行させても、文字列リテラル内には出現できない。
以前、どっちなんだろう？と調べたときに「\(改行)」は空文字列と解釈されるシーケンスだ、と書かれてるの(そういうエスケープシーケンスの一覧表)を見たんだけど実際は違ったらしい。
一次情報にあたらなければ同じミスをおかすんじゃないかと手許にあった「Final final final final draft Standard ECMA-262 5th edition」というタイトルの pdfを開いてみた。(3rd ed.ではなく 5th ed.だということに注意)
A line terminator cannot occur within any token except a StringLiteral. Line terminators may only occur within a StringLiteral token as part of a LineContinuation.
NOTE A line terminator character cannot appear in a string literal, except as part of a LineContinuation to produce the empty character sequence. The correct way to cause a line terminator character to be part of the String value of a string literal is to use an escape sequence such as \n or \u000A.
日本語にもそういう罠があるけど、英語だとうっかり正反対の意味にとってしまうことがあって恐い。それでも、行継続の意味に \(改行)を使う(それは空文字列として解釈される)ことは exception(例外)として認められているように読める。
3rdから 5thに更新するにあたり現状を追認するように書き換わったのかもしれないけど……ECMAScript3の仕様はどこ？
面倒くさがらずにダウンロードしてきた。
NOTE A 'LineTerminator' character cannot appear in a string literal, even if preceded by a backslash \. The correct way to cause a line terminator character to be part of the string value of a string literal is to use an escape sequence such as \n or \u000A.
5thで exceptだった部分に even ifが使われている。現バージョンでは文字列リテラル内での「\(改行)」の使用は明確に否定されてた。
というわけで上のサンプルソースの記述を正しくなるように変更しました。
最終更新: 2014-12-24T10:54+0900
個人的にはなくても不便はないけども、番号を表示する方法のアテができたので。
求める条件は
SyntaxHighlighterのように "view source", "copy to clipboard"機能を用意して、行番号が一緒にコピーされる欠点をカバーするのは次善の策。
WP-Syntaxがやっているように、1行 2列のテーブルを作って、左の列に行番号を、右の列にハイライトされたソースコードを配置するのは、サポートするブラウザも多そうで良さげ。
でも行番号あり・なしで二通りの出力フォーマットを用意するのはスクリプトのサイズの面から避けたい。何と言っても、忘れていたけど、shjs-0.4.2をいじくったものであるこの日記の /shjs/sh_main.js はハイライトするついでに、各行に <span class="odd">、<span class="even">というタグをかぶせていたのだった(しかも 3行の追加だけで)。その方面でいくことにする。
つまり、CSS2の counter-reset, counter-increment, counter に全面的に頼った方法。contentで追加した文字列がコピペ不能なのがかえって幸いした。Fx 3.0.7、Safari 3.2.2、Opera 9.64、IE8で期待通りの表示を確認した。(※末尾に追記あり)
pre.sh_sourceCode.sh_numbered .odd:before,
pre.sh_sourceCode.sh_numbered .even:before {
counter-increment: sh_sourceCode;
content: counter(sh_sourceCode, decimal-leading-zero) ": ";
}
--- sh_main.js-0.4.2 Mon May 12 23:07:40 2008
+++ sh_main.js Fri Mar 13 23:29:34 2009
@@ -60,6 +60,8 @@
currentStyle = style;
};
+ var oddLine = false;
+
var endOfLinePattern = /\r\n|\r|\n/g;
endOfLinePattern.lastIndex = 0;
var inputStringLength = inputString.length;
@@ -78,6 +80,7 @@
}
var line = inputString.substring(start, end);
+ builder.startElement((oddLine = !oddLine) ? 'odd' : 'even');
var matchCache = null;
var matchCacheState = -1;
@@ -158,6 +161,7 @@
builder.endElement();
}
currentStyle = undefined;
+ builder.endElement();
if (endOfLineMatch) {
builder.text(endOfLineMatch[0]);
}
@@ -307,8 +311,13 @@
@param element a DOM <pre> element containing the source code to be highlighted
@param language a language definition object
*/
-function sh_highlightElement(htmlDocument, element, language) {
+function sh_highlightElement(htmlDocument, element, language, firstline) {
sh_addClass(element, "sh_sourceCode");
+ if (firstline !== null && ! isNaN(firstline)) {
+ // cssのセレクタで区別できるように。
+ this.sh_addClass(element, "sh_numbered");
+ element.style.counterReset = "sh_sourceCode " + (parseInt(firstline) - 1);
+ }
var inputString;
if (element.childNodes.length === 0) {
return;
@@ -345,7 +354,8 @@
if (prefix === "sh_") {
var language = htmlClass.substring(3);
if (language in sh_languages) {
- sh_highlightElement(htmlDocument, element, sh_languages[language]);
+ // firstlineなんて非標準属性をでっちあげないで
+ // スクリプトにパラメータを渡す方法は？
+ // (class属性を乱用するのは気に入らない)
+ sh_highlightElement(htmlDocument, element, sh_languages[language], element.getAttribute("firstline"));
}
else {
throw "Found <pre> element with class='" + htmlClass + "', but no such language exists";
sh_main.js (version 0.5)への変更も似たようなものだけど、sh_load()の中にも変更すべき場所がある。
sh_main.js (version 0.6)を対応させるのは面倒なので省略。0.4.2も実はそうだったんだけど、shjsはスタイルのネストを想定していない。例えばこれ。
// URL inside comment. <http://vvvvvv.sakura.ne.jp>
ハイライトされた結果の HTMLはこうなる。
<span class="sh_comment">// URL inside comment. <</span><span class="sh_url"><a class="sh_url" href="http://vvvvvv.sakura.ne.jp">http://vvvvvv.sakura.ne.jp</a></span><span class="sh_comment">></span>
フラットな構造で、comment, url, commentと 3つの要素が並んでいる。commentが urlを含むような構造にはならない。0.6ではハイライト前後のタグ構造をマージする仕組みになっているから、0.4.2や 0.5のように ad hocなごまかしができなくて、まずはこの前提を取り払わなければいけない……。
<<< language, number >>>
を
<pre class="sh_language" firstline="number"> </pre>
に変換します。
--- hikidoc.rb.108 Thu Aug 28 22:11:00 2008
+++ hikidoc.rb Fri Mar 13 23:05:05 2009
@@ -335,7 +378,7 @@
@output.preformatted(@output.text(text))
end
- BLOCK_PRE_OPEN_RE = /\A<<<\s*(\w+)?/
+ BLOCK_PRE_OPEN_RE = /\A<<<\s*(.*\S)?/
BLOCK_PRE_CLOSE_RE = /\A>>>/
def compile_block_pre(f)
@@ -665,9 +706,18 @@
end
def block_preformatted(str, info)
- syntax = info ? info.downcase : nil
+ syntax, firstline = *(info ? info.split(/\s*,\s*/) : [])
+ syntax = syntax.downcase if syntax
+ firstline = /\A[-+]?\d+\z/.match(firstline).to_a[0] if firstline
if syntax
begin
+ attr_firstline = firstline ? %Q( firstline="#{escape_html_param firstline}") : ""
+ @f.print %Q(<pre class="sh_#{escape_html_param syntax}"#{attr_firstline}>), text(str), "</pre>\n"
+ @f.puts inline_plugin(%Q(shjs #{syntax.dump}))
+ return
+
convertor = Syntax::Convertors::HTML.for_syntax(syntax)
@f.puts convertor.convert(str)
return
お試しください。
Firefox> 行番号が選択されたり選択されなかったりする。見た目の選択範囲に関わらず行番号はコピーされない。 Safari> 行番号も選択範囲に入るがコピーはされない。 Opera> 行番号がコピーされる。 IE8> 行番号がコピーされる。ダメダメだあ。(この機能は封印しよう)
やっぱり一行二列の表を作る方法でいくことにした。
この方法だと、preを一旦取り除いて tableの下に追加する関係からか、同じ preにハイライト処理が二回走ってしまう(getElementsByTagName()で得られる NodeListが liveである、ということ)。sh_sourceCodeというクラス名を目印に、二度目以降の処理をスキップするよう動作を変更した。
Internet Explorerは 8になっても一筋縄ではいかないようで……。左右の列の<pre>の高さが、デフォルトスタイルシートと同じ font-size:80%でないと揃わない。「IE8互換表示」や「IE7」モードだと揃うんだけど。
二重処理を防ごうと Array.prototype.sliceを使って NodeListを Arrayに変換しようと思ったらまたしても IEの壁。オブジェクトを指定してください、と相変わらずわかりにくいエラーメッセージ。(prototype.jsが愚直にループをまわしてるのは IEのせいかもね)
<table>を使うとその中の <pre>の幅が、内容に同期している(最小にして十分なサイズ)。他の <pre>と同じように、いつでも本文と同じ幅に揃えたいなー。
<pre class="sh_javascript" firstline="00339"> このような <pre>を出力すると…… </pre>
sh_putLinenumber: function(element, param, inputString) {
var startline = parseInt(param, 10);
var opt = /^([-+]?)(0*)(\d+)/.exec(param);
var opt_explicit_sign = (opt[1] === '+') ? '+' : '';
var opt_zero_padding = (0 !== opt[2].length) ? new Array(opt[2].length + opt[3].length + 1).join('0') : '';
var re_zero_padding = new RegExp('^0+(?=\\d{' + opt_zero_padding.length + '})');
var nums = inputString.match(/(?:\r\n?|\n)(?!$)|$/g);
if (0 !== opt_explicit_sign.length || 0 !== opt_zero_padding.length) {
for (var i = 0; i !== nums.length; ++i) {
nums[i] =
(0 < startline + i ? opt_explicit_sign : startline + i < 0 ? '-' : '') +
(opt_zero_padding + Math.abs(startline + i)).replace(re_zero_padding, '') +
nums[i];
}
}
else {
for (var i = 0; i !== nums.length; ++i) {
nums[i] = '' + (startline + i) + nums[i];
}
}
var d = element.ownerDocument;
var e = {table:'table', tbody:'tbody', tr:'tr', tdLeft:'td', pre:'pre', tdRight:'td'};
for (var p in e) {
e[p] = d.createElement(e[p]);
}
element.parentNode.replaceChild(e['table'], element);
e['table'].appendChild(e['tbody']).appendChild(e['tr']);
e['tr'].appendChild(e['tdLeft']).appendChild(e['pre']).appendChild(d.createTextNode(nums.join('')));
e['tr'].appendChild(e['tdRight']).appendChild(element);
e['table'].className = 'sh_sourceTable';
e['pre'].className = 'sh_sourceCode sh_numbers';
return element;
},
341-344、346-354、358行がオプションのために追加した部分。(SyntaxHighlighter2.0の行ハイライト機能はこういときにつかうのだな。イラネと思っていたのを改めます)
固定幅というわけではなくて、0の数以上に繰り上がれば桁が増える。上の場合では 99999行目を超えたとき。テストする段で気付いたが、最低でも 92行のソースコードを貼らないと恩恵に与れない……。
正規表現を持ち出すまでもなく、適切な数の 0をくっつけるだけでよかったんだね(> JavaScriptのビルトインオブジェクトの拡張：ゼロパディング - 気まぐれショウルーム)。先に調べよう。過去に、適切な数の 0を知るために log(10)をとればいいと無邪気に考えていた苦い記憶があるので、最初に正規表現を持ち出してしまった(それもどうだ？)という事情があったりもするんだけど。(Number.toString(10).lengthで済んでしまうなんて！)
<pre>直後の改行は存在しないかのように扱われるが、</pre>直前の改行は存在する(スクリプトで取得できる)ものの表示されない(4つのブラウザで確認)。というわけで、末尾の空行に行番号を付けてしまうと列の左右で行の数が一致しなくなる(だから除外する)。
Google Chrome(1.0.154.53)は
<pre>.innerHTML = <pre>.innerHTML
とやるたびに先頭の改行文字を取り除いていってしまうんじゃないか？ 個別のブラウザ対応は切りがないし、完全対応は不可能なので、行番号を付けるときは <pre>の最初と最後の行を空行にしないのが最も安全。
トンデモ IEさんは <pre>.innerHTML= だろうと <tag style="white-space:pre">.innerHTML= だろうと空白をトリミングしてくれますしね。
テストが不十分なので、langファイルの自動読み込み部分など、一度も実行されていない部分が動くかは不明。
最小化方法は JSMin。ためしに YUI Compressorにもかけてみたがローカル変数の短縮を全くやってくれなくて JSMinと大差ない結果だった。一番外側の無名関数の実行部分をとりのぞいたらちゃんとローカル変数名の短縮もやってくれた。
小手先の変更もいくつか加えた。(ブラウザ判別コードの実行を一度だけにしたり << 関数の中で分岐するんでなく、判別結果で関数を取り換える)
アナウンスされている変更点は…… (注: 日本語部分は俺の勝手な訳のような注釈のようなもの)
December 15, 2008 - SHJS 0.6
SHJS 0.6 is available for download.
SHJS 0.6 includes several new features, improvements and bug fixes:
SHJS is now distributed under version 3 of the GNU General Public License. (Older releases of SHJS were distributed under version 2 of the GNU GPL.)
ライセンスが GPLv2から GPLv3へ変更。
Markup inside pre elements is now preserved.
PREタグの中の HTMLマークアップが保存される。(以前は Node.dataを再帰的に取り出したもの。乱暴にいうと PRE.{innerText|textContent}に相当するものが利用されていた。ver.0.5ではマークアップとして <br>のみが考慮されていた。)
Several new languages (from the latest release of GNU Source-highlight) are included: S-Lang, Scala, Java properties files, Desktop files, LSM (Linux Software Map) files, Xorg configuration files, RPM spec files, Haxe, LDAP files, GLSL, Objective Caml, Standard ML, JavaScript with DOM, and C (separate from the C++ language file).
最新の GNU Source-highlightから新しい言語ファイルを追加。JavaScriptには DOMキーワードを含んだ lang/sh_javascript_dom.jsが追加された。(sh_javascript_dom = sh_javascript + applicationCache|closed|Components|content|controllers|crypto|defaultStatus|dialogArguments|directories|document|frameElement|frames|fullScreen|globalStorage|history|innerHeight|innerWidth|length|location|locationbar|menubar|name|navigator|opener|outerHeight|outerWidth|pageXOffset|pageYOffset|parent|personalbar|pkcs11|returnValue|screen|availTop|availLeft|availHeight|availWidth|colorDepth|height|left|pixelDepth|top|width|screenX|screenY|scrollbars|scrollMaxX|scrollMaxY|scrollX|scrollY|self|sessionStorage|sidebar|status|statusbar|toolbar|top|window + alert|addEventListener|atob|back|blur|btoa|captureEvents|clearInterval|clearTimeout|close|confirm|dump|escape|find|focus|forward|getAttention|getComputedStyle|getSelection|home|moveBy|moveTo|open|openDialog|postMessage|print|prompt|releaseEvents|removeEventListener|resizeBy|resizeTo|scroll|scrollBy|scrollByLines|scrollByPages|scrollTo|setInterval|setTimeout|showModalDialog|sizeToContent|stop|unescape|updateCommands|onabort|onbeforeunload|onblur|onchange|onclick|onclose|oncontextmenu|ondragdrop|onerror|onfocus|onkeydown|onkeypress|onkeyup|onload|onmousedown|onmousemove|onmouseout|onmouseover|onmouseup|onpaint|onreset|onresize|onscroll|onselect|onsubmit|onunload)
Many other languages have minor improvements.
言語ファイルのアップデート。
Compressed .min.css stylesheets are now included in the distribution.
最小化した CSSファイルを同梱。(.jsも .cssも YUI Compressorを使用。ver.0.5までは .jsのみが JSMinで処理されていた)
Please note that the format of language-specific JavaScript files has changed in SHJS 0.6. JavaScript language files from version 0.6 will not work with sh_main.js from previous releases, and vice versa. Make sure you upgrade both the sh_main.js file and language-specific files.
古い言語ファイル(lang/*.js)と新しいメインスクリプト(sh_main.js)は互換性がない(逆も同じ)。両方入れ替えるべし。
大きな変更は <pre></pre>内の HTMLマークアップがシンタックスハイライト後も保存されること。(タグがたすき掛けになるときはどうするんだろ？)
言語ファイルの変更は小さくて、"next"、"regex"、"style"、"exit"というプロパティを持ったパターンオブジェクトが、3要素の配列になっている。
function sh_highlightElement(element, language) {
sh_addClass(element, 'sh_sourceCode');
var originalTags = [];
var inputString = sh_extractTags(element, originalTags);
var highlightTags = sh_highlightString(inputString, language);
var tags = sh_mergeTags(originalTags, highlightTags);
// この documentFragmentはグローバル変数の document由来。
var documentFragment = sh_insertTags(tags, inputString);
while (element.hasChildNodes()) {
element.removeChild(element.firstChild);
}
// element.ownerDocument != documentFragment.ownerDocumentのとき失敗しませんか？
element.appendChild(documentFragment);
}
コメントを参照のこと。IEのバージョンが 5.5くらいだった時に失敗したような記憶が根拠で、確証はないし、レアケースだとは思うけど。(フレームをまたいで sh_highlightElement(element, language)を呼び出したとき(=スクリプトとエレメントが異なるドキュメントに属するとき)に起こるかなぁ？)
<pre class="sh_ruby"> require 'sqlite3' <strong>require</strong> 'sqlite3' <strong>req</strong>uire 'sqlite3' </pre> <pre class="sh_javascript"> /* http://example.com http://example<em>.</em>com */ </pre>
<pre class="sh_ruby sh_sourceCode"> <span class="sh_preproc">require</span> <span class="sh_string">'sqlite3'</span> <strong><span class="sh_preproc">require</span></strong> <span class="sh_string">'sqlite3'</span> <strong><span class="sh_preproc">req</span></strong><span class="sh_preproc">uire</span> <span class="sh_string">'sqlite3'</span> </pre> <pre class="sh_javascript sh_sourceCode"> <span class="sh_comment">/*</span> <a href="http://example.com" class="sh_url">http://example.com</a> <a href="http://example.com" class="sh_url">http://example</a><em><a href="http://example.com" class="sh_url">.</a></em><a href="http://example.com" class="sh_url">com</a> <span class="sh_comment">*/</span> </pre>
SHJSの挿入するタグは必要に応じてぶつ切りにされるみたい。
移行スクリプトはこれ( migrate_05_06.js )。shjs-0.5までの lang/sh_*.jsファイルをドロップすると lang/sh_*.06.jsというファイルができてくるという寸法。ちなみに JScript製。
テストもかねてバージョン 0.6を走らせてみたけど、軽くなってる道理がない*ので、この日記では shjs-0.4.2に手を入れたものを使い続けている。
言語ファイルのフォーマット変更は速度的に有利。
パターンマッチの結果を Stateをまたいで保存するようになっているので、この日記の sh_ruby.jsのようにあっちこっち跳びまわる言語ファイルに有利に働く。いちばん時間を消費しているのが RegExp.exec()と DOMツリーへの HTML断片の追加なのでパターンマッチ結果のキャッシュは大事。(もっとも 0.4.2のときからキャッシュの拡大は個人的にやっていた)
* <pre>内のマークアップを保存するためにハイライト前と後の、二つの HTML文字列をマージしている。でもその機能、俺個人はいらないのよね。
- SHJS can now automatically load language script files (feature request #2007022 - thanks to Michal Nazarewicz and Eugene Marcotte).
- Highlighting of C/C++ and JavaScript has been improved.
- A new language file for Oracle SQL has been added (thanks to Mike Breeze).
- Case-insensitive regular expressions are now handled more efficiently.
- SHJS now treats <br> tags as line terminators in input (bug #2054144 - thanks to Altforweilerer).
- Compressed .min.js files are now generated with YUI Compressor.
languageファイルの自動読み込みは Msxml2.XMLHTTPか XMLHttpRequestを利用する。
<script>タグを挿入するのかも*と思っていたが今風のやり方だった。(SourceForgeの Feature Requestsで両派の議論があったようで、0.5では Asynchronous XMLHttpRequestを採用したけど将来かわるかもー、だって)
lang/sh_javascript.jsの全変更点(多分)は
新たに対応したものも対応が外れたものもあるが、どちらも JavaScriptの仕様に近づくための変更という点は共通。
それでもやっぱり Javaっぽいのは、java.langまるごとインクルードだった前バージョンの source-highlight-lang/javascript.langが、java.langの中身をベースに足し引きしたものに変わったに過ぎないから。
「大文字小文字を無視する正規表現を効率的に」っていうのは lang/sh_sql.jsを見るにこういうこと。
/[Vv][Aa][Rr][Cc][Hh][Aa][Rr]/ // ver. 0.4.2 /VARCHAR/i // ver. 0.5
……。
YUI Compressorはローカル変数名を縮めることで JSMin以上の圧縮を図る。
他にも、obj["prop"]を obj.propに(可能なら)したり、連結されるリテラル文字列を予め一つにしたり、オブジェクトノーテイション(って言うの？)のプロパティ名部分の引用符を取り除いたり({"p1":v1, "p2":v2} -> {p1:v1, p2:v2})、するらしい。
おれは JSMinでアグレッシブ(level 3 of 3)に最小化する(と、不要な空白と全ての改行が取り除かれるので、セミコロンインサーションの余地がなくなって、一つのセミコロンも省略できなくなる)のが好きなんだけど。何より Javaの実行環境がないから、YUI Compressorは動かない……。
ブラウザ(クライアントサイド)で実行されるのでサーバーの負荷が増えません。
メインスクリプト(最小化されたものが数KB)は必須ですが各言語ファイルはオプションです。名前も知らない言語の定義ファイルまでブラウザにダウンロードしてもらう必要はありません。
自動認識のような不確かなものに頼りません。(自分の書いているものが何語なのか知らない人は少ないでしょう。あえて情報を削ってスクリプトの仕事を増やす必要はありません)
言語ファイルは、状態オブジェクトの配列です。各状態は正規表現のパターンを一つ以上持ち、マッチしたパターンにより配色と遷移先を決定します。状態が増えるのをいとわなければ何でもできます⁑⁂。
ダブルクォーテーション文字列や数字や URLなどにマッチする正規表現を並べて順番にマッチングさせるだけのハイライターより一段上のパターン認識が可能です。(有名どころの SyntaxHighlighter 2.0は XRegExpというライブラリを使用していて、これが Perl5や鬼車や .NET並の正規表現を JavaScriptでも使用可能にしています。これも一歩踏み出す一つの方法ですが、ほとんど XMLのハイライトでしか使われてないようにも見えるのがもったいない)
JavaScriptの方は letみたいな新しいキーワードには対応していないが、JScript5.5(ECMAScript3)に準拠したスクリプトのハイライトに可能な限り対応している。Javaもどきの実装とは全然違います。
Rubyの方もがんばったけど、こちらは正規表現による字句解析レベルでは判断の付かない要素が多くて、例えば
str1 = % hoge ; #=> "hoge" str2 = "%04d-%02d-%02d" % [2008, 8, 20] #=> "2008-08-20"
% をメソッドと判断する(下段)か %!string! とする(上段)かは文脈がないと決められない。現在は後者が誤って %!string! と判断されている(%!string!記法の区切り文字としてスペースを認めなければ、より多くのケースで妥当な表示が得られるのはわかっているが……)。また、改行を含む %!string! リテラルにも対応していない(はてなはこれができる。悔しい)が、かっこを使った %記法( %[string]など )では改行を含むことができる。
既知の不具合はこれだけ。(知らないだけ)
* その場合スクリプトが実行されないことがあったような……(検索結果>http://la.ma.la/blog/diary_200612061928.htm ) と思ったが、IEで innerHTMLを使った場合の話だった。とはいえ、DOMで <script>エレメントを作成することは可能で、実行もされるというのだろうか？
⁑ 厳密ではない。感覚的な言葉。
⁂ この文では普通の正規表現以上の表現力(例えばかっこの対応を調べられる)があるのを説明できていないような。(ある状態から別の状態へ移動するだけでなく後戻りすることもできるから、というのでは説明になっているだろうか？
*4 2008年12月にリリースされた shjs-0.6でフォーマットが変更になったので shjs-0.5用。
$ で GREPしてみたらこういうものが無数に見つかった。だいたいが一行コメントの中に対応した state。終了条件は行末で、URLを含んでいれば sh_urlとしてマークする。
{
'exit': true,
'regex': /$/g
},
{
'regex': /(?:<?)[A-Za-z0-9_\.\/\-_]+@[A-Za-z0-9_\.\/\-_]+(?:>?)/g,
'style': 'sh_url'
},
URLが改行の直前まで続いていれば、終了条件としての行末の検出がスキップされて一行コメントが次の行まで継続する。まさしく 20080513p01の問題の繰り返し。
結局、sh_main.jsに非互換な変更を加えるのは問題大ありだと判明したので sh_javascript.jsで対応することにしましたよ、と。
[ // state 2: in "string"
{
regex: /\\[\\"]/g
},
{
next: 6,
regex: /\\$/gm
},
{
exit: true,
regex: /"|$/gm
}
],
[ // state 6: eat an end-of-line ※空行は食べられないよ
{
exit: true,
regex: /^/gm
}
]
動作確認は昨日の日記で。
例えば、JavaScriptのリテラル文字列では \ と改行のシークェンスは空文字を意味している。つまりこういうこと
var str = "空白を含まない\ ひとつながりの文字列です";
このシークェンスを認めるように、ダブルクォーテーション文字列の終了条件として次のようなものを shjs/lang/sh_javascript.js に含めてみたがうまくいかなかった。
[ // "string"
{
// \\ と \" と \(改行) を 1つのシークェンスとして
// 食べてしまう。終了位置を見誤らないためであって、
// 特に何をするということもない。/\\(.|$)/gm でも構わない。
regex: /\\(?:[\\"]|$)/gm
},
{
// エスケープされていない " に出会ったら "～" の中に
// いるという状態(state)から exitする。
// " がないまま行末に達したら、終端されていない不正な
// 文字列だと判断して、やはり exitする。
exit: true,
regex: /"|$/gm
}
],
少し前に「行末に達した時点でマッチングを打ち切っていたのが間違い。$は空文字列にもマッチする。全てのマッチに失敗するまで続ける必要があった(20080513p01)」と自分のミスを書いて、これを修正したのだが、shjs-0.4.2はもちろん正しく、全てのマッチが失敗するまで続けている。
そうすると何が起こるか。/\\$/gm にマッチした後でも /"|$/gm のマッチに成功してしまい、結果、行末に \ があろうがなかろうが exitしてしまう。
もちろん行末に達したからといってすぐにマッチングを打ち切っては 20080513p01と同じ間違いを犯すことになるので、同一 state内で*二回以上*行末にマッチすることがないように sh_main.jsを変更した。
内の方のループの、頻繁に実行される部分に if が増えたのが気に入らないものの、悪影響のある非互換でもないし、首尾は上々だし(冒頭の文字列のハイライト結果が見本)、悪くない。
var str = "終端されていない 不正な文字列です";
var str = "終端されていない\" 不正な文字列です";
*たまたま*行末にある \" にマッチしたことで、終了条件である行末の検出がスキップされて、次の行までが文字列だと判断されている*。\" とのマッチは \$ と違い行末を要求していないから、この場合は一行目で exitしてほしい。
* 20080530p01で修正したので文章とハイライト結果が食い違っているかもしれない。
例えばこのページ http://vvvvvv.sakura.ne.jp/ds14050/diary/20080112-7.html 。Endキーで末尾に移動して PageUpで戻っていくと空白の PREが目に入ると思う。その少し上にはページの内容を覆い隠す黒い領域があるはず。(そうでなければ修正されたのだろう。Firefox2で最初に確認し、Firefox3.0RC1でも直っていなかったが)
大量の PREが存在したり、一つだけでも巨大な PREが存在する場合に起こる様子。innerHTMLで PREの内容を置き換えているのも原因になっているかもしれない。
画面の末端にスクロールした状態でページをリロード(F5 or Ctrl+R)すると下方の PREが正常に表示される反面、上端付近の PREに同じ問題が生じる。遠方の PREの書き換えに問題があるのでは？
真っ白の PREの中で、右クリックしたりテキストを選択したりといったアクションを起こせば正常に表示されることが多い。
あと、PREの中から開始した選択は PREの外に出られなかったり。(これは TEXTAREAと違い PREでは Ctrl+Aで全文選択ができないために用意された代替手段だという気もする)
オリジナルの sh_javascript.jsはコメントの中の URLっぽい部分とメールアドレスっぽい部分をハイパーリンクにしていた。機能が劣るのは遺憾なので sh_javascript.jsと sh_ruby.jsに、コメントと文字列の中の URLっぽい部分をハイパーリンク化する機能を追加した。
その過程で気付いた、一行コメントの終了条件などに使われている $アンカーのマッチングが行われない場合があったのを修正した。(行末に達した時点でマッチングを打ち切っていたのが間違い。$は空文字列にもマッチする。全てのマッチに失敗するまで続ける必要があった)。これは自分が 2008-02-25に持ち込んだバグでオリジナルには存在しない。
# http://vvvvvv.sakura.ne.jp/ds14050/badboy/log/ How is this line highlighted ?
最終更新: 2009-09-01T05:05+0900
このようにハイライトされます。
'%04d-%02d-%02d' % [2008, 5, 8]
(整形した)HTMLソースはこう。
<span class="sh_string">'%04d-%02d-%02d'</span> <span class="sh_string">% [2008, </span> <span class="sh_number">5</span> <span class="sh_symbol">,</span> <span class="sh_number">8</span> <span class="sh_cbracket">]</span>
「% [2008, 」が一つの文字列にされてしまっている。どういう判断なのかと調べれば、%!string! と同じものだと見なされていた。(そのルールは自分で書いたんだけども)
知っていたでしょうか？ %リテラルの区切りには空白(改行も！)が使えるのでした。(alnumと mbchar以外なら OKっぽい。変態すぎるよ)
最終更新: 2010-03-21T03:27+0900
SHJSの sh_main.jsを高速化したことを以前書いた。(20080204p01)
SHJSのページには動作を確認したブラウザとして以下が挙げられている。
sh_main.jsの修正版は Firefox2と IE7と Opera9で正しく動作することの確認と速度の比較を行っている。
IE6での確認は IE7から戻すのが面倒なので省略する。
Sarari3は Vistaで動くものがダウンロードできるので確認してみたところ動いた。(表示も正常)
いじったことで対応ブラウザが減っていなくて良かった。(IE6は？)
SHJSの作者は Code Conventions for the JavaScript Programming Language や jslint: The JavaScript Verifier かそれに類似した文書を読んでいるに違いない。(これらのページを今日発見した)
というのも、sh_main.jsを JSLintでチェックしてみたが、こういうエラーしか出なかった。
Error: Implied global: document 362, sh_languages 347, window 332
このエラーは JSLint向けにコメントを埋め込めば取り除けるものだし、そうしないと不可避だともいえるもの。
Error:
Implied global: document 207 360, sh_languages 332, window 329
Problem at line 73 character 48: Use the array literal notation [].
matchCaches = language.matchCaches = new Array(language.length);
Problem at line 86 character 17: 'i' is already defined.
for(var i = matchCaches.length-1; i !== -1; --i) {
Problem at line 97 character 22: 'i' is already defined.
for (var i = state.length-1; i !== -1; --i) {
Problem at line 110 character 17: 'i' is already defined.
var i = (pair[0] & 0x3F);
Problem at line 280 character 15: Use '!==' to compare with '0'.
while(0 != this._currentStyles.length) {
Problem at line 389 character 14: 'node' is already defined.
var node = this.free_;
「var array = new Array(length);」を「var array = []; array.length = length;」や「var array = Array.prototype.slice.call({length:length}, 0);」 と書き換えることは拒否する。
(new Array(length)が一番簡潔で自然な書き方)
(JavaScript 1.7の配列内包に書き換えるのには吝かでない)
(一つを除いて) 無視できる警告*ばかりで良かった。
* 無視したら警告の意味がない。forループの変数なんて(古い VC使い以外には)スコープの誤解を招きやすいという理由で、避けなければいけないものの筆頭ともいえる。
SHJSのブラウザでの実行時間を削るには sh_main.js(SHJSのメインスクリプト)を速くするか、正規表現を効率的なものにする方法がある。(>遅い正規表現(20080116p01))。
正規表現に関してできることは限られるうえ、知識も少ない(『詳説 正規表現 第三版』待ち)ので、可能な限り文字クラスや文字集合といわれるものを使うように気を付けただけにとどまる。(sh_ruby.js, sh_javascript.js)
メインスクリプトの sh_main.jsに対してできることは多い。この日記の現在?の最新ページ(2008年1月12日から7日間)を表示して、sh_highlightDocument()前後での経過時間を表示したところこのようになった。
| Firefox2 | IE7(64-bit) | IE7(32-bit) | Opera9.25 | |
|---|---|---|---|---|
| sh_main.js (0.4.2) | 935ms | 1050ms | 1270ms | 1260±150ms |
| 改変版 | 600ms | 680ms | 865ms | 1200±150ms |
| 削減率 | 36% | 35% | 32% | 5% |
ハイライト対象が少なくて数ミリ秒で処理が終わるような場合はオーバーヘッドのために改変版の方が 1-2ミリ秒遅くなるが、それよりもスクリプトがブラウザをロックする時間が長くなるような場合にこそ速度改善が必要なので OK。
代償としてファイルサイズが sh_main.jsで 10.5KiBから 12.7KiBへ +2.2KiB。jsmin圧縮後の sh_main.min.jsで 6.22KiBから 7.82KiBへ +1.60KiB。Apacheによる gzip圧縮やブラウザのキャッシュに期待します。
普段は全く Operaを使わないし、詳しくもない。むしろ Operaではキーボードを使ったブラウジングもままならない。そんな人間が Firefox+Firebugを頼りに sh_main.jsの修正を行ったので Operaの速度が改善しないのは仕方のない部分がある。(IEは改善したが)。(あんだけいじってトータルで変わらない方がすごい。どこが足を引っぱっているのだろう)。リテラル文字列と Stringオブジェクトの差が他のブラウザより大きいらしいが、それが原因？
EfficientJavaScript - Dev.Opera - 効率的な JavaScript (www.hyuki.com)
Operaでの JavaScriptの実行時間が他のブラウザに比べて長いのははっきりした理由があって、Operaはスクリプトが全力疾走中であってもユーザーの操作に対する反応を後回しにしたりしない。これは偉い。ユーザーを待たせない代わりにスクリプトが遅れるのは当然の代償で仕方がない。
あ、スクリプトでなく再描画が律速してるから改善しないということ？
(常に最新版だが一時的にバグが混入していることがあるかも)
すぐ上のリンク先はすでに変更が反映されている。
これら二つの記事を参考に escapeHTML()を変更した。測定に使ったページでは 9000回ちかく呼び出されるメソッドなので影響はバカにならない。といっても 600msだったのが 590msを切るようになった、というレベル。むしろ下請けfunctionを隠蔽できたことの方が嬉しい。
escapeHTML()自体、sh_builderのインターフェイスではないので、外部から呼び出せないようにすべきかもしれないが、functionをかぶせるたびに呼び出しのオーバーヘッドが増える気がしてそうはしていない。
SHJSの patternStackオブジェクトは外部と完全に独立して動作するのに、sh_highlightString()が呼ばれるたびに無名クラスとそのインスタンスを作成するような方法がとられている。コンストラクタと prototypeを書こう。(sh_highlightString()は HTML文書内の <pre class="sh_XXX">の数だけしか呼ばれないから影響は小さいが。件のページでは 58回)。
sh_highlightString()からしか使われないのにスタックの可視範囲が広がるのが気になるなら、さっき覚えた無名functionで二つをくるんでしまえば良い。
var sh_highlightString = (function(){
var Stack = function(){
this.stack_ = [];
};
Stack.prototype.getLength = function(){/* ... */};
// ……
return function(){
var patternStack = new Stack();
/* sh_highlightStringの中身がつづく…… */
};
})();
まあ、速度が改善するわけではないので、書き直さないんだけど。
innerHTMLや textContent、innerTextの使用は堕落だという気もするが、冗長な上に呼び出しを重ねることで遅くなる DOMメソッドがいけない。