[implementations-list] Welcome, Vegard, our newest committer

Jason Spiro jasonspiro3 at gmail.com
Sun Dec 27 20:46:35 CET 2009

On Fri, Dec 25, 2009 at 7:53 PM, Vegard Øye <vegard_oye at hotmail.com> wrote:

>> From: jasonspiro3 at gmail.com
>> 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

>> 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

> (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 :)

>> 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?  :)


More information about the implementations-list mailing list