From: Karl Maihofer <ignoramus@gmx.de>
To: Nicolas Goaziou <n.goaziou@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Lists handling
Date: Sat, 27 Nov 2010 12:47:21 +0100 [thread overview]
Message-ID: <20101127124721.89832xmy1mxuwzwg@webmail.df.eu> (raw)
In-Reply-To: <28320_1290815524_oAQNq442028994_87wrnzhcde.wl%n.goaziou@gmail.com>
Hi Nicolas!
Thanks for your answer!
Nicolas Goaziou <n.goaziou@gmail.com> schrieb:
> Wouldn't drawers be more appropriate here than inline tasks? Not that
> it would work with a drawer either, but the examples given seem to
> focus more on content than on a task title.
In fact I have both, text comments and tasks that interrupt my lists.
So I think for me it is a more natural solution to use inline tasks. I
write my notes between the start- and end-line of an inline task. And
sometimes I then realize that there is something to take care of. So
the inline task gets a TODO-state. Without inline tasks withhin the
list I would have to add an extra inline task above or below the list.
But some of my lists are several pages long, so this would not be the
Org-way to define tasks (right there where the work had to be done).
Of course this is a special case. My lists do not contain my thoughts,
but a given structure. I have to comment this structure. And it should
be possible to differenciate between the lists and the comments in the
HTML export. All this worked quite well with inline tasks.
> I don't understand what the indentation problem you're talking about
> is, [...]
You are right, identation was the wrong word. I meant promoting and
demoting the current subtree with M-S-left or right arrow key. In the
example below if the cursor is on Item 1 and I hit M-S-right arrow key
Item 1a is demoted, but not Item 1b because of the inline task in
between.
,----
| - Item 1
| - Item 1a
| *************** Inline Task
| Here is text.
| *************** END
| - Item 1b
| - Item 2
| - Item 3
`----
This is a big issue for me because I will have to edit the structure
of the lists regularly. Until now this is not possible once I have
added my comments. And it would be much effort to cut the comments,
edit the structure and paste the comments again. So if promoting and
demoting would work in this structure it would be a big help in my case.
> [...] but I worked on indentation wrt inline tasks recently. My work is
> at: git://github.com/ngz/org-mode-lists.git inlinetask
> It might solve some of your problems.
I just checked out a copy and I'll have a look. Thanks for that. Did
you work on the demote/promote problem, too?
> I'm writing down ideas to put in a future update of lists. Some
> previously "unsupported anymore" stuff may appear again, after a phase
> of testing on a parallel git branch.
>
> In this context, you raise an interesting question about inline tasks.
> I have my idea (read below), but a discussion about it might be
> productive.
> It looks to me the syntax is way too subtle to be clear. Moreover,
> lists are all about indentation, and inline tasks defeat that as they
> live at column 0. They also visually break any structure around.
Perhaps syntax highlighting of inline tasks is an idea to solve the
visusl problem. If the inline task gets a background color one can
differentiate easier between the list and the task.
> To be honest, I'm not very enthusiastic about allowing inline tasks
> within lists. On the other hand, I will definitely let drawers in,
> thus my first question.
As pointed out above in my special case inline tasks would be a great
thing to have in lists. But I understand your reservation. It would be
an impurity withhin a list.
With a drawer, you mean something like the following?
,----
| - Item 1
| - Item 1a
| :COMMENT:
| This is a comment.
| :END:
| - Item 1b
| - Item 2
| - Item 3
`----
In my special case this would be second choice. But I think I could
live without tasks but with comments withhin lists when I change my
workflow a bit.
In HTML export it would then be important to be able to format the
comment with CSS. Right now my inline tasks get a nice border and a
colored background so that the comments can be recognized withhin the
lists. Would this be possible for drawers, too?
Regards,
Karl
next prev parent reply other threads:[~2010-11-27 11:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-26 18:16 Lists handling Karl Maihofer
2010-11-26 23:51 ` Nicolas Goaziou
[not found] ` <28320_1290815524_oAQNq442028994_87wrnzhcde.wl%n.goaziou@gmail.com>
2010-11-27 11:47 ` Karl Maihofer [this message]
2010-11-27 18:12 ` Nicolas Goaziou
2010-11-28 13:59 ` Carsten Dominik
2010-11-28 19:02 ` Eric S Fraga
[not found] ` <14003_1290970935_oASJ2FXi018046_87zkst5l1u.fsf@ucl.ac.uk>
2010-11-28 20:08 ` Karl Maihofer
[not found] ` <5367_1290881529_oARIC8fA005869_87vd3ihc0d.wl%n.goaziou@gmail.com>
2010-11-28 11:55 ` Karl Maihofer
2010-11-28 12:12 ` Nicolas Goaziou
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=20101127124721.89832xmy1mxuwzwg@webmail.df.eu \
--to=ignoramus@gmx.de \
--cc=emacs-orgmode@gnu.org \
--cc=n.goaziou@gmail.com \
/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).