@[TOC](項目なり)

# 改めて文字コードについて  191008
- 保存できない文字コードがあったらエラーを返す仕様だった
でもそのあとを考えてなかった
とりあえずエラー位置に飛べるようにはしたが、u8で保存すれば解決することはわかってる
cp932にこだわってエラー文字を直すのは無駄なんだよねえ
エラーになった文字が何だったのかは知りたいから飛ぶ機能はあって良いんだけどさ
- でもなあ、何となくcp932を残しておきたいって思いもある
ロード時のエンコに関係なく保存時は全てu8にしちゃえば良いだけなんだけども
- 「保存時のエンコードを指定」の機能は必要かもしれない
コンボボックスで選択かな？チェックボックスでも良いか
でもデザイナのUIは作りたくないな～
- 「強制的にU８で保存」にするか！！
「本当に良いですか」を出したりして

# 高速化
scieditor2 は結構完成度が高いと思う
自作だから当たり前だけど凄く使いやすいし
今はこまごまと機能を追加してるが根本的に直したい部分はあんまり思い浮かばない
強いて言えば高速化かな
となるとC++ですよね～

python は遅いって事になってるけどキャッシュされればそれほどでもない
遅いのは最初だけって事ですね
あえてC++でコンパイルする意味があるのか？？
python のままで極力高速化できるようにした方が良いかな


# scieditor2 機能拡張

色んな機能を本体では無くて後付けで実装したい
プラグイン形式では無理かな
起動高速化のために起動時はチェックしない仕組みで

gPad はオブジェクトを提供してユーザーに使わせる仕組み
文法はWSH
どういう仕組みなんじゃ！！！

とりあえずシンチラの付加機能的なものは別クラスにまとめた方がすっきりするかも
起動は少し速くなるんじゃろうか？？

# model データの書き出しについて 190926
treeView の model の書き出しだけど
ストレートにmodelのデータをスキャンするようなコードにしたが、オリジナル文書から解析ロジックそのままで書き出すことも出来たなあ
全く別なロジックを考えたので無駄だったような？？
modelをスキャンした方が早いはずだから正解だったのかな？

オリジナル文書からって事になると解析ロジックはいらない、単に検索して該当行を抽出するだけで良かったのか
現在の行単位検索でもいけたな
modelの書き出しではなくて検索結果の書き出しを実装すれば良いだけだったか！！

アウトラインの指定項目を選択、って機能は必要だけどmodelの書き出しはいらなかったのか
行単位検索の出力のオプションで実装するだけで良かったような気がしてきた

頭の体操にはなったから良いんだけども (ノﾟoﾟ)ノ 


----
 └──> [scieditor2](https://mimemo.io/m/zeXgworpjz4K0Ek)