[implementations-list] Welcome, Vegard, our newest committer (was: Helping to maintain Vimpulse)
On Wed, Dec 23, 2009 at 11:02 AM, Alessandro Piras <[email protected]> wrote:
it's ok for me. Alessandro Piras
Good. Vegard, thank you very much for offering to help. Vegard, the rest of this email is for you, but anyone else is free to read it also if they want. I added you as a Vimpulse "team member" on Assembla. Vimpulse's Assembla space (project page) is www.assembla.com/spaces/vimpulse. You should now be able to do anything you want in Trac and SVN. If I am wrong about this, please let me know. You can help us as much or as little as you want. After you do any patch reviewing or other work which gets included in Vimpulse, please add yourself to the Acknowledgements file. Since you're new, I think it'd be better if you not commit your own patch until at least one person other than you has tested it and told you it works for them on their version of *macs. This can be a friend or classmate of yours, or someone on IRC (Vimpulse has no IRC channel yet, but Emacs has one), or someone on the mailing list. Dear list: Would one of you please volunteer to test Vegard's patch and check that it works? You can do whatever else you like. Something useful, I think, would be to deal or help deal with open issues in Trac. But note that the lower issue numbers -- I don't remember which but maybe up to about #5 -- are old patches that I never got around to dealing with, and ended up forwarding the entire emails to Trac. They're probably bitrotted by now. They're probably more work to deal with. It might help to ask the original patch senders to fix them up so you can review and maybe commit. Ask them to resend as a patch to current SVN. When it's time to release a new version, type "make" to run the cat command listed in the Makefile, then copy and paste the entire contents of vimpulse-big.el into EmacsWiki. We release often. Release whenever you want. The steps to do include editing the version and Changelog top version, and testing to make sure that Vimpulse will load and work on your version of Emacs and XEmacs. Create an svn tag too. I think it would be best if every EmacsWiki version corresponded to some SVN numbered revision. After you release, bump the version in svn by adding "+svn" to its number. When you merge in any patch, you should edit Changelog and probably Acknowledgements. Always make a comment in SVN when you commit. Make svn commits often. If you want, just copy and paste your Changelog comment into the svn commit comments field. I use M-q in Emacs to re-wrap comments in the area at the top of the file. For changes adding or significantly removing a copyright-significant amount of code, you should also add a copyright line with the author's name to Copyright, and ask the author to agree that they will sign a FSF copyright assignment form if and when Vimpulse gets into Emacs. I don't remember anymore what "copyright-significant" means. Maybe the huge copyright-related mailing list thread from earlier this year contains an answer? I don't remember. Vimpulse has horrible documentation. Our documentation policy so far has unfortunately often been lax. I'm about to write a mail to the list about this problem. You may have lots of questions. Ask us whatever you want, and ask questions as often as you want. There's no such thing as a stupid question. :)
From: [email protected] Date: Wed, 23 Dec 2009 22:38:08 -0500
You can help us as much or as little as you want. After you do any patch reviewing or other work which gets included in Vimpulse, please add yourself to the Acknowledgements file.
Is it okay if I use the format below to avoid spam? Vegard Øye <vegard underline oye at hotmail dot com>
Since you're new, I think it'd be better if you not commit your own patch until at least one person other than you has tested it and told you it works for them on their version of *macs. This can be a friend or classmate of yours, or someone on IRC (Vimpulse has no IRC channel yet, but Emacs has one), or someone on the mailing list.
That's fair, but I don't know of anyone outside this mailing list who is using Emacs with Vim keys. (BTW, do you mean the "small fixes" patch I posted to the mailing list on 1 Dec, or vimpulse-modal.el?)
You can do whatever else you like. Something useful, I think, would be to deal or help deal with open issues in Trac.
Yes, I intend to start with the older ones. However, the current revision has problems of its own which also need attention -- see below.
Release whenever you want. The steps to do include editing the version and Changelog top version, and testing to make sure that Vimpulse will load and work on your version of Emacs and XEmacs.
The current SVN revision, 0.3.0+svn, does not work properly on neither Emacs nor XEmacs. XEmacs 21.4.22 complains of "Malformed list: :background" when executing (require 'vimpulse) in the *scratch* buffer, and Vimpulse is not loaded; try again, however, and it loads. But Visual mode doesn't work, as `make-overlay' is undefined in XEmacs. XEmacs doesn't have overlays, but something superficially similar called "extents", so any code for coloring text needs to written twice, it seems. As for GNU Emacs 23.1, the problems are more easy to fix: first, cl.el needs to be loaded, either by doing (require 'cl) before loading Vimpulse or prepending (eval-when-compile (require 'cl)) to Vimpulse's code. (In the long run, we should probably rid the code of all cl.el dependencies.) There's also a complaint of a free variable `vimpulse-last-yank' in vimpulse-visual-mode.el, but this is just a matter of moving all variable declarations to the beginning of the file, which is where they should be anyway. To sum up, I feel the above fixes for GNU Emacs are so trivial they should just be committed without further ado (but let me know if you disagree), but XEmacs is significantly more work (I don't know how much). I think XEmacs support will have to be put on hold for now, and returned to before release.
Create an svn tag too. I think it would be best if every EmacsWiki version corresponded to some SVN numbered revision. After you release, bump the version in svn by adding "+svn" to its number.
If I understand correctly, 0.3.0+svn is the working copy of 0.3.1 (or whatever number the next release will have). Should I make a tag copy of version 0.3.0, which is found on EmacsWiki?
I use M-q in Emacs to re-wrap comments in the area at the top of the file.
Yes, this keystroke is ingrained into my muscle memory. :)
I don't remember anymore what "copyright-significant" means. Maybe the huge copyright-related mailing list thread from earlier this year contains an answer? I don't remember.
IIRC, 15 lines is the "magic" number. So, for example, that the latest version of vimpulse-modal.el incorporates three lines from a certain XEmacs request thread is probably not significant. Happy holidays! Vegard Øye _________________________________________________________________ Nye Windows 7: PCen som passer for deg. Finn ut mer. http://windows.microsoft.com/shop
On Fri, Dec 25, 2009 at 7:53 PM, Vegard Øye <[email protected]> wrote:
From: [email protected] Date: Wed, 23 Dec 2009 22:38:08 -0500
You can help us as much or as little as you want. After you do any patch reviewing or other work which gets included in Vimpulse, please add yourself to the Acknowledgements file.
Is it okay if I use the format below to avoid spam?
Vegard Øye <vegard underline oye at hotmail dot com>
I think Vegard Øye <vegard_oye at hotmail dot com> would be less confusing. But you can use whatever format you want. IIRC I personally just use my name and a link to my webpage at the top of the file.
Since you're new, I think it'd be better if you not commit your own patch until at least one person other than you has tested it and told you it works for them on their version of *macs. This can be a friend or classmate of yours, or someone on IRC (Vimpulse has no IRC channel yet, but Emacs has one), or someone on the mailing list.
That's fair, but I don't know of anyone outside this mailing list who is using Emacs with Vim keys. (BTW, do you mean the "small fixes" patch I posted to the mailing list on 1 Dec, or vimpulse-modal.el?)
See my answer below.
You can do whatever else you like. Something useful, I think, would be to deal or help deal with open issues in Trac.
Yes, I intend to start with the older ones. However, the current revision has problems of its own which also need attention -- see below.
The older ones might be too bitrotted to be worth bothering with. :) By the way, in case you didn't know: Trac can send mail. Just add any email address to the Cc field. Don't add a name or angle brackets; it may cause problems. I have configured Trac to add a footnote to the bottom of every message telling people not to reply by email, as Trac ignores such replies.
Release whenever you want. The steps to do include editing the version and Changelog top version, and testing to make sure that Vimpulse will load and work on your version of Emacs and XEmacs.
The current SVN revision, 0.3.0+svn, does not work properly on neither Emacs nor XEmacs. XEmacs 21.4.22 complains of "Malformed list: :background" when executing (require 'vimpulse) in the *scratch* buffer, and Vimpulse is not loaded; try again, however, and it loads. But Visual mode doesn't work, as `make-overlay' is undefined in XEmacs. XEmacs doesn't have overlays, but something superficially similar called "extents", so any code for coloring text needs to written twice, it seems.
As for GNU Emacs 23.1, the problems are more easy to fix: first, cl.el needs to be loaded, either by doing (require 'cl) before loading Vimpulse or prepending (eval-when-compile (require 'cl)) to Vimpulse's code.
There was some discussion about cl.el on this list a few months ago. I don't remember what was concluded. Please read it before you do anything relating to cl.el; once you have read it, do whatever you want.
(In the long run, we should probably rid the code of all cl.el dependencies.)
That makes sense, as IIRC Richard Stallman doesn't like cl.el.
There's also a complaint of a free variable `vimpulse-last-yank' in vimpulse-visual-mode.el, but this is just a matter of moving all variable declarations to the beginning of the file, which is where they should be anyway.
To sum up, I feel the above fixes for GNU Emacs are so trivial they should just be committed without further ado (but let me know if you disagree)
You can always commit bug fixes without asking. :) My concern is that new features, like like vimpulse-modal
, but XEmacs is significantly more work (I don't know how much).
Ah, I didn't know how badly Vimpulse supports XEmacs now. I think XEmacs support will have to be put on hold for now, and
returned to before release.
OK. All your ideas sound good. I don't know what to say about XEmacs. Dear everyone-else, what do you think?
Create an svn tag too. I think it would be best if every EmacsWiki version corresponded to some SVN numbered revision. After you release, bump the version in svn by adding "+svn" to its number.
If I understand correctly, 0.3.0+svn is the working copy of 0.3.1 (or whatever number the next release will have).
Yes, you understand correctly.
Should I make a tag copy of version 0.3.0, which is found on EmacsWiki?
If you want to, you can; since that's an old version, if you don't want to bother, that's also fine. I don't remember; maybe it was me who forgot to make the tag copy last time :) [snip]
I don't remember anymore what "copyright-significant" means. Maybe the huge copyright-related mailing list thread from earlier this year contains an answer? I don't remember.
IIRC, 15 lines is the "magic" number. So, for example, that the latest version of vimpulse-modal.el incorporates three lines from a certain XEmacs request thread is probably not significant.
As far as I remember, the general rule is 10 lines, but sometimes the general rule doesn't apply. But maybe I remember wrong. I've never heard "15 lines". If you happen to remember offhand: Where did you hear that? :) Cheers, -Jason
I am replying to my own message with some followup comments. On Sun, Dec 27, 2009 at 2:46 PM, Jason Spiro <[email protected]> wrote:
On Fri, Dec 25, 2009 at 7:53 PM, Vegard Øye <[email protected]> wrote:
From: [email protected] Date: Wed, 23 Dec 2009 22:38:08 -0500
[snip]
As for GNU Emacs 23.1, the problems are more easy to fix: first, cl.el needs to be loaded, either by doing (require 'cl) before loading Vimpulse or prepending (eval-when-compile (require 'cl)) to Vimpulse's code.
There was some discussion about cl.el on this list a few months ago. I don't remember what was concluded. Please read it before you do anything relating to cl.el; once you have read it, do whatever you want.
Actually, I realize the discussion was a few years ago. You can read the discussion where I forwarded it, at http://my-trac.assembla.com/vimpulse/ticket/2 -- "[PATCH] rewrite viper-normalize-minor-mode-map-alist not to use cl.el's 'push' macro". [snip]
You can always commit bug fixes without asking. :) My concern is that new features, like like vimpulse-modal
The above is an incomplete paragraph. I meant to write the following paragraphs instead. You can always commit bug fixes without asking. :) Since you are new, and since I'm not an elisp expert, I don't know the quality of the new feature code you write. I'm going to leave it for Alessandro or anyone else on the list to review vimpulse-modal, which is your first feature patch, especially since I am no longer maintainer, and I am busy. But I know Alessandro is busy too. If you want, you can write a mail to the list with a subject line something like 'Call for a volunteer to review and test vimpulse-modal.el'. If anyone reviews it and tests it on any Emacs and says it is fine, you may commit it. If you called for a volunteer and nothing happened after a month, then that shows that Vimpulse is sorely lacking active maintainer power, and you can commit it yourself. Once vimpulse-modal has been committed, then you can commit whatever else you want. When I was maintainer, I insisted that Vimpulse should work just like Vim. If someone wrote a new Vimpulse feature that didn't work like Vim, I asked the submitter to get Vim to include that new functionality first. Now Alessandro is maintainer, and I don't know what his ideas about this are. * If Alessandro's ideas are like mine, then if you want to have features that Bram refuses to add to Vim, then you should start a project which consists of a set of addons to Vimpulse, and call it something like "vimpulse-addons", and maintain it. We won't mind. :) And you still will be able to contribute to Vimpulse. * If his ideas are not like mine, then do what he tells you to do. [snip] Kind regards, -Jason
From: [email protected] Date: Sun, 27 Dec 2009 16:51:15 -0500
There was some discussion about cl.el on this list a few months ago. I don't remember what was concluded. Please read it before you do anything relating to cl.el; once you have read it, do whatever you want.
Actually, I realize the discussion was a few years ago. You can read the discussion where I forwarded it, at http://my-trac.assembla.com/vimpulse/ticket/2 -- "[PATCH] rewrite viper-normalize-minor-mode-map-alist not to use cl.el's 'push' macro".
Here's my summary of the debate: 1. An extension cannot be included in GNU Emacs if it contains (require 'cl). 2. It may, however, contain (eval-when-compile (require 'cl)), which loads macros only. 3. In the long run, code depending on cl.el should be rewritten. Based on this, I'll add #2 to the code immediately, and put #3 on the TODO list.
Should I make a tag copy of version 0.3.0, which is found on EmacsWiki?
If you want to, you can; since that's an old version, if you don't want to bother, that's also fine. I don't remember; maybe it was me who forgot to make the tag copy last time :)
After some diffing, it seems that revision 14 is most similar to the one that's found on EmacsWiki (there's a docstring which is formatted slightly differently). I'll tag that.
I don't remember anymore what "copyright-significant" means.
IIRC, 15 lines is the "magic" number.
I've never heard "15 lines". If you happen to remember offhand: Where did you hear that? :)
From Donald R. Robertson, the FSF clerk, in a post forwarded to the mailing list in June:
It's not really an exact science. Copyright protects a somewhat nebulous idea known as expression, and that concept isn't necessarily tied to length of a work. A very short work, like say a poem, may contain copyrightable expression whereas a very long work, like a phone book, may not. A sort of rule of thumb that we use is that something less than 15 lines is unlikely to be copyright significant, while something more than 15 lines is more likely. In the end, the maintainer really has to look at the quality as well as quantity of the work and decide whether it's worth assigning or not.
http://lists.ourproject.org/pipermail/implementations-list/2009-June/000044.... Best regards, Vegard _________________________________________________________________ Få nye Windows Live™ Messenger. http://download.live.com/messenger
On Mon, Dec 28, 2009 at 11:55 AM, Vegard Øye <[email protected]> wrote:
Based on this, I'll add #2 to the code immediately, and put #3 on the TODO list.
Thank you. By the way, I haven't been using the TODO list stored in the file "TODO" lately; I've instead been using the bug tracker for all new ideas I've had. This lets other people submit ideas, and gives them equal billing with committers' ideas. But I wonder if the bug tracker is really best to use though.
After some diffing, it seems that revision 14 is most similar to the one that's found on EmacsWiki (there's a docstring which is formatted slightly differently). I'll tag that.
OK.
From Donald R. Robertson, the FSF clerk, in a post forwarded to the mailing list in June:
It's not really an exact science. Copyright protects a somewhat nebulous idea known as expression, and that concept isn't necessarily tied to length of a work. A very short work, like say a poem, may contain copyrightable expression whereas a very long work, like a phone book, may not. A sort of rule of thumb that we use is that something less than 15 lines is unlikely to be copyright significant, while something more than 15 lines is more likely. In the end, the maintainer really has to look at the quality as well as quantity of the work and decide whether it's worth assigning or not.
http://lists.ourproject.org/pipermail/implementations-list/2009-June/000044....
Ah, I must've remembered that email wrongly; I apologize for that. Thanks for refreshing my memory.
participants (2)
-
Jason Spiro -
Vegard Øye