On 13 Dec 2001, Adrian Aichner wrote: [] I use XEmacs 21.1.14 and 21.4.4. Trying to use a C-h f on `edit-options' doesn't make sense That's what I mean; for XEmacs I consider defvar deprecated, use defcustom instead. Am I wrong? Valid, yes. But isn't that just for backward compatibility? Thanks that looks like what I was missing. I'll have a look at that. At least it's a start ;-) Jarl

Hi again. Please comment if I am getting things wrong: On 14 Dec 2001, Stephen J. Turnbull wrote: It affects (hyper-)?apropos with an indication that it is a user-variable, no other way right? Related is the affect to `set-variable' which completion includes it if and only if the doc string contains an asterisk. Since these are intended for users to modify, I believe that _every_ defcustom should have an asterisk at the begining of a doc string. In that case why do we at all have asterisks in defcustom doc strings, couldn't they just behave like if the doc-string _always_ contained an asterisk? (i.e. let the defcustom expansion insert one if there is none) Since these are for other package writers. I can see no reason for having an asterisk in the doc string for them, AFAIK the "*" only affects the `set-variable' function and (hyper-)?apropos as described above. Could anybody come up with (real-life) examples of when it's a good idea to include "*" and when it is not a good idea to include "*" in a defvar declaration I agree. As I get it "*" in the doc string should never appear; they are not mean to be modified, certainly not by users. So why don't we make defconst ignore (or remove) any initial asterisks in doc strings for defconst declarations. I assume that "*" in doc string for functions does not have any effect since (interactive ... ) is used instead to make them commands, right? I am sorry to ask such seemingly not very important questions, but if it finds it ways to the documentation (as I have plans for it to do) I hope it will help the community and comming elisp hackers to write nice and consistent code. Jarl

On Fri, 14 Dec 2001, Matt Tucker wrote: [] After I wrote the posting I considered that too, but it seems like you got a very good point here; "features", i.e. properties shouldn't go in docstrings. I think it's a good idea. Worth it? Don't know. defcustoms should always set the user property defconst should never set the user property. Regarding defvar I still feel need of good examples of when set and not to set it the user property (especially when to _set_ (include "*") it user-intended). I am looking through the big reservoir of good lisp examples right now, and hope to find a good example there. In the function space the (interactive ... ) kind of serve that functionality (sets it to be user-intended) BTW: I found another situation where defvar could/should not be replaced dy defconst nor defcustom: When some information has to be stored internally from function call to function call (like the kill-ring and search-ring). In OO-terms one can think of them as private members. Jarl

On Sat, 15 Dec 2001, Paul Krause wrote: Yes, but when you want to store information from one function call to the next one, there are only global public space to use, so defvar is it. Jarl

On Sun, 16 Dec 2001, Paul Krause wrote: Will not work. since the functions when invoked will refer to kill-ring, kill-ring-yank-pointer, which in your example is not declared (at time of invocation). Test it yourself on: (let ((private-var "privacy")) (defun show-private () (message private-var)) (defun change-private (new-private) (setq private-var new-private)) ) Call to show-private will fail unless you call change-private first which will *create* the public global variable private-var (which has nothing to do with the one found in line one of the example). The netto-effect of the example is exactly the same (not sure about byte-compilation) as the two lines without (let ...): (defun show-private () (message private-var)) (defun change-private (new-private) (setq private-var new-private)) Sorry, but to me it's not clear at all what you mean. Jarl

|--==> "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;---|