Rodney Sparapani <rsparapa(a)mcw.edu&gt; wrote: Of course, but what is your point exactly ? In particular, if by "we should have both", you mean that every instance of XEmacs on OS X would look for packages both in the Mac places and in the Unix places, you're sure going to get trouble (duplicate features and stuff). -- Resistance is futile. You will be jazzimilated. Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (0)1 44 08 01 85 94276 Le Kremlin-Bicêtre, France Fax.+33 (0)1 53 14 59 22 didier(a)xemacs.org _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

skip(a)pobox.com wrote: Hi Guys: Let me backup. What I meant was that ~/.xemacs would be created as usual and it would be symlinked to ~/Library/Application\ Support/XEmacs. I was thinking that if you installed a package you would want it installed for both Carbon and X11 versions of XEmacs (there is nothing I hate more when testing different versions than finding that one of them doesn't support a package that I need to use and would want to test). And, similarly for /usr/local/share/xemacs and /Library/Application Support/XEmacs. So, it is only looking in one place for each. Now, how these symlinks are created, I don't know. I guess you have to have Mac OS X rules for make install anyways. However, we may not have all of the bugs worked out of Mac OS X XEmacs for a while so I'm assuming that we will make these symlinks by hand for now (and it might help testing for any Carbon vs. X11 issues). Having said all that, both Carbon and X11 XEmacs seem clunky. What would it take to make a Cocoa version of XEmacs? I read up on Cocoa a while back and it's Objective-C, but I really didn't understand it (I dabble in C++, but that was not helping). I'm using Cocoa Emacs with a similar symlinking scheme and everything seems to work the way you want it to. Not to hijack the thread of course :o) Rodney _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Rodney Sparapani writes: A pile of new developers. As of Saturday when Aidan announced his intention to take a vacation from XEmacs work for several months, there are ZERO XEmacs developers working on Carbon, and AFAIK we have ZERO developers who know anything about Objective-C or Cocoa. Feel free to discuss as much as you like, but the current staff is showing no signs whatsoever of working on this. N.B. Didier is a XEmacs Reviewer, he looks like the most likely candidate for actually doing something (like approving patches) at the moment. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Rodney Sparapani writes: Mostly they should work, except for a few tightly bound to the overlay vs extent distinction. Put them late in your load path so that packages distributed with Emacs work. The obvious thing is to set up the load-path by hand in your init file, but there should be a way to tell Emacs that "everything in this hierarchy should be searched for Lisp libraries". _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Rodney Sparapani writes: Well, in one sense there already two: the CVS "packages" module, and the sumo tarballs + "find /path/to/packages -name '*.elc' -exec rm \{\}". It is up to individual maintainers whether they accept bug reports from GNU Emacs users. I would encourage that, but I see no reason why we should do anything more. That is, I predict it will not be appreciated, let alone reciprocated, by GNU Emacs.[1] David, what do you think? Volunteers welcome; we would be happy to provide a primary distribution point for it, and bug reporting redirection to the maintainer. Footnotes: [1] GNU Emacs will of course continue making its contribution to the world at large, including XEmacs without limitation. But that's unilateral, not reciprocal. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Rodney> Wow! This is fantastic. They seem to work perfectly. Has Rodney> there been any thought of making a distro for Emacs? AFAICT, Rodney> it would only take minor changes. For example, the Rodney> byte-compiled files would not be distributed, or something Rodney> like that. I sometimes contemplate over the idea of making a package system in the spirit of gentoo portage, e.g. distributing source code that is compiled locally by the user. I just can't figure out whether it would be an overall good idea or not. ;-) Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Stephen> I have to wonder what more you plan on doing beyond what M-x Stephen> batch-byte-compile already does? Well I don't plan to do anything at all. At times though I have been thinking about whether a source code based package system would make sence. Things that spring to my mind are: - doing the byte compilation locally so that the right byte code is generated naturally. The same Emacs used for running the package is also used for compiling it. - the build would handle Emacs properties like mule or nonmule depending on what version of Emacs is used for the build. - at the same time construct the package system to handle dependencies properly between packages, including dependencies to the Emacs binary. - support for third party packages. - ... Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Stephen> We haven't had any byte-code compatibility problems with the Stephen> policy of compiling under 21.4. In general compiling under a Stephen> particular XEmacs would mean that people with multiple Stephen> installations of XEmacs would not be able to share packages Stephen> among them. True but I never said the package system would be for XEmacs only. Stephen> On the other hand, I think eventually we should move to Stephen> compiling on-the-fly like Python and Perl. That would mean Stephen> the same thing, for the same reason. Yes, that would be a nice. Stephen> They're not actually relevant to the byte code. The issue is Stephen> simply whether the XEmacs doing the compilation can read Stephen> multibyte characters or not. I'm pretty sure that a no-mule Stephen> XEmacs can correctly compile Lisp that requires Mule to Stephen> execute as long as all non-ASCII characters and strings are Stephen> built up with `make-character' etc. I think this is true in Stephen> general! Well a package system is not only for byte compilation but also for giving a user a reasonable list of available packages. Packages that can't be used with the Emacs at hand should not be possible to install. So a mule package will not be available to a non mule XEmacs for example. Stephen> I'm not sure what you mean by "dependencies on the Emacs Stephen> binary". I mean that a specific version of a package might not be available for all versions of the binaries. Like the current problem with ecb. It doesn't work with 21.5. If there is an older version of ecb that works with 21.5 that version is the one that a 21.5 user will see. Stephen> Dealing with Lisp dependencies, though, is pretty hard, Stephen> because Lisp doesn't really provide anything beyond autoload Stephen> and require to deal with them: everything just lives on the Stephen> load-path. The big problem is that you can compile a library Stephen> successfully without having its prerequisites present, Stephen> *except* for macros, which must be defined in the compilation Stephen> environment. But you can't know which "functions" are Stephen> actually implemented as macros (and it might even change Stephen> across versions of Emacs). Yes, and it is here I start to wonder whether it will be worth it. Lisp is pretty good in it self to handle dependencies and sometimes a package is useful although some part of it depends on something that isn't available. Still some packages do come with a list of things that must be available for it to work and that type of dependencies could be handled. But no, I don't plan on doing something like this. It was just something I thought about when helping out a little with the xemacs packages for gentoo. Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

On Fri, Feb 01 2008, Stephen J. Turnbull wrote: ,----[ (info "(elisp)Startup Summary") ] | 1. It adds subdirectories to `load-path', by running the file named | `subdirs.el' in each directory in the list. Normally this file | adds the directory's subdirectories to the list, and these will be | scanned in their turn. The files `subdirs.el' are normally | generated automatically by Emacs installation. `---- $ cat /usr/share/emacs/22.1/site-lisp/subdirs.el (if (fboundp 'normal-top-level-add-subdirs-to-load-path) (normal-top-level-add-subdirs-to-load-path)) Bye, Reiner. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta