all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* need advice about fixing up my new vimpact-mode, a Vim emulation mode based on viper-mode
@ 2007-02-19 10:37 Jason Spiro
  2007-02-19 15:49 ` Lennart Borgman (gmail)
  2007-02-19 21:59 ` Michael Kifer
  0 siblings, 2 replies; 5+ messages in thread
From: Jason Spiro @ 2007-02-19 10:37 UTC (permalink / raw
  To: help-gnu-emacs; +Cc: kifer

Hi help-gnu-emacs@gnu.org readers,

I have created a mode called vimpact-mode, a Vim emulation mode based
on viper-mode.  It is based mainly on snippets of code from around the
Web.  The pre-alpha is at:

http://www.jspiro.com/files/sw/vimpact-mode/vimpact-mode-0.0.1.el

I now have four questions.

Vimpact-mode is currently a major mode; that's bad.  (It uses
define-derived-mode, which unfortunately lets me make major modes
only.)  I want to make it into a minor mode, but I am not sure if I
should make it a derivative of viper-mode or if I should fork the
viper elisp files and distribute my mode's code.

Here are my design goals:

* I plan for all all viper and vimpact functions and customizable
variables to have the same prefix, "viper-".  I don't want some to
begin with "viper-" and some to begin with "vimpact-".  That'd be
confusing.

Question 1:  Do you think I am right: is my way better than the other
option of having a mix of prefixes?

* I'd prefer vimpact to be an add-on to viper, not a fork of it, since
I want vimpact to contain only vim-derived features, not all-new ones.

Question 2:  Do you think I am right about my add-on idea?  Or would
it be better if all or most of the vimpact-mode changes could somehow
be merged into viper-mode (perhaps I could do it)?

Question 3:  How much time would it take me, a mediocre elisp coder,
to make vimpact into a proper minor mode that starts up viper-mode
then adds the vimpact customizations (the add-on idea from before)?
How much time would it take me to merge the vimpact-mode changes into
the viper source code?

Question 4:  Considering that I am an elisp newbie, is anyone willing
to do the work themselves?  :-)  You then would be the maintainer of
vimpact-mode.

Thanks in advance,
Jason Spiro

-- 
Jason Spiro: computer consulting with a smile.
I also provide training and spyware removal services for homes and businesses.
Call or email for a FREE 5-minute consultation. Satisfaction guaranteed.
+1 (416) 781-5938 / Email: info@jspiro.com / MSN: jasonspiro@hotmail.com

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: need advice about fixing up my new vimpact-mode, a Vim emulation mode based on viper-mode
  2007-02-19 10:37 need advice about fixing up my new vimpact-mode, a Vim emulation mode based on viper-mode Jason Spiro
@ 2007-02-19 15:49 ` Lennart Borgman (gmail)
  2007-02-19 19:22   ` Jason Spiro
  2007-02-19 21:59 ` Michael Kifer
  1 sibling, 1 reply; 5+ messages in thread
From: Lennart Borgman (gmail) @ 2007-02-19 15:49 UTC (permalink / raw
  To: Jason Spiro; +Cc: help-gnu-emacs, kifer

Jason Spiro wrote:
> Hi help-gnu-emacs@gnu.org readers,


Hi Jason,

Nice to see you are interested in Viper.


> Here are my design goals:
> 
> * I plan for all all viper and vimpact functions and customizable
> variables to have the same prefix, "viper-".  I don't want some to
> begin with "viper-" and some to begin with "vimpact-".  That'd be
> confusing.
> 
> Question 1:  Do you think I am right: is my way better than the other
> option of having a mix of prefixes?


I think it would be better to use something like vimpact for the add-ons 
you make. But why not just vim- ?


> * I'd prefer vimpact to be an add-on to viper, not a fork of it, since
> I want vimpact to contain only vim-derived features, not all-new ones.
> 
> Question 2:  Do you think I am right about my add-on idea?  Or would
> it be better if all or most of the vimpact-mode changes could somehow
> be merged into viper-mode (perhaps I could do it)?


Yes, it must be an add-on and it can not be a major mode. (Merging with 
Viper would come much later when the add-on is stable and mature.)


> Question 3:  How much time would it take me, a mediocre elisp coder,
> to make vimpact into a proper minor mode that starts up viper-mode
> then adds the vimpact customizations (the add-on idea from before)?
> How much time would it take me to merge the vimpact-mode changes into
> the viper source code?


Maybe the biggest problem is that you may need to familiarize yourself 
with the latest version of Viper and maybe its code too.

And I believe it would be a merit if you understand how to get the 
add-ons working smoothly with Viper.


Are you using Emacs 22? This is not yet released, but stable and in late 
beta-test. It comes with Viper and I think Viper has been much improved 
in that version.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: need advice about fixing up my new vimpact-mode, a Vim emulation mode based on viper-mode
  2007-02-19 15:49 ` Lennart Borgman (gmail)
