Development workflow

Development workflow

[Marcelo de Moraes Serpa]

[-- Attachment #1: Type: text/plain, Size: 380 bytes --]

Hey guys,

I'd like to start hacking the orgmode codebase and perhaps add my own
extensions and modifications. What's the best workflow? My main editor is
now MacVim, could I use it to edit and compile with emacs? I can understand
if things go smoother with emacs, and I could use viper if needed. I just
need to know how the overall hacking process look like.

Cheers,

Marcelo.

[-- Attachment #2: Type: text/html, Size: 452 bytes --]

Re: Development workflow

[Jambunathan K]

> Hey guys,
>
> I'd like to start hacking the orgmode codebase and perhaps add my own
> extensions and modifications. What's the best workflow? My main
> editor is now MacVim, could I use it to edit and compile with emacs?
> I can understand if things go smoother with emacs, and I could use
> viper if needed. I just need to know how the overall hacking process
> look like.

If you are comfortable with MacVim go with it. You don't have to compile
your elisp files at all and as a developer I would even venture to say
you shouldn't.

One's development workflow is well one's own and the only way to start
is to start with what one already knows and what one is already
comfortable with. In my experience, trying to be efficient while
starting out will remove the fun out of what you are doing.

If you are serious about your work, choose to work with the info/manuals
ONLY and use Google only as a supplement. Make a note of things as you
USE things so that you don't have to do it twice and keep organizing the
notes as it evolves. Good NOTE TAKING is a practical skill that will
help you in all endeavours.

Jambunathan K.

> Cheers,
>
> Marcelo.
>
>

-- 

Fwd: Development workflow

[Marcelo de Moraes Serpa]

[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]

Thanks Jambunathan, that's really some good advice. You're right, sometimes
we just postpone things because we think we should "get ready" for it.
Profound and true.

To make things easier though, I think I'll just go with Emacs + Vipermode
:)

Cheers,

Marcelo.
*
*

On Wed, Jul 27, 2011 at 11:32 PM, Jambunathan K <kjambunathan@gmail.com>wrote:

>
> > Hey guys,
> >
> > I'd like to start hacking the orgmode codebase and perhaps add my own
> > extensions and modifications. What's the best workflow? My main
> > editor is now MacVim, could I use it to edit and compile with emacs?
> > I can understand if things go smoother with emacs, and I could use
> > viper if needed. I just need to know how the overall hacking process
> > look like.
>
> If you are comfortable with MacVim go with it. You don't have to compile
> your elisp files at all and as a developer I would even venture to say
> you shouldn't.
>
> One's development workflow is well one's own and the only way to start
> is to start with what one already knows and what one is already
> comfortable with. In my experience, trying to be efficient while
> starting out will remove the fun out of what you are doing.
>
> If you are serious about your work, choose to work with the info/manuals
> ONLY and use Google only as a supplement. Make a note of things as you
> USE things so that you don't have to do it twice and keep organizing the
> notes as it evolves. Good NOTE TAKING is a practical skill that will
> help you in all endeavours.
>
> Jambunathan K.
>
> > Cheers,
> >
> > Marcelo.
> >
> >
>
> --
>

[-- Attachment #2: Type: text/html, Size: 2453 bytes --]

Re: Fwd: Development workflow

[Bastien]

Marcelo de Moraes Serpa <celoserpa@gmail.com> writes:

> Thanks Jambunathan, that's really some good advice. You're right,
> sometimes we just postpone things because we think we should "get
> ready" for it. Profound and true.

Indeed: http://vimeo.com/26415958

-- 
 Bastien

Re: Development workflow

[Bastien]

Hi Marcelo,

Jambunathan K <kjambunathan@gmail.com> writes:

> You don't have to compile your elisp files at all and as a developer I
> would even venture to say you shouldn't.

I also recommend not compiling your .el files, you will have more
useful debug traces (setq edebug-on-error t).

I would suggest reading the documentation of Edebug in the Elisp info
file.  M-x edebug-defun RET on functions will let you go through the
functions' evaluation step by step and understand better what they do
right (and wrong).

Also, please use git branches and send patch with git format-patch.

If you have comments about the code while reading through, please 
share them freely -- a longstanding wish of mine is to organize a 
live code review with core Org hackers:

  http://scientopia.org/blogs/goodmath/2011/07/06/things-everyone-should-do-code-review/

Good luck!

-- 
 Bastien