Jan> Hrvoje Niksic <hniksic(a)srce.hr&gt; writes: Jan> I suggest not using an .xemacs-custom file but use Jan> .xemacs/options.el even if we do not use .xemacs/init.el, Jan> because Jan> 1. We already have been doing it (unintentionnaly) and it Jan> seems to Jan> work. Jan> 2. Having an .xemacs-custom file is making the (eventual) Jan> migration to Jan> .xemacs/ based system even more difficult as it is yet Jan> another file to care for. Jan> 3. We have .xemacs anyway for the package system. Sounds reasonable to me. I am certainly on the pro ".xemacs/" side. (As usual I don't think we should be so conservative...) MS> ~/.xemacs is a package hierarchy. Whose idea was that? "~/.xemacs/" was marked to be for users configuration files _and_ personal packages and libraries. In particular I thought "~/.xemacs/{mule-}packages/" was meant for packages, just like for "$prefix/lib/xemacs/{mule-}packages/". I am very much again the current behaviour that grabs "any" subdirectory of "~/.xemacs/" and bungs it onto `load-path'. Please give us some freedom in how we use "~/.xemacs/". Thank you. -- Jens-Ulrik Holger Petersen <http://www.kurims.kyoto-u.ac.jp/~petersen/> Research Institute for Mathematical Sciences, Kyoto University