@ 2007-02-19 19:22   ` Jason Spiro
  0 siblings, 0 replies; 5+ messages in thread
From: Jason Spiro @ 2007-02-19 19:22 UTC (permalink / raw
  To: Lennart Borgman (gmail)
  Cc: jshawkin, spadgett1, kifer, brad.beveridge, help-gnu-emacs,
	Alessandro Piras, samuel.padgett

Hi Lennart,
Thanks for your reply before.

(Cc'ing some other individuals who have been active in the topic on
the mailing lists. Original thread is at
http://preview.tinyurl.com/2lcwpc or at
http://news.gmane.org/find-root.php?message_id=%3cc241693f0702190237s615bbef0p189b1b10516752cf%40mail.gmail.com%3e
 . If you prefer not to be CCed in the future, please tell me.)

2007/2/19, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:
> Jason Spiro wrote:
> > I have created a mode called vimpact-mode, a Vim emulation mode based
> > on viper-mode.  It is based mainly on snippets of code from around the
> > Web.  The pre-alpha is at:
> > http://www.jspiro.com/files/sw/vimpact-mode/vimpact-mode-0.0.1.el
...
> > Here are my design goals:
> >
> > * I plan for all all viper and vimpact functions and customizable
> > variables to have the same prefix, "viper-".  I don't want some to
> > begin with "viper-" and some to begin with "vimpact-".  That'd be
> > confusing.
> >
> > Question 1:  Do you think I am right: is my way better than the other
> > option of having a mix of prefixes?
>
> I think it would be better to use something like vimpact for the add-ons
> you make. But why not just vim- ?

IMO, vim- seems more obvious to learners since the mode is called
vimpact.  :-)  Why don't you think it would be best to use the single
prefix viper- for everything?

> > * I'd prefer vimpact to be an add-on to viper, not a fork of it, since
> > I want vimpact to contain only vim-derived features, not all-new ones.
> >
> > Question 2:  Do you think I am right about my add-on idea?  Or would
> > it be better if all or most of the vimpact-mode changes could somehow
> > be merged into viper-mode (perhaps I could do it)?
>
> Yes, it must be an add-on and it can not be a major mode. (Merging with
> Viper would come much later when the add-on is stable and mature.)

OK.  Would it be easier:

* if I fork Viper now then do a computer-assisted merge later,

* or if my mode, when it is loaded, loads viper and all its little
minor modes?  (Any later merge would then have to be manually done by
me.  I wonder if I'd ever get around to it.  :-)  )

> > Question 3:  How much time would it take me, a mediocre elisp coder,
> > to make vimpact into a proper minor mode that starts up viper-mode
> > then adds the vimpact customizations (the add-on idea from before)?
> > How much time would it take me to merge the vimpact-mode changes into
> > the viper source code?
>
> Maybe the biggest problem is that you may need to familiarize yourself
> with the latest version of Viper and maybe its code too.

OK, I guess I'll have to dig in. :-)  But do any of you know of any
good Emacs or viper hackers in my city (Toronto) by any chance?  Or
will there likely be any viper people at Ottawa Linux Symposium this
summer?

> And I believe it would be a merit if you understand how to get the
> add-ons working smoothly with Viper.

I'd be glad to hear people's feedback about how it works now, as well
as contributions  :-)  though I still have not done much work on it
yet.  Plus, I still want to merge in
http://common-lisp.net/project/vial/darcs/extended-viper/vimlike.el
which is by, I think, brad.beveridge@gmail.com and Alessandro Piras
<laynor@gmail.com>.

> Are you using Emacs 22? This is not yet released, but stable and in late
> beta-test. It comes with Viper and I think Viper has been much improved
> in that version.

I am using emacs-snapshot-gtk 1:20060915-1 from Ubuntu Edgy, a
5-month-old CVS snapshot.  Perhaps it is better if I upgrade to
version 1:20070217-1 from Debian's unstable repo?

Cheers,
Jason

-- 
Jason Spiro: computer consulting with a smile.
I also provide training and spyware removal services for homes and businesses.
Call or email for a FREE 5-minute consultation. Satisfaction guaranteed.
+1 (416) 781-5938 / Email: info@jspiro.com / MSN: jasonspiro@hotmail.com

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: need advice about fixing up my new vimpact-mode, a Vim emulation mode based on viper-mode
  2007-02-19 10:37 need advice about fixing up my new vimpact-mode, a Vim emulation mode based on viper-mode Jason Spiro
  2007-02-19 15:49 ` Lennart Borgman (gmail)
