[MonoDevelop] ChangeLog add-in patch

Lluis Sanchez lluis at ximian.com
Sun Nov 5 20:30:03 EST 2006


> and first of all, the due kudos to all monodevelop developers on this
> list. It is the best IDE available on Linux and that's all needed to
> say. Now to ChangeLog..


> When using emacs I find myself writing much more detailed ChangeLogs
> than when using MD, because MD's ChangeLog add-in is a little bit picky
> about when you can insert an entry or header. I have a patch that
> changes the default behaviour in the following ways:
> 1/ Just one command "Insert ChageLog Entry", an header is automatically
> added if missing or if the top-most header is different from the one
> we're about to add.
> 2/ The command can be issued from anywhere and the add-in looks for the
> right ChangeLog file and even creates one if necessary. It looks for
> ChangeLog in the current project, then in its parent combine and so on,
> up to the top-most combine. If no ChangeLog is found, one is created in
> the current project directory. So if you like a single top-level
> ChangeLog just create an empty one in the combine before adding the
> first entry, else let the plugin create one in the project for you.

> The code is quite dirty, I plan to clean it up and add a couple of
> features or two if you like the patch. The diff is for current HEAD,
> taken from the top directory (i.e., monodevelop) and attached to this
> email.

There are some indentation issues, but other than that it looks ok to

+ // TODO: Is there a better way to bring a new document to front?
+ IdeApp.Workbench.OpenDocument(document.FileName,

Yes: document.Select ()

Now, I'm improving right now the version control add-in and I think it
would be nice to integrate into it ChangeLog support. My idea is the
* Using the Status view the user can see what has changed in a
* In that view, it can select files that have changed and enter comments
about the change.
* When clicking on Commit, MD would collect all comments, update the
changelog file (following the same rules you propose) and commit using
the same comments as commit message.

I think this would save a lot of work.


More information about the Monodevelop-list mailing list