FGALDC 14
/RE:6319 RE:PAD作成マクロではありませんが

　こんにちは、Ｈi.Ｆi.さん

》　的外しかもしれませんが、マクロにこだわる理由はあるのでしょうか？　と言う

いえ、全然外れておりません。
目的が達成できればそれでいい、と言う考えはそれなりにあったりします。

》のは、padmesと言うソフトで希望機能をある程度カバー出来るからです。

私は今まで、NIFTY のメールや会議室へのレスの文書を作るときには、NIFP を
使ってきました。

私は NIFTY への接続は、母艦である PC-9801DA (*1)を使って行っておりました。
そして、得られた生ログをオアシスポケット３に転送して、通勤の際に電車の中
で読んでおります。分割ログにしてしまうと、ファイルの数が増えてしまうので
転送の手間が大変です。
(*1)最近、PC-9821As に更改（苦笑）

でもって、横着なので通常は母艦でもログの保存は生ログで行っております。
会議室の改廃など、なんかの機会があると、会議室毎の分割ログを作ります。
現在は、FGALTM の分割ログを作り終わったところです。
かつて作ったものでは、FGALWT とか FGALST とか FGALIAN とか。

ポケ３でログを閲覧するときは、MIEL を使っています。
Vz や NIFP だと、消費電力が大きいので、ただ閲覧するだけのときには使わない
ようにしています。多分、キー入力か何かの割り込みルーチンの関係だとは思わ
れます。たとえば、MIEL でもキーを連打していると消費電力が増えます。
ただ、レスやメールなどで PAD ﾌｧｲﾙを作るときには、９８でもポケ３でも、NIFP
から Vz を起動させています。

PAD を作る頻度が最も高いのは、母艦でログを閲覧している最中です。
ポケ３では、平均的な１日分のログのサイズ（約 200KB）だと毎日の通勤時
間（往復３．５時間、乗り換え含む）ではおおむね閲覧だけで終わってしまうこ
とが多いです。
ただ、打ち合わせなどで勤務時間中に他のロケーションへ移動することがあると
きは、やはり電車の中などでポケ３をいじるようなこともありますが、あまり頻
度は高くありません。あとは、会議中に内職していることもありますが。

NIFP は、ツリー表示ができるのは便利です。しかし、基本的に単一の生ログを閲
覧することだけを考えて作られているものです。そのため、複数のログを読み込
むことは隠し機能で可能ですが、それぞれの生ログに同一の会議室があっても、
それを一つのツリーにまとめて表示してくれることはないようです。
また、ポケ３では、巨大なログファイルになるとツリーを表示するまでの時間が
現実的ではないという問題もあります。

そこで、複数の生ログから、会議室毎の発言ツリーを抽出するという AWK のスク
リプトをでっち上げてしまいました。ただ単に、発言ヘッダのタグ情報を会議室
毎のファイルに抽出するスクリプトと、それぞれのタグファイルをツリー状にな
らべるというスクリプトの２段構成になっているので、あまり美しいとはいえま
せんが、やろうと思えば過去５年分の生ログを全部処理させるという大技も可能
なはずです。まぁ、発言数が多ければメモリが不足するでしょうけど。
出来上がったツリーファイルの上でタグジャンプさせれば、Vz でツリーを追いか
けながら複数の生ログを行ったりきたりすることが可能です。

ところで、NIFP にはいろいろと高度な機能があるのですが、現実に私が使ってい
るのは、ツリー表示機能と PAD ﾌｧｲﾙ作成機能だけです。
ここで、ツリー表示機能が別手段で実現してしまうと、残る PAD ﾌｧｲﾙ作成機能も
何らかの手段で代替できれば、NIFP と完全に手を切ることが可能となります。こ
れが実現すれば、外部記憶容量が現在トータルで 6MB しかないポケ３では、DIET
で圧縮しても 100KB あるファイルを削除できるということになり、非常に大きな
メリットをもたらします。

そこで、Vz のマクロで PAD を作成することを考えました。


ということで、長文になってしまいましたが、なにとぞよしなに。

                                                           としき