Now inquisitor is licensed under the MIT license, but is it right? For it I should do two things: survey and decision.

TODO

• check license
  • original code of Gauche → MIT
  • Masayuki Onjo's portion → Dual licensed: GPL and BSD 2-clause
  • zqwell's portion → GPL (v2? v3?)
    • libguess? → MIT
• decide license of inquisitor that is compatible all above

grey -> Shinichi Tanaka

Error occurs when quickloading inquisitor.

CL-USER> (ql:quickload :inquisitor)
To load "inquisitor":
  Load 1 ASDF system:
    inquisitor
; Loading "inquisitor"
[package inquisitor.names]

Reader error on #<BASIC-FILE-CHARACTER-INPUT-STREAM ("/path/to/inquisitor/src/names.lisp"/8 UTF-8) #x3020013DCBED>, near position 7051, within "works) :cr)
    ((:c":
Dot context error.
   [Condition of type CCL::SIMPLE-READER-ERROR]

inquisitor:detect-external-format for stream uses and increments stream's current-position.

UTF-8 named :utf8 in inquisitor on master at now but it seems that UTF-8 should be named like :utf-8.

Because of:

• each implementations have UTF-8 as :utf-8
• other character encodings of Unicode named like <name>-<surfix>

guessを取り込む。
そのさい、keyword.lispの関数をexportしたり(エンコーディング名の処理系非依存化)、guess.lispのDFAユーティリティをdfa.lispにまとめたりする。

It is a problem that inquisitor (or others) has no way to know implementation independent name (encoding name, eol style name. e.g. UTF-8 (enc), LF (eol)) from implementation dependent name.

For instance, when I want to know the encoding name of *standard-input* and want to write file with same encoding as stdin's one.

This code causes an error at inquisitor.encoding.guess::guess-jp:

(defparameter x
 #(140 246 147 73 130 200 145 123 141 245 140 87 129 65 146 178 141 184 138 175
    130 170 130 162 130 233 129 66 10 130 237 130 189 130 181 130 205 148 222 130
   231 130 170 148 67 150 177 130 240 144 139 141 115 130 181 130 196 130 162
   130 233 130 198 130 177 130 235 130 240 140 169 130 189 129 66))

(inquisitor:detect-external-format x :jp)

Now, I think inquisitor's package names are too long. Additionally function/method names are also long, codes using inquisitor is wrapped. (e.g. inquisitor:detect-external-format)

Providing shoter nicknames makes inquisitor more useful.

• inquisitor => inq
• inquisitor.eol => inq.eol
  • or public APIs are exported only in inq.

Specification documents are:

• Unicode
  • UTF-8: https://tools.ietf.org/html/rfc3629
  • UTF-16: https://tools.ietf.org/html/rfc2781
  • UCS-2
  • http://www.unicode.org/versions/Unicode9.0.0/
• Japanese
  • ISO-2022-jp
  • EUC-jp
  • CP932 (SJIS)
• Tiwanese
  • Big 5
  • ISO-2022-tw
• Chinese
  • GB2312
  • DB18030
  • ISO-2022-cn
• Korean
  • EUC-kr
  • Johab
  • ISO-2022-kr
• Arabic
  • ISO-8859-6
  • CP1259
• Greek
  • ISO-8859-7
  • CP1253
• Hebrew
  • ISO-8859-8
  • CP1255
• Trukish
  • ISO8859-9
  • CP1254
• Russian
  • ISO-8859-5
  • KOI8-R
  • KOI8-U
  • CP866
  • CP1251
• Polish
  • ISO-8859-2
  • CP1250
• Baltic
  • ISO-8859-13
  • CP1257

ECLでrequireすると、エンコーディング名がない(例: 'ext:iso2022-jp)と出てエラーになる。

I think inquisitor must abstract external-format in several libraries; e.g. flexi-streams and babel.

libraries

• babel
• flexi-streams

• 改行コード利用可能かを返す述語
• 各改行コードのキーワードを返す関数(guessのように)
• 判定処理

Hebrew traditional alphabet represent only consonants. Vowels has no correspond character. But it's inconvinient. Then Nikud are added to Hebrew writing system. Nikud are characters represent vowels.

So ISO 8859 Part 8 has no nikud in it but codepage 1255 has.

Inquisitor has no test such that.

For more convenience, provide some roswell script.

• inq.ros
  • inq.ros [scheme] [path] --- detect encoding from path
  • inq.ros [scheme] --- detect encoding from STDIO

or

• inq-[scheme].ros
  • command line params
    • inq-[scheme].ros [path] --- detect encoding from path
    • inq-[scheme].ros --- detect encoding from STDIO
  • example: inq-jp.ros /path/to/file.txt => utf-8
• inq-eol.ros [path] --- detect eol-style

Is detecting from STDIO needed?

Now, a lurking bug rises!
This commit can't pass this test. Test data is this.

テストが終わったら申請する

Correct CP932 name on LispWorks is :shift-sjis, but inquisitor returns wrong name.

Because of this, lem has a sadly hack:

https://github.com/cxxxr/lem/blob/8be6a9c91937af0b01bd4ca076104d3154935fc9/lem-core/file-ext.lisp#L66

If you use the latest git version of inquisitor, (ql:quickload "inquisitor-flexi" :verbose t) does not work in recent SBCLs.

Should inquisitor provide implementation independent encoding/end-of-line name?
When just to know encoding/eol name, returning impl's name is inconvenient.

On refine-name-mapping branch, I changed name mapping structure. Oh, large!

So it shoud be tested. Tests about:

• +available-encodings+, +available-eols+
• independent-name per implementation
• dependent-name per implementation
• unicode-p

Docstrings bring some convenience. For example, API reference included documentation on quickdocs!

I think the timing of adding docstrings is after rearranging API(#22).

サポートするコード ページ(VS.NET2003)

Confirmation required.

from https://github.com/t-sin/inquisitor/pull/50/files#diff-8b59a91a78709dc487f614e8f8f07c29R29

Common Lispのloopマクロ

(loop for i from 1 to 3
         with j = i
         collect (list i j))

with j = iはループ毎に更新されるのではなく最初に一回だけなので
結果は((1 1) (2 2) (3 3))ではなく((1 1) (2 1) (3 1))です

detect-end-of-lineのloopを見てみると

(loop for n = (read-sequence vec stream) ; ここでバッファ変数vecを更新して
         with eol = (eol-guess-from-vector vec) ; ここで前の行のvecではなく空のバッファのvecを使ってeolには常にnilが入る
         until (or (zerop n)
                      (not (null eol))) ; eolは常にnilなので(not (null eol))は常にnilでloopを抜ける
         finally (return eol))

この結果detect-end-of-lineは常にnilを返します

このloopのwithをforに変えて動かすと正しく動くはずなんですがテストが通りません
テストの失敗した部分を見てみると
× :LF is expected to be NIL
となっています
しかしこれは:LFが正しいはずなんです

他の場所でも
:UCS-2LE is expected to be :UTF-16BE や
:BIG5 is expected to be :ISO-2022-TW がありますが
これもdetect-end-of-lineの結果を引きずってるみたいです

常にnilを返すバグを無視してテストのほうを変えて動くようにしてるように見えます
この機能は都合が悪くてわざと一時的に動かないようにしてるんでしょうか

気が向いたら直しておいてほしいです

Is inquisitor fast?????

TODO:

• テスト用テキストデータ集め
• テストを書く!!(各処理系ごとに)

指定したファイルはhttps://raw.githubusercontent.com/xyzzy-022/xyzzy/develop/lisp/winhelp.l

(with-open-file (in "winhelp.l"
                    :element-type '(unsigned-byte 8))
  (inquisitor:detect-encoding in :jp)) 
=> :UTF-8

ライブラリを使う側でsbclとその他に分けて
sbclならread-lineで得た文字列の末尾を除去しないといけません
これはinquisitor側でした方がいいと思います

ひとつめはwith-open-fileをinquisitor側でサポートしてgray-streamsを使う方法を考えました
このやり方だと万事うまくいきそうですがsbclのcrlfのためだけにこれをするのは冗長で実装が面倒です

ふたつめはwith-open-fileと一緒にdo-read-lineもinquisitor側でサポートします

(with-input-file ((in external-format) path ...)
  (do-read-line ((string eof-p) in external-format)
    ...))

こうすると末尾のcrの除去を裏に隠せます

変数external-formatを明示的に書いた理由は
ライブラリを使う側でファイルの保存時に文字コードを保つために必要だからです
sbclなら改行コードも考慮する必要があるのでふたつ目の方法だとdo-print-line
ひとつ目の方法だと定義したstreamクラスのスロットににencodingとend-of-lineを入れておく必要があります

ライセンスを決める。Gaucheの元のコードのライセンスに反しないものを選ぶこと。

• remove detecting-buffer-size (#19)
• let detect-encoding and detect-end-of-line be method
  • those can treat vector, stream and pathname same as detect-external-format
• can supply buffer size as &optional to detect-encoding and detect-end-of-line
  • do to detect- things
  • if you wanna check whole file, supply :full

From #41 (in Japanese). Checking BOM codes in guess-* are same. So those code can be factor out.

ドキュメントがまったく充実していない。

system:available-encodingsで可能なエンコーディングのリストを得られる。
また、ソースでexternal-formatの定義を見つけた(定義)。

サポートする処理系にLispWorksを含めるべきか。

charset:iso8859-5だけがないと言われてる。他はOKということか？　マニュアルを調査。

[package inquisitor.encoding.keyword]
*** - READ from
#<INPUT BUFFERED FILE-STREAM CHARACTER
#P"/home/travis/build/t-sin/inquisitor/src/encoding/keyword.lisp"
@307>
: # has no external symbol with name "ISO8859-5"

[https://travis-ci.org/t-sin/inquisitor/jobs/76869696]

Remove *detecting-buffer-size* and add optional size parameter to detecter methods.

That is what I feel...

Provide API for detecting encoding without scheme.
Its precision is worse than with scheme, however, little convenient.