Emacs package management with org-mode

Emacs package management with org-mode

[andrea Crotti]

I was keeping a list of packages I use with emacs (here)
http://github.com/AndreaCrotti/Emacs-conf/blob/master/.emacs.d/README.txt

but now I had another idea, why don't create a table with org mode?

I thought a table like

| PACK | UPDATE CMD | REPO | COMMENT | RANK | CONF |

where
PACK: name and link
UPDATE CMD: command shell or elisp to give to update it
REPO: where is actually stored (could be a file or a directory)
CONF: my configuration file

So in this way in my dream if for example I want to update auto-complete
my function
- looks for it on the table
- cd to the right directory
- git pull the differences (and do other things as needed)

and I have all the informations in one table.

It's not so easy I guess but it maybe worth the effort, what do you think?
Thanks

Re: Emacs package management with org-mode

[David Maus]

Hi Andrea,

At Sat, 14 Nov 2009 18:35:28 +0000 (UTC),
andrea Crotti wrote:
> 
> I was keeping a list of packages I use with emacs (here)
> http://github.com/AndreaCrotti/Emacs-conf/blob/master/.emacs.d/README.txt
> 
> but now I had another idea, why don't create a table with org mode?
> 
> I thought a table like
> 
> | PACK | UPDATE CMD | REPO | COMMENT | RANK | CONF |
> 
> where
> PACK: name and link
> UPDATE CMD: command shell or elisp to give to update it
> REPO: where is actually stored (could be a file or a directory)
> CONF: my configuration file
> 
> So in this way in my dream if for example I want to update auto-complete
> my function
> - looks for it on the table
> - cd to the right directory
> - git pull the differences (and do other things as needed)
> 
> and I have all the informations in one table.
> 
> It's not so easy I guess but it maybe worth the effort, what do you think?
> Thanks

Interesting idea as this sounds as a nice way to manage
my list of remote repositories I am subscribed to. I cannot provide a
fully working solution (yet?) but after playing arround with column
view (Manual, Sec. 7.5) something like that could be a starting point:

,----
| * Repositories
|   :PROPERTIES:
|   :COLUMNS: %25ITEM %25Path %12LastUpdate
|   :END:
|         
|   #+BEGIN: columnview :hlines 1 :id local
|   | ITEM            | Path        | LastUpdate       |
|   |-----------------+-------------+------------------|
|   | * Repository    |             |                  |
|   | ** Repository 1 | /home/david | 2009-10-11 11:12 |
|   #+END:
|   
| ** Repository 1
|   :PROPERTIES:
|   :Path: /home/david
|   :LastUpdate: 2009-10-11 11:12
|   :END:
`----

Instead of using a table to *store* the information about the
repositories, use a dynamically created property view to display
repository information that are kept in headlines with the appropriate
properites.

So an update-function would process all "repository headlines"
(org-map-entry), read it's properties and act according to
them. Despite of simply executing an update command it seems to me
that wrapping common update commands (wget, git, hg etc.) in elisp
functions that call the program and parse it's output. For instance
one might find it useful to get notified if an update failed or, more
general, keep a condensed update log for each repository.

Regards,

  -- David

-- 
OpenPGP... 0x316F4BE4670716FD
Jabber.... dmjena@jabber.org
Email..... maus.david@gmail.com
ICQ....... 241051416