SY> Martin Schwenke <martin(a)meltin.net&gt; wrote: VS> Why not do this now, before this file becomes part of XEmacs? OK, I'll do that before the first version gets committed. Will someone else do the initial commit or will I? SY> Yep. Martin, please send me (privately) your public SSH SY> (version 1) key and your preferences for a user name. Done... VS> To me it seems that this file could be just dropped in (doing VS> the necessary changes in package-info.in and Makefile in VS> prog-modes) and the old eiffel3.el removed; and doing so VS> wouldn't break anything. SY> That sounds good to me. And in the unlikely event that something does get broken, it can be almost certainly be fixed quite quickly... :-) VS> One question, should we put a (provide 'eiffel3) into this new VS> file for backwards compatibility? Not needed, I think... SY> It probably wouldn't hurt to have that in there, but I SY> wouldn't veto the file if it didn't have it. I'll let you SY> guys decide whether or not you want to put it in. Would it be bad form to leave an eiffel3.el around containing only: (require 'eiffel) (provide 'eiffel3) It's gross, but it means we could have it both ways. If not, my preference is to leave it out. Actually, in a way, I'd prefer to break peoples' configuration so that they know a fairly big change has occurred... peace & happiness, martin

|--==> "VS" == Ville Skytt <Ville> writes: VS> I just did, see my message in xemacs-patches. Basically I added the new VS> file as eiffel.el, removed the old eiffel3.el and fixed Makefile and VS> package-info.in. Cool. I'll get a new prog-modes into Pre-Release. -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

|--==> "MS" == Martin Schwenke <martin(a)meltin.net&gt; writes: VS> I just did, see my message in xemacs-patches. Basically I VS> added the new file as eiffel.el, removed the old eiffel3.el VS> and fixed Makefile and package-info.in. MS> OK, thanks... MS> Although I've now CVS checked out prog-modes and eiffel3.el is still MS> there, and eiffel.el isn't. Am I missing something? No, I haven't seen it go in yet either. I sent an email to Ville about it, but he hasn't replied yet so he must be busy doing other things at the moment. Martin, could you please check your eiffel.el into CVS and remove eiffel3.el. If you're not sure what to do with the Makefile and package-info.in files, that's cool, I'll take care of it. Thanks. -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

Ville> On Mon, 2002-06-03 at 14:21, Steve Youngs wrote: VS> I just did, see my message in xemacs-patches. Basically I VS> added the new file as eiffel.el, removed the old eiffel3.el VS> and fixed Makefile and package-info.in. MS> OK, thanks... MS> Although I've now CVS checked out prog-modes and eiffel3.el is still MS> there, and eiffel.el isn't. Am I missing something? >> No, I haven't seen it go in yet either. I sent an email to Ville >> about it, but he hasn't replied yet so he must be busy doing other >> things at the moment. Ville> Yes, I've been busy as well as unable to access my mails Ville> for a while, but I'm sorta back in business now. Ville> Anyway, I think I had checked these changes in, but I'm Ville> unable to verify that now; "cvs update" and "checkout" give Hi Ville! http://cvs.xemacs.org/query.cgi?repository=%2Fpack%2Fxemacscvs&branch... suggests your changes did not go in. What's the output you got from the cvs commands you used for commiting? Ville> timeouts, using the :ext method with ssh or the anon Ville> :pserver. "ssh -v xemacs(a)cvs.xemacs.org&quot; seems to work Ville> fine, though. Anybody else seeing this? See step 4 under http://www.xemacs.org/Develop/cvsaccess.html#committers What do you get when you enter commands noop and version ? Best regards, Adrian Ville> Please go ahead and commit as I can't do that right now (and my Ville> apologies if I didn't do that previously). Ville> It might be good to add the "-ko" flag to the new eiffel.el if you don't Ville> want xemacs CVS to change the CVS keywords (I see at least $Id$ is in Ville> eiffel.el). Eg. "cvs add -ko eiffel.el". Ville> Cheers, Ville> -- Ville> Ville Skyttä <ville.skytta(a)xemacs.org&gt; -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

|--==> "VS" == Ville Skytt <Ville> writes: VS> I just fixed my local cvs setup problems and committed this, it should VS> be in now. Yep, just saw it go in. Thanks Ville. -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

VS> I just fixed my local cvs setup problems and committed this, VS> it should be in now. Martin> OK, thanks! Martin> There's a couple of minor problems, since there's still Martin> some internal references to eiffel-mode.el (such as the Martin> provide). I've fixed them at this end and also fixed a Martin> bug and a couple of other things. Martin> I'm ready to post a patch (from "cvs diff") to Martin> xemacs-patches, but I'm not sure of the exact procedure. Martin> There's various subject line tags ([PATCH] is obvious, Martin> [AC] & [C] aren't). Can someone please fill me in on what Martin> exactly to post to keep noise on xemacs-patches to a Martin> minimum? Hi Martin, I just have a minute ... Please type C-h B (describe-beta) and see ** Creating patches for submission ================================== See also step 6 in http://www.xemacs.org/Develop/index.html Hope this helps, Adrian Martin> Thanks... Martin> peace & happiness, Martin> martin -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

Ville> On Fri, 2002-06-07 at 11:53, Adrian Aichner wrote: Martin> There's a couple of minor problems, since there's still Martin> some internal references to eiffel-mode.el (such as the Martin> provide). I've fixed them at this end and also fixed a Martin> bug and a couple of other things. Martin> I'm ready to post a patch (from "cvs diff") to Martin> xemacs-patches, but I'm not sure of the exact procedure. Martin> There's various subject line tags ([PATCH] is obvious, Martin> [AC] & [C] aren't). Can someone please fill me in on what Martin> exactly to post to keep noise on xemacs-patches to a Martin> minimum? >> Please type >> C-h B (describe-beta) >> and see >> ** Creating patches for submission >> ================================== >> See also step 6 in >> http://www.xemacs.org/Develop/index.html Ville> I was looking for documentation of the patches mailing list Ville> keywords a while back, too, and was unable to find it (the Ville> pointers Adrian gave are good, but don't contain this Ville> info). Maybe the best way ATM is to browse the Ah, right, forgot to mention patch-keywords.el which is part of the xemacs-devel package. You'll need (require 'patch-keywords) since it has no autoload cookies. Shouldn't it have autoload cookies? Use M-x patch-keywords-insert-gnus or M-x patch-keywords-insert-vm depending on your MUA. Use C-h f (describe-function) on above functions for details. patch-keywords.el provides a key mapping for gnus too: M-p patch-keywords-insert-gnus If you use a different MUA, you can still look at valid keywords in variable patch-keywords - List of keywords used for reviewing patches. Hope this helps, Adrian Ville> xemacs-patches archives and see how people use them. IMHO Ville> it would be good if these would be documented somewhere Ville> (maybe just add the keywords to the docs from Ville> describe-beta). Here's how I've understood them: Ville> A = APPROVE - reviewed, approved, often combined with COMMIT Ville> C = COMMIT - committed to CVS Ville> S = SUPERSEDES - a revised patch Ville> V = VETO - a rejected patch, and the reason Ville> Q = QUERY - need more info Ville> R = RECOMMEND - recommended for some version Ville> PATCH - yep Ville> Use the abbreviation in subjects, and the expanded form in Ville> the start of the message body. Ville> -- Ville> Ville Skyttä Ville> ville.skytta at xemacs.org -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

|--==> "VS" == Ville Skytt <Ville> writes: VS> IMHO it would be good if these would be documented somewhere VS> (maybe just add the keywords to the docs from describe-beta). Totally agree. I'll see if I can't do something about it. VS> A = APPROVE - reviewed, approved, often combined with COMMIT VS> C = COMMIT - committed to CVS VS> S = SUPERSEDES - a revised patch VS> V = VETO - a rejected patch, and the reason VS> Q = QUERY - need more info VS> R = RECOMMEND - recommended for some version VS> PATCH - yep VS> Use the abbreviation in subjects, and the expanded form in the start of VS> the message body. <shameless-plug> 'patch-keywords.el' will do this for you automagically. </shameless-plug> -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|

|--==> "MS" == Martin Schwenke <martin(a)meltin.net&gt; writes: MS> OK, I'll do that before the first version gets committed. Will MS> someone else do the initial commit or will I? You can, once I've given you access. I'll give you a heads up when everything's set. -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|