@ 2007-02-19 21:59 ` Michael Kifer
  2007-02-20 23:24   ` Jason Spiro
  1 sibling, 1 reply; 5+ messages in thread
From: Michael Kifer @ 2007-02-19 21:59 UTC (permalink / raw
  To: Jason Spiro; +Cc: help-gnu-emacs


"Jason Spiro" <jasonspiro4@gmail.com> writes:
>
> Hi help-gnu-emacs@gnu.org readers,
> 
> I have created a mode called vimpact-mode, a Vim emulation mode based
> on viper-mode.  It is based mainly on snippets of code from around the
> Web.  The pre-alpha is at:
> 
> http://www.jspiro.com/files/sw/vimpact-mode/vimpact-mode-0.0.1.el
> 
> I now have four questions.
> 
> Vimpact-mode is currently a major mode; that's bad.  (It uses
> define-derived-mode, which unfortunately lets me make major modes
> only.)  I want to make it into a minor mode, but I am not sure if I
> should make it a derivative of viper-mode or if I should fork the
> viper elisp files and distribute my mode's code.

Yes, for an editor emulator, I think, a major mode is close to unacceptable.
Viper used to be a major mode long time ago and there were too many
usability problems with that. Basically, too much of emacs functionality is
shut out by such a major mode.


> Here are my design goals:
> 
> * I plan for all all viper and vimpact functions and customizable
> variables to have the same prefix, "viper-".  I don't want some to
> begin with "viper-" and some to begin with "vimpact-".  That'd be
> confusing.
> 
> Question 1:  Do you think I am right: is my way better than the other
> option of having a mix of prefixes?

I think it is not acceptable to use the same prefix as some other package
unless your package can be logically considered an extension of that other
package. Even then it might be better to use a different prefix.

> * I'd prefer vimpact to be an add-on to viper, not a fork of it, since
> I want vimpact to contain only vim-derived features, not all-new ones.

Yes. In fact, why can't it be just another viper keymap?

> Question 2:  Do you think I am right about my add-on idea?  Or would
> it be better if all or most of the vimpact-mode changes could somehow
> be merged into viper-mode (perhaps I could do it)?

Eventually maybe. I haven't used vim extensively for a long time, but
what kind of essential functionality are you planning to add?


> Question 3:  How much time would it take me, a mediocre elisp coder,
> to make vimpact into a proper minor mode that starts up viper-mode
> then adds the vimpact customizations (the add-on idea from before)?
> How much time would it take me to merge the vimpact-mode changes into
> the viper source code?

