Re: Q: Making an XEmacs package

|--==> "JF" == Jarl Friis <jarl(a)diku.dk&gt; writes: JF> Hi. JF> I am planning to make an XEmacs package one day (out of eSMS) and needs JF> some information of how to do that. There will probably come a series of JF> questions regarding this. Feel free to ask anything you like. As the XEmacs Packages Dude, I'll do my best to help. JF> I partially document my experiences so I may come up with some JF> documentation patches for the lispref.texi file during all JF> this. That would be fantastic, Jarl! And we would be eternally grateful to you for that. JF> Please don't give me a RTFM, since it may actually be TFM I'm JF> criticising. Cool, just let us know when you are criticising TFM, so we don't. :-) JF> As I see it user-options should not be declared with `defvar', JF> but rather `defcustom'. does that make `defvar' obsolete? No, 'defvar' is not obsolete. I agree that most user-customisable variables should be declared with 'defcustom', but there may be times when you don't wish to do that. As an example, your package may be quite complex and be designed for both novice and advanced users. There could quite possibly be some customisable things in your package that might confuse or cause problems for the novice user simply because they don't really know what they are doing. So you declare those as 'defvar's to help saving the novice from shooting themselves in the foot. JF> Since a variable is either a "constant" that is not intended for user JF> modifications (using `defcons') or it's a user customisation (using JF> `defcustom'), can anyone come up with an example of when it's appropriate JF> to use `defvar'? That's 'defconst', BTW. To answer the question, yes. See above and also: How about a variable (not a constant) that a user would not normally see or have need to alter? A real world example that's close to your heart because you wrote it.:-) JF> Can anyone point me to some documentation on how to make the jump from a JF> simple *.el-file to a real integrated XEmacs package? A list of criterias JF> on file/directory-structure, etc. would be nice. Steve T made a start to this: 'C-h C-i xemacs RET m packages RET m creating RET' The way you structure the source is not as important as how the compiled, installed package is structured. Your package needs to be able use this hierarchy: ./xemacs-packages/ | |---/etc/ | | | |---/pkgname/ (auxiliary files eg pixmaps here) | |---/info/ (formatted TeXinfo docs here) | |---/lib-src/ (auxiliary binaries here, think Eicq's icq2tcp) | |---/lisp/ | | | |---/pkgname/ (*.el *.elc here) | |---/man/ | |---/pkgname/ (TeXinfo source here) That's how it is once a user installs your package. How you set up the source is pretty much up to you. Grab a couple of packages out of CVS and see how others have done it. cvs -d :pserver:cvs＠cvs.xemacs.org:/pack/xemacscvs co pkgname (eg "eicq" or "gnus" or "vm") -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|