!!!文字列の検索・置換を行うDA （ Palm OS 5 ） *投稿者： 陰郎 *カテゴリ： ... *優先度： 普通 *状態： リリース済 *日時： 2006年06月16日 01時16分32秒 {{bugstate}} !!内容 えぇと、自分で書いちゃいます。（笑 　以前、オフ会で聞いた話なのですが、文字列の検索や置換を行う DA として存在している ReplaceDA が Palm OS 5 では動作しないとのこと。陰郎個人は ReplaceDA の存在を知らなかったのですが、随分前に標準の MemoPad に検索機能が無いことを（イマサラながら）知って愕然としたこともあり、必要と感じています。 　で、作成する気満々なのですが、ここでは仕様の詳細について皆さんからご意見を頂けたらな、と思っています。基本的には ReplaceDA と同等の機能を実現する予定ですが、削ったり付け足したりするかもしれません。「 これは是非！ 」というのがあれば参考にさせていただきます。 ＃ このコーナーの使い方としてはいささか反則かも ＃ しれませんが、皆様どうかご容赦の程を。（汗 　 !!仕様（ 検討中 ） !全般 *DA として動作する。 *検索と置換ができる。 *ワイルドカード検索ができる。 *正規表現検索ができる（遠い将来の話）。 *オーバーラップ検索・置換ができる。 *大文字と小文字を区別しない検索ができる。 !置換 *順次置換と一括置換ができる。 *選択範囲のみを対象とした一括置換ができる（これはボツの方向で）。 !その他 *検索文字列および置換文字列の履歴を保存する。 *起動時の選択文字列をデフォルトの検索文字列とする。 　 !ノーマル検索 *\t、\n、\s などの特殊文字略記を使用できる。 !ワイルドカード検索 *\t、\n、\s などの特殊文字略記を使用できる。 *? で任意の一文字（１バイトではない）とマッチする。ただし、? は改行コードとはマッチしない。 * * で０文字以上の連続する文字とマッチする。ただし、* は改行コードを跨がない。 * * の動作は最短一致で固定される。これにより、特定位置からのマッチは最大１つに限定される。 　 !!画面イメージ（試作段階） 　ひとまず、画面がもっとも小さいノーマル／ワイルドカード検索の場合で以下のようにしようと考えています。 {{ref_image 061022-sample-1.gif}} 　検索文字列の右にある［ｖ］というボタンは、タップすると過去の検索文字列の履歴を表示するためのものです。［Ｎ］［Ｗ］［Ｒ］という３つのプッシュボタンは、順にノーマル検索、ワイルドカード検索、正規表現検索の各モードを選択するためのものです。その下には検索か置換かを選択するプッシュボタンもあります。Replace というプッシュボタンをタップして置換モードに入ると、下図のように検索文字列を入力するフィールドの下に置換文字列を入力するフィールドが現れます。 {{ref_image 061022-sample-2.gif}} 　さらに［Ｒ］ボタンをタップして正規表現検索／置換モードに入ると、正規表現のオプションを入力するためのフィールドも表示されます（下図参照）。これが現時点で最大のウィンドウサイズです。 {{ref_image 061022-sample-3.gif}} 　正規表現はオプションが非常に多くなりそうなので、フィールドに文字列で入力するという逃げを考えています。それだけではキツいので、[Support] ボタンを用意してオプション文字列を生成するためのサポート画面に飛ばそうかと．．．まぁ、正規表現機能はまだ絵空事ですが。（汗 　 !!ダウンロード 　現在、Version 0.70 がリリースされています。以下のサイトからダウンロードすることができます。 　http://www.project-enigma.jp/products/ReplacedDA/index.htm 　 !!正規表現検索機能に関する計画 　当面のリリースでは正規表現検索機能はサポートされませんが、将来的には実現したいと考えています。以下のページにて、ゆっくりとではありますが勧めていくことにします。 [[正規表現検索エンジンの実装について]]　（ members only ） 　 !!コメント *正規表現を！是非！ - alg (2006年06月16日 08時04分25秒) *やっぱりきたかー。正規表現。陰郎は正規表現にはうるさいよ？　でも、そもそも空間制限のキツい Palm で、しかもさらに制約の多い DA でやるの？　ひとまず、陰郎の持ってるエンジンを alg さんに見てもらおうかな．．．どのあたりの機能までサポートするか、それが問題なので．．．フルスペックはキツいと思うけど。（汗 - 陰郎 (2006年06月16日 10時18分31秒) *あんまり大風呂敷を広げると収拾つかなくなるので、最初は正規表現機能はナシでリリースになるだろうな、と思っています。ただ、後から機能として組み込めるような設計にはしとく予定です。 - 陰郎 (2006年06月16日 10時52分16秒) *開発宣言板も必要なのか？な。 - kitta (2006年06月16日 12時32分21秒) *開発宣言板までは必要ないと思いますよ．．．頻繁に発生するモノではないでしょうし。ちなみに、作成しようと思っている DA は Palm OS 5 専用にする予定です。なぜなら、検索エンジンを ARMlet で組むかもしれないから。OS 4 以前は ReplaceDA を使用してね、ということで。 - 陰郎 (2006年06月16日 12時51分41秒) *たしかに正規表現フル実装はキツそうです。OS 5であっても。もしよかったら、正規表現エンジン見せてください。 - alg (2006年06月16日 13時23分22秒) *了解す。今夜連絡します。検索部分を完全に ARMlet 化するとして、問題は利用可能なメモリ空間ですね．．．はてさて、どこまでできるやら。 - 陰郎 (2006年06月16日 15時15分52秒) *画面デザインを考え中です。基本的には設定は１画面で済ませるつもりですが、［検索／置換］を切り替えるボタンによって置換文字列入力フィールドの表示が切り替わるようにしようと思っています。また、普段使用しないような詳細オプションの表示・非表示も切り替えられるようにしようと思っています。問題になるのが、検索方法によって詳細オプションの内容が変わることです。現在、通常検索・ワイルドカード検索・正規表現検索を予定していますが、指定できるオプションはそれぞれ異なります。特に正規表現検索は山のようにオプションが存在するでしょう。DA らしく、歯切れの良いデザインにしたいのですが．．． - 陰郎 (2006年06月19日 20時57分04秒) *些細な進捗報告ですみません。現在、非 ARM 環境でも正規表現検索以外は動作するようにしようかと検討中。枠組みはできました。エンジン部分は後回しで、起動時画面の操作感だけでも先に検証できるモノを上げようともがいてます。御意見・御要望引き続き募集中．．． - 陰郎 (2006年06月20日 23時25分26秒) *DA で大域データが使用できないことから、C++ の言語機能の一部が使用できないことが判明しました。そのため、設計がほとんどやり直しです。また、この影響が ARMlet 内にも及ぶのかどうか、確認が必要です。もしそうだとしたら、陰郎の正規表現エンジンはまったく使い物になりません．．．（涙 - 陰郎 (2006年06月22日 02時51分52秒) ::Re: - Souten (2006年06月27日 18時50分42秒) :::ReplaceDA、待ってました！ 本当によく使っていたDAなのでOS5で動いてくれたらメチャメチャ嬉です。 お忙しいのは存じておりますが、完成するのを心待ちにしております。 ::Re:Soutenさん - 陰郎 (2006年06月27日 19時07分44秒) :::わお、Souten さん、お越しいただきありがとうございます！ ちょっと色々と企みすぎて大変ですが、段階的に作ることで早めのリリースを目指します。頑張ります！ ::Re:ARMlet 内での大域 - 陰郎 (2006年06月29日 00時06分23秒) :::えぇと．．．Palm Hacker's Salon の「PalmOS 5 Hack開発講座 第7回」を読んでいました．．．それによれば、「 [r10]レジスタをいじってあげるとARMletコード中でグローバル変数の取り扱いができるように 」なるのだそうです。ということは、イジらなければ無理ということ．．．かな。すなわち、仮想関数や例外処理も無理、ということかな．．．（涙 ::Re: - 陰郎 (2006年07月20日 12時27分19秒) :::えとですね、しばらく ARMlet のことは忘れることにしました。おそらくは９割方はプレインテキストの検索・置換が使われるわけですから、まずは動くものを作ろうということで。こっちもぼちぼち動くことにしますね。 ::Re: - 陰郎 (2006年08月04日 23時19分52秒) :::ちょっとずつ、こちらも進めていきます。仕様案の部分を少しイジりました。早めに動くものを作りたいのですが．．． ::ワイルドカードって - 陰郎 (2006年08月07日 23時37分39秒) :::仕様面で情けない質問です。ワイルドカードって言ったら、ひとまず * と ? がサポートしてあればいいですかね？　「 ワイルドカード 」っていう表現だけで萎えちゃう方もいるであろうことは分かった上での質問です。UNIX な方ならグロブの方がお好みでしょうし。Mac な文化ではなんと言うのかな？　ま、何にせよ、ひとまず * と ? のサポートしか考えてませんが、いかがでしょう？　あ、もちろんマルチバイト文字は意識しますよ。 ::Re:ワイルドカード - alg (2006年08月08日 09時13分09秒) :::私個人としては、*と?で充分じゃないかと思います。 一般的には何ていうんだろう…？ マルチバイト文字を意識するってことは、?でシングルバイト文字もマルチバイト文字もヒットするってことですよね。 …と、ここまで書いて気づいたのですが、*は量指定子にはしないってことですかね？ ::Re:ワイルドカード - 陰郎 (2006年08月08日 10時48分59秒) :::陰郎の意識としては、? と * を正規表現で言えばそれぞれ . （ドット）および .* に該当すると考えています。* が .* であって .+ でないことに注意。また、標準的な正規表現では . が改行コードとマッチしないことにもご注目。すなわち、陰郎の考えているワイルドカード検索では、* は０文字以上の連続で、かつ改行コードを跨ぎません．．．と、alg さんの疑問には答えられているかな？ ::Re:ワイルドカード - alg (2006年08月09日 23時01分15秒) :::なるほどなるほど。ちゃんと答えになってますよー。ありがとうございます。 ::Re:ワイルドカード - 陰郎 (2006年08月10日 12時30分39秒) :::えぇと、愛用のエディタで試してみたところ、* はやはり改行を跨ぎませんでした。一応予想＆期待どおりでほっとしてます。ちなみに、ワイルドカード検索は最短マッチであるべきでしょうか？　それとも最長マッチであるべきでしょうか？　どういう意味かというと、たとえば ababababababab という文字列に対して a*b というワイルドカード検索をかけたとします。最長マッチならばいきなり ababababababab という文字列全体が検索結果としてマッチします。最短マッチならばまず ab がマッチし、次を検索すると abab 、次が ababab ．．．という感じに長くなっていきます。インクリメンタルな検索・置換をサポートするとこのような心配事が出てきてしまうわけですが、一括置換まで視野に入れて考えようとすると結構厄介そうで．．． ::画面デザイン - 陰郎 (2006年08月10日 12時52分26秒) :::画面デザインについて相談です。おそらく、８割方の使用はプレインテキスト検索だと思うんですよ。で残りの２割くらいがワイルドカード検索。正規表現検索は（ その機能があったとしても ）まぁ誤差の範囲かな、と。人によってその比率は違うだろうとは思いますが．．．で、あまりに色々なオプション設定が画面にひしめき合ってると使いにくいじゃないですか。なので、検索条件を指定する画面を簡易画面と詳細画面に分けようかな、と。そうすれば、大半の使用ではシンプルで分かりやすいユーザーインタフェイスにできます。しかし、検索と置換でさらに分けると４画面になってしまうんですけどね。いかがでしょう？ ::Re:画面デザイン - 鶴丸 (2006年08月10日 23時17分35秒) :::o(^^)o　詳細検索画面に、置換しょりの項目もあれば良いかと思いますが・・・ ::Re:画面デザイン - 陰郎 (2006年08月11日 00時25分46秒) :::置換のための入力フィールドは、簡易画面にもあった方がいいでしょう。そうでないと、単純に Plam を Palm に置換したいだけの時でも山ほど設定項目が目に入ってくることになります。なので、検索・置換 ｘ 簡易・詳細で４画面．．．とは言っても、実際には入力フィールドやらボタンやらチェックボックスを非表示にしたり位置を移動することで対応できるでしょうから、２画面、ひょっとすると１画面でイケるかもしれません．．．さらに言うならば、検索方法（プレインテキスト・ワイルドカード・正規表現）によって表示される設定項目も変わるかもしれませんね。あー風呂敷広げすぎかしら。（汗 ::Re: - たいち@管理人 (2006年08月11日 10時30分40秒) :::えっと、既にご存じかもしれませんが、参考になればと・・・ FindHack 4.0.7 > http://www.palmgear.com/index.cfm?fuseaction=software.showsoftware&PartnerREF=&siteid=1&prodID=780 置き換えは出来ませんが、私は検索にはこれを使ってます。検索機能だけで見ると最強かと・・・ ::Re:FindHack - 陰郎 (2006年08月11日 11時56分13秒) :::おー、これはスゴい。グローバルな検索からアクティブフィールド限定の検索までサポートするんですね．．．ちなみに、これは DA でなく Hack なんですね。ひとまず思ったポイントは、日本語文字コードは正しく扱えるか？　ということ。あとはシェアウェアであることですね。フリーウェアで日本語文字コードを正しく扱えるモノが作れれば、アドバンテージはありますかね．．．？ ::Re: - たいち@管理人 (2006年08月11日 12時28分51秒) :::私が使っている上では、日本語大丈夫です。DA となると例えば、立ち上げているアプリ内（開いているメモ内）など、特定の領域での検索が可能でしょうし、その置き換えも可能となれば、私は欲しい事極まりないです。正直欲しいです。FindHackに関しては、全てのアプリ内での検索ですので、コンセプトは自体が違いますので、需要豊富だと思います。日本だけでなく、海外の人の方がもっと欲しがるでしょうね(^^;;; ::Re:FindHack - たいち@管理人 (2006年08月11日 12時30分19秒) :::期間限定の試用が可能ですので、使ってみられてはいかがでしょう？ ::Re:FindHack - 陰郎 (2006年08月11日 12時50分50秒) :::日本語大丈夫なんですか？　陰郎が言っている「日本語大丈夫」という意味は、たとえば半角の A でグローバル検索をかけても、「陰」という字だけがあるメモが検索結果に含まれない、ということを意味します（「陰」という字の後続バイトは半角の A と同じなのです）。つまり、ひとまず日本語の検索ができます、という意味ではなく、マルチバイト文字を正しく処理できるかどうか、という意味なんですね。英語版 Palm の標準検索機能でも、A という文字だけで検索をかけると、日本語文字を含むデータが大量にひっかかります。非常に開発寄りの発想なのは承知の上ですが、日本語が 『正しく』処理できるといえるにはそういう点もクリアしている必要があると思っています。 ::Re: - たいち@管理人 (2006年08月11日 12時54分11秒) :::あー良く理解出来ませんが（汗）Aで検索すると日本語の検索結果も出てきますので、多分「正しく」処理出来ていないと言えるでしょうか？（滝汗） ::Re: - 陰郎 (2006年08月11日 13時27分55秒) :::残念ながら、「厳密には」正しく処理できていない、ということになってしまいます。通常、半角１文字だけを指定して検索するというのはまずやらないので、事実上影響はないのですけどね。（笑 ::Re: - 陰郎 (2006年08月17日 12時45分54秒) :::えぇと、ご無沙汰してます。開発を続行できる状況になりつつありますので、ぼちぼち活動を再開します．．．早めに動くものを作りますね。叩き台という位置づけで。 ::プレインテキスト検索 - 陰郎 (2006年08月18日 12時23分47秒) :::　検索処理の実際について。すべての検索モードで日本語文字を正しく処理できるようにする予定ですが、Shift-JIS コード前提になります。で、大文字小文字を同一視した検索もサポートする必要があるので、結局はプレインテキスト検索でも API を使わずに自前で書く必要があるのかな、と。BMH法を予定していますが、検索ループ内部の対象文字列マッチには文字列比較APIを使う予定ですが、この点について仕様上の疑問があります。いわゆる全角のアルファベットまで大文字小文字を同一視する必要があるでしょうか？　そうなると結構面倒なんですけど．．．ね。（汗 ::Re:プレインテキスト検索 - 陰郎 (2006年08月20日 23時50分16秒) :::プレインテキスト検索の時点で軽くハマり中です。マルチバイト文字列同士の文字列検索で、BMH法って正しく動作させられるのでしょうか．．．　現在位置でマッチ失敗した後、その次の１文字がリードバイトかトレールバイトか分からなければその先どうしようもない気がしてます。イチイチ調べるくらいなら単純法の方がマシですし、実際マルチバイト文字環境に対応している strstr() の実装は、目にした事のあるものは全て単純法を使用していました．．．　あ、独り言だと思って読み流してください。 ::Re:ワイルドカード - 陰郎 (2006年08月22日 12時42分39秒) :::以前、ワイルドカードにおける * は正規表現で言うところの .* であって .+ ではないと書きました。つまり、改行以外の０文字以上の連続と言うことになるのですが、そうすると検索文字列として * だけを指定した場合、０文字マッチが成立してしまいます。インクリメンタルな検索をサポートする場合、これは非常に都合が悪いような気がするのですが、いかがなものでしょうか。そもそも、０幅マッチを上手く画面上でユーザーに提示する方法がないような気がします．．． ::Re:ワイルドカード - 陰郎 (2006年08月22日 13時04分58秒) :::いささか苦しいですが、そもそもマッチは１文字以上であるというのを大前提にすることで上記の問題はクリアできると考えることにしました。で、次なる問題として、同一開始位置からの複数マッチを許すか、という問題があります。これは、2006/08/10 に書いた「最短マッチか最長マッチか」という問題に関係します。最長マッチであれば常に同一開始位置からのマッチは最大１つですが、最短マッチの場合、順に長いマッチ幅を選択するようにもできますし、より長いマッチは無視するような仕様にもできるでしょう。つまり、このコメントに対して“最*マッチか”というワイルドカード検索をした場合に、結果が「最短マッチか」だけなのか、続いて「最短マッチか最長マッチか」という結果が得られるのか、の違いです。 ::Re:ワイルドカード - 陰郎 (2006年08月22日 23時21分00秒) :::愛用のエディタで色々試していますが、どうやら同一開始位置からのマッチは１つで、かつ最短マッチとされているようです。おそらく、改行を含む長いテキストを検索する際にもっとも自然かつ無難だからなのでしょう。ひとまず、異論のない限りはこの仕様で行こうと思います。どの仕様かというと、「最短マッチで、同一開始位置からのマッチは最大１つ。かつ ? および * は改行とマッチしない。」です。ご意見ありましたら宜しく。 ::画面構成 - 陰郎 (2006年08月24日 00時37分39秒) :::なんとなく、検索ロジックがでっちあがりつつあるので、画面構成を真剣に考えようかと。で、ハリボテを作りつつ考えました。プレインテキスト検索とワイルドカード検索だけなら、オプションは case sense と over wrap しかないな、と。正規表現は当面先送りなので、無理無理広げてきた小さな風呂敷をここらで少し畳もうかと思います。まずはシンプルな画面構成で。頑張ります。 ::タブや改行のメタ文字 - 陰郎 (2006年08月24日 12時29分26秒) :::多くのエディタでは、検索モードを問わず \t や \n といった記述によってタブ文字や改行を指定することができます。これって必要でしょうか（ 個人的には必要と考えています ）。また、Palm では特にそうですがスペースを指定する場合は分かりにくくなるので \s で半角スペースを指定できるとか。ひとまずその３つを考えていますが、いかがでしょうか。 ::Re:タブや改行のメタ文字 - alg (2006年08月24日 13時12分55秒) :::\tと\nは是非ほしいところです。 （というか私が使う正規表現の大半はこの二つかも） \sは普段使わないのでなんともいえませんが、あると便利かもしれませんね。 Palmの画面で半角スペースって、意外と見づらいですし。 話はずれますが、等幅フォントのPalm用エディタがあるといいんですけどね。 もしくはPalmOS標準機能として、プロポーショナルと等幅を切り替えられる、とか。 ::Re:タブや改行のメタ文字 - 陰郎 (2006年08月24日 23時16分27秒) :::ひとまず、\n、\t、\s はそれぞれ改行、タブ文字、スペースとマッチするようにし、\ にそれ以外の文字が後続した場合は \ は無視されるものとします。文字としての \ を指定したい場合は \\ と記述する．．．と。これは一般的なエスケープ指定の慣習通りなので特に問題ないでしょう。この記法はプレインテキスト検索、ワイルドカード検索の両方で有効となります。余談ですが、正規表現の場合、\s は文字クラス略記となり、「 空白類文字 」として扱われます。つまり、\s は大まかに言って ［\t\n ］と同義です。 ::検索モードごとの動作 - 陰郎 (2006年08月29日 12時55分22秒) :::現在、ハリボテをなんとか動かそうとしております。で、ここらで各種検索モードの動作をまとめておきたいな、と。ノーマル（プレインテキスト）検索はマッチ幅が（当然）固定なので、ある位置からのマッチは１つに限られます。ワイルドカード検索に関しては、* の動作を最短一致に限定することで、特定位置からのマッチを１つに固定します（ココが一番議論になりそうなトコですが）。で、まだ絵空事ですが正規表現検索については量指定子のパワーを最大限引き出すため、特定位置からのマッチが複数成立するようにするつもりです。 ::画面イメージ - 陰郎 (2006年08月30日 00時57分24秒) :::何とか動かそうとしているハリボテですが、ひとまず画面イメージを乗せてみました。このページの真ん中あたりです．．．こういう感じで使えるといいのですが。 ::Re:画面イメージ - alg (2006年08月30日 13時38分13秒) :::画面のハリボテができるだけでも、ちょっと完成に近づいた気がしてやる気が出てきますよね。…私だけ？　プッシュボタンで動作を選択するというのは、わかりやすくてよいと思います。あとは、各種オプション（一括置換と順次置換どっち？とか）を設定する画面を開くボタンが要るのかな、と。 ::Re:画面イメージ - 陰郎 (2006年08月30日 18時20分32秒) :::一括置換と順次置換の選択についてなのですが、現時点では、「 最初は自動的に順次置換で、置換確認の画面上で ReplaceAll ボタンをタップすることで以降を一括置換 」という動きにしようかと思っています。理由は、Palm のデータに関する考え方として「上書き保存」や「保存しないで終了」という考え方がなく、変更は即座に保存されることです。無制限 Undo も難しいため、一括置換は Palm ではリスキーな行為と言えるでしょう。そのため、可能ならば一括置換はあまりお勧めしたくないんですね。だからせめてワンクッション置きたいな、と。ちなみに、他に陰郎が失念してそうな設定はありますでしょか？　最近脳が疲れているみたいで、度忘れが激しいんですよ。（汗 ::ドラッガブルでサイズ可変 - 陰郎 (2006年08月31日 12時32分18秒) :::先日このページの真ん中あたりに載せた画面イメージにあるとおり、検索モードや検索／置換の設定によってウィンドウのサイズが変化するようになっています。しかし、何も考えずにこれをドラッガブルフォームにしてしまうとチト厄介な気がしてきました。ウィンドウサイズが変化する際に、画面のどこにいるかによってはサイズと共に位置をズラさないと画面からはみ出してしまうでしょう。それを制御するのはそれほど大変ではないのですが、問題は使っているときに違和感を感じないかどうか。変化するのは縦方向のサイズだけで、伸びるときは基本的に下方向です。ただし、下方向に伸ばした結果画面からはみ出す場合に限り上方向に伸ばす．．．というだけなのですけどね。問題ないでしょうか．．． ::動くハリボテ - 陰郎 (2006年09月03日 19時02分25秒) :::検索・置換の実処理はまだ未実装ですが、ひとまず動くハリボテをアップしました。ページ中程の試作品ダウンロードコーナーからどうぞ。 ::Re:動くハリボテ - alg (2006年09月04日 13時47分00秒) :::試してみました。着々と進んでますね。上下方向のサイズ変更の挙動は、特に違和感ありません。こういう動作はよくあると思います。 ::Re:動くハリボテ - 陰郎 (2006年09月04日 22時35分32秒) :::alg さん、ありがとうございます。しかし、陰郎的にはほんの少し違和感があったので、少しイジったものをアップしました。どのようにイジったかというと、画面が伸び縮みする際、可能な限り背景が広く見えている領域を侵さないように動きます。実際問題として上下方向にしか伸び縮みはしないので話は簡単です。伸びる場合、狭い方に伸びるだけの余裕があればそちらに伸び、狭い方が狭すぎる場合は広い方に伸びます。縮む場合は常に広い側を縮ませます。分かりにくいかもしれませんが、やってみればわかると思います。こういう微妙なところの使い勝手は大事だと思うので。一度お試しください。 ::履歴の表示と選択 - 陰郎 (2006年09月06日 00時07分19秒) :::履歴の表示と選択の機能についてご意見を賜りたく。履歴の保存方法なのですが、検索文字列と置換文字列はそれぞれ別の履歴として保存するべきでしょうか？　それともまとめて保存すべきでしょうか？　前者のメリットとしては、何よりもわかりやすいことが挙げられます。一方、後者のメリットとしては、たとえば過去に置換に使用した文字列を検索に使用することができます。陰郎個人としてはどちらかといえば後者に傾いています。しかし、ワイルドカード検索や正規表現検索では、このことはほとんど意味を成しません。なぜなら、検索文字列を置換文字列（またはその逆）として使用することはまずないからです。また、検索モードを跨いで履歴を共有することにも意味はないでしょう。さて、皆さんはどのようにお考えになりますでしょか。 ::Re:履歴の表示と選択 - alg (2006年09月06日 00時55分05秒) :::別々がわかりやすくていいんじゃないでしょうか。過去に置換に使用した文字列を検索に利用する場合は、コピペすれば済みますし、というのが個人的な意見です。あ、コピペはできますよね？ ::Re:履歴の表示と選択 - 陰郎 (2006年09月06日 12時34分32秒) :::うーん確かに。そうなると、３つの検索モードで履歴を共有することはありませんし、検索と置換でも履歴を共有することはなくなりますね。もちろんコピー＆ペーストはできるようにします。残る問題は、画面上のコントロールとして何を選択するかでしょう。パソコン上で動作するOSのほとんどでは、Windows でいうところのドロップダウンコンボボックスが存在します。これはテキストボックスとドロップダウンリストボックスを一緒にしたようなもので、履歴はドロップダウンリストから、新規入力なら直接．．．といった使い方ができます。残念ながら、Palm にはこれに該当するコントロールがないんですよね。なので現時点では入力フィールドと履歴表示のためのボタンを別モノとして表示しています。 ::Re:履歴の表示と選択 - 陰郎 (2006年09月07日 12時49分22秒) :::履歴表示＆選択機能を実装中です．．．最初は ListMakeDA のように別画面でやるつもりだったのですが、デザイン的にイマイチだったため、メインの画面内でやることにしました。通常非表示のリストボックスを用意しておき、履歴ボタンをタップすると対応する入力フィールドに重ねるようにリストを表示します。まだ実装途中なので試作品のアップはまだですが、思っていたより簡単にできそうな気がしてきました。これが終わると、いよいよ検索・置換の実ロジックに作業が移ります．．． ::Re:履歴の表示と選択 - 陰郎 (2006年09月17日 18時51分37秒) :::えーと、ご無沙汰ですみません。仕事でドタバタしてました。なんとか復帰します。今回は履歴の保存方法についてご相談、です。現在、３つの検索モードごとに検索・置換それぞれで１０個の履歴を保存しようとしています。入力フィールドは検索・置換ともに64バイト。すると、それだけで 3 x 2 x 10 x 64 = 3,840 バイト。つまりそれだけで4KB近い情報が Preference として保存されるわけです。なんかちと無駄な気がしてきまして。人によってはまったく使わないモードもあるわけですから、思い切って履歴の共有という選択肢も検討してみようかと考えました。履歴を共有する場合、検索履歴ではそれぞれの履歴に検索モード情報をつけることで、その履歴を選択した場合に自動的に検索モードが変更される、というのを考えています。モード間で履歴を共有するかわりに履歴を15個まで保存したとしても、2 x 15 x 64 = 1,920 バイト。さっきの半分になります。もちろん、検索モードのマークのためにもう少し膨らみますが．．．いかがなものでしょうか。 ::Re:履歴の表示と選択 - 陰郎 (2006年09月18日 00時41分19秒) :::上記の（空間的な理由からの）履歴共有案での実装をアップしてみました。相変わらず検索・置換の実ロジックは未実装です。現状では、OKボタンをタップした場合のみ、履歴が記録されます。検索・置換ともに履歴は１５個まで。検索の履歴には、それぞれに検索の種類を示す "N - " や "W - " 、"R - " といったマークがつきます。履歴から検索文字列を選択すると、自動的にその履歴の検索モードに変更されます．．．と、ひとまずこんな感じでしょうか。仕様（案）が二転三転して申し訳ありませんです。ご意見いただけたら幸いです。 ::Re:履歴の表示と選択 - alg (2006年09月18日 21時09分35秒) :::なるほど、面白い方法ですね。こういう履歴の共有はいいんじゃないでしょうか。データ容量を減らすためにも、履歴共有のほうが良さそうですね。 ::Re:履歴の表示と選択 - 陰郎 (2006年09月21日 00時03分45秒) :::コメントありがとうございます。ひとまず履歴の保存はこの方式で行こうと思います。 ::検索中画面での Back ボタン - 陰郎 (2006年09月21日 00時05分02秒) :::今度は検索実行中の画面についてご相談させてください。現時点では、条件を指定して検索（または置換）を開始すると、別の小さな画面が表示されるような感じで実装を進めています。検索ならば［Next］ボタンをタップすれば順に検索結果が表示されるイメージです。［×］ボタンでDAの実行を終了するのですが、ここで［Back］ボタンはあったほうがよいでしょうか？　［Back］ボタンがあれば、たとえば検索条件を間違えたときなどにDAを終了しないでも再実行できます。可能な限り画面は小さくしておきたいので、無ければないでもいいのかな、というところなのですが．．．ご意見いただけたら幸いです。 ::Re:検索中画面での Back ボタン - 陰郎 (2006年09月22日 00時08分37秒) :::［Back］ボタンを実装してみたのですが、［Next］ボタンと並べると、上方向への検索機能に見えてしまうことに気付きました。現状、上方向への検索機能は予定していません。理由は、ノーマル（プレインテキスト）検索以外の検索モードで実装する自信が無いからです（ワイルドカード検索はまだいいのですが、正規表現となると自然な挙動というのが想像つきません）。［Back］ボタンは追加する気満々だったのですが、悩み中に逆戻りです。ご意見・ご指摘ありましたら宜しくお願いします。 ::Re: - EIJ (2006年09月22日 00時33分47秒) :::本来Nextに対応するものはPreviousなのでBackでも違和感を感じませんが、より誤解の少ない物がよいならCancelはどうでしょうか？単語が長くなるのが気になるのであれば日本語にして"条件"とするかグラフィカルボタンにするとか ::Re:検索中画面での Back ボタン - 陰郎 (2006年09月22日 23時48分25秒) :::あ、たしかに逆方向検索なら［Prev］の方が適切ですね。ならば［Back］ボタンでもいいかな．．．あ、ちなみに日本語バージョンは別で作成しようかな、と考えています。日本語バージョンでは［戻る］ボタンにすればいいかな、と考え中です。 ::Replace All ボタンの是非 - 陰郎 (2006年09月25日 23時02分43秒) :::今度は置換モードの話題ですが、Replace All ボタンというのはあるべきでしょうか。何を心配しているかというと、アプリのロジックでフィールド上の文字列をイジった場合、Undo が効かないわけです。マニュアルで注意したところで、常にがっかりする人の先回りができるとは限りません。潜在的な災厄の元になる可能性を考えた場合、１つ１つ確認しながら置換した方がいいのでは．．．というわけです。アプリレベルで Undo をサポートするのもちょっと考えましたが、ひとまず脇に置いておくつもりです。さて、いかがでしょうか。 ::Re:Replace All - alg (2006年09月28日 22時31分47秒) :::Replace Allボタンは、あったほうが便利だとは思います。しかしうっかりやらかしてしまったときのUndoがないと、厳しいですねぇ。もしUndoなしでReplace Allボタンを実装するなら、Replace Allボタンを押したらAlertで「戻せないけど、ホントによろし？」としつこく確認してからにするとか。あるいは、置換対象のファイルを(裏で)まるごと複製しておいて、Replace All直前の状態には戻せるようにしておくとか？うーん…。 ::Re:Replace All - 陰郎 (2006年09月29日 01時03分08秒) :::あぁ、バックグラウンドでフィールドの内容を丸ごとバックアップしておくのはいいかもしれませんね。しかし、その方法で Undo するのであれば、ＤＡを終了するわけにはいきませんから、置換した数だけ提示して確定か取り消しかを確認することになりますね。この路線で検討してみます。ありがとうございます。 ::ひとまず検索機能の実装 - 陰郎 (2006年10月04日 00時38分05秒) :::ご無沙汰してスミマセン。ひとまず、ノーマル検索・ワイルドカード検索機能のみを実装したものをアップしてみました。置換はまだ手付かずです。正規表現もまだ当然ゼロです。オーバーラップ検索はできてるはずです。\t \n \s をそれぞれタブ文字、改行、半角スペースとして扱うのもできてると思います．．．が、思い切りドラフトなので使用には気をつけてください。コケてもデータを破壊したりはしないとは思いますが。 ::Re:ひとまず検索機能の実装 - 陰郎 (2006年10月04日 01時16分51秒) :::早速ですが、Case sense オプションが正しく動作してないっぽいです。明日（というか２４時間くらい後）に確認・修正します。 ::Re:Re:ひとまず検索機能の実装 - 鶴丸 (2006年10月04日 11時40分24秒) :::あっ！でましばし待ちと言う事で(^^ゞ ::Re:ひとまず検索機能の実装 - 陰郎 (2006年10月04日 23時28分07秒) :::Case sense オプションの実装を修正したものをアップしました。また、検索モードを正規表現にした場合にアラートが無限ループしてしまう事象を修正しました。ところで、Case sense オプションの実装は内部で StrNCompare API と StrNCaselessCompare API を使い分けることで実現していますが、StrNCompare でも Case insensitive な比較をしてしまっていました。このような事象を確認したのは Tungsten T5 と Treo650 です。Palm OS Simulator では正しく動作していました。今回は、MemCmp API でも代用できるため、そちらに切り替えることでひとまずの対処としています．．．StrNCompare API の挙動について何かご存知の方、情報いただけると幸いです。 ::続いて置換機能の実装 - 陰郎 (2006年10月08日 15時11分58秒) :::置換機能を実装したモノをアップしてみました。ひとまず、Replace All で Undo を提供するという話は棚上げ状態です。また、編集メニューを追加しましたので、/x や /c 、/p でカット・コピー・貼り付けができます。ちなみに、古いバージョンが入っている状態で新しいものをインストールすると、起動時にリセットする場合があるようです。このような場合は、一度削除してから再度インストールして見てください。 ::起動時選択文字列について - 陰郎 (2006年10月09日 00時56分25秒) :::多くのエディタでは、検索機能の実行時に選択している文字列を自動的に検索文字列に指定します。これをやるのは有用ではなかろうかと。現在、検索文字列に指定できるのは６４バイトまでなので、DA 起動時にアクティブなフィールドで６４バイト以下の文字列が選択されていれば自動的にその文字列を検索文字列として指定するようにしようかと考えています。ちなみに、「選択範囲内のみ一括置換」という機能を実装しようと考えていた時期もありましたが、ひとまずそれはやめにしておこうと思っています。 ::Re:起動時選択文字列について - 陰郎 (2006年10月09日 15時43分01秒) :::昨夜書いた内容で実装してみました。アップ済みです。DA起動時に文字列選択状態だと、自動的にそれを検索文字列として指定します。ただし64バイト以下の場合のみです。また、そのような状態で検索を実行すると、選択中の文字列が検索にかからない微妙なバグが確認されています。これは、カーソル位置が選択文字列の末尾にある場合だけ発生します（カーソル位置以降しか検索しないので）。ここは早めに修正しようと思っています。 ::Re:起動時選択文字列について - 陰郎 (2006年10月10日 22時42分11秒) :::前回のコメントで報告したバグを修正した版をアップしました。文字列選択状態でDAを起動した場合、カーソル位置に関わらず選択文字列の最左位置から検索を開始するようにしました。 ::ドキュメント書き始めます - 陰郎 (2006年10月12日 22時06分11秒) :::まだ細部を詰める必要はあると思っていますが、正規表現機能以外は一通り揃ったと考えています。そこで、そろそろドキュメントを書き始めようかと。毎度イマイチなモノしか書けないとは思いますが、なんとか作りますんで。引き続き、使用感、改善要望、その他ご意見歓迎ですので宜しくお願いします。 ::ARMlet 実装について - 陰郎 (2006年10月15日 23時29分14秒) :::ご無沙汰してます。以前書いたかどうか忘れましたが、現在アップしてある実装は ARM コードを使用していません（プレインテキスト検索やワイルドカード検索は68Kコードのままでもいいかなとは思っていますが）。しかし、将来的には正規表現検索機能も入れたいし、検索ロジックは全部 ARM コードで統一したいと。そんなわけでこの週末はお試し実装を繰り返しつつ連敗を喫しておりました。なんとか目処はつきましたので、学んだことを開発情報に書きつつ、進めて行きたいと思っています。 ::日本語表示版 - 陰郎 (2006年10月22日 00時20分58秒) :::画面上の表示文字列を日本語にしたバージョンをアップしました。相違点は画面上の文字列表示だけで、以前からアップしているバージョンでも日本語文字列（Shift-JIS前提ですが）は正しく処理できています。ついでに画面イメージの一部を日本語リソース版に変えてみました。 ::Re:ARMlet 実装について - 陰郎 (2006年10月22日 23時32分16秒) :::ARMlet での検索処理の実装ができましたので、ダウンロード対象の試作品をアップしました。Palm OS Simulator では DLL 実装の提供となりますので、ReplacedDADLL.dll を Palm OS Simulator のインストール先にコピーする必要があります．．．実際問題として、高々数キロバイトの文字列検索では ARMlet でも 68K エミュレーションでも処理速度に違いは無いのですが、ひとまず将来への布石ということで。 ::Re: - Souten (2006年10月24日 04時52分07秒) :::忙しくて進捗状況を拝見出来ずにいたのですが…久しぶりに来てビックリ！試作品ができているではありませんか！！！ 試作品でもメチャクチャ嬉しい！ 早速ダウンロードさせて頂きました。 でも今日はチト酔っているので明日の朝の楽しみにとっておきます。 本当に嬉しい！感謝！感謝！！感謝っす！！！ ::Re: - 陰郎 (2006年10月25日 00時02分21秒) :::あーSoutenさん、来場感謝です♪　試作品とはいっても事実上の初期リリース候補です。深刻なバグさえなければ、最初のリリースになると思いますよ。あとはドキュメントを書きますんで．．．それが一番苦手だったりしますが。（汗 ::ワイルドカード検索における * や ? のエスケープは必要？ - 陰郎 (2006年10月28日 23時30分51秒) :::．．．でしょうか。よくよく考えたら実装してません。そのため、ワイルドカード検索機能で「文字としての * や ? 」は使えないことになってしまいます。エスケープできるようにした方がいいでしょうか。それともこのままでもいいでしょうか。やった方がいいかなー．．．とは感じてますが、同意が無いようならそのままにするかもしれません。ご意見がありましたらどうぞ宜しく。 ::Re:* や ? のエスケープ - alg (2006年10月29日 21時39分26秒) :::あるに越したことはないけど、優先度は低い。そんな感じですね。*や?自体を検索したいときは、それ自身1文字なら通常検索で検索できますし。「*と何か一文字」みたいなのは検索できませんけど、まぁそれほど重要ではないかな、と。なので、ゆっくり気長にそのうち実装してください、というのが私の意見です。 ::Re:* や ? のエスケープ - 陰郎 (2006年10月31日 23時55分33秒) :::反応遅くなってスミマセン。ひとまずはそのままにしますけども、対応するかどうか少々悩み中です。正規表現と比較すると、ワイルドカードを使う人の中には \ 記号でエスケープする、ということを知らない人も多いと思うので、\\* のつもりで \* と書く可能性もありますよね。ドキュメントで説明しても皆が読むとは限りませんし．．．嗚呼。 ::ARM 検索のバグおよび現状報告 - 陰郎 (2006年11月01日 00時00分43秒) :::ARMlet での検索機能にちょっとしたバグが見つかりました。修正は済んでいますが、正式（といっても Version 0.70 ）リリースまでは寝かせておこうと思っています。さっさとドキュメント書いてリリースしたいのですが、苦手な作業なので進んでません。ごめんなさい。ちなみに、やるつもりでやってないことがいくつかありますが、それは改めて整理させてください。 ::version 0.70 - 陰郎 (2006年11月05日 04時00分00秒) :::Version 0.70 ということでひとまずリリースしました。これにともない、試作品のダウンロードは終了としました。 ::version 0.71 - 陰郎 (2006年11月06日 19時57分28秒) :::CLIE NX だと Palm OS 5 であるにも関わらずサポート外バージョンと判定されるバグが報告されました。「【C/C++】 Palm OS のバージョンをチェックする方法」のページでほしさんにコメントいただいた内容にずばり当てはまるバグです。修正版をアップしましたが、手元に CLIE NX シリーズがありません。どなたか NX シリーズをお持ちの方がいましたら動作確認いただけると幸いです。 ::Re: - shino-ji (2006年11月06日 22時56分54秒) :::ClieNX80Vでの動作確認です。 version0.70で表示されていたサポート外バージョンのダイアログはversion0.71では表示されなくなり、正常に動作しております。詳細についての確認はしておりませんが、選択フィールド内の検索については問題なく動作しております。 とりあえず、問題のバグについては解消しているものと思われます。 ::Re: - 陰郎 (2006年11月06日 23時40分15秒) :::shino-ji さん、ご確認ありがとうございます。ひとまず安心しました。 ::Re: - Ｑt (2006年11月07日 00時42分00秒) :::CLIE NX80Vで動作しないと報告をしていた者です。 動作するようになりました。 *どもども。Treo700pでも、一通り動作してます。 - 木彫り熊 (2006年11月08日 00時38分38秒) *コメントスパムが来ますので、コメント欄をコメントアウトしました。コメントを追加したい方は、コメント欄の復活させるか、または直接編集してください。- 陰郎 (2007年02月07日 00時59分00秒) //{{comment multi}}