http://www.namazu.org/~kose/nnir-1.68.el.patch.bz2
に置きました。
Group buffer から G G で検索。
# でマークしてあればそのグループだけを検索。
です。
もう少し詳しくは
http://www.NetLaputa.ne.jp/~kose/Emacs/#Gnus-nnir
をどうぞ。
P.S.
Gnus から Namazu を使った検索を行う elisp って一般的には何が
使われているのでしょう?
P.P.S.
http://www.namazu.org/~kose/
の下に Namazu 関連のもの(ページ)を置きたいのですが、よろしい
ですよね?
--
こせき @ Meadow のページも作成中
http://www.NetLaputa.ne.jp/~kose/Emacs/Meadow/
ko...@yk.NetLaputa.ne.jp
小> nnir.el 1.68 がリリースされたので、検索エンジンとして
小> Namazu を使えるように追加したパッチを
小> http://www.namazu.org/~kose/nnir-1.68.el.patch.bz2
小> に置きました。
遅くなりましたが、試してみました。便利ですよねえ。
小> Gnus から Namazu を使った検索を行う elisp って一般的には何が
小> 使われているのでしょう?
拙作の namazu-gnus.el を含めて何種類かあると思うのですが、nnir.el が一
番良いような気がしてきました。昔のメールを探すときには、何処のフォルダ
に保存したかも忘れている場合が多いので、そうすると、デフォルト動作が
「全体を検索する」になっている nnir.el が便利かなあ、と。
でもって、これを自分の手元だけで管理するのは面倒なので、T-gnus に組み
込んでしまおうか、などと考えているのですが、よろしいでしょうか?
--
土屋 雅稔 ( TSUCHIYA Masatoshi )
小関さん> nnir.el 1.68 がリリースされたので、検索エンジンとして
小関さん> Namazu を使えるように追加したパッチを
小関さん> http://www.namazu.org/~kose/nnir-1.68.el.patch.bz2
小関さん> に置きました。
土屋さん> 遅くなりましたが、試してみました。便利ですよねえ。
[...]
土屋さん> でもって、これを自分の手元だけで管理するのは面倒なので、
土屋さん> T-gnus に組み込んでしまおうか、などと考えているのですが、よ
土屋さん> ろしいでしょうか?
個人的には「ぜひお願いします」です。:-)
土屋さんと同様、別管理は面倒なので今まで手を出していませんでした。
小関さんも CVS commit できることだし、今後のメンテも万全、と。
;; 後で構わないのですが、できれば info も。^^;;
--
Katsumi Yamaoka <yam...@jpl.org>
;; 上記の nnir-1.68.el.patch.bz2 の辺りにカーソルを置いて
;; M-x w3m-download すると get できてしまうのはとっても便利です。
;; (自画自賛 ^^;;)
あぁ、ボクにはそういう発想がなくて、nnir の作者の Kai さんに
直接パッチを送ろうかなと思ってました。でもそのためには
Namazu の説明を Kai さんにしないと....。で止ってました。
そっか、そういう share(共有)する方法もあるのか。
と思ったしだいなので、
山岡> 個人的には「ぜひお願いします」です。:-)
山岡> 土屋さんと同様、別管理は面倒なので今まで手を出していませんでした。
山岡> 小関さんも CVS commit できることだし、今後のメンテも万全、と。
ボクからも是非お願いします。
nnir は他の検索エンジン(IMAP 等も)も使えるので、Namazu 使い
以外の方も試してみてくださいね。
;; ボクが T-gnus 使いじゃないからそういう発想にならなかった
;; んだろうな。:-p
土> でもって、これを自分の手元だけで管理するのは面倒なので、
土> T-gnus に組み込んでしまおうか、などと考えているのですが、よ
土> ろしいでしょうか?
山> 個人的には「ぜひお願いします」です。:-)
お二人に賛成して頂いたので、とりあえず t-gnus-6_15-quimby 枝に commit
しておきました。
なお、より新しい nnir-1.72 が公開されていたので、それを拾ってきたので
すが、これには既に namazu support が組み込まれていました。また、オリジ
ナルの nnir.el を保存するための枝 grossjoh を作成してあります。
;; それに気づかずに小関さんのパッチを適用しようとしたりして、レポジト
;; リ操作でかなり間違いをやってしまい、レポジトリをかなり汚してしまい
;; ました…。どうもすみません。
>> On Tue, 04 Sep 2001 17:07:51 +0900
>> 「小」== ko...@wizard.tamra.co.jp (小関 吉則 (KOSEKI Yoshinori)) said as follows:
小> あぁ、ボクにはそういう発想がなくて、nnir の作者の Kai さんに
小> 直接パッチを送ろうかなと思ってました。でもそのためには
小> Namazu の説明を Kai さんにしないと....。で止ってました。
既に誰か別の人が連絡されているようですよ。
ただ、小関さんの版からは、1つだけですが変数名が変更になっているので、
注意が必要です。
旧: nnir-namazu-index
新: nnir-namazu-index-directory
gnus-group.el / gnus.el を変更し、T-gnus ではキーバインドについての設
定は不要になるようにしてあります。したがって、例えば、以下のように設定
しておくと、nnir.el が利用できるようになります。
(setq nnir-search-engine 'namazu
nnir-mail-backend '(nnml "")
nnir-namazu-remove-prefix (expand-file-name "~/Mail")
nnir-namazu-index-directory (expand-file-name "~/namazu"))
--
土屋 雅稔 ( TSUCHIYA Masatoshi )
[...]
小> あぁ、ボクにはそういう発想がなくて、nnir の作者の Kai さんに
小> 直接パッチを送ろうかなと思ってました。でもそのためには
小> Namazu の説明を Kai さんにしないと....。で止ってました。
土> 既に誰か別の人が連絡されているようですよ。
見てみました。ボクが Namazu を追加したのとは別の実装ですね、
これ。
ボクがやったのは nnir-run-glimpse を元にして作成したので
(defvar nnir-engines
'((glimpse nnir-run-glimpse
((group . "Group spec: ")))
(namazu nnir-run-namazu
((group . "Group spec: ")))
^^^^^^^^^^^^^^^^^^^^^^
としました。
何が違うかっていうと 検索対象グループの指定ができるようにし
てある点。# でマークした(複数の)グループを検索できるようにし
てある点が違います。
使い勝手は格段に違うと思います。
なお、nnir-run-glimpse を元に nnir-run-namazu という関数をで
っちあげたものなので(きたないのですが)レビューしていただける
と嬉しいです。
もっと綺麗に書けるという話もあるし、グループを絞って検索する
方法(実装)をもっとスマートにできるような気もするのです。
(+uri:... で指定してあります。)
その後に commit しましょうか。
--
こせき @ Meadow のページも作成中
http://www.NetLaputa.ne.jp/~kose/Emacs/Meadow/
ko...@yk.NetLaputa.ne.jp
P.S.
エラーになるので Typo だけ直しときました。
小> 見てみました。ボクが Namazu を追加したのとは別の実装ですね、
小> これ。
ほう。
小> 何が違うかっていうと 検索対象グループの指定ができるようにし
小> てある点。# でマークした(複数の)グループを検索できるようにし
小> てある点が違います。
小> 使い勝手は格段に違うと思います。
そうでしょうねえ。
小> なお、nnir-run-glimpse を元に nnir-run-namazu という関数をで
小> っちあげたものなので(きたないのですが)レビューしていただける
小> と嬉しいです。
ではでは、と思って双方の実装を詳細に検討してみたのですが。主に、私の使
い方の問題なのですが、nnir.el では難しいことが2つあります。
(1) 複数の一時グループを取り扱えない。例えば、ある文字列で検索を行い、
一時グループを生成する。その一時グループを横においておき、別の検索
要求を処理して、それらの結果を見比べるような使い方ができない。
(2) 小関さんの用法のような、複数のサーバーに対する対応が構造的に難しい。
改良することはできなくはないのですが、nnir.el の根幹部分に手を入れるこ
とになるので、本家の変更に追随することが非常に困難になると予想されます。
そんなわけで、新規に実装をやり直そうかなあ、という気がしています。
--
土屋 雅稔 ( TSUCHIYA Masatoshi )
http://www-nagao.kuee.kyoto-u.ac.jp/member/tsuchiya/
;; typo 等の連絡有難うございました > 山岡さん
小> もっと綺麗に書けるという話もあるし、グループを絞って検索する
小> 方法(実装)をもっとスマートにできるような気もするのです。
小> (+uri:... で指定してあります。)
gnus-namazu.el でも全グループを網羅した単一の巨大なインデックスに対し
て、+uri: でグループを限定するという実装方法を踏襲しているのですが、こ
の方法ではうまくいかない場合があるようです。
私の ~/Mail/ の下には、約6万通のメールが保管されています。さらに、ニュー
スの過去記事の一部が ~/News/cache/ の下に保管されていて、これらを単一
のインデックスで検索しようとしています。
この時、メールに検索範囲を限定するために
+uri:/home/tsuchiya/Mail/ query
という検索式を使って検索すると、
References: [ (Too many words matched. Ignored) ]
というエラーで、1通も一致しないという結果になってしまいます。+uri: を
使わず、単に「query」を検索式として検索すると、正常に発見されるのです
が…。
というわけで、グループを限定する方法についてアイデアをお持ちの方はいらっ
しゃいませんか。
土> gnus-namazu.el でも全グループを網羅した単一の巨大なインデックスに対し
土> て、+uri: でグループを限定するという実装方法を踏襲しているのですが、こ
土> の方法ではうまくいかない場合があるようです。
## 実は、mew-nmz はこいつがいやなのも一因で、1folder=1index とい
## う namazu らしからぬ方法を使っていたのでした。けど、そろそろ
## 改造しないと。。。
土> +uri:/home/tsuchiya/Mail/ query
土> という検索式を使って検索すると、
土> References: [ (Too many words matched. Ignored) ]
もしかすると、namazu 2.0.6 以降だとお望みのとおりに動作するかも
しれないです。
## というか大丈夫だと思うけど、別のバグを見つけてしまいました。
## う~~ん。
--
白井秀行 (mailto:shi...@meadowy.org)
土> References: [ (Too many words matched. Ignored) ]
白井> もしかすると、namazu 2.0.6 以降だとお望みのとおりに動作するかも
白井> しれないです。
2.0.6 使ってます、しくしく。
--
土屋 雅稔 ( TSUCHIYA Masatoshi )
白井> もしかすると、namazu 2.0.6 以降だとお望みのとおりに動作するかも
白井> しれないです。
土> 2.0.6 使ってます、しくしく。
あらまぁ。。。
Namazu は
% namazu --all --list query index..
という形式で動かしているのですよね。
Mew だと、MH 形式になっているので、folder(いや group か ^^;) の
絞り込みをするときに
% namazu --all --list "namazu" ~/Namazu/Mail/ml/semi-gnus/ ~/Namazu/Mail/xxxx
/home/shirai/Mail/ml/semi-gnus/5525
/home/shirai/Mail/ml/semi-gnus/5312
/home/shirai/Mail/ml/semi-gnus/5521
/home/shirai/Mail/ml/semi-gnus/3046
/home/shirai/Mail/ml/semi-gnus/5524
/home/shirai/Mail/xxxx/1000
/home/shirai/Mail/xxxx/99
/home/shirai/Mail/ml/semi-gnus/6000
<<snip>>
を
(let ((msgregex (concat "^\\(.*\\)"
(regexp-quote mew-path-separator) ;; == "/"/
"\\([1-9][0-9]*\\)"))
な感じの regex で search して、対象の folder を求めています。
Gnus の場合は良くわかりませんが、同様の手法が使えるのではないで
しょうか。
--
白井秀行 (mailto:shi...@meadowy.org)
土> グループ単位で個別にインデックスを作ると、あるグループだけを対象として
土> 検索する場合であれば、かなり高速化されそうなので、そんなに悪い解ではな
土> いと思うのです。
これ、勘違いでした。profile をとってみると、gnus-group-read-group() が
大部分の時間を消費しているので、namazu の呼び出しでいくら頑張っても無
駄っぽいです。
Function Name Call Count Elapsed Time Average Time
=============================== ========== ============ ============
gnus-namazu-search 100 168.64875299 1.6864875299
gnus-group-read-group 100 163.67209899 1.6367209899
gnus-namazu/search 100 2.6097000000 0.0260970000
gnus-group-read-ephemeral-group 100 1.2892540000 0.0128925400
gnus-namazu/call-namazu 100 1.0307460000 0.0103074600
gnus-group-read-group() の読解は、やっていることがややこしくて挫折しま
した…。
ところで、ものは相談なのですが、この gnus-namazu.el も CVS につっこん
でしまってもよいでしょうか?
; いえその、個人で管理してるのが面倒になったものですから。
;; そういえば、nnir.el では summary buffer で ^ が使えませんね。検索さ
;; れた記事同士ではうまく動くのですが、検索されなかった記事まで辿ろう
;; とすることは出来ないようです。
gnus-namazu.elを使い始めました。以前のnamazu-gnus.elとindexの作り方につ
いての考え方が変わったのですね。
いつのまにかgnus-namazuになっていてふと驚きました。
さて、今回namazu-gnusからgnus-namazuに乗り換えたのですが、最初いくらあり
そうなキーワードを入れてもNo entryになってしまっていました。
追いかけてみたところ、私の環境では
nnml-directory は "~/Mail" となっているのに、
gnus-namazu/call-namazu()の出力ではフルパスになっていることが分かりまし
た。
gnus-namazu-server-directoryを以下のようにちょっと変更するとこちらでは動
くようになったのですが、これだと使えなくなる人もいるのですよね。
namazuのindexをつくるとき、
$ mknmz -c -h -a -O ~/News/namazu ~/Mail
としているのですが、これだとnamazu用indexのどこにも~/Mailという文字列が
入りそうにないですよね。
なにか設定がおかしいでしょうか。
namazuはFreeBSD portsのja-namazu-2.0.5をそのまま使っています。
------
--- gnus-namazu.el~ Mon Sep 10 02:56:08 2001
+++ gnus-namazu.el Mon Sep 10 02:56:32 2001
@@ -141,9 +141,10 @@
"Return the top directory of articles in SERVER."
(and (memq (car server) '(nnml nnmh))
(nnoo-change-server (car server) (nth 1 server) (nthcdr 2 server))
- (file-name-as-directory (if (eq 'nnml (car server))
- nnml-directory
- nnmh-directory))))
+ (file-name-as-directory
+ (expand-file-name (if (eq 'nnml (car server))
+ nnml-directory
+ nnmh-directory)))))
;;; Functions to call Namazu.
------
--
Koichi Inoue, ARGV
E-Mail: in...@argv.org
ICQ UIN: 74900690
井> gnus-namazu.elを使い始めました。以前のnamazu-gnus.elとindexの作り
井> 方についての考え方が変わったのですね。いつのまにかgnus-namazuになっ
井> ていてふと驚きました。
すみません、驚かせてしまいましたか。
ご指摘の通り、index の作り方についての考えが変わったものですから、同じ
名前で公開するのは混乱の元かなあ、と思って *わざと* 名前を変えたのです
けれど。
井> さて、今回namazu-gnusからgnus-namazuに乗り換えたのですが、最初いくらあり
井> そうなキーワードを入れてもNo entryになってしまっていました。
井> 追いかけてみたところ、私の環境では
井> nnml-directory は "~/Mail" となっているのに、
井> gnus-namazu/call-namazu()の出力ではフルパスになっていることが分かりまし
井> た。
井> gnus-namazu-server-directoryを以下のようにちょっと変更するとこちらでは動
井> くようになったのですが、これだと使えなくなる人もいるのですよね。
パッチ有難うございます。井上さんの修正で正しいと思います。
土> パッチ有難うございます。井上さんの修正で正しいと思います。
ようやく気持が固まったので、gnus-namazu.el を t-gnus-6_15-quimby 枝に
追加しました。
;; Info は今度追加します。
質問なのですが、From: からアドレス本体を取り出すために std11.el に依存
しているのですが、これを Gnus 本体で完結するようにできないでしょうか。
土屋さん> 質問なのですが、From: からアドレス本体を取り出すために
土屋さん> std11.el に依存しているのですが、これを Gnus 本体で完結する
土屋さん> ようにできないでしょうか。
必要でしたら実施してしまって下さい。Gnus 本体と言わず、XEmacs や
Emacs 標準のライブラリを使う分には問題無いのではないでしょうか。
ただ、忘れないでいただきたいのは、T-gnus は Mule 2...@19.34 をサ
ポートしていることです。
APEL, FLIM, SEMI あっての T-gnus ですが、Oort Gnus とソースコー
ドを共有にするなどの目的でそれらの機能を使わないようにすることは、
個人的には推進していきたいテーマの一つです。
;; そして、開発者のみなさんにもう一つ望むのは、最新の Oort Gnus
;; をご自分の環境で使えるようにしておいていただくことです。:-)
--
Katsumi Yamaoka <yam...@jpl.org>
土> 質問なのですが、From: からアドレス本体を取り出すために
土> std11.el に依存しているのですが、これを Gnus 本体で完結する
土> ようにできないでしょうか。
山> 必要でしたら実施してしまって下さい。
分かりにくい書き方でごめんなさい。
From: 行の内容を解析して、アドレス本体のみを取り出したいのですが、私は
std11-extract-address-components() による方法しか知りません。この FLIM
依存を取り除きたいのですが、簡単な方法をご存じないでしょうか。
という意図の質問でした。というわけで、ご存じの方は教えてください、宜し
くお願いします。
山> APEL, FLIM, SEMI あっての T-gnus ですが、Oort Gnus とソースコー
山> ドを共有にするなどの目的でそれらの機能を使わないようにすることは、
山> 個人的には推進していきたいテーマの一つです。
はい、私もそう思います。
;; 小関さんのような方もいらっしゃることですしね。
山> ;; そして、開発者のみなさんにもう一つ望むのは、最新の Oort Gnus
山> ;; をご自分の環境で使えるようにしておいていただくことです。:-)
うぎゃあ。
土> 質問なのですが、From: からアドレス本体を取り出すために
土> std11.el に依存しているのですが、これを Gnus 本体で完結する
土> ようにできないでしょうか。
山> 必要でしたら実施してしまって下さい。
土屋さん> 分かりにくい書き方でごめんなさい。
土屋さん> From: 行の内容を解析して、アドレス本体のみを取り出したいので
土屋さん> すが、私はstd11-extract-address-components() による方法しか
土屋さん> 知りません。この FLIM依存を取り除きたいのですが、簡単な方法
土屋さん> をご存じないでしょうか。
あ、そういうことでしたか。先読みしてしまった。^^;;
mail-extract-address-components ではどうでしょうか。おそらく動作
確認が必要だとは思いますが。この関数は mail-extr.el にありますが、
少なくとも Mule 2.3 以上では autoloaded になっています。
[...]
山> ;; そして、開発者のみなさんにもう一つ望むのは、最新の Oort Gnus
山> ;; をご自分の環境で使えるようにしておいていただくことです。:-)
土屋さん> うぎゃあ。
たしかに最初はしんどいかもしれない。^^;;
ぼくは Emacs の起動時に load-path の順序を入れ替えてしまっていま
す。だから今現在 T-gnus を使っている XEmacs のままで Oort Gnus
を使うことはできません。(それが出来るようにすることは不可能では
ないと思いますが。)
--
Katsumi Yamaoka <yam...@jpl.org>
山> mail-extract-address-components ではどうでしょうか。おそらく動作
山> 確認が必要だとは思いますが。この関数は mail-extr.el にありますが、
山> 少なくとも Mule 2.3 以上では autoloaded になっています。
どうも。置き換えたら動きましたので、さくさくと commit してしまいました。
これで何ができるかというと、C-c C-n +from: TAB RET と入力することによ
り、現在閲覧中の記事の筆者のメールアドレスが補完されます。すると、同じ
筆者の書いたメールのみをすぐに取り出すことができる、というわけです。
;; / a だと、既に summary buffer に表示されている記事を対象として、筆
;; 者によって表示を制限するだけですが、gnus-namazu-search() を使う方法
;; では、全ての記事が対象になります。
C-c C-n +f TAB まで入力すると、+from: まで補完されますから、結局、
C-c C-n +f TAB TAB RET で済むんですけどね。
なお、同じ表題の記事をリストアップする場合には、C-c C-n +sub TAB TAB RET
でできます。
山> ;; そして、開発者のみなさんにもう一つ望むのは、最新の Oort Gnus
山> ;; をご自分の環境で使えるようにしておいていただくことです。:-)
土> うぎゃあ。
山> たしかに最初はしんどいかもしれない。^^;;
問題が T-gnus にあるのか、Gnus 本体にあるのかを判定するためには不可欠
だということは、理解はできるのですけれど。
山> ぼくは Emacs の起動時に load-path の順序を入れ替えてしまっていま
山> す。
やっぱり、そうなりますよね。
というわけで、CVS で最新を取得してくるところまでは、作業しました。残り
はまた今度にさせてください…。
gnus-namazu.el で使われている関数 `regexp-opt' なんですが、今ど
き regexp-opt.el が無い、古い Emacsen に対応したコードを書く枷を
嵌めるよりは、Mule 2.3 のユーザ自身に regexp-opt.el を持ってもら
うことにしてみました。以下 Mul...@1934.ja より:
T-gnus のいくつかのモジュールは `regexp-opt' などの関数を使います。そ
れらの関数は、最近の Emacsen では regexp-opt.el(c) で定義されているの
ですが、Mule 2.3 はそれを標準の Lisp ライブラリの中に含んでいません。
以下のように contrib/regexp-opt.el を site-lisp ディレクトリ (または他
のディレクトリ) にコピーして、byte-compile して下さい。
% cp -p contrib/regexp-opt.el /usr/local/share/mule/site-lisp
% cd /usr/local/share/mule/site-lisp/
% mule -batch -q -no-site-file -f batch-byte-compile regexp-opt.el
--
Katsumi Yamaoka <yam...@jpl.org>
山> 以前にも、regexp-opt.el が Mule 2.3 に無い問題を指摘して、相応の
山> 対処をしたいただいた記憶があるのですが、今回は別。
いつも、お手数をおかけして済みません。
指摘を受けた記憶がかすかに残っていたので、調査は始めていたのですが、手
元の mule2 だと何処かで定義されてしまうらしく、勘違いかと思ってました。
;; こういう時は、find-function が切実に欲しい…。
山> gnus-namazu.el で使われている関数 `regexp-opt' なんですが、今ど
山> き regexp-opt.el が無い、古い Emacsen に対応したコードを書く枷を
山> 嵌めるよりは、Mule 2.3 のユーザ自身に regexp-opt.el を持ってもら
山> うことにしてみました。
了解。
土> ;; Info は今度追加します。
gnus-ja.texi に gnus-namazu.el についての記述を追加しました。
;; nnir.el はまだです。というか、より詳しい小関さんに期待、かも。