[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orgmode] Org-mode and taskpaper

From: Russell Adams
Subject: Re: [Orgmode] Org-mode and taskpaper
Date: Tue, 1 Apr 2008 03:03:17 -0500
User-agent: Mutt/1.5.13 (2006-08-11)

On Tue, Apr 01, 2008 at 09:26:49AM +0200, Carsten Dominik wrote:
> Dear all,
> the recent discussion about Taskpaper in the thread started
> by Clint Laskowski has made me realize how much we have lost
> out way with Org-mode.  Org-mode was once a compact and
> easy tool just like taskpaper.  In fact, looking at the
> features of taskpaper, one might think that they had an older
> version of Org-mode as model and goal of their development.
> But in the meantime, mostly due to a mountain of demands
> from this group, it has become so bloated with mostly
> useless features, that all but the most geeky users are
> totally confused by this.
> Reading this thread has really cost me a lot of sleep, but
> I have now come to the conclusion that we need to turn
> the tide and downscope Org-mode significantly.  Luckily
> I have recently put much effort into splitting org.el
> into a number of separate files with separate features.
> This allows us a very simple and straight-forward path
> for this down-scoping effort.  I can simply try to remove
> one of these separate files after the other and then see
> how much complaining I will get for this.  In this way,
> we can make this process community-based, but I will
> need you to frequently update org-mode and to give me
> feedback during the process.
> Those of you who actively follow the git repository
> might have noticed that this morning I have started
> by removing org-table.el, the file containing the
> table editor.  Unfortunately this also means that the
> clocktable support no longer works, but I have always
> considered this as a sickening feature anyway, which
> tries to streamline our life, but in fact only leads to
> more work, and to more time taken away from spending with
> partners, kids and friends.
> I hope that you can all agree with my conclusion.  If not,
> than I am confident that with time you will realize
> just how important today's decision was.
> - Carsten


I certainly agree that refactoring the code to move blocks of
functionality into separate files makes perfect sense. Perhaps some of
the functions could be turned into "plugins" using appropriate hooks.

All successful projects suffer from feature creep. My opinion would be
that when drawing a line for the "core" feature set, ensure that any
existing features can continue to exist as a plugin, optionally
maintained separately. This can reduce the complexity and learning
curve for the core, while allowing us complexity junkies to tinker.

As to tables, I would miss them dearly. They aren't immediately
related to folding outlines or schedules, but I frequently use short
tables for summing information and the exported view is nice.

Perhaps you could post a list of the features you consider core, and
what items border on too complex that you want to trim. I think it
would make for interesting discussion.


Russell Adams                            address@hidden

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

reply via email to

[Prev in Thread] Current Thread [Next in Thread]