Re: find-function vs. Windows paths

Jeff> I think you're missing something here with the search load Jeff> path thing. load-history is used to figure out what file Jeff> contains the function. The load-path is used to find the Jeff> file (except when absolute file names are used). Right. The point is that I don't want to waste my time editing files that are just going to get overwritten the next time I do a build and install, I want to go right to the source. Jeff> On the other hand, if you try to find Jeff> 'make-specifier-and-init', we look in load-history, and find Jeff> that it is defined in Jeff> "/opt/sfw/lib/xemacs-21.4.6/lisp/specifier.elc" So, we know Jeff> exactly where this source file is - it is Jeff> "/opt/sfw/lib/xemacs-21.4.6/lisp/specifier.el" Jeff> This works as long as the file is there. Well, this Just Works _for my purposes_. I want XEmacs to tell me that the file isn't there---in my setup, sometimes it is, and sometimes it isn't. I don't want XEmacs substituting a file with identical text from somewhere else. It's fine if it works the way you want it to _by default_. But please don't break things so it _can't_ work the way I want it to. Jeff> So, something needs to be fixed. Agreed. But I see no good from inserting lies in load-history. Jeff> Alternatively, we could make 'symbol-file' smarter by not Jeff> returning absolute paths that don't exist, symbol-file is documented to return the file the symbol was loaded from, not a file from elsewhere. If that file doesn't exist, tough. It's the caller's responsibility to deal with that. Jeff> or make 'find-function-search-for-symbol' try harder. This is what I would like to do. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py