Ville Skyttä <scop(a)xemacs.org&gt; writes: I believe your Canna patch deleted a directory prefix from some module name, right? If so, your patch should go in. (... and mine should render Stephen's objection unnecessary) If not, it shouldn't. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Ville Skyttä writes: AFAIK, the pathfinding magic will do it magically. APPROVE I'll take responsibility if something breaks. (Maybe I'll ask Mike to actually fix it :-) but I promise to dive and catch the bug report before it hits the floor.) More precisely, go ahead and apply it. It's going in the right direction, the current code is broken, and more work is needed in any case (I want to get rid of the explicit reference to the module being loaded). _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

On Tuesday 06 February 2007 18:40, Michael Sperber wrote: Towards away from the filesystem root, without caring about directory names it recurses into? Then I would understand :) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Michael Sperber writes: I think that all this is true, but unfortunately I'm now running into the "why is XEmacs looking for installed files?" problem, so I can't yet say "works for me". :-( `paths-find-module-directory' uses `paths-find-architecture-directory'. Unfortunately, `paths-find-architecture-directory' does a breadth- first search across roots, looking for architecture-specific directories first, so it will definitely find "/usr/local/xemacs/xemacs-21.5-b27/powerpc-apple-darwin8.8.0/modules" before it finds "~/Software/XEmacs/git-staging/+build/modules" even though I'm running in-place. This seems very undesirable to me. First, I would think that you'd want an in-place XEmacs to try to find its associated files first. This is especially true of modules, I would think, since we do not have a published API for basic editor structures like buffers, and the modules just #include the private headers. I'm tempted to go so far as to say that the pdump build-id should be in the module, and XEmacs should refuse to load a module with a different build-id without user interaction. This is implementable; an in-place XEmacs can be identified with near certainty from the presence of lib-src and tests directories (among others) combined with the absence of the arch- specific directory under the root. Second, I would think that in general you want all of the various core pieces to come from the same build. Eg, when (as you and Aidan have both recently done, in opposite directions) some function is moved between C and Lisp. While it seems likely (except for modules) that things will work out that way, I don't see anything in the path- finding code that tries to enforce it. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta