gtags-find-tag が動かない件 - GONE WITH THE MEDICINE

どうもです。

Meadowでは，大丈夫。けど，NTEamcs23だと，
gtags-get-rootpath で取得したディレクトリに cd するときに，
no such directory とのエラー。

追記その3 (2010/11/12 (Fri) 02:54ぐらい)

根本的に解決されました。
cygwin-mouont を require するのを忘れてました。
以前，どこからかコピーして貼り付けたまんまでした。

(when (and (featurep 'meadow) (locate-library "cygwin-mount"))
 (require 'cygwin-mount)
 (cygwin-mount-activate))

こうなっていて，ntemacs に移行後修正してなかったので，
require されてませんでした。
チャンチャン。
ntemacs，gtags の中の人達，少しでも疑ってすみませんでした。
でも，両方とも好きなのでまだまだ使わせてもらいますよっと。

というわけで，設定。

(require 'cygwin-mount)
(cygwin-mount-activate)

以下，解決に至る道程

原因は gtags ではなくて，expand-file-name に絶対パスを渡したときの挙動の違い。

Meadow での挙動

以下の通り，相対パス，絶対パス，それぞれについて，
Windowsで有効なパスを出してくれる。
(有効というのはおかしい言い方な気もしますね)
つまり，Meadowの場合のパスは，正しいわけです。

(expand-file-name "/home/whitypig/src/googletest/gtest-1.5.0")
"e:/cygwin/home/whitypig/src/googletest/gtest-1.5.0"

(expand-file-name "../")
"e:/cygwin/home/"

(expand-file-name "~/")
"e:/cygwin/home/whitypig/"

NTEmacs23.2.1 での挙動

相対パスの場合は，問題なくて，Meadowと同じ挙動。
でも，絶対パスを渡したときには，Windows内では，無効なパスが出てくる。

;; アウト!!
(expand-file-name "/home/whitypig/src/googletest/gtest-1.5.0")
"e:/home/whitypig/src/googletest/gtest-1.5.0"

;; これは正しい
(expand-file-name "../")
"e:/cygwin/home/"

;; これも正しい
(expand-file-name "~/")
"e:/cygwin/home/whitypig/"

expand-file-name のソース見ようとしたけど，C Source Codeだったorz。
ソース落としてくるかな。

このエントリ書いていて，ふと気づいたので，試してみた。

(expand-file-name "home/whitypig/src/googletest")
"e:/cygwin/home/whitypig/home/whitypig/src/googletest"

ぬあぁっ!
これはオッケーなのか。
ということは，やはり，「/」で始まるパスが渡されたときの挙動ということか。

これって，どうやって回避すればいいんだろう。。。
ワシが何かの設定を忘れているのだろうか?
何か知っている人いましたら，教えて下さい。
gtags.el に手を入れるのは何か違う気がするしなぁ。

おまけ

こないだいっていた，

tags-table-set-list がsessionに記録されない件
auto-complete-etags.el のcandidates-faceがオレオレ色に染まらない件

の2つですが，tags-table-set-list については，本日確認したら，
記録されてました。なので，解決。

後者の件については，gtest.TAGS という，google test のソースに対して，
etagsして作成したタグファイルを使用中の時には，染まらない。
けど，usr.include.TAGS とか，別のタグファイルを使用中の時には，
オレオレ色に染まってくれる。うーん。謎は深まるばかりだ。

追記

いや，「/」を渡したときの挙動は，NTEmacs の挙動も正しいと言える気がしてきた。

;; Meadow の場合
(expand-file-name "/")
"e:/cygwin/"

;; NTEmacs の場合
(expand-file-name "/")
"e:/"

追記その2

とりあえず，global-5.9.2 にしてみた。

ほいで，解決した。
gtags-path-style を relative にしたらいけた。
デフォルトの root のままだと，やっぱり同様のエラーでだめ。
一応と思って，以前のバージョンの，gtags.el を使ってみたけど，
そっちでも大丈夫だった。
ま，ルートディレクトリを経由しなければ，大丈夫ということですかな。
それから，ワタシの環境だけかもしれないけど，
5.9.2 で，gtags-path-style を absolute にすると，
移動先のバッファを選択したときに，間違ったパスが使用されるので，
その間違ったパスに対して，find-file かますので，
新たにファイルが作成されてしまうです。

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; gtags, global
(when (require 'gtags nil t)
  (add-hook 'gtags-mode-hook 'my-gtags-mode-hook-func)
  ;; to avoid confilicting with find-tag of etags
  (define-key gtags-mode-map "\e*" nil)
  (define-key gtags-mode-map "\e." nil)
  (setq gtags-path-style 'relative))

(defun my-gtags-mode-hook-func ()
  (interactive)
  ;; \C-c\C-b was originally assined to `c-submit-bug-report'
  (define-key gtags-mode-map "\C-c\C-f" 'gtags-find-tag)
  (define-key gtags-mode-map "\C-c\C-b" 'gtags-pop-stack)
  (define-key gtags-select-mode-map "\C-c\C-b" 'gtags-pop-stack))

なんかはじめると，何かしらの不具合とか，改善案とか思いついて，
本来の目的を忘れてそちらをやっている気がする・・・。
いや，間違いなくそうだろう。うー。
結局，expand-file-name のmeadowとntemacsでの挙動の違い
については謎のままだ。
meadowが頑張っているんだろうなぁ。