* Lists, headlines, inline tasks, etc. (Re: Lists handling)
@ 2010-11-28 22:01 Samuel Wales
0 siblings, 0 replies; only message in thread
From: Samuel Wales @ 2010-11-28 22:01 UTC (permalink / raw)
To: Karl Maihofer
Cc: Nicolas Goaziou, Eric S Fraga, emacs-orgmode, Carsten Dominik
Philosophically, or better, fundamentally, what are the
differences between headlines and lists? Haven't thought
about list syntax deeply, but for one, you can have text
before a list and then after it. For another, headlines
allow significant metadata.
Also, we have mechanisms, including the agenda, user code,
and even third-party stuff, that treat headlines specially.
Lists are typically (almost always) treated as text content
in .org files. Exporters treat lists as exported lists, of
course. Lists have checkboxes and bullet styles.
I think these things make lists different from headlines.
===
I am starting to favor inline tasks in lists, if it is
possible to implement. It keeps the concepts separate and
allows ALL properties of headlines. These include todo kw,
drawers, properties, tags, count and percent cookies,
priorities, headline coloring, other coloring, and existing
user code for headlines.
Somehow, actually, I sense the potential for constant bug fixes,
compatibility problems, version issues, surprise export
behavior, and regular expression issues over the next few
years if some of these are implemented in lists. I don't
think it's worth it. At least, that is my intuition.
Inline tasks are pretty much guaranteed to do the things we
want them to do. And they fit with the philosophy in org of
putting tasks in your notes exactly where you want them,
instead of keeping them separate. If you have a long list,
not allowing inline tasks in the list prevents that.
===
When I started with org, I thought lists might be an
extraneous concept; anything we want to do with them should
be done with headlines. But now that I have learned more
about org and exporting, I think it's a good idea to have
lists.
The fundamental principle in software that this raised, for
me, is the concept that if two things are similar enough,
they should be made the same, only parameterized. But we
are past the point of no return on lists. For example, we
can't implement lists and headlines with the same code. And
different code to do the same thing is just wrong. :)
Of course we should have list navigation and shifting
(promoting, demoting, moving) be analogous with headlines.
But that is behavior; it isn't a fundamental need for
parameterization.
I'd say, with my current knowledge of org, it seems much
better to allow inline tasks than to gradually make lists
more like headlines by adding todo kw and the like.
I know opinions vary on this (including Carsten's desire,
expressed long ago, to add todo kw to lists). And I don't need inline
tasks in lists.
And again I have not thought deeply about list syntax.
So consider it merely ideas for consideration.
Another possibility is to use ID markers, which you can insert
anywhere, can be made invisible for export, and can point to a real
task. But it's not quite the same thing as an inline task.
Samuel
--
Q: How many CDC "scientists" does it take to change a lightbulb?
A: "You only think it's dark." [CDC has denied a deadly serious
disease for 25 years]
==========
HIV-like virus: http://www.wpinstitute.org/xmrv/index.html -- PLEASE DONATE
===
I want to see the original (pre-hold) Lo et al. 2010 NIH/FDA/Harvard MLV paper.
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2010-11-28 22:01 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-11-28 22:01 Lists, headlines, inline tasks, etc. (Re: Lists handling) Samuel Wales
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).