From: Carsten Dominik <firstname.lastname@example.org>
To: Eric S Fraga <email@example.com>
Cc: Emacs Org mode mailing list <firstname.lastname@example.org>
Subject: Re: advice: how to export a list without exporting all entries
Date: Thu, 24 Mar 2011 16:19:23 +0100 [thread overview]
Message-ID: <5E6F4851-F46B-42DB-9260-320244D45A77@gmail.com> (raw)
On 21.3.2011, at 10:16, Eric S Fraga wrote:
> I chair a particular committee at work and am responsible for keeping
> track of any actions that arise from our meetings. I use org for this
> (obviously ;-). So far, so good.
> I would like to move to a system in which all the actions are numbered
> sequentially. At present, they are numbered sequentially within a list
> for each meeting. I would like to have a single list which grows over
> time. However, when I distribute the minutes of the latest meeting, I
> would like to only have those actions which are not yet complete listed
> in the document I circulate. The complication is that I want those
> actions that have actually been done still in the list but not exported.
> Is there any way to /comment/ out individual list items (whether bullet
> or enumerated) on export? I export typically to latex but this need not
> be a constraint. Simply putting [ ] versus [X] boxes on the items is not
> satisfactory as the list would be very long if all items were included in
> the export.
> Is there some hook that I can intercept that would enable this? Can I
> encapsulate individual list items into latex macros with the status of
> the [ ] or [X] boxes? I am more than happy to write latex code as
> required! Or even, at a push, elisp code...
I guess you could use one of the export hooks to clean up your
exported file when you are done. However, the problem will always
be that if you take a list environment, the numbering of the list
items will change when you take out items. An I am sure you know
from experience how nice it is to be able to talk about the number
of an action item, in order to get everyone on the same page
quickly. I am afraid it will be hard to achieve this with the
path you are thinking about.
Defining and tracking action items through a series of meetings where
I have to do the notes is a frequent tasks for me. Here is my workflow
for this - maybe you can pick and choose some stuff for yourself.
In particular, I use outline nodes for tasks, in order to keep access
to the machinery Org gives me for tracking stuff.
1. I use a special Org file for each meeting series
2. In the file, I use the following setup (at the end of the file, for
the file variables):
* COMMENT SETUP
#+TODO: TODO | DELG CNCL DOME
#+EXPORT_EXCLUDE_TAGS: noexport closed
# Local Variables:
# org-todo-state-tags-triggers: ((done ("closed" . t)))
Your tags and TODO states may be different, of cause.
What is important here is that I define that some tags mark a
tree to be excluded from export. Also, I set a local value for
=org-todo-state-tags-triggers= which arranges for action items to
receive a "closed" tag when they are marked done. Since this tag
also excludes stuff from exporting, done items will automatically
not be exported.
3. I am not using an ordered list for the action items. Instead, I
give them explicit numbers, in the sequence in which I am defining
the actions. I am using some custom code (see end of this mail) to
create these actions with unique numbers. Running
`M-x org-maction-new-action' (this is `C-c n' in my setup) will
insert a new action that looks like this:
** TODO Action #2: :#2:
The action starts with "Action #2", and it is tagged by "#2" to that
I can tag other stuff relating to this action and search for it.
Once I mark this action as DONE, it will automatically become
** DONE Action #2: Do this and that :#2:Peter:closed:
In this way it will be excluded from export, unless you change
EXPORT_EXCLUDE_TAGS (remove the "closed" there) temporarily to
produce an export with all the DONE stuff included.
4. My workflow is then as follows:
a. For each meeting I start a new top-level section in the document
for the notes. In the notes I create new actions and leave them
there for the time being.
b. I also have a top-level section "ACTIONS" in the file. This
section contains all the actions from previous meetings, each
action identified by its unique number. I have this section
right after the meeting notes sections, so that I can easily
export the latest meeting notes together with the action list,
simply by selection the two sequential trees.
c. During the meeting, I create new actions inside the meeting
notes. I also tag each action with names of people who are
responsible for it, so that I can later easily make lists of
actions for individual people, to send around reminders.
d. After the meeting I export the current meeting notes and the
ACTIONS section (as a list of old actions) and send it around.
At this moment, I have the new actions only in the meeting
notes, and not in the general actions list, to highlight
them as new. Depending on your preferences, you could also do
(e) before sending out the notes.
e. When that is done, I *copy* the new actions from the last
meeting to the ACTIONS section. I organize this section, change
the sequence of actions, create subsections with related actions
together etc. For trivial task lists, the list just stays simple
and flat, but from complex consortia I do a lot of structuring
I then deactivate the actions in the meeting notes I just sent
around by marking the entire new notes tree with an ARCHIVE tag.
Then, TODO lists and other Agenda views will get entries from
the ACTIONS tree, not from the meeting notes. Instead of
copying, you could also *move* (refile) the actions to the
ACTIONS tree, but I like to keep them there (deactivated), so
that I have a copy of the notes exactly as sent around, in the
file. The idea is that the meeting notes are fixed, and all
procedural stuff with the actions will be added and tracked
in the ACTIONS tree.
f. Between meetings I use the ACTIONS tree to generate reminders
for people in the list, check DONE tasks off etc. Before the
next meeting, I create an agenda view to show me which actions
have been closed during the last period. I add this list to the
agenda for the next meeting to inform everyone about the stuff
that is closed and off the list. I also attach an export of the
current ACTIONS tree to the agenda, for reference during the
following meeting. The closed items will not be on that tree
anymore, because the export does not use items with the
"closed" tag. The nice thing (and I think this was Eric's
intent as well) is that the members of the meeting always have
an uncluttered list of actions, while you as the responsible
person still have all the old tags and the history at your
This has worked really well for me, both for meetings that happen
locally, and for meetings with international groups who meet via
Below you can find the (trivial) custom code I am using to create
new actions with unique identifying numbers.
With kind regards
Appendix: The meeting actions code
(defgroup org-mactions nil
"Meeting action items in Org mode."
:tag "Org MActions"
(defcustom org-maction-todo-keyword "TODO"
"Default TODO keyword for new meeting actions."
(defcustom org-maction-tag-prefix "#"
"Prefix for numbered action tags action tags"
(defcustom org-maction-action-format "Action #%d: "
"Default structure of the headling of a new action.
%d will become the number of the action."
(defun org-maction-new-number ()
"One plut the current highest action number."
(let ((re (concat "\\`" (regexp-quote org-maction-tag-prefix)
(1+ (apply 'max 0
(if (string-match re (car e))
(string-to-number (match-string 1 (car e)))
(defun org-maction-new-action ()
"Insert a new meeting action."
(let* ((num (org-maction-new-number))
(tag (concat org-maction-tag-prefix (number-to-string num))))
(org-insert-todo-heading nil 'force)
(unless (eql (char-before) ?\ ) (insert " "))
(insert (format org-maction-action-format num))
(org-toggle-tag tag 'on)
(if (= (point-max) (point-at-bol))
(save-excursion (goto-char (point-at-eol)) (insert "\n")))
(unless (eql (char-before) ?\ ) (insert " "))))
next prev parent reply other threads:[~2011-03-24 17:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-21 9:16 advice: how to export a list without exporting all entries Eric S Fraga
2011-03-23 17:29 ` Nicolas
2011-03-24 8:55 ` Eric S Fraga
2011-04-01 16:26 ` Nicolas
2011-04-01 16:52 ` Eric S Fraga
2011-04-01 20:20 ` Nicolas
2011-03-24 15:19 ` Carsten Dominik [this message]
2011-03-24 19:12 ` Eric S Fraga
2011-03-24 20:45 ` Eric S Fraga
2011-03-24 21:00 ` Carsten Dominik
2011-03-28 18:46 ` Carsten Dominik
2011-03-29 6:39 ` Eric S Fraga
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:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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
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).