Here is an algorithm to measure the time:

1. Start by implementing exactly 1/2 of the vimpact-mode functionality.
2. Carefully measure the time it took you to do this.
3. Multiply that amount by 2 (that is number "two").
4. Add 20% to the result to cover various eventualities.

:-)


> Question 4:  Considering that I am an elisp newbie, is anyone willing
> to do the work themselves?  :-)  You then would be the maintainer of
> vimpact-mode.

:-)


	cheers
	  --michael  


> Thanks in advance,
> Jason Spiro
> 
> -- 
> Jason Spiro: computer consulting with a smile.
> I also provide training and spyware removal services for homes and businesses.
> Call or email for a FREE 5-minute consultation. Satisfaction guaranteed.
> +1 (416) 781-5938 / Email: info@jspiro.com / MSN: jasonspiro@hotmail.com
> 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: need advice about fixing up my new vimpact-mode, a Vim emulation mode based on viper-mode
  2007-02-19 21:59 ` Michael Kifer
@ 2007-02-20 23:24   ` Jason Spiro
  0 siblings, 0 replies; 5+ messages in thread
From: Jason Spiro @ 2007-02-20 23:24 UTC (permalink / raw
  To: Michael Kifer
  Cc: jshawkin, spadgett1, brad.beveridge, help-gnu-emacs,
	Alessandro Piras, samuel.padgett

Hi Michael, thanks for replying.

A new development: After sending out this email, Alessandro mailed me
privately about his own vim emulation code. I will send it to you
privately and also to whoever wants. It is public domain license; I
hope to rename the code and post it on EmacsWiki.

But my questions below still apply :-)

2007/2/19, Michael Kifer <kifer@cs.sunysb.edu> wrote:
[snip]
> "Jason Spiro" <jasonspiro4@gmail.com> writes:
...
> > http://www.jspiro.com/files/sw/vimpact-mode/vimpact-mode-0.0.1.el
> ...
> I think it is not acceptable to use the same prefix as some other package
> unless your package can be logically considered an extension of that other
> package. Even then it might be better to use a different prefix.

Even though it can be confusing for users that a mode which is based
on another mode has 2 different prefixes? :-)

> Yes. In fact, why can't it be just another viper keymap?

Because I think users will contribute more changes if the official
source sits on the EmacsWiki. It's simply easier to make changes. And
easier to roll back bad changes. :-)

Emacs is cool in that it's the only app I know of where many plugins
are editable text sitting on a wiki.

> Eventually maybe. I haven't used vim extensively for a long time, but
> what kind of essential functionality are you planning to add?

A few examples:

* Point movement features, gg
* Scrolling features, zt zb zz
* Search for word features, * #
* Tags support, C-] and C-t
* Undo/redo, u C-r
* Window manipulation, C-wC-w, C-wo, C-wc
* Expand abbreviation, C-n
* Visual mode commands, v, o, O, d, y, c
* split, vsplit, bdelete, bn

> Here is an algorithm to measure the time:
>
> 1. Start by implementing exactly 1/2 of the vimpact-mode functionality.
> 2. Carefully measure the time it took you to do this.
> 3. Multiply that amount by 2 (that is number "two").
> 4. Add 20% to the result to cover various eventualities.
>
> :-)

haha

-- 
Jason Spiro: computer consulting with a smile.
I also provide training and spyware removal services for homes and businesses.
Call or email for a FREE 5-minute consultation. Satisfaction guaranteed.
+1 (416) 781-5938 / Email: info@jspiro.com / MSN: jasonspiro@hotmail.com

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2007-02-20 23:24 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-02-19 10:37 need advice about fixing up my new vimpact-mode, a Vim emulation mode based on viper-mode Jason Spiro
2007-02-19 15:49 ` Lennart Borgman (gmail)
2007-02-19 19:22   ` Jason Spiro
2007-02-19 21:59 ` Michael Kifer
2007-02-20 23:24   ` Jason Spiro

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.