From: Samuel Wales <samologist@gmail.com>
To: Karl Maihofer <ignoramus@gmx.de>
Cc: Nicolas Goaziou <n.goaziou@gmail.com>,
Eric S Fraga <ucecesf@ucl.ac.uk>,
emacs-orgmode@gnu.org,
Carsten Dominik <carsten.dominik@gmail.com>
Subject: Lists, headlines, inline tasks, etc. (Re: Lists handling)
Date: Sun, 28 Nov 2010 15:01:16 -0700 [thread overview]
Message-ID: <AANLkTi=gFM0nCjAFyLEd5Am9Pp6PRH-UsnX2PPcKVD=8@mail.gmail.com> (raw)
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.
reply other threads:[~2010-11-28 22:01 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='AANLkTi=gFM0nCjAFyLEd5Am9Pp6PRH-UsnX2PPcKVD=8@mail.gmail.com' \
--to=samologist@gmail.com \
--cc=carsten.dominik@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=ignoramus@gmx.de \
--cc=n.goaziou@gmail.com \
--cc=ucecesf@ucl.ac.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).