22224 lines
		
	
	
		
			992 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			22224 lines
		
	
	
		
			992 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
This is org, produced by makeinfo version 4.13 from org.texi.
 | 
						||
 | 
						||
This manual is for Org version 8.3.6 (release_8.3.6-6-g194e51).
 | 
						||
 | 
						||
   Copyright (C) 2004-2016 Free Software Foundation, Inc.
 | 
						||
 | 
						||
     Permission is granted to copy, distribute and/or modify this
 | 
						||
     document under the terms of the GNU Free Documentation License,
 | 
						||
     Version 1.3 or any later version published by the Free Software
 | 
						||
     Foundation; with no Invariant Sections, with the Front-Cover Texts
 | 
						||
     being "A GNU Manual," and with the Back-Cover Texts as in (a)
 | 
						||
     below.  A copy of the license is included in the section entitled
 | 
						||
     "GNU Free Documentation License."
 | 
						||
 | 
						||
     (a) The FSF's Back-Cover Text is: "You have the freedom to copy and
 | 
						||
     modify this GNU manual."
 | 
						||
 | 
						||
INFO-DIR-SECTION Emacs editing modes
 | 
						||
START-INFO-DIR-ENTRY
 | 
						||
* Org Mode: (org).      Outline-based notes management and organizer
 | 
						||
END-INFO-DIR-ENTRY
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Top,  Next: Introduction,  Prev: (dir),  Up: (dir)
 | 
						||
 | 
						||
Org Mode Manual
 | 
						||
***************
 | 
						||
 | 
						||
This manual is for Org version 8.3.6 (release_8.3.6-6-g194e51).
 | 
						||
 | 
						||
   Copyright (C) 2004-2016 Free Software Foundation, Inc.
 | 
						||
 | 
						||
     Permission is granted to copy, distribute and/or modify this
 | 
						||
     document under the terms of the GNU Free Documentation License,
 | 
						||
     Version 1.3 or any later version published by the Free Software
 | 
						||
     Foundation; with no Invariant Sections, with the Front-Cover Texts
 | 
						||
     being "A GNU Manual," and with the Back-Cover Texts as in (a)
 | 
						||
     below.  A copy of the license is included in the section entitled
 | 
						||
     "GNU Free Documentation License."
 | 
						||
 | 
						||
     (a) The FSF's Back-Cover Text is: "You have the freedom to copy and
 | 
						||
     modify this GNU manual."
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Introduction::                Getting started
 | 
						||
* Document structure::          A tree works like your brain
 | 
						||
* Tables::                      Pure magic for quick formatting
 | 
						||
* Hyperlinks::                  Notes in context
 | 
						||
* TODO items::                  Every tree branch can be a TODO item
 | 
						||
* Tags::                        Tagging headlines and matching sets of tags
 | 
						||
* Properties and columns::      Storing information about an entry
 | 
						||
* Dates and times::             Making items useful for planning
 | 
						||
* Capture - Refile - Archive::  The ins and outs for projects
 | 
						||
* Agenda views::                Collecting information into views
 | 
						||
* Markup::                      Prepare text for rich export
 | 
						||
* Exporting::                   Sharing and publishing notes
 | 
						||
* Publishing::                  Create a web site of linked Org files
 | 
						||
* Working with source code::    Export, evaluate, and tangle code blocks
 | 
						||
* Miscellaneous::               All the rest which did not fit elsewhere
 | 
						||
* Hacking::                     How to hack your way around
 | 
						||
* MobileOrg::                   Viewing and capture on a mobile device
 | 
						||
* History and acknowledgments::  How Org came into being
 | 
						||
* GNU Free Documentation License::  The license for this documentation.
 | 
						||
* Main Index::                  An index of Org's concepts and features
 | 
						||
* Key Index::                   Key bindings and where they are described
 | 
						||
* Command and Function Index::  Command names and some internal functions
 | 
						||
* Variable Index::              Variables mentioned in the manual
 | 
						||
 | 
						||
 --- The Detailed Node Listing ---
 | 
						||
 | 
						||
Introduction
 | 
						||
 | 
						||
* Summary::                     Brief summary of what Org does
 | 
						||
* Installation::                Installing Org
 | 
						||
* Activation::                  How to activate Org for certain buffers
 | 
						||
* Feedback::                    Bug reports, ideas, patches etc.
 | 
						||
* Conventions::                 Typesetting conventions in the manual
 | 
						||
 | 
						||
Document structure
 | 
						||
 | 
						||
* Outlines::                    Org is based on Outline mode
 | 
						||
* Headlines::                   How to typeset Org tree headlines
 | 
						||
* Visibility cycling::          Show and hide, much simplified
 | 
						||
* Motion::                      Jumping to other headlines
 | 
						||
* Structure editing::           Changing sequence and level of headlines
 | 
						||
* Sparse trees::                Matches embedded in context
 | 
						||
* Plain lists::                 Additional structure within an entry
 | 
						||
* Drawers::                     Tucking stuff away
 | 
						||
* Blocks::                      Folding blocks
 | 
						||
* Footnotes::                   How footnotes are defined in Org's syntax
 | 
						||
* Orgstruct mode::              Structure editing outside Org
 | 
						||
* Org syntax::                  Formal description of Org's syntax
 | 
						||
 | 
						||
Visibility cycling
 | 
						||
 | 
						||
* Global and local cycling::    Cycling through various visibility states
 | 
						||
* Initial visibility::          Setting the initial visibility state
 | 
						||
* Catching invisible edits::    Preventing mistakes when editing invisible parts
 | 
						||
 | 
						||
Tables
 | 
						||
 | 
						||
* Built-in table editor::       Simple tables
 | 
						||
* Column width and alignment::  Overrule the automatic settings
 | 
						||
* Column groups::               Grouping to trigger vertical lines
 | 
						||
* Orgtbl mode::                 The table editor as minor mode
 | 
						||
* The spreadsheet::             The table editor has spreadsheet capabilities
 | 
						||
* Org-Plot::                    Plotting from org tables
 | 
						||
 | 
						||
The spreadsheet
 | 
						||
 | 
						||
* References::                  How to refer to another field or range
 | 
						||
* Formula syntax for Calc::     Using Calc to compute stuff
 | 
						||
* Formula syntax for Lisp::     Writing formulas in Emacs Lisp
 | 
						||
* Durations and time values::   How to compute durations and time values
 | 
						||
* Field and range formulas::    Formula for specific (ranges of) fields
 | 
						||
* Column formulas::             Formulas valid for an entire column
 | 
						||
* Lookup functions::            Lookup functions for searching tables
 | 
						||
* Editing and debugging formulas::  Fixing formulas
 | 
						||
* Updating the table::          Recomputing all dependent fields
 | 
						||
* Advanced features::           Field and column names, parameters and automatic recalc
 | 
						||
 | 
						||
Hyperlinks
 | 
						||
 | 
						||
* Link format::                 How links in Org are formatted
 | 
						||
* Internal links::              Links to other places in the current file
 | 
						||
* External links::              URL-like links to the world
 | 
						||
* Handling links::              Creating, inserting and following
 | 
						||
* Using links outside Org::     Linking from my C source code?
 | 
						||
* Link abbreviations::          Shortcuts for writing complex links
 | 
						||
* Search options::              Linking to a specific location
 | 
						||
* Custom searches::             When the default search is not enough
 | 
						||
 | 
						||
Internal links
 | 
						||
 | 
						||
* Radio targets::               Make targets trigger links in plain text
 | 
						||
 | 
						||
TODO items
 | 
						||
 | 
						||
* TODO basics::                 Marking and displaying TODO entries
 | 
						||
* TODO extensions::             Workflow and assignments
 | 
						||
* Progress logging::            Dates and notes for progress
 | 
						||
* Priorities::                  Some things are more important than others
 | 
						||
* Breaking down tasks::         Splitting a task into manageable pieces
 | 
						||
* Checkboxes::                  Tick-off lists
 | 
						||
 | 
						||
Extended use of TODO keywords
 | 
						||
 | 
						||
* Workflow states::             From TODO to DONE in steps
 | 
						||
* TODO types::                  I do this, Fred does the rest
 | 
						||
* Multiple sets in one file::   Mixing it all, and still finding your way
 | 
						||
* Fast access to TODO states::  Single letter selection of a state
 | 
						||
* Per-file keywords::           Different files, different requirements
 | 
						||
* Faces for TODO keywords::     Highlighting states
 | 
						||
* TODO dependencies::           When one task needs to wait for others
 | 
						||
 | 
						||
Progress logging
 | 
						||
 | 
						||
* Closing items::               When was this entry marked DONE?
 | 
						||
* Tracking TODO state changes::  When did the status change?
 | 
						||
* Tracking your habits::        How consistent have you been?
 | 
						||
 | 
						||
Tags
 | 
						||
 | 
						||
* Tag inheritance::             Tags use the tree structure of the outline
 | 
						||
* Setting tags::                How to assign tags to a headline
 | 
						||
* Tag hierarchy::               Create a hierarchy of tags
 | 
						||
* Tag searches::                Searching for combinations of tags
 | 
						||
 | 
						||
Properties and columns
 | 
						||
 | 
						||
* Property syntax::             How properties are spelled out
 | 
						||
* Special properties::          Access to other Org mode features
 | 
						||
* Property searches::           Matching property values
 | 
						||
* Property inheritance::        Passing values down the tree
 | 
						||
* Column view::                 Tabular viewing and editing
 | 
						||
* Property API::                Properties for Lisp programmers
 | 
						||
 | 
						||
Column view
 | 
						||
 | 
						||
* Defining columns::            The COLUMNS format property
 | 
						||
* Using column view::           How to create and use column view
 | 
						||
* Capturing column view::       A dynamic block for column view
 | 
						||
 | 
						||
Defining columns
 | 
						||
 | 
						||
* Scope of column definitions::  Where defined, where valid?
 | 
						||
* Column attributes::           Appearance and content of a column
 | 
						||
 | 
						||
Dates and times
 | 
						||
 | 
						||
* Timestamps::                  Assigning a time to a tree entry
 | 
						||
* Creating timestamps::         Commands which insert timestamps
 | 
						||
* Deadlines and scheduling::    Planning your work
 | 
						||
* Clocking work time::          Tracking how long you spend on a task
 | 
						||
* Effort estimates::            Planning work effort in advance
 | 
						||
* Timers::                      Notes with a running timer
 | 
						||
 | 
						||
Creating timestamps
 | 
						||
 | 
						||
* The date/time prompt::        How Org mode helps you entering date and time
 | 
						||
* Custom time format::          Making dates look different
 | 
						||
 | 
						||
Deadlines and scheduling
 | 
						||
 | 
						||
* Inserting deadline/schedule::  Planning items
 | 
						||
* Repeated tasks::              Items that show up again and again
 | 
						||
 | 
						||
Clocking work time
 | 
						||
 | 
						||
* Clocking commands::           Starting and stopping a clock
 | 
						||
* The clock table::             Detailed reports
 | 
						||
* Resolving idle time::         Resolving time when you've been idle
 | 
						||
 | 
						||
Capture - Refile - Archive
 | 
						||
 | 
						||
* Capture::                     Capturing new stuff
 | 
						||
* Attachments::                 Add files to tasks
 | 
						||
* RSS feeds::                   Getting input from RSS feeds
 | 
						||
* Protocols::                   External (e.g., Browser) access to Emacs and Org
 | 
						||
* Refile and copy::             Moving/copying a tree from one place to another
 | 
						||
* Archiving::                   What to do with finished projects
 | 
						||
 | 
						||
Capture
 | 
						||
 | 
						||
* Setting up capture::          Where notes will be stored
 | 
						||
* Using capture::               Commands to invoke and terminate capture
 | 
						||
* Capture templates::           Define the outline of different note types
 | 
						||
 | 
						||
Capture templates
 | 
						||
 | 
						||
* Template elements::           What is needed for a complete template entry
 | 
						||
* Template expansion::          Filling in information about time and context
 | 
						||
* Templates in contexts::       Only show a template in a specific context
 | 
						||
 | 
						||
Archiving
 | 
						||
 | 
						||
* Moving subtrees::             Moving a tree to an archive file
 | 
						||
* Internal archiving::          Switch off a tree but keep it in the file
 | 
						||
 | 
						||
Agenda views
 | 
						||
 | 
						||
* Agenda files::                Files being searched for agenda information
 | 
						||
* Agenda dispatcher::           Keyboard access to agenda views
 | 
						||
* Built-in agenda views::       What is available out of the box?
 | 
						||
* Presentation and sorting::    How agenda items are prepared for display
 | 
						||
* Agenda commands::             Remote editing of Org trees
 | 
						||
* Custom agenda views::         Defining special searches and views
 | 
						||
* Exporting agenda views::      Writing a view to a file
 | 
						||
* Agenda column view::          Using column view for collected entries
 | 
						||
 | 
						||
The built-in agenda views
 | 
						||
 | 
						||
* Weekly/daily agenda::         The calendar page with current tasks
 | 
						||
* Global TODO list::            All unfinished action items
 | 
						||
* Matching tags and properties::  Structured information with fine-tuned search
 | 
						||
* Timeline::                    Time-sorted view for single file
 | 
						||
* Search view::                 Find entries by searching for text
 | 
						||
* Stuck projects::              Find projects you need to review
 | 
						||
 | 
						||
Presentation and sorting
 | 
						||
 | 
						||
* Categories::                  Not all tasks are equal
 | 
						||
* Time-of-day specifications::  How the agenda knows the time
 | 
						||
* Sorting agenda items::        The order of things
 | 
						||
* Filtering/limiting agenda items::  Dynamically narrow the agenda
 | 
						||
 | 
						||
Custom agenda views
 | 
						||
 | 
						||
* Storing searches::            Type once, use often
 | 
						||
* Block agenda::                All the stuff you need in a single buffer
 | 
						||
* Setting options::             Changing the rules
 | 
						||
 | 
						||
Markup for rich export
 | 
						||
 | 
						||
* Structural markup elements::  The basic structure as seen by the exporter
 | 
						||
* Images and tables::           Images, tables and caption mechanism
 | 
						||
* Literal examples::            Source code examples with special formatting
 | 
						||
* Include files::               Include additional files into a document
 | 
						||
* Index entries::               Making an index
 | 
						||
* Macro replacement::           Use macros to create templates
 | 
						||
* Embedded LaTeX::           LaTeX can be freely used inside Org documents
 | 
						||
* Special blocks::              Containers targeted at export back-ends
 | 
						||
 | 
						||
Structural markup elements
 | 
						||
 | 
						||
* Document title::              Where the title is taken from
 | 
						||
* Headings and sections::       The document structure as seen by the exporter
 | 
						||
* Table of contents::           The if and where of the table of contents
 | 
						||
* Lists::                       Lists
 | 
						||
* Paragraphs::                  Paragraphs
 | 
						||
* Footnote markup::             Footnotes
 | 
						||
* Emphasis and monospace::      Bold, italic, etc.
 | 
						||
* Horizontal rules::            Make a line
 | 
						||
* Comment lines::               What will *not* be exported
 | 
						||
 | 
						||
Embedded LaTeX
 | 
						||
 | 
						||
* Special symbols::             Greek letters and other symbols
 | 
						||
* Subscripts and superscripts::  Simple syntax for raising/lowering text
 | 
						||
* LaTeX fragments::          Complex formulas made easy
 | 
						||
* Previewing LaTeX fragments::  What will this snippet look like?
 | 
						||
* CDLaTeX mode::                Speed up entering of formulas
 | 
						||
 | 
						||
Exporting
 | 
						||
 | 
						||
* The export dispatcher::       The main exporter interface
 | 
						||
* Export back-ends::            Built-in export formats
 | 
						||
* Export settings::             Generic export settings
 | 
						||
* ASCII/Latin-1/UTF-8 export::  Exporting to flat files with encoding
 | 
						||
* Beamer export::               Exporting as a Beamer presentation
 | 
						||
* HTML export::                 Exporting to HTML
 | 
						||
* LaTeX and PDF export::     Exporting to LaTeX, and processing to PDF
 | 
						||
* Markdown export::             Exporting to Markdown
 | 
						||
* OpenDocument Text export::    Exporting to OpenDocument Text
 | 
						||
* Org export::                  Exporting to Org
 | 
						||
* Texinfo export::              Exporting to Texinfo
 | 
						||
* iCalendar export::            Exporting to iCalendar
 | 
						||
* Other built-in back-ends::    Exporting to a man page
 | 
						||
* Export in foreign buffers::   Author tables and lists in Org syntax
 | 
						||
* Advanced configuration::      Fine-tuning the export output
 | 
						||
 | 
						||
HTML export
 | 
						||
 | 
						||
* HTML Export commands::        How to invoke HTML export
 | 
						||
* HTML doctypes::               Org can export to various (X)HTML flavors
 | 
						||
* HTML preamble and postamble::  How to insert a preamble and a postamble
 | 
						||
* Quoting HTML tags::           Using direct HTML in Org mode
 | 
						||
* Links in HTML export::        How links will be interpreted and formatted
 | 
						||
* Tables in HTML export::       How to modify the formatting of tables
 | 
						||
* Images in HTML export::       How to insert figures into HTML output
 | 
						||
* Math formatting in HTML export::  Beautiful math also on the web
 | 
						||
* Text areas in HTML export::   An alternative way to show an example
 | 
						||
* CSS support::                 Changing the appearance of the output
 | 
						||
* JavaScript support::          Info and Folding in a web browser
 | 
						||
 | 
						||
LaTeX and PDF export
 | 
						||
 | 
						||
* LaTeX export commands::    How to export to LaTeX and PDF
 | 
						||
* Header and sectioning::       Setting up the export file structure
 | 
						||
* Quoting LaTeX code::       Incorporating literal LaTeX code
 | 
						||
* LaTeX specific attributes::  Controlling LaTeX output
 | 
						||
 | 
						||
OpenDocument text export
 | 
						||
 | 
						||
* Pre-requisites for ODT export::  What packages ODT exporter relies on
 | 
						||
* ODT export commands::         How to invoke ODT export
 | 
						||
* Extending ODT export::        How to produce `doc', `pdf' files
 | 
						||
* Applying custom styles::      How to apply custom styles to the output
 | 
						||
* Links in ODT export::         How links will be interpreted and formatted
 | 
						||
* Tables in ODT export::        How Tables are exported
 | 
						||
* Images in ODT export::        How to insert images
 | 
						||
* Math formatting in ODT export::  How LaTeX fragments are formatted
 | 
						||
* Labels and captions in ODT export::  How captions are rendered
 | 
						||
* Literal examples in ODT export::  How source and example blocks are formatted
 | 
						||
* Advanced topics in ODT export::  Read this if you are a power user
 | 
						||
 | 
						||
Math formatting in ODT export
 | 
						||
 | 
						||
* Working with LaTeX math snippets::  How to embed LaTeX math fragments
 | 
						||
* Working with MathML or OpenDocument formula files::  How to embed equations in native format
 | 
						||
 | 
						||
Advanced topics in ODT export
 | 
						||
 | 
						||
* Configuring a document converter::  How to register a document converter
 | 
						||
* Working with OpenDocument style files::  Explore the internals
 | 
						||
* Creating one-off styles::     How to produce custom highlighting etc
 | 
						||
* Customizing tables in ODT export::  How to define and use Table templates
 | 
						||
* Validating OpenDocument XML::  How to debug corrupt OpenDocument files
 | 
						||
 | 
						||
Texinfo export
 | 
						||
 | 
						||
* Texinfo export commands::     How to invoke Texinfo export
 | 
						||
* Document preamble::           File header, title and copyright page
 | 
						||
* Headings and sectioning structure:: Building document structure
 | 
						||
* Indices::                     Creating indices
 | 
						||
* Quoting Texinfo code::        Incorporating literal Texinfo code
 | 
						||
* Texinfo specific attributes:: Controlling Texinfo output
 | 
						||
* An example::
 | 
						||
 | 
						||
Publishing
 | 
						||
 | 
						||
* Configuration::               Defining projects
 | 
						||
* Uploading files::             How to get files up on the server
 | 
						||
* Sample configuration::        Example projects
 | 
						||
* Triggering publication::      Publication commands
 | 
						||
 | 
						||
Configuration
 | 
						||
 | 
						||
* Project alist::               The central configuration variable
 | 
						||
* Sources and destinations::    From here to there
 | 
						||
* Selecting files::             What files are part of the project?
 | 
						||
* Publishing action::           Setting the function doing the publishing
 | 
						||
* Publishing options::          Tweaking HTML/LaTeX export
 | 
						||
* Publishing links::            Which links keep working after publishing?
 | 
						||
* Sitemap::                     Generating a list of all pages
 | 
						||
* Generating an index::         An index that reaches across pages
 | 
						||
 | 
						||
Sample configuration
 | 
						||
 | 
						||
* Simple example::              One-component publishing
 | 
						||
* Complex example::             A multi-component publishing example
 | 
						||
 | 
						||
Working with source code
 | 
						||
 | 
						||
* Structure of code blocks::    Code block syntax described
 | 
						||
* Editing source code::         Language major-mode editing
 | 
						||
* Exporting code blocks::       Export contents and/or results
 | 
						||
* Extracting source code::      Create pure source code files
 | 
						||
* Evaluating code blocks::      Place results of evaluation in the Org mode buffer
 | 
						||
* Library of Babel::            Use and contribute to a library of useful code blocks
 | 
						||
* Languages::                   List of supported code block languages
 | 
						||
* Header arguments::            Configure code block functionality
 | 
						||
* Results of evaluation::       How evaluation results are handled
 | 
						||
* Noweb reference syntax::      Literate programming in Org mode
 | 
						||
* Key bindings and useful functions::  Work quickly with code blocks
 | 
						||
* Batch execution::             Call functions from the command line
 | 
						||
 | 
						||
Header arguments
 | 
						||
 | 
						||
* Using header arguments::      Different ways to set header arguments
 | 
						||
* Specific header arguments::   List of header arguments
 | 
						||
 | 
						||
Using header arguments
 | 
						||
 | 
						||
* System-wide header arguments::  Set global default values
 | 
						||
* Language-specific header arguments::  Set default values by language
 | 
						||
* Header arguments in Org mode properties::  Set default values for a buffer or heading
 | 
						||
* Language-specific header arguments in Org mode properties::  Set language-specific default values for a buffer or heading
 | 
						||
* Code block specific header arguments::  The most common way to set values
 | 
						||
* Header arguments in function calls::  The most specific level
 | 
						||
 | 
						||
Specific header arguments
 | 
						||
 | 
						||
* var::                         Pass arguments to code blocks
 | 
						||
* results::                     Specify the type of results and how they will
 | 
						||
                                be collected and handled
 | 
						||
* file::                        Specify a path for file output
 | 
						||
* file-desc::                   Specify a description for file results
 | 
						||
* dir::                         Specify the default (possibly remote)
 | 
						||
                                directory for code block execution
 | 
						||
* exports::                     Export code and/or results
 | 
						||
* tangle::                      Toggle tangling and specify file name
 | 
						||
* mkdirp::                      Toggle creation of parent directories of target
 | 
						||
                                files during tangling
 | 
						||
* comments::                    Toggle insertion of comments in tangled
 | 
						||
                                code files
 | 
						||
* padline::                     Control insertion of padding lines in tangled
 | 
						||
                                code files
 | 
						||
* no-expand::                   Turn off variable assignment and noweb
 | 
						||
                                expansion during tangling
 | 
						||
* session::                     Preserve the state of code evaluation
 | 
						||
* noweb::                       Toggle expansion of noweb references
 | 
						||
* noweb-ref::                   Specify block's noweb reference resolution target
 | 
						||
* noweb-sep::                   String used to separate noweb references
 | 
						||
* cache::                       Avoid re-evaluating unchanged code blocks
 | 
						||
* sep::                         Delimiter for writing tabular results outside Org
 | 
						||
* hlines::                      Handle horizontal lines in tables
 | 
						||
* colnames::                    Handle column names in tables
 | 
						||
* rownames::                    Handle row names in tables
 | 
						||
* shebang::                     Make tangled files executable
 | 
						||
* tangle-mode::                 Set permission of tangled files
 | 
						||
* eval::                        Limit evaluation of specific code blocks
 | 
						||
* wrap::                        Mark source block evaluation results
 | 
						||
* post::                        Post processing of code block results
 | 
						||
* prologue::                    Text to prepend to code block body
 | 
						||
* epilogue::                    Text to append to code block body
 | 
						||
 | 
						||
Miscellaneous
 | 
						||
 | 
						||
* Completion::                  M-TAB knows what you need
 | 
						||
* Easy templates::              Quick insertion of structural elements
 | 
						||
* Speed keys::                  Electric commands at the beginning of a headline
 | 
						||
* Code evaluation security::    Org mode files evaluate inline code
 | 
						||
* Customization::               Adapting Org to your taste
 | 
						||
* In-buffer settings::          Overview of the #+KEYWORDS
 | 
						||
* The very busy C-c C-c key::   When in doubt, press C-c C-c
 | 
						||
* Clean view::                  Getting rid of leading stars in the outline
 | 
						||
* TTY keys::                    Using Org on a tty
 | 
						||
* Interaction::                 Other Emacs packages
 | 
						||
* org-crypt::                   Encrypting Org files
 | 
						||
 | 
						||
Interaction with other packages
 | 
						||
 | 
						||
* Cooperation::                 Packages Org cooperates with
 | 
						||
* Conflicts::                   Packages that lead to conflicts
 | 
						||
 | 
						||
Hacking
 | 
						||
 | 
						||
* Hooks::                       How to reach into Org's internals
 | 
						||
* Add-on packages::             Available extensions
 | 
						||
* Adding hyperlink types::      New custom link types
 | 
						||
* Adding export back-ends::     How to write new export back-ends
 | 
						||
* Context-sensitive commands::  How to add functionality to such commands
 | 
						||
* Tables in arbitrary syntax::  Orgtbl for LaTeX and other programs
 | 
						||
* Dynamic blocks::              Automatically filled blocks
 | 
						||
* Special agenda views::        Customized views
 | 
						||
* Speeding up your agendas::    Tips on how to speed up your agendas
 | 
						||
* Extracting agenda information::  Post-processing of agenda information
 | 
						||
* Using the property API::      Writing programs that use entry properties
 | 
						||
* Using the mapping API::       Mapping over all or selected entries
 | 
						||
 | 
						||
Tables and lists in arbitrary syntax
 | 
						||
 | 
						||
* Radio tables::                Sending and receiving radio tables
 | 
						||
* A LaTeX example::          Step by step, almost a tutorial
 | 
						||
* Translator functions::        Copy and modify
 | 
						||
* Radio lists::                 Sending and receiving lists
 | 
						||
 | 
						||
MobileOrg
 | 
						||
 | 
						||
* Setting up the staging area::  Where to interact with the mobile device
 | 
						||
* Pushing to MobileOrg::        Uploading Org files and agendas
 | 
						||
* Pulling from MobileOrg::      Integrating captured and flagged items
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Introduction,  Next: Document structure,  Prev: Top,  Up: Top
 | 
						||
 | 
						||
1 Introduction
 | 
						||
**************
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Summary::                     Brief summary of what Org does
 | 
						||
* Installation::                Installing Org
 | 
						||
* Activation::                  How to activate Org for certain buffers
 | 
						||
* Feedback::                    Bug reports, ideas, patches etc.
 | 
						||
* Conventions::                 Typesetting conventions in the manual
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Summary,  Next: Installation,  Up: Introduction
 | 
						||
 | 
						||
1.1 Summary
 | 
						||
===========
 | 
						||
 | 
						||
Org is a mode for keeping notes, maintaining TODO lists, and project
 | 
						||
planning with a fast and effective plain-text system.  It also is an
 | 
						||
authoring system with unique support for literate programming and
 | 
						||
reproducible research.
 | 
						||
 | 
						||
   Org is implemented on top of Outline mode, which makes it possible
 | 
						||
to keep the content of large files well structured.  Visibility cycling
 | 
						||
and structure editing help to work with the tree.  Tables are easily
 | 
						||
created with a built-in table editor.  Plain text URL-like links
 | 
						||
connect to websites, emails, Usenet messages, BBDB entries, and any
 | 
						||
files related to the projects.
 | 
						||
 | 
						||
   Org develops organizational tasks around notes files that contain
 | 
						||
lists or information about projects as plain text.  Project planning
 | 
						||
and task management makes use of metadata which is part of an outline
 | 
						||
node.  Based on this data, specific entries can be extracted in queries
 | 
						||
and create dynamic agenda views that also integrate the Emacs calendar
 | 
						||
and diary.  Org can be used to implement many different project
 | 
						||
planning schemes, such as David Allen's GTD system.
 | 
						||
 | 
						||
   Org files can serve as a single source authoring system with export
 | 
						||
to many different formats such as HTML, LaTeX, Open Document, and
 | 
						||
Markdown.  New export backends can be derived from existing ones, or
 | 
						||
defined from scratch.
 | 
						||
 | 
						||
   Org files can include source code blocks, which makes Org uniquely
 | 
						||
suited for authoring technical documents with code examples. Org source
 | 
						||
code blocks are fully functional; they can be evaluated in place and
 | 
						||
their results can be captured in the file.  This makes it possible to
 | 
						||
create a single file reproducible research compendium.
 | 
						||
 | 
						||
   Org keeps simple things simple.  When first fired up, it should feel
 | 
						||
like a straightforward, easy to use outliner.  Complexity is not
 | 
						||
imposed, but a large amount of functionality is available when needed.
 | 
						||
Org is a toolbox.  Many users actually run only a (very personal)
 | 
						||
fraction of Org's capabilities, and know that there is more whenever
 | 
						||
they need it.
 | 
						||
 | 
						||
   All of this is achieved with strictly plain text files, the most
 | 
						||
portable and future-proof file format.  Org runs in Emacs.  Emacs is
 | 
						||
one of the most widely ported programs, so that Org mode is available
 | 
						||
on every major platform.
 | 
						||
 | 
						||
   There is a website for Org which provides links to the newest
 | 
						||
version of Org, as well as additional information, frequently asked
 | 
						||
questions (FAQ), links to tutorials, etc.  This page is located at
 | 
						||
`http://orgmode.org'.  
 | 
						||
 | 
						||
   An earlier version (7.3) of this manual is available as a paperback
 | 
						||
book from Network Theory Ltd.
 | 
						||
(http://www.network-theory.co.uk/org/manual/)
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Installation,  Next: Activation,  Prev: Summary,  Up: Introduction
 | 
						||
 | 
						||
1.2 Installation
 | 
						||
================
 | 
						||
 | 
						||
Org is part of recent distributions of GNU Emacs, so you normally don't
 | 
						||
need to install it.  If, for one reason or another, you want to install
 | 
						||
Org on top of this pre-packaged version, there are three ways to do it:
 | 
						||
 | 
						||
   * By using Emacs package system.
 | 
						||
 | 
						||
   * By downloading Org as an archive.
 | 
						||
 | 
						||
   * By using Org's git repository.
 | 
						||
 | 
						||
   We strongly recommend to stick to a single installation method.
 | 
						||
 | 
						||
Using Emacs packaging system
 | 
						||
............................
 | 
						||
 | 
						||
Recent Emacs distributions include a packaging system which lets you
 | 
						||
install Elisp libraries.  You can install Org with `M-x package-install
 | 
						||
RET org'.
 | 
						||
 | 
						||
Important: you need to do this in a session where no `.org' file has
 | 
						||
been visited, i.e., where no Org built-in function have been loaded.
 | 
						||
Otherwise autoload Org functions will mess up the installation.
 | 
						||
 | 
						||
   Then, to make sure your Org configuration is taken into account,
 | 
						||
initialize the package system with `(package-initialize)' in your
 | 
						||
`.emacs' before setting any Org option.  If you want to use Org's
 | 
						||
package repository, check out the Org ELPA page
 | 
						||
(http://orgmode.org/elpa.html).
 | 
						||
 | 
						||
Downloading Org as an archive
 | 
						||
.............................
 | 
						||
 | 
						||
You can download Org latest release from Org's website
 | 
						||
(http://orgmode.org/).  In this case, make sure you set the load-path
 | 
						||
correctly in your `.emacs':
 | 
						||
 | 
						||
     (add-to-list 'load-path "~/path/to/orgdir/lisp")
 | 
						||
 | 
						||
   The downloaded archive contains contributed libraries that are not
 | 
						||
included in Emacs.  If you want to use them, add the `contrib'
 | 
						||
directory to your load-path:
 | 
						||
 | 
						||
     (add-to-list 'load-path "~/path/to/orgdir/contrib/lisp" t)
 | 
						||
 | 
						||
   Optionally, you can compile the files and/or install them in your
 | 
						||
system.  Run `make help' to list compilation and installation options.
 | 
						||
 | 
						||
Using Org's git repository
 | 
						||
..........................
 | 
						||
 | 
						||
You can clone Org's repository and install Org like this:
 | 
						||
 | 
						||
     $ cd ~/src/
 | 
						||
     $ git clone git://orgmode.org/org-mode.git
 | 
						||
     $ make autoloads
 | 
						||
 | 
						||
   Note that in this case, `make autoloads' is mandatory: it defines
 | 
						||
Org's version in `org-version.el' and Org's autoloads in
 | 
						||
`org-loaddefs.el'.
 | 
						||
 | 
						||
   Remember to add the correct load-path as described in the method
 | 
						||
above.
 | 
						||
 | 
						||
   You can also compile with `make', generate the documentation with
 | 
						||
`make doc', create a local configuration with `make config' and install
 | 
						||
Org with `make install'.  Please run `make help' to get the list of
 | 
						||
compilation/installation options.
 | 
						||
 | 
						||
   For more detailed explanations on Org's build system, please check
 | 
						||
the Org Build System page on Worg
 | 
						||
(http://orgmode.org/worg/dev/org-build-system.html).
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Activation,  Next: Feedback,  Prev: Installation,  Up: Introduction
 | 
						||
 | 
						||
1.3 Activation
 | 
						||
==============
 | 
						||
 | 
						||
Since Emacs 22.2, files with the `.org' extension use Org mode by
 | 
						||
default.  If you are using an earlier version of Emacs, add this line
 | 
						||
to your `.emacs' file:
 | 
						||
 | 
						||
     (add-to-list 'auto-mode-alist '("\\.org\\'" . org-mode))
 | 
						||
 | 
						||
   Org mode buffers need font-lock to be turned on: this is the default
 | 
						||
in Emacs(1).
 | 
						||
 | 
						||
   There are compatibility issues between Org mode and some other Elisp
 | 
						||
packages, please take the time to check the list (*note Conflicts::).
 | 
						||
 | 
						||
   The four Org commands `org-store-link', `org-capture', `org-agenda',
 | 
						||
and `org-iswitchb' should be accessible through global keys (i.e.,
 | 
						||
anywhere in Emacs, not just in Org buffers).  Here are suggested
 | 
						||
bindings for these keys, please modify the keys to your own liking.
 | 
						||
     (global-set-key "\C-cl" 'org-store-link)
 | 
						||
     (global-set-key "\C-ca" 'org-agenda)
 | 
						||
     (global-set-key "\C-cc" 'org-capture)
 | 
						||
     (global-set-key "\C-cb" 'org-iswitchb)
 | 
						||
 | 
						||
   To turn on Org mode in a file that does not have the extension
 | 
						||
`.org', make the first line of a file look like this:
 | 
						||
 | 
						||
     MY PROJECTS    -*- mode: org; -*-
 | 
						||
 | 
						||
which will select Org mode for this buffer no matter what the file's
 | 
						||
name is.  See also the variable `org-insert-mode-line-in-empty-file'.
 | 
						||
 | 
						||
   Many commands in Org work on the region if the region is active.  To
 | 
						||
make use of this, you need to have `transient-mark-mode'
 | 
						||
(`zmacs-regions' in XEmacs) turned on.  In Emacs 23 this is the default,
 | 
						||
in Emacs 22 you need to do this yourself with
 | 
						||
     (transient-mark-mode 1)
 | 
						||
   If you do not like `transient-mark-mode', you can create an active
 | 
						||
region by using the mouse to select a region, or pressing `C-<SPC>'
 | 
						||
twice before moving the cursor.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) If you don't use font-lock globally, turn it on in Org buffer
 | 
						||
with `(add-hook 'org-mode-hook 'turn-on-font-lock)'
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Feedback,  Next: Conventions,  Prev: Activation,  Up: Introduction
 | 
						||
 | 
						||
1.4 Feedback
 | 
						||
============
 | 
						||
 | 
						||
If you find problems with Org, or if you have questions, remarks, or
 | 
						||
ideas about it, please mail to the Org mailing list
 | 
						||
<emacs-orgmode@gnu.org>.  You can subscribe to the list on this web
 | 
						||
page (https://lists.gnu.org/mailman/listinfo/emacs-orgmode).  If you
 | 
						||
are not a member of the mailing list, your mail will be passed to the
 | 
						||
list after a moderator has approved it(1).
 | 
						||
 | 
						||
   For bug reports, please first try to reproduce the bug with the
 | 
						||
latest version of Org available--if you are running an outdated
 | 
						||
version, it is quite possible that the bug has been fixed already.  If
 | 
						||
the bug persists, prepare a report and provide as much information as
 | 
						||
possible, including the version information of Emacs (`M-x
 | 
						||
emacs-version <RET>') and Org (`M-x org-version RET'), as well as the
 | 
						||
Org related setup in `.emacs'.  The easiest way to do this is to use
 | 
						||
the command
 | 
						||
     M-x org-submit-bug-report RET
 | 
						||
   which will put all this information into an Emacs mail buffer so
 | 
						||
that you only need to add your description.  If you are not sending the
 | 
						||
Email from within Emacs, please copy and paste the content into your
 | 
						||
Email program.
 | 
						||
 | 
						||
   Sometimes you might face a problem due to an error in your Emacs or
 | 
						||
Org mode setup.  Before reporting a bug, it is very helpful to start
 | 
						||
Emacs with minimal customizations and reproduce the problem.  Doing so
 | 
						||
often helps you determine if the problem is with your customization or
 | 
						||
with Org mode itself.  You can start a typical minimal session with a
 | 
						||
command like the example below.
 | 
						||
 | 
						||
     $ emacs -Q -l /path/to/minimal-org.el
 | 
						||
 | 
						||
   However if you are using Org mode as distributed with Emacs, a
 | 
						||
minimal setup is not necessary.  In that case it is sufficient to start
 | 
						||
Emacs as `emacs -Q'.  The `minimal-org.el' setup file can have contents
 | 
						||
as shown below.
 | 
						||
 | 
						||
     ;;; Minimal setup to load latest 'org-mode'
 | 
						||
 | 
						||
     ;; activate debugging
 | 
						||
     (setq debug-on-error t
 | 
						||
           debug-on-signal nil
 | 
						||
           debug-on-quit nil)
 | 
						||
 | 
						||
     ;; add latest org-mode to load path
 | 
						||
     (add-to-list 'load-path (expand-file-name "/path/to/org-mode/lisp"))
 | 
						||
     (add-to-list 'load-path (expand-file-name "/path/to/org-mode/contrib/lisp" t))
 | 
						||
 | 
						||
   If an error occurs, a backtrace can be very useful (see below on how
 | 
						||
to create one).  Often a small example file helps, along with clear
 | 
						||
information about:
 | 
						||
 | 
						||
  1. What exactly did you do?
 | 
						||
 | 
						||
  2. What did you expect to happen?
 | 
						||
 | 
						||
  3. What happened instead?
 | 
						||
        Thank you for helping to improve this program.
 | 
						||
 | 
						||
How to create a useful backtrace
 | 
						||
................................
 | 
						||
 | 
						||
If working with Org produces an error with a message you don't
 | 
						||
understand, you may have hit a bug.  The best way to report this is by
 | 
						||
providing, in addition to what was mentioned above, a _backtrace_.
 | 
						||
This is information from the built-in debugger about where and how the
 | 
						||
error occurred.  Here is how to produce a useful backtrace:
 | 
						||
 | 
						||
  1. Reload uncompiled versions of all Org mode Lisp files.  The
 | 
						||
     backtrace contains much more information if it is produced with
 | 
						||
     uncompiled code.  To do this, use
 | 
						||
          C-u M-x org-reload RET
 | 
						||
     or select `Org -> Refresh/Reload -> Reload Org uncompiled' from the
 | 
						||
     menu.
 | 
						||
 | 
						||
  2. Go to the `Options' menu and select `Enter Debugger on Error'
 | 
						||
     (XEmacs has this option in the `Troubleshooting' sub-menu).
 | 
						||
 | 
						||
  3. Do whatever you have to do to hit the error.  Don't forget to
 | 
						||
     document the steps you take.
 | 
						||
 | 
						||
  4. When you hit the error, a `*Backtrace*' buffer will appear on the
 | 
						||
     screen.  Save this buffer to a file (for example using `C-x C-w')
 | 
						||
     and attach it to your bug report.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Please consider subscribing to the mailing list, in order to
 | 
						||
minimize the work the mailing list moderators have to do.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Conventions,  Prev: Feedback,  Up: Introduction
 | 
						||
 | 
						||
1.5 Typesetting conventions used in this manual
 | 
						||
===============================================
 | 
						||
 | 
						||
TODO keywords, tags, properties, etc.
 | 
						||
.....................................
 | 
						||
 | 
						||
Org mainly uses three types of keywords: TODO keywords, tags and
 | 
						||
property names.  In this manual we use the following conventions:
 | 
						||
 | 
						||
`TODO'
 | 
						||
`WAITING'
 | 
						||
     TODO keywords are written with all capitals, even if they are
 | 
						||
     user-defined.
 | 
						||
 | 
						||
`boss'
 | 
						||
`ARCHIVE'
 | 
						||
     User-defined tags are written in lowercase; built-in tags with
 | 
						||
     special meaning are written with all capitals.
 | 
						||
 | 
						||
`Release'
 | 
						||
`PRIORITY'
 | 
						||
     User-defined properties are capitalized; built-in properties with
 | 
						||
     special meaning are written with all capitals.
 | 
						||
 | 
						||
   Moreover, Org uses option keywords (like `#+TITLE' to set the title)
 | 
						||
and environment keywords (like `#+BEGIN_HTML' to start a `HTML'
 | 
						||
environment).  They are written in uppercase in the manual to enhance
 | 
						||
its readability, but you can use lowercase in your Org files(1).
 | 
						||
 | 
						||
Keybindings and commands
 | 
						||
........................
 | 
						||
 | 
						||
The manual suggests a few global keybindings, in particular `C-c a' for
 | 
						||
`org-agenda' and `C-c c' for `org-capture'.  These are only
 | 
						||
suggestions, but the rest of the manual assumes that these keybindings
 | 
						||
are in place in order to list commands by key access.
 | 
						||
 | 
						||
   Also, the manual lists both the keys and the corresponding commands
 | 
						||
for accessing a functionality.  Org mode often uses the same key for
 | 
						||
different functions, depending on context.  The command that is bound
 | 
						||
to such keys has a generic name, like `org-metaright'.  In the manual
 | 
						||
we will, wherever possible, give the function that is internally called
 | 
						||
by the generic command.  For example, in the chapter on document
 | 
						||
structure, `M-<right>' will be listed to call `org-do-demote', while in
 | 
						||
the chapter on tables, it will be listed to call
 | 
						||
`org-table-move-column-right'.  If you prefer, you can compile the
 | 
						||
manual without the command names by unsetting the flag `cmdnames' in
 | 
						||
`org.texi'.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Easy templates insert lowercase keywords and Babel dynamically
 | 
						||
inserts `#+results'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Document structure,  Next: Tables,  Prev: Introduction,  Up: Top
 | 
						||
 | 
						||
2 Document structure
 | 
						||
********************
 | 
						||
 | 
						||
Org is based on Outline mode and provides flexible commands to edit the
 | 
						||
structure of the document.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Outlines::                    Org is based on Outline mode
 | 
						||
* Headlines::                   How to typeset Org tree headlines
 | 
						||
* Visibility cycling::          Show and hide, much simplified
 | 
						||
* Motion::                      Jumping to other headlines
 | 
						||
* Structure editing::           Changing sequence and level of headlines
 | 
						||
* Sparse trees::                Matches embedded in context
 | 
						||
* Plain lists::                 Additional structure within an entry
 | 
						||
* Drawers::                     Tucking stuff away
 | 
						||
* Blocks::                      Folding blocks
 | 
						||
* Footnotes::                   How footnotes are defined in Org's syntax
 | 
						||
* Orgstruct mode::              Structure editing outside Org
 | 
						||
* Org syntax::                  Formal description of Org's syntax
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Outlines,  Next: Headlines,  Up: Document structure
 | 
						||
 | 
						||
2.1 Outlines
 | 
						||
============
 | 
						||
 | 
						||
Org is implemented on top of Outline mode.  Outlines allow a document
 | 
						||
to be organized in a hierarchical structure, which (at least for me) is
 | 
						||
the best representation of notes and thoughts.  An overview of this
 | 
						||
structure is achieved by folding (hiding) large parts of the document
 | 
						||
to show only the general document structure and the parts currently
 | 
						||
being worked on.  Org greatly simplifies the use of outlines by
 | 
						||
compressing the entire show/hide functionality into a single command,
 | 
						||
`org-cycle', which is bound to the <TAB> key.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Headlines,  Next: Visibility cycling,  Prev: Outlines,  Up: Document structure
 | 
						||
 | 
						||
2.2 Headlines
 | 
						||
=============
 | 
						||
 | 
						||
Headlines define the structure of an outline tree.  The headlines in Org
 | 
						||
start with one or more stars, on the left margin(1) (2).  For example:
 | 
						||
 | 
						||
     * Top level headline
 | 
						||
     ** Second level
 | 
						||
     *** 3rd level
 | 
						||
         some text
 | 
						||
     *** 3rd level
 | 
						||
         more text
 | 
						||
 | 
						||
     * Another top level headline
 | 
						||
 | 
						||
Note that a headline named after `org-footnote-section', which defaults
 | 
						||
to `Footnotes', is considered as special.  A subtree with this headline
 | 
						||
will be silently ignored by exporting functions.
 | 
						||
 | 
						||
   Some people find the many stars too noisy and would prefer an
 | 
						||
outline that has whitespace followed by a single star as headline
 | 
						||
starters.  *note Clean view::, describes a setup to realize this.
 | 
						||
 | 
						||
   An empty line after the end of a subtree is considered part of it and
 | 
						||
will be hidden when the subtree is folded.  However, if you leave at
 | 
						||
least two empty lines, one empty line will remain visible after folding
 | 
						||
the subtree, in order to structure the collapsed view.  See the
 | 
						||
variable `org-cycle-separator-lines' to modify this behavior.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) See the variables `org-special-ctrl-a/e', `org-special-ctrl-k',
 | 
						||
and `org-ctrl-k-protect-subtree' to configure special behavior of `C-a',
 | 
						||
`C-e', and `C-k' in headlines.
 | 
						||
 | 
						||
   (2) Clocking only works with headings indented less than 30 stars.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Visibility cycling,  Next: Motion,  Prev: Headlines,  Up: Document structure
 | 
						||
 | 
						||
2.3 Visibility cycling
 | 
						||
======================
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Global and local cycling::    Cycling through various visibility states
 | 
						||
* Initial visibility::          Setting the initial visibility state
 | 
						||
* Catching invisible edits::    Preventing mistakes when editing invisible parts
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Global and local cycling,  Next: Initial visibility,  Up: Visibility cycling
 | 
						||
 | 
						||
2.3.1 Global and local cycling
 | 
						||
------------------------------
 | 
						||
 | 
						||
Outlines make it possible to hide parts of the text in the buffer.  Org
 | 
						||
uses just two commands, bound to <TAB> and `S-<TAB>' to change the
 | 
						||
visibility in the buffer.
 | 
						||
 | 
						||
`<TAB>'     (`org-cycle')
 | 
						||
     _Subtree cycling_: Rotate current subtree among the states
 | 
						||
 | 
						||
          ,-> FOLDED -> CHILDREN -> SUBTREE --.
 | 
						||
          '-----------------------------------'
 | 
						||
 | 
						||
     The cursor must be on a headline for this to work(1).  When the
 | 
						||
     cursor is at the beginning of the buffer and the first line is not
 | 
						||
     a headline, then <TAB> actually runs global cycling (see
 | 
						||
     below)(2).  Also when called with a prefix argument (`C-u <TAB>'),
 | 
						||
     global cycling is invoked.
 | 
						||
 | 
						||
`S-<TAB>'     (`org-global-cycle')
 | 
						||
C-u <TAB>
 | 
						||
     _Global cycling_: Rotate the entire buffer among the states
 | 
						||
 | 
						||
          ,-> OVERVIEW -> CONTENTS -> SHOW ALL --.
 | 
						||
          '--------------------------------------'
 | 
						||
 | 
						||
     When `S-<TAB>' is called with a numeric prefix argument N, the
 | 
						||
     CONTENTS view up to headlines of level N will be shown.  Note that
 | 
						||
     inside tables, `S-<TAB>' jumps to the previous field.
 | 
						||
 | 
						||
`C-u C-u <TAB>'     (`org-set-startup-visibility')
 | 
						||
     Switch back to the startup visibility of the buffer (*note Initial
 | 
						||
     visibility::).  
 | 
						||
 | 
						||
`C-u C-u C-u <TAB>'     (`show-all')
 | 
						||
     Show all, including drawers.  
 | 
						||
 | 
						||
`C-c C-r'     (`org-reveal')
 | 
						||
     Reveal context around point, showing the current entry, the
 | 
						||
     following heading and the hierarchy above.  Useful for working
 | 
						||
     near a location that has been exposed by a sparse tree command
 | 
						||
     (*note Sparse trees::) or an agenda command (*note Agenda
 | 
						||
     commands::).  With a prefix argument show, on each level, all
 | 
						||
     sibling headings.  With a double prefix argument, also show the
 | 
						||
     entire subtree of the parent.  
 | 
						||
 | 
						||
`C-c C-k'     (`show-branches')
 | 
						||
     Expose all the headings of the subtree, CONTENT view for just one
 | 
						||
     subtree.  
 | 
						||
 | 
						||
`C-c <TAB>'     (`show-children')
 | 
						||
     Expose all direct children of the subtree.  With a numeric prefix
 | 
						||
     argument N, expose all children down to level N.  
 | 
						||
 | 
						||
`C-c C-x b'     (`org-tree-to-indirect-buffer')
 | 
						||
     Show the current subtree in an indirect buffer(3).  With a numeric
 | 
						||
     prefix argument N, go up to level N and then take that tree.  If N
 | 
						||
     is negative then go up that many levels.  With a `C-u' prefix, do
 | 
						||
     not remove the previously used indirect buffer.  
 | 
						||
 | 
						||
`C-c C-x v'     (`org-copy-visible')
 | 
						||
     Copy the visible text in the region into the kill ring.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) see, however, the option `org-cycle-emulate-tab'.
 | 
						||
 | 
						||
   (2) see the option `org-cycle-global-at-bob'.
 | 
						||
 | 
						||
   (3) The indirect buffer (*note Indirect Buffers: (emacs)Indirect
 | 
						||
Buffers.) will contain the entire buffer, but will be narrowed to the
 | 
						||
current tree.  Editing the indirect buffer will also change the
 | 
						||
original buffer, but without affecting visibility in that buffer.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Initial visibility,  Next: Catching invisible edits,  Prev: Global and local cycling,  Up: Visibility cycling
 | 
						||
 | 
						||
2.3.2 Initial visibility
 | 
						||
------------------------
 | 
						||
 | 
						||
When Emacs first visits an Org file, the global state is set to
 | 
						||
OVERVIEW, i.e., only the top level headlines are visible(1).  This can
 | 
						||
be configured through the variable `org-startup-folded', or on a
 | 
						||
per-file basis by adding one of the following lines anywhere in the
 | 
						||
buffer:
 | 
						||
 | 
						||
     #+STARTUP: overview
 | 
						||
     #+STARTUP: content
 | 
						||
     #+STARTUP: showall
 | 
						||
     #+STARTUP: showeverything
 | 
						||
 | 
						||
   The startup visibility options are ignored when the file is open for
 | 
						||
the first time during the agenda generation: if you want the agenda to
 | 
						||
honor the startup visibility, set `org-agenda-inhibit-startup' to `nil'.
 | 
						||
 | 
						||
Furthermore, any entries with a `VISIBILITY' property (*note Properties
 | 
						||
and columns::) will get their visibility adapted accordingly.  Allowed
 | 
						||
values for this property are `folded', `children', `content', and `all'.
 | 
						||
 | 
						||
`C-u C-u <TAB>'     (`org-set-startup-visibility')
 | 
						||
     Switch back to the startup visibility of the buffer, i.e.,
 | 
						||
     whatever is requested by startup options and `VISIBILITY'
 | 
						||
     properties in individual entries.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) When `org-agenda-inhibit-startup' is non-`nil', Org will not
 | 
						||
honor the default visibility state when first opening a file for the
 | 
						||
agenda (*note Speeding up your agendas::).
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Catching invisible edits,  Prev: Initial visibility,  Up: Visibility cycling
 | 
						||
 | 
						||
2.3.3 Catching invisible edits
 | 
						||
------------------------------
 | 
						||
 | 
						||
Sometimes you may inadvertently edit an invisible part of the buffer
 | 
						||
and be confused on what has been edited and how to undo the mistake.
 | 
						||
Setting `org-catch-invisible-edits' to non-`nil' will help prevent
 | 
						||
this.  See the docstring of this option on how Org should catch
 | 
						||
invisible edits and process them.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Motion,  Next: Structure editing,  Prev: Visibility cycling,  Up: Document structure
 | 
						||
 | 
						||
2.4 Motion
 | 
						||
==========
 | 
						||
 | 
						||
The following commands jump to other headlines in the buffer.
 | 
						||
 | 
						||
`C-c C-n'     (`outline-next-visible-heading')
 | 
						||
     Next heading.  
 | 
						||
 | 
						||
`C-c C-p'     (`outline-previous-visible-heading')
 | 
						||
     Previous heading.  
 | 
						||
 | 
						||
`C-c C-f'     (`org-forward-same-level')
 | 
						||
     Next heading same level.  
 | 
						||
 | 
						||
`C-c C-b'     (`org-backward-same-level')
 | 
						||
     Previous heading same level.  
 | 
						||
 | 
						||
`C-c C-u'     (`outline-up-heading')
 | 
						||
     Backward to higher level heading.  
 | 
						||
 | 
						||
`C-c C-j'     (`org-goto')
 | 
						||
     Jump to a different place without changing the current outline
 | 
						||
     visibility.  Shows the document structure in a temporary buffer,
 | 
						||
     where you can use the following keys to find your destination: 
 | 
						||
          <TAB>         Cycle visibility.
 | 
						||
          <down> / <up>   Next/previous visible headline.
 | 
						||
          <RET>         Select this location.
 | 
						||
          /           Do a Sparse-tree search
 | 
						||
          The following keys work if you turn off `org-goto-auto-isearch'
 | 
						||
          n / p        Next/previous visible headline.
 | 
						||
          f / b        Next/previous headline same level.
 | 
						||
          u            One level up.
 | 
						||
          0-9          Digit argument.
 | 
						||
          q            Quit
 | 
						||
     See also the option `org-goto-interface'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Structure editing,  Next: Sparse trees,  Prev: Motion,  Up: Document structure
 | 
						||
 | 
						||
2.5 Structure editing
 | 
						||
=====================
 | 
						||
 | 
						||
`M-<RET>'     (`org-insert-heading')
 | 
						||
     Insert a new heading/item with the same level as the one at point.
 | 
						||
 | 
						||
     If the cursor is in a plain list item, a new item is created
 | 
						||
     (*note Plain lists::).  To prevent this behavior in lists, call
 | 
						||
     the command with one prefix argument.  When this command is used
 | 
						||
     in the middle of a line, the line is split and the rest of the
 | 
						||
     line becomes the new item or headline.  If you do not want the
 | 
						||
     line to be split, customize `org-M-RET-may-split-line'.
 | 
						||
 | 
						||
     If the command is used at the _beginning_ of a line, and if there
 | 
						||
     is a heading or an item at point, the new heading/item is created
 | 
						||
     _before_ the current line.  If the command is used at the _end_ of
 | 
						||
     a folded subtree (i.e., behind the ellipses at the end of a
 | 
						||
     headline), then a headline will be inserted after the end of the
 | 
						||
     subtree.
 | 
						||
 | 
						||
     Calling this command with `C-u C-u' will unconditionally respect
 | 
						||
     the headline's content and create a new item at the end of the
 | 
						||
     parent subtree.
 | 
						||
 | 
						||
     If point is at the beginning of a normal line, turn this line into
 | 
						||
     a heading.  
 | 
						||
 | 
						||
`C-<RET>'     (`org-insert-heading-respect-content')
 | 
						||
     Just like `M-<RET>', except when adding a new heading below the
 | 
						||
     current heading, the new heading is placed after the body instead
 | 
						||
     of before it.  This command works from anywhere in the entry.  
 | 
						||
 | 
						||
`M-S-<RET>'     (`org-insert-todo-heading')
 | 
						||
     Insert new TODO entry with same level as current heading.  See
 | 
						||
     also the variable `org-treat-insert-todo-heading-as-state-change'.  
 | 
						||
 | 
						||
`C-S-<RET>'     (`org-insert-todo-heading-respect-content')
 | 
						||
     Insert new TODO entry with same level as current heading.  Like
 | 
						||
     `C-<RET>', the new headline will be inserted after the current
 | 
						||
     subtree.  
 | 
						||
 | 
						||
`<TAB>'     (`org-cycle')
 | 
						||
     In a new entry with no text yet, the first <TAB> demotes the entry
 | 
						||
     to become a child of the previous one.  The next <TAB> makes it a
 | 
						||
     parent, and so on, all the way to top level.  Yet another <TAB>,
 | 
						||
     and you are back to the initial level.  
 | 
						||
 | 
						||
`M-<left>'     (`org-do-promote')
 | 
						||
     Promote current heading by one level.  
 | 
						||
 | 
						||
`M-<right>'     (`org-do-demote')
 | 
						||
     Demote current heading by one level.  
 | 
						||
 | 
						||
`M-S-<left>'     (`org-promote-subtree')
 | 
						||
     Promote the current subtree by one level.  
 | 
						||
 | 
						||
`M-S-<right>'     (`org-demote-subtree')
 | 
						||
     Demote the current subtree by one level.  
 | 
						||
 | 
						||
`M-S-<up>'     (`org-move-subtree-up')
 | 
						||
     Move subtree up (swap with previous subtree of same level).  
 | 
						||
 | 
						||
`M-S-<down>'     (`org-move-subtree-down')
 | 
						||
     Move subtree down (swap with next subtree of same level).  
 | 
						||
 | 
						||
`M-h'     (`org-mark-element')
 | 
						||
     Mark the element at point.  Hitting repeatedly will mark
 | 
						||
     subsequent elements of the one just marked.  E.g., hitting <M-h>
 | 
						||
     on a paragraph will mark it, hitting <M-h> immediately again will
 | 
						||
     mark the next one.  
 | 
						||
 | 
						||
`C-c @'     (`org-mark-subtree')
 | 
						||
     Mark the subtree at point.  Hitting repeatedly will mark
 | 
						||
     subsequent subtrees of the same level than the marked subtree.  
 | 
						||
 | 
						||
`C-c C-x C-w'     (`org-cut-subtree')
 | 
						||
     Kill subtree, i.e., remove it from buffer but save in kill ring.
 | 
						||
     With a numeric prefix argument N, kill N sequential subtrees.  
 | 
						||
 | 
						||
`C-c C-x M-w'     (`org-copy-subtree')
 | 
						||
     Copy subtree to kill ring.  With a numeric prefix argument N, copy
 | 
						||
     the N sequential subtrees.  
 | 
						||
 | 
						||
`C-c C-x C-y'     (`org-paste-subtree')
 | 
						||
     Yank subtree from kill ring.  This does modify the level of the
 | 
						||
     subtree to make sure the tree fits in nicely at the yank position.
 | 
						||
     The yank level can also be specified with a numeric prefix
 | 
						||
     argument, or by yanking after a headline marker like `****'.  
 | 
						||
 | 
						||
`C-y'     (`org-yank')
 | 
						||
     Depending on the options `org-yank-adjusted-subtrees' and
 | 
						||
     `org-yank-folded-subtrees', Org's internal `yank' command will
 | 
						||
     paste subtrees folded and in a clever way, using the same command
 | 
						||
     as `C-c C-x C-y'.  With the default settings, no level adjustment
 | 
						||
     will take place, but the yanked tree will be folded unless doing
 | 
						||
     so would swallow text previously visible.  Any prefix argument to
 | 
						||
     this command will force a normal `yank' to be executed, with the
 | 
						||
     prefix passed along.  A good way to force a normal yank is `C-u
 | 
						||
     C-y'.  If you use `yank-pop' after a yank, it will yank previous
 | 
						||
     kill items plainly, without adjustment and folding.  
 | 
						||
 | 
						||
`C-c C-x c'     (`org-clone-subtree-with-time-shift')
 | 
						||
     Clone a subtree by making a number of sibling copies of it.  You
 | 
						||
     will be prompted for the number of copies to make, and you can
 | 
						||
     also specify if any timestamps in the entry should be shifted.
 | 
						||
     This can be useful, for example, to create a number of tasks
 | 
						||
     related to a series of lectures to prepare.  For more details, see
 | 
						||
     the docstring of the command `org-clone-subtree-with-time-shift'.  
 | 
						||
 | 
						||
`C-c C-w'     (`org-refile')
 | 
						||
     Refile entry or region to a different location.  *Note Refile and
 | 
						||
     copy::.  
 | 
						||
 | 
						||
`C-c ^'     (`org-sort')
 | 
						||
     Sort same-level entries.  When there is an active region, all
 | 
						||
     entries in the region will be sorted.  Otherwise the children of
 | 
						||
     the current headline are sorted.  The command prompts for the
 | 
						||
     sorting method, which can be alphabetically, numerically, by time
 | 
						||
     (first timestamp with active preferred, creation time, scheduled
 | 
						||
     time, deadline time), by priority, by TODO keyword (in the
 | 
						||
     sequence the keywords have been defined in the setup) or by the
 | 
						||
     value of a property.  Reverse sorting is possible as well.  You
 | 
						||
     can also supply your own function to extract the sorting key.
 | 
						||
     With a `C-u' prefix, sorting will be case-sensitive.  
 | 
						||
 | 
						||
`C-x n s'     (`org-narrow-to-subtree')
 | 
						||
     Narrow buffer to current subtree.  
 | 
						||
 | 
						||
`C-x n b'     (`org-narrow-to-block')
 | 
						||
     Narrow buffer to current block.  
 | 
						||
 | 
						||
`C-x n w'     (`widen')
 | 
						||
     Widen buffer to remove narrowing.  
 | 
						||
 | 
						||
`C-c *'     (`org-toggle-heading')
 | 
						||
     Turn a normal line or plain list item into a headline (so that it
 | 
						||
     becomes a subheading at its location).  Also turn a headline into
 | 
						||
     a normal line by removing the stars.  If there is an active
 | 
						||
     region, turn all lines in the region into headlines.  If the first
 | 
						||
     line in the region was an item, turn only the item lines into
 | 
						||
     headlines.  Finally, if the first line is a headline, remove the
 | 
						||
     stars from all headlines in the region.
 | 
						||
 | 
						||
   When there is an active region (Transient Mark mode), promotion and
 | 
						||
demotion work on all headlines in the region.  To select a region of
 | 
						||
headlines, it is best to place both point and mark at the beginning of a
 | 
						||
line, mark at the beginning of the first headline, and point at the line
 | 
						||
just after the last headline to change.  Note that when the cursor is
 | 
						||
inside a table (*note Tables::), the Meta-Cursor keys have different
 | 
						||
functionality.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Sparse trees,  Next: Plain lists,  Prev: Structure editing,  Up: Document structure
 | 
						||
 | 
						||
2.6 Sparse trees
 | 
						||
================
 | 
						||
 | 
						||
An important feature of Org mode is the ability to construct _sparse
 | 
						||
trees_ for selected information in an outline tree, so that the entire
 | 
						||
document is folded as much as possible, but the selected information is
 | 
						||
made visible along with the headline structure above it(1).  Just try
 | 
						||
it out and you will see immediately how it works.
 | 
						||
 | 
						||
   Org mode contains several commands for creating such trees, all these
 | 
						||
commands can be accessed through a dispatcher:
 | 
						||
 | 
						||
`C-c /'     (`org-sparse-tree')
 | 
						||
     This prompts for an extra key to select a sparse-tree creating
 | 
						||
     command.  
 | 
						||
 | 
						||
`C-c / r'     (`org-occur')
 | 
						||
     Prompts for a regexp and shows a sparse tree with all matches.  If
 | 
						||
     the match is in a headline, the headline is made visible.  If the
 | 
						||
     match is in the body of an entry, headline and body are made
 | 
						||
     visible.  In order to provide minimal context, also the full
 | 
						||
     hierarchy of headlines above the match is shown, as well as the
 | 
						||
     headline following the match.  Each match is also highlighted; the
 | 
						||
     highlights disappear when the buffer is changed by an editing
 | 
						||
     command(2), or by pressing `C-c C-c'.  When called with a `C-u'
 | 
						||
     prefix argument, previous highlights are kept, so several calls to
 | 
						||
     this command can be stacked.  
 | 
						||
 | 
						||
`M-g n'  or  `M-g M-n'     (`next-error')
 | 
						||
     Jump to the next sparse tree match in this buffer.  
 | 
						||
 | 
						||
`M-g p'  or  `M-g M-p'     (`previous-error')
 | 
						||
     Jump to the previous sparse tree match in this buffer.
 | 
						||
 | 
						||
For frequently used sparse trees of specific search strings, you can
 | 
						||
use the option `org-agenda-custom-commands' to define fast keyboard
 | 
						||
access to specific sparse trees.  These commands will then be
 | 
						||
accessible through the agenda dispatcher (*note Agenda dispatcher::).
 | 
						||
For example:
 | 
						||
 | 
						||
     (setq org-agenda-custom-commands
 | 
						||
           '(("f" occur-tree "FIXME")))
 | 
						||
 | 
						||
will define the key `C-c a f' as a shortcut for creating a sparse tree
 | 
						||
matching the string `FIXME'.
 | 
						||
 | 
						||
   The other sparse tree commands select headings based on TODO
 | 
						||
keywords, tags, or properties and will be discussed later in this
 | 
						||
manual.
 | 
						||
 | 
						||
   To print a sparse tree, you can use the Emacs command
 | 
						||
`ps-print-buffer-with-faces' which does not print invisible parts of
 | 
						||
the document (3).  Or you can use `C-c C-e C-v' to export only the
 | 
						||
visible part of the document and print the resulting file.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) See also the variable `org-show-context-detail' to decide how
 | 
						||
much context is shown around each match.
 | 
						||
 | 
						||
   (2) This depends on the option `org-remove-highlights-with-change'
 | 
						||
 | 
						||
   (3) This does not work under XEmacs, because XEmacs uses selective
 | 
						||
display for outlining, not text properties.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Plain lists,  Next: Drawers,  Prev: Sparse trees,  Up: Document structure
 | 
						||
 | 
						||
2.7 Plain lists
 | 
						||
===============
 | 
						||
 | 
						||
Within an entry of the outline tree, hand-formatted lists can provide
 | 
						||
additional structure.  They also provide a way to create lists of
 | 
						||
checkboxes (*note Checkboxes::).  Org supports editing such lists, and
 | 
						||
every exporter (*note Exporting::) can parse and format them.
 | 
						||
 | 
						||
   Org knows ordered lists, unordered lists, and description lists.
 | 
						||
   * _Unordered_ list items start with `-', `+', or `*'(1)  as bullets.
 | 
						||
 | 
						||
   * _Ordered_ list items start with a numeral followed by either a
 | 
						||
     period or a right parenthesis(2), such as `1.' or `1)'(3).  If you
 | 
						||
     want a list to start with a different value (e.g., 20), start the
 | 
						||
     text of the item with `[@20]'(4).  Those constructs can be used in
 | 
						||
     any item of the list in order to enforce a particular numbering.
 | 
						||
 | 
						||
   * _Description_ list items are unordered list items, and contain the
 | 
						||
     separator ` :: ' to distinguish the description _term_ from the
 | 
						||
     description.
 | 
						||
 | 
						||
   Items belonging to the same list must have the same indentation on
 | 
						||
the first line.  In particular, if an ordered list reaches number
 | 
						||
`10.', then the 2-digit numbers must be written left-aligned with the
 | 
						||
other numbers in the list.  An item ends before the next line that is
 | 
						||
less or equally indented than its bullet/number.
 | 
						||
 | 
						||
   A list ends whenever every item has ended, which means before any
 | 
						||
line less or equally indented than items at top level.  It also ends
 | 
						||
before two blank lines(5).  In that case, all items are closed.  Here
 | 
						||
is an example:
 | 
						||
 | 
						||
     ** Lord of the Rings
 | 
						||
        My favorite scenes are (in this order)
 | 
						||
        1. The attack of the Rohirrim
 | 
						||
        2. Eowyn's fight with the witch king
 | 
						||
           + this was already my favorite scene in the book
 | 
						||
           + I really like Miranda Otto.
 | 
						||
        3. Peter Jackson being shot by Legolas
 | 
						||
           - on DVD only
 | 
						||
           He makes a really funny face when it happens.
 | 
						||
        But in the end, no individual scenes matter but the film as a whole.
 | 
						||
        Important actors in this film are:
 | 
						||
        - Elijah Wood :: He plays Frodo
 | 
						||
        - Sean Astin :: He plays Sam, Frodo's friend.  I still remember
 | 
						||
          him very well from his role as Mikey Walsh in The Goonies.
 | 
						||
 | 
						||
   Org supports these lists by tuning filling and wrapping commands to
 | 
						||
deal with them correctly(6), and by exporting them properly (*note
 | 
						||
Exporting::).  Since indentation is what governs the structure of these
 | 
						||
lists, many structural constructs like `#+BEGIN_...' blocks can be
 | 
						||
indented to signal that they belong to a particular item.
 | 
						||
 | 
						||
   If you find that using a different bullet for a sub-list (than that
 | 
						||
used for the current list-level) improves readability, customize the
 | 
						||
variable `org-list-demote-modify-bullet'.  To get a greater difference
 | 
						||
of indentation between items and their sub-items, customize
 | 
						||
`org-list-indent-offset'.
 | 
						||
 | 
						||
   The following commands act on items when the cursor is in the first
 | 
						||
line of an item (the line with the bullet or number).  Some of them
 | 
						||
imply the application of automatic rules to keep list structure intact.
 | 
						||
If some of these actions get in your way, configure
 | 
						||
`org-list-automatic-rules' to disable them individually.
 | 
						||
 | 
						||
`<TAB>'     (`org-cycle')
 | 
						||
     Items can be folded just like headline levels.  Normally this
 | 
						||
     works only if the cursor is on a plain list item.  For more
 | 
						||
     details, see the variable `org-cycle-include-plain-lists'.  If
 | 
						||
     this variable is set to `integrate', plain list items will be
 | 
						||
     treated like low-level headlines.  The level of an item is then
 | 
						||
     given by the indentation of the bullet/number.  Items are always
 | 
						||
     subordinate to real headlines, however; the hierarchies remain
 | 
						||
     completely separated.  In a new item with no text yet, the first
 | 
						||
     <TAB> demotes the item to become a child of the previous one.
 | 
						||
     Subsequent <TAB>s move the item to meaningful levels in the list
 | 
						||
     and eventually get it back to its initial position.  
 | 
						||
 | 
						||
`M-<RET>'     (`org-insert-heading')
 | 
						||
     Insert new item at current level.  With a prefix argument, force a
 | 
						||
     new heading (*note Structure editing::).  If this command is used
 | 
						||
     in the middle of an item, that item is _split_ in two, and the
 | 
						||
     second part becomes the new item(7).  If this command is executed
 | 
						||
     _before item's body_, the new item is created _before_ the current
 | 
						||
     one.
 | 
						||
 | 
						||
`M-S-<RET>'
 | 
						||
     Insert a new item with a checkbox (*note Checkboxes::).  
 | 
						||
 | 
						||
`S-up'
 | 
						||
`S-down'
 | 
						||
     Jump to the previous/next item in the current list(8), but only if
 | 
						||
     `org-support-shift-select' is off.  If not, you can still use
 | 
						||
     paragraph jumping commands like `C-<up>' and `C-<down>' to quite
 | 
						||
     similar effect.  
 | 
						||
 | 
						||
`M-up'
 | 
						||
`M-down'
 | 
						||
     Move the item including subitems up/down(9) (swap with
 | 
						||
     previous/next item of same indentation).  If the list is ordered,
 | 
						||
     renumbering is automatic.  
 | 
						||
 | 
						||
`M-left'
 | 
						||
`M-right'
 | 
						||
     Decrease/increase the indentation of an item, leaving children
 | 
						||
     alone.  
 | 
						||
 | 
						||
`M-S-<left>'
 | 
						||
`M-S-<right>'
 | 
						||
     Decrease/increase the indentation of the item, including subitems.
 | 
						||
     Initially, the item tree is selected based on current indentation.
 | 
						||
     When these commands are executed several times in direct
 | 
						||
     succession, the initially selected region is used, even if the new
 | 
						||
     indentation would imply a different hierarchy.  To use the new
 | 
						||
     hierarchy, break the command chain with a cursor motion or so.
 | 
						||
 | 
						||
     As a special case, using this command on the very first item of a
 | 
						||
     list will move the whole list.  This behavior can be disabled by
 | 
						||
     configuring `org-list-automatic-rules'.  The global indentation of
 | 
						||
     a list has no influence on the text _after_ the list.  
 | 
						||
 | 
						||
`C-c C-c'
 | 
						||
     If there is a checkbox (*note Checkboxes::) in the item line,
 | 
						||
     toggle the state of the checkbox.  In any case, verify bullets and
 | 
						||
     indentation consistency in the whole list.  
 | 
						||
 | 
						||
`C-c -'
 | 
						||
     Cycle the entire list level through the different
 | 
						||
     itemize/enumerate bullets (`-', `+', `*', `1.', `1)') or a subset
 | 
						||
     of them, depending on `org-plain-list-ordered-item-terminator',
 | 
						||
     the type of list, and its indentation.  With a numeric prefix
 | 
						||
     argument N, select the Nth bullet from this list.  If there is an
 | 
						||
     active region when calling this, selected text will be changed
 | 
						||
     into an item.  With a prefix argument, all lines will be converted
 | 
						||
     to list items.  If the first line already was a list item, any item
 | 
						||
     marker will be removed from the list.  Finally, even without an
 | 
						||
     active region, a normal line will be converted into a list item.  
 | 
						||
 | 
						||
`C-c *'
 | 
						||
     Turn a plain list item into a headline (so that it becomes a
 | 
						||
     subheading at its location).  *Note Structure editing::, for a
 | 
						||
     detailed explanation.  
 | 
						||
 | 
						||
`C-c C-*'
 | 
						||
     Turn the whole plain list into a subtree of the current heading.
 | 
						||
     Checkboxes (*note Checkboxes::) will become TODO (resp. DONE)
 | 
						||
     keywords when unchecked (resp. checked).  
 | 
						||
 | 
						||
`S-left/right'
 | 
						||
     This command also cycles bullet styles when the cursor in on the
 | 
						||
     bullet or anywhere in an item line, details depending on
 | 
						||
     `org-support-shift-select'.  
 | 
						||
 | 
						||
`C-c ^'
 | 
						||
     Sort the plain list.  You will be prompted for the sorting method:
 | 
						||
     numerically, alphabetically, by time, by checked status for check
 | 
						||
     lists, or by a custom function.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) When using `*' as a bullet, lines must be indented or they will
 | 
						||
be seen as top-level headlines.  Also, when you are hiding leading
 | 
						||
stars to get a clean outline view, plain list items starting with a
 | 
						||
star may be hard to distinguish from true headlines.  In short: even
 | 
						||
though `*' is supported, it may be better to not use it for plain list
 | 
						||
items.
 | 
						||
 | 
						||
   (2) You can filter out any of them by configuring
 | 
						||
`org-plain-list-ordered-item-terminator'.
 | 
						||
 | 
						||
   (3) You can also get `a.', `A.', `a)' and `A)' by configuring
 | 
						||
`org-list-allow-alphabetical'.  To minimize confusion with normal text,
 | 
						||
those are limited to one character only.  Beyond that limit, bullets
 | 
						||
will automatically fallback to numbers.
 | 
						||
 | 
						||
   (4) If there's a checkbox in the item, the cookie must be put
 | 
						||
_before_ the checkbox.  If you have activated alphabetical lists, you
 | 
						||
can also use counters like `[@b]'.
 | 
						||
 | 
						||
   (5) See also `org-list-empty-line-terminates-plain-lists'.
 | 
						||
 | 
						||
   (6) Org only changes the filling settings for Emacs.  For XEmacs,
 | 
						||
you should use Kyle E. Jones' `filladapt.el'.  To turn this on, put
 | 
						||
into `.emacs': `(require 'filladapt)'
 | 
						||
 | 
						||
   (7) If you do not want the item to be split, customize the variable
 | 
						||
`org-M-RET-may-split-line'.
 | 
						||
 | 
						||
   (8) If you want to cycle around items that way, you may customize
 | 
						||
`org-list-use-circular-motion'.
 | 
						||
 | 
						||
   (9) See `org-list-use-circular-motion' for a cyclic behavior.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Drawers,  Next: Blocks,  Prev: Plain lists,  Up: Document structure
 | 
						||
 | 
						||
2.8 Drawers
 | 
						||
===========
 | 
						||
 | 
						||
Sometimes you want to keep information associated with an entry, but you
 | 
						||
normally don't want to see it.  For this, Org mode has _drawers_.  They
 | 
						||
can contain anything but a headline and another drawer.  Drawers look
 | 
						||
like this:
 | 
						||
 | 
						||
     ** This is a headline
 | 
						||
        Still outside the drawer
 | 
						||
        :DRAWERNAME:
 | 
						||
        This is inside the drawer.
 | 
						||
        :END:
 | 
						||
        After the drawer.
 | 
						||
 | 
						||
   You can interactively insert drawers at point by calling
 | 
						||
`org-insert-drawer', which is bound to <C-c C-x d>.  With an active
 | 
						||
region, this command will put the region inside the drawer.  With a
 | 
						||
prefix argument, this command calls `org-insert-property-drawer' and
 | 
						||
add a property drawer right below the current headline.  Completion
 | 
						||
over drawer keywords is also possible using <M-TAB>.
 | 
						||
 | 
						||
   Visibility cycling (*note Visibility cycling::) on the headline will
 | 
						||
hide and show the entry, but keep the drawer collapsed to a single
 | 
						||
line.  In order to look inside the drawer, you need to move the cursor
 | 
						||
to the drawer line and press <TAB> there.  Org mode uses the
 | 
						||
`PROPERTIES' drawer for storing properties (*note Properties and
 | 
						||
columns::), and you can also arrange for state change notes (*note
 | 
						||
Tracking TODO state changes::) and clock times (*note Clocking work
 | 
						||
time::) to be stored in a drawer `LOGBOOK'.  If you want to store a
 | 
						||
quick note in the LOGBOOK drawer, in a similar way to state changes, use
 | 
						||
 | 
						||
`C-c C-z'
 | 
						||
     Add a time-stamped note to the LOGBOOK drawer.
 | 
						||
 | 
						||
   You can select the name of the drawers which should be exported with
 | 
						||
`org-export-with-drawers'.  In that case, drawer contents will appear in
 | 
						||
export output.  Property drawers are not affected by this variable:
 | 
						||
configure `org-export-with-properties' instead.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Blocks,  Next: Footnotes,  Prev: Drawers,  Up: Document structure
 | 
						||
 | 
						||
2.9 Blocks
 | 
						||
==========
 | 
						||
 | 
						||
Org mode uses begin...end blocks for various purposes from including
 | 
						||
source code examples (*note Literal examples::) to capturing time
 | 
						||
logging information (*note Clocking work time::).  These blocks can be
 | 
						||
folded and unfolded by pressing TAB in the begin line.  You can also
 | 
						||
get all blocks folded at startup by configuring the option
 | 
						||
`org-hide-block-startup' or on a per-file basis by using
 | 
						||
 | 
						||
     #+STARTUP: hideblocks
 | 
						||
     #+STARTUP: nohideblocks
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Footnotes,  Next: Orgstruct mode,  Prev: Blocks,  Up: Document structure
 | 
						||
 | 
						||
2.10 Footnotes
 | 
						||
==============
 | 
						||
 | 
						||
Org mode supports the creation of footnotes.  In contrast to the
 | 
						||
`footnote.el' package, Org mode's footnotes are designed for work on a
 | 
						||
larger document, not only for one-off documents like emails.
 | 
						||
 | 
						||
   A footnote is started by a footnote marker in square brackets in
 | 
						||
column 0, no indentation allowed.  It ends at the next footnote
 | 
						||
definition, headline, or after two consecutive empty lines.  The
 | 
						||
footnote reference is simply the marker in square brackets, inside
 | 
						||
text.  For example:
 | 
						||
 | 
						||
     The Org homepage[fn:1] now looks a lot better than it used to.
 | 
						||
     ...
 | 
						||
     [fn:1] The link is: http://orgmode.org
 | 
						||
 | 
						||
   Org mode extends the number-based syntax to _named_ footnotes and
 | 
						||
optional inline definition.  Using plain numbers as markers (as
 | 
						||
`footnote.el' does) is supported for backward compatibility, but not
 | 
						||
encouraged because of possible conflicts with LaTeX snippets (*note
 | 
						||
Embedded LaTeX::).  Here are the valid references:
 | 
						||
 | 
						||
`[1]'
 | 
						||
     A plain numeric footnote marker.  Compatible with `footnote.el',
 | 
						||
     but not recommended because something like `[1]' could easily be
 | 
						||
     part of a code snippet.
 | 
						||
 | 
						||
`[fn:name]'
 | 
						||
     A named footnote reference, where `name' is a unique label word,
 | 
						||
     or, for simplicity of automatic creation, a number.
 | 
						||
 | 
						||
`[fn:: This is the inline definition of this footnote]'
 | 
						||
     A LaTeX-like anonymous footnote where the definition is given
 | 
						||
     directly at the reference point.
 | 
						||
 | 
						||
`[fn:name: a definition]'
 | 
						||
     An inline definition of a footnote, which also specifies a name
 | 
						||
     for the note.  Since Org allows multiple references to the same
 | 
						||
     note, you can then use `[fn:name]' to create additional references.
 | 
						||
 | 
						||
   Footnote labels can be created automatically, or you can create
 | 
						||
names yourself.  This is handled by the variable
 | 
						||
`org-footnote-auto-label' and its corresponding `#+STARTUP' keywords.
 | 
						||
See the docstring of that variable for details.
 | 
						||
 | 
						||
The following command handles footnotes:
 | 
						||
 | 
						||
`C-c C-x f'
 | 
						||
     The footnote action command.
 | 
						||
 | 
						||
     When the cursor is on a footnote reference, jump to the
 | 
						||
     definition.  When it is at a definition, jump to the (first)
 | 
						||
     reference.
 | 
						||
 | 
						||
     Otherwise, create a new footnote.  Depending on the option
 | 
						||
     `org-footnote-define-inline'(1), the definition will be placed
 | 
						||
     right into the text as part of the reference, or separately into
 | 
						||
     the location determined by the option `org-footnote-section'.
 | 
						||
 | 
						||
     When this command is called with a prefix argument, a menu of
 | 
						||
     additional options is offered:
 | 
						||
          s   Sort the footnote definitions by reference sequence.  During editing,
 | 
						||
              Org makes no effort to sort footnote definitions into a particular
 | 
						||
              sequence.  If you want them sorted, use this command, which will
 | 
						||
              also move entries according to `org-footnote-section'.  Automatic
 | 
						||
              sorting after each insertion/deletion can be configured using the
 | 
						||
              option `org-footnote-auto-adjust'.
 | 
						||
          r   Renumber the simple `fn:N' footnotes.  Automatic renumbering
 | 
						||
              after each insertion/deletion can be configured using the option
 | 
						||
              `org-footnote-auto-adjust'.
 | 
						||
          S   Short for first `r', then `s' action.
 | 
						||
          n   Normalize the footnotes by collecting all definitions (including
 | 
						||
              inline definitions) into a special section, and then numbering them
 | 
						||
              in sequence.  The references will then also be numbers.  This is
 | 
						||
              meant to be the final step before finishing a document (e.g., sending
 | 
						||
              off an email).
 | 
						||
          d   Delete the footnote at point, and all definitions of and references
 | 
						||
              to it.
 | 
						||
     Depending on the variable `org-footnote-auto-adjust'(2),
 | 
						||
     renumbering and sorting footnotes can be automatic after each
 | 
						||
     insertion or deletion.
 | 
						||
 | 
						||
`C-c C-c'
 | 
						||
     If the cursor is on a footnote reference, jump to the definition.
 | 
						||
     If it is a the definition, jump back to the reference.  When
 | 
						||
     called at a footnote location with a prefix argument, offer the
 | 
						||
     same menu as `C-c C-x f'.  
 | 
						||
 | 
						||
`C-c C-o  or mouse-1/2'
 | 
						||
     Footnote labels are also links to the corresponding
 | 
						||
     definition/reference, and you can use the usual commands to follow
 | 
						||
     these links.
 | 
						||
 | 
						||
`C-c ''
 | 
						||
 | 
						||
`C-c ''
 | 
						||
     Edit the footnote definition corresponding to the reference at
 | 
						||
     point in a seperate window.  This may be useful if editing
 | 
						||
     footnotes in a narrowed buffer.  The window can be closed by
 | 
						||
     pressing `C-c ''.
 | 
						||
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) The corresponding in-buffer setting is: `#+STARTUP: fninline' or
 | 
						||
`#+STARTUP: nofninline'
 | 
						||
 | 
						||
   (2) the corresponding in-buffer options are `fnadjust' and
 | 
						||
`nofnadjust'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Orgstruct mode,  Next: Org syntax,  Prev: Footnotes,  Up: Document structure
 | 
						||
 | 
						||
2.11 The Orgstruct minor mode
 | 
						||
=============================
 | 
						||
 | 
						||
If you like the intuitive way the Org mode structure editing and list
 | 
						||
formatting works, you might want to use these commands in other modes
 | 
						||
like Text mode or Mail mode as well.  The minor mode `orgstruct-mode'
 | 
						||
makes this possible.   Toggle the mode with `M-x orgstruct-mode RET', or
 | 
						||
turn it on by default, for example in Message mode, with one of:
 | 
						||
 | 
						||
     (add-hook 'message-mode-hook 'turn-on-orgstruct)
 | 
						||
     (add-hook 'message-mode-hook 'turn-on-orgstruct++)
 | 
						||
 | 
						||
   When this mode is active and the cursor is on a line that looks to
 | 
						||
Org like a headline or the first line of a list item, most structure
 | 
						||
editing commands will work, even if the same keys normally have
 | 
						||
different functionality in the major mode you are using.  If the cursor
 | 
						||
is not in one of those special lines, Orgstruct mode lurks silently in
 | 
						||
the shadows.
 | 
						||
 | 
						||
   When you use `orgstruct++-mode', Org will also export indentation and
 | 
						||
autofill settings into that mode, and detect item context after the
 | 
						||
first line of an item.
 | 
						||
 | 
						||
   You can also use Org structure editing to fold and unfold headlines
 | 
						||
in _any_ file, provided you defined `orgstruct-heading-prefix-regexp':
 | 
						||
the regular expression must match the local prefix to use before Org's
 | 
						||
headlines.  For example, if you set this variable to `";; "' in Emacs
 | 
						||
Lisp files, you will be able to fold and unfold headlines in Emacs Lisp
 | 
						||
commented lines.  Some commands like `org-demote' are disabled when the
 | 
						||
prefix is set, but folding/unfolding will work correctly.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Org syntax,  Prev: Orgstruct mode,  Up: Document structure
 | 
						||
 | 
						||
2.12 Org syntax
 | 
						||
===============
 | 
						||
 | 
						||
A reference document providing a formal description of Org's syntax is
 | 
						||
available as a draft on Worg
 | 
						||
(http://orgmode.org/worg/dev/org-syntax.html), written and maintained
 | 
						||
by Nicolas Goaziou.  It defines Org's core internal concepts such as
 | 
						||
`headlines', `sections', `affiliated keywords', `(greater) elements'
 | 
						||
and `objects'.  Each part of an Org file falls into one of the
 | 
						||
categories above.
 | 
						||
 | 
						||
   To explore the abstract structure of an Org buffer, run this in a
 | 
						||
buffer:
 | 
						||
 | 
						||
     M-: (org-element-parse-buffer) RET
 | 
						||
 | 
						||
   It will output a list containing the buffer's content represented as
 | 
						||
an abstract structure.  The export engine relies on the information
 | 
						||
stored in this list.  Most interactive commands (e.g., for structure
 | 
						||
editing) also rely on the syntactic meaning of the surrounding context.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Tables,  Next: Hyperlinks,  Prev: Document structure,  Up: Top
 | 
						||
 | 
						||
3 Tables
 | 
						||
********
 | 
						||
 | 
						||
Org comes with a fast and intuitive table editor.  Spreadsheet-like
 | 
						||
calculations are supported using the Emacs `calc' package (*note Calc:
 | 
						||
(calc)Top.).
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Built-in table editor::       Simple tables
 | 
						||
* Column width and alignment::  Overrule the automatic settings
 | 
						||
* Column groups::               Grouping to trigger vertical lines
 | 
						||
* Orgtbl mode::                 The table editor as minor mode
 | 
						||
* The spreadsheet::             The table editor has spreadsheet capabilities
 | 
						||
* Org-Plot::                    Plotting from org tables
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Built-in table editor,  Next: Column width and alignment,  Up: Tables
 | 
						||
 | 
						||
3.1 The built-in table editor
 | 
						||
=============================
 | 
						||
 | 
						||
Org makes it easy to format tables in plain ASCII.  Any line with `|' as
 | 
						||
the first non-whitespace character is considered part of a table.  `|'
 | 
						||
is also the column separator(1).  A table might look like this:
 | 
						||
 | 
						||
     | Name  | Phone | Age |
 | 
						||
     |-------+-------+-----|
 | 
						||
     | Peter |  1234 |  17 |
 | 
						||
     | Anna  |  4321 |  25 |
 | 
						||
 | 
						||
   A table is re-aligned automatically each time you press <TAB> or
 | 
						||
<RET> or `C-c C-c' inside the table.  <TAB> also moves to the next
 | 
						||
field (<RET> to the next row) and creates new table rows at the end of
 | 
						||
the table or before horizontal lines.  The indentation of the table is
 | 
						||
set by the first line.  Any line starting with `|-' is considered as a
 | 
						||
horizontal separator line and will be expanded on the next re-align to
 | 
						||
span the whole table width.  So, to create the above table, you would
 | 
						||
only type
 | 
						||
 | 
						||
     |Name|Phone|Age|
 | 
						||
     |-
 | 
						||
 | 
						||
and then press <TAB> to align the table and start filling in fields.
 | 
						||
Even faster would be to type `|Name|Phone|Age' followed by `C-c <RET>'.
 | 
						||
 | 
						||
   When typing text into a field, Org treats <DEL>, <Backspace>, and
 | 
						||
all character keys in a special way, so that inserting and deleting
 | 
						||
avoids shifting other fields.  Also, when typing _immediately after the
 | 
						||
cursor was moved into a new field with `<TAB>', `S-<TAB>' or `<RET>'_,
 | 
						||
the field is automatically made blank.  If this behavior is too
 | 
						||
unpredictable for you, configure the options `org-enable-table-editor'
 | 
						||
and `org-table-auto-blank-field'.
 | 
						||
 | 
						||
Creation and conversion
 | 
						||
.......................
 | 
						||
 | 
						||
`C-c |     (`org-table-create-or-convert-from-region')'
 | 
						||
     Convert the active region to a table.  If every line contains at
 | 
						||
     least one TAB character, the function assumes that the material is
 | 
						||
     tab separated.  If every line contains a comma, comma-separated
 | 
						||
     values (CSV) are assumed.  If not, lines are split at whitespace
 | 
						||
     into fields.  You can use a prefix argument to force a specific
 | 
						||
     separator: `C-u' forces CSV, `C-u C-u' forces TAB, `C-u C-u C-u'
 | 
						||
     will prompt for a regular expression to match the separator, and a
 | 
						||
     numeric argument N indicates that at least N consecutive spaces,
 | 
						||
     or alternatively a TAB will be the separator.
 | 
						||
     If there is no active region, this command creates an empty Org
 | 
						||
     table.  But it is easier just to start typing, like
 | 
						||
     `|Name|Phone|Age <RET> |- <TAB>'.
 | 
						||
 | 
						||
Re-aligning and field motion
 | 
						||
............................
 | 
						||
 | 
						||
`C-c C-c     (`org-table-align')'
 | 
						||
     Re-align the table and don't move to another field.  
 | 
						||
 | 
						||
`C-c SPC     (`org-table-blank-field')'
 | 
						||
     Blank the field at point.  
 | 
						||
 | 
						||
`<TAB>     (`org-table-next-field')'
 | 
						||
     Re-align the table, move to the next field.  Creates a new row if
 | 
						||
     necessary.  
 | 
						||
 | 
						||
`S-<TAB>     (`org-table-previous-field')'
 | 
						||
     Re-align, move to previous field.  
 | 
						||
 | 
						||
`<RET>     (`org-table-next-row')'
 | 
						||
     Re-align the table and move down to next row.  Creates a new row if
 | 
						||
     necessary.  At the beginning or end of a line, <RET> still does
 | 
						||
     NEWLINE, so it can be used to split a table.  
 | 
						||
 | 
						||
`M-a     (`org-table-beginning-of-field')'
 | 
						||
     Move to beginning of the current table field, or on to the
 | 
						||
     previous field.  
 | 
						||
 | 
						||
`M-e     (`org-table-end-of-field')'
 | 
						||
     Move to end of the current table field, or on to the next field.
 | 
						||
 | 
						||
Column and row editing
 | 
						||
......................
 | 
						||
 | 
						||
`M-<left>     (`org-table-move-column-left')'
 | 
						||
`M-<right>     (`org-table-move-column-right')'
 | 
						||
     Move the current column left/right.  
 | 
						||
 | 
						||
`M-S-<left>     (`org-table-delete-column')'
 | 
						||
     Kill the current column.  
 | 
						||
 | 
						||
`M-S-<right>     (`org-table-insert-column')'
 | 
						||
     Insert a new column to the left of the cursor position.  
 | 
						||
 | 
						||
`M-<up>     (`org-table-move-row-up')'
 | 
						||
`M-<down>     (`org-table-move-row-down')'
 | 
						||
     Move the current row up/down.  
 | 
						||
 | 
						||
`M-S-<up>     (`org-table-kill-row')'
 | 
						||
     Kill the current row or horizontal line.  
 | 
						||
 | 
						||
`M-S-<down>     (`org-table-insert-row')'
 | 
						||
     Insert a new row above the current row.  With a prefix argument,
 | 
						||
     the line is created below the current one.  
 | 
						||
 | 
						||
`C-c -     (`org-table-insert-hline')'
 | 
						||
     Insert a horizontal line below current row.  With a prefix
 | 
						||
     argument, the line is created above the current line.  
 | 
						||
 | 
						||
`C-c <RET>     (`org-table-hline-and-move')'
 | 
						||
     Insert a horizontal line below current row, and move the cursor
 | 
						||
     into the row below that line.  
 | 
						||
 | 
						||
`C-c ^     (`org-table-sort-lines')'
 | 
						||
     Sort the table lines in the region.  The position of point
 | 
						||
     indicates the column to be used for sorting, and the range of
 | 
						||
     lines is the range between the nearest horizontal separator lines,
 | 
						||
     or the entire table.  If point is before the first column, you
 | 
						||
     will be prompted for the sorting column.  If there is an active
 | 
						||
     region, the mark specifies the first line and the sorting column,
 | 
						||
     while point should be in the last line to be included into the
 | 
						||
     sorting.  The command prompts for the sorting type
 | 
						||
     (alphabetically, numerically, or by time).  You can sort in normal
 | 
						||
     or reverse order.  You can also supply your own key extraction and
 | 
						||
     comparison functions.  When called with a prefix argument,
 | 
						||
     alphabetic sorting will be case-sensitive.
 | 
						||
 | 
						||
Regions
 | 
						||
.......
 | 
						||
 | 
						||
`C-c C-x M-w     (`org-table-copy-region')'
 | 
						||
     Copy a rectangular region from a table to a special clipboard.
 | 
						||
     Point and mark determine edge fields of the rectangle.  If there
 | 
						||
     is no active region, copy just the current field.  The process
 | 
						||
     ignores horizontal separator lines.  
 | 
						||
 | 
						||
`C-c C-x C-w     (`org-table-cut-region')'
 | 
						||
     Copy a rectangular region from a table to a special clipboard, and
 | 
						||
     blank all fields in the rectangle.  So this is the "cut" operation.  
 | 
						||
 | 
						||
`C-c C-x C-y     (`org-table-paste-rectangle')'
 | 
						||
     Paste a rectangular region into a table.  The upper left corner
 | 
						||
     ends up in the current field.  All involved fields will be
 | 
						||
     overwritten.  If the rectangle does not fit into the present table,
 | 
						||
     the table is enlarged as needed.  The process ignores horizontal
 | 
						||
     separator lines.  
 | 
						||
 | 
						||
`M-<RET>     (`org-table-wrap-region')'
 | 
						||
     Split the current field at the cursor position and move the rest
 | 
						||
     to the line below.  If there is an active region, and both point
 | 
						||
     and mark are in the same column, the text in the column is wrapped
 | 
						||
     to minimum width for the given number of lines.  A numeric prefix
 | 
						||
     argument may be used to change the number of desired lines.  If
 | 
						||
     there is no region, but you specify a prefix argument, the current
 | 
						||
     field is made blank, and the content is appended to the field
 | 
						||
     above.
 | 
						||
 | 
						||
Calculations
 | 
						||
............
 | 
						||
 | 
						||
`C-c +     (`org-table-sum')'
 | 
						||
     Sum the numbers in the current column, or in the rectangle defined
 | 
						||
     by the active region.  The result is shown in the echo area and can
 | 
						||
     be inserted with `C-y'.  
 | 
						||
 | 
						||
`S-<RET>     (`org-table-copy-down')'
 | 
						||
     When current field is empty, copy from first non-empty field
 | 
						||
     above.  When not empty, copy current field down to next row and
 | 
						||
     move cursor along with it.  Depending on the option
 | 
						||
     `org-table-copy-increment', integer field values will be
 | 
						||
     incremented during copy.  Integers that are too large will not be
 | 
						||
     incremented.  Also, a `0' prefix argument temporarily disables the
 | 
						||
     increment.  This key is also used by shift-selection and related
 | 
						||
     modes (*note Conflicts::).
 | 
						||
 | 
						||
Miscellaneous
 | 
						||
.............
 | 
						||
 | 
						||
`C-c `     (`org-table-edit-field')'
 | 
						||
     Edit the current field in a separate window.  This is useful for
 | 
						||
     fields that are not fully visible (*note Column width and
 | 
						||
     alignment::).  When called with a `C-u' prefix, just make the full
 | 
						||
     field visible, so that it can be edited in place.  When called
 | 
						||
     with two `C-u' prefixes, make the editor window follow the cursor
 | 
						||
     through the table and always show the current field.  The follow
 | 
						||
     mode exits automatically when the cursor leaves the table, or when
 | 
						||
     you repeat this command with `C-u C-u C-c `'.
 | 
						||
 | 
						||
`M-x org-table-import RET'
 | 
						||
     Import a file as a table.  The table should be TAB or whitespace
 | 
						||
     separated.  Use, for example, to import a spreadsheet table or data
 | 
						||
     from a database, because these programs generally can write
 | 
						||
     TAB-separated text files.  This command works by inserting the
 | 
						||
     file into the buffer and then converting the region to a table.
 | 
						||
     Any prefix argument is passed on to the converter, which uses it
 | 
						||
     to determine the separator.  
 | 
						||
 | 
						||
`C-c |     (`org-table-create-or-convert-from-region')'
 | 
						||
     Tables can also be imported by pasting tabular text into the Org
 | 
						||
     buffer, selecting the pasted text with `C-x C-x' and then using the
 | 
						||
     `C-c |' command (see above under Creation and conversion).
 | 
						||
 | 
						||
`M-x org-table-export RET'
 | 
						||
     Export the table, by default as a TAB-separated file.  Use for data
 | 
						||
     exchange with, for example, spreadsheet or database programs.  The
 | 
						||
     format used to export the file can be configured in the option
 | 
						||
     `org-table-export-default-format'.  You may also use properties
 | 
						||
     `TABLE_EXPORT_FILE' and `TABLE_EXPORT_FORMAT' to specify the file
 | 
						||
     name and the format for table export in a subtree.  Org supports
 | 
						||
     quite general formats for exported tables.  The exporter format is
 | 
						||
     the same as the format used by Orgtbl radio tables, see *note
 | 
						||
     Translator functions::, for a detailed description.
 | 
						||
 | 
						||
   If you don't like the automatic table editor because it gets in your
 | 
						||
way on lines which you would like to start with `|', you can turn it
 | 
						||
off with
 | 
						||
 | 
						||
     (setq org-enable-table-editor nil)
 | 
						||
 | 
						||
Then the only table command that still works is `C-c C-c' to do a
 | 
						||
manual re-align.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) To insert a vertical bar into a table field, use `\vert' or,
 | 
						||
inside a word `abc\vert{}def'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Column width and alignment,  Next: Column groups,  Prev: Built-in table editor,  Up: Tables
 | 
						||
 | 
						||
3.2 Column width and alignment
 | 
						||
==============================
 | 
						||
 | 
						||
The width of columns is automatically determined by the table editor.
 | 
						||
And also the alignment of a column is determined automatically from the
 | 
						||
fraction of number-like versus non-number fields in the column.
 | 
						||
 | 
						||
   Sometimes a single field or a few fields need to carry more text,
 | 
						||
leading to inconveniently wide columns.  Or maybe you want to make a
 | 
						||
table with several columns having a fixed width, regardless of content.
 | 
						||
To set(1) the width of a column, one field anywhere in the column may
 | 
						||
contain just the string `<N>' where `N' is an integer specifying the
 | 
						||
width of the column in characters.  The next re-align will then set the
 | 
						||
width of this column to this value.
 | 
						||
 | 
						||
     |---+------------------------------|               |---+--------|
 | 
						||
     |   |                              |               |   | <6>    |
 | 
						||
     | 1 | one                          |               | 1 | one    |
 | 
						||
     | 2 | two                          |     ----\     | 2 | two    |
 | 
						||
     | 3 | This is a long chunk of text |     ----/     | 3 | This=> |
 | 
						||
     | 4 | four                         |               | 4 | four   |
 | 
						||
     |---+------------------------------|               |---+--------|
 | 
						||
 | 
						||
Fields that are wider become clipped and end in the string `=>'.  Note
 | 
						||
that the full text is still in the buffer but is hidden.  To see the
 | 
						||
full text, hold the mouse over the field--a tool-tip window will show
 | 
						||
the full content.  To edit such a field, use the command `C-c `' (that
 | 
						||
is `C-c' followed by the grave accent).  This will open a new window
 | 
						||
with the full field.  Edit it and finish with `C-c C-c'.
 | 
						||
 | 
						||
   When visiting a file containing a table with narrowed columns, the
 | 
						||
necessary character hiding has not yet happened, and the table needs to
 | 
						||
be aligned before it looks nice.  Setting the option
 | 
						||
`org-startup-align-all-tables' will realign all tables in a file upon
 | 
						||
visiting, but also slow down startup.  You can also set this option on
 | 
						||
a per-file basis with:
 | 
						||
 | 
						||
     #+STARTUP: align
 | 
						||
     #+STARTUP: noalign
 | 
						||
 | 
						||
   If you would like to overrule the automatic alignment of number-rich
 | 
						||
columns to the right and of string-rich column to the left, you can use
 | 
						||
`<r>', `<c>'(2) or `<l>' in a similar fashion.  You may also combine
 | 
						||
alignment and field width like this: `<r10>'.
 | 
						||
 | 
						||
   Lines which only contain these formatting cookies will be removed
 | 
						||
automatically when exporting the document.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) This feature does not work on XEmacs.
 | 
						||
 | 
						||
   (2) Centering does not work inside Emacs, but it does have an effect
 | 
						||
when exporting to HTML.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Column groups,  Next: Orgtbl mode,  Prev: Column width and alignment,  Up: Tables
 | 
						||
 | 
						||
3.3 Column groups
 | 
						||
=================
 | 
						||
 | 
						||
When Org exports tables, it does so by default without vertical lines
 | 
						||
because that is visually more satisfying in general.  Occasionally
 | 
						||
however, vertical lines can be useful to structure a table into groups
 | 
						||
of columns, much like horizontal lines can do for groups of rows.  In
 | 
						||
order to specify column groups, you can use a special row where the
 | 
						||
first field contains only `/'.  The further fields can either contain
 | 
						||
`<' to indicate that this column should start a group, `>' to indicate
 | 
						||
the end of a column, or `<>' (no space between `<' and `>') to make a
 | 
						||
column a group of its own.  Boundaries between column groups will upon
 | 
						||
export be marked with vertical lines.  Here is an example:
 | 
						||
 | 
						||
     | N | N^2 | N^3 | N^4 | ~sqrt(n)~ | ~sqrt[4](N)~ |
 | 
						||
     |---+-----+-----+-----+-----------+--------------|
 | 
						||
     | / |   < |     |   > |         < |            > |
 | 
						||
     | 1 |   1 |   1 |   1 |         1 |            1 |
 | 
						||
     | 2 |   4 |   8 |  16 |    1.4142 |       1.1892 |
 | 
						||
     | 3 |   9 |  27 |  81 |    1.7321 |       1.3161 |
 | 
						||
     |---+-----+-----+-----+-----------+--------------|
 | 
						||
     #+TBLFM: $2=$1^2::$3=$1^3::$4=$1^4::$5=sqrt($1)::$6=sqrt(sqrt(($1)))
 | 
						||
 | 
						||
   It is also sufficient to just insert the column group starters after
 | 
						||
every vertical line you would like to have:
 | 
						||
 | 
						||
     |  N | N^2 | N^3 | N^4 | sqrt(n) | sqrt[4](N) |
 | 
						||
     |----+-----+-----+-----+---------+------------|
 | 
						||
     | /  | <   |     |     | <       |            |
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Orgtbl mode,  Next: The spreadsheet,  Prev: Column groups,  Up: Tables
 | 
						||
 | 
						||
3.4 The Orgtbl minor mode
 | 
						||
=========================
 | 
						||
 | 
						||
If you like the intuitive way the Org table editor works, you might
 | 
						||
also want to use it in other modes like Text mode or Mail mode.  The
 | 
						||
minor mode Orgtbl mode makes this possible.  You can always toggle the
 | 
						||
mode with `M-x orgtbl-mode RET'.  To turn it on by default, for example
 | 
						||
in Message mode, use
 | 
						||
 | 
						||
     (add-hook 'message-mode-hook 'turn-on-orgtbl)
 | 
						||
 | 
						||
   Furthermore, with some special setup, it is possible to maintain
 | 
						||
tables in arbitrary syntax with Orgtbl mode.  For example, it is
 | 
						||
possible to construct LaTeX tables with the underlying ease and power of
 | 
						||
Orgtbl mode, including spreadsheet capabilities.  For details, see
 | 
						||
*note Tables in arbitrary syntax::.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: The spreadsheet,  Next: Org-Plot,  Prev: Orgtbl mode,  Up: Tables
 | 
						||
 | 
						||
3.5 The spreadsheet
 | 
						||
===================
 | 
						||
 | 
						||
The table editor makes use of the Emacs `calc' package to implement
 | 
						||
spreadsheet-like capabilities.  It can also evaluate Emacs Lisp forms to
 | 
						||
derive fields from other fields.  While fully featured, Org's
 | 
						||
implementation is not identical to other spreadsheets.  For example,
 | 
						||
Org knows the concept of a _column formula_ that will be applied to all
 | 
						||
non-header fields in a column without having to copy the formula to
 | 
						||
each relevant field.  There is also a formula debugger, and a formula
 | 
						||
editor with features for highlighting fields in the table corresponding
 | 
						||
to the references at the point in the formula, moving these references
 | 
						||
by arrow keys
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* References::                  How to refer to another field or range
 | 
						||
* Formula syntax for Calc::     Using Calc to compute stuff
 | 
						||
* Formula syntax for Lisp::     Writing formulas in Emacs Lisp
 | 
						||
* Durations and time values::   How to compute durations and time values
 | 
						||
* Field and range formulas::    Formula for specific (ranges of) fields
 | 
						||
* Column formulas::             Formulas valid for an entire column
 | 
						||
* Lookup functions::            Lookup functions for searching tables
 | 
						||
* Editing and debugging formulas::  Fixing formulas
 | 
						||
* Updating the table::          Recomputing all dependent fields
 | 
						||
* Advanced features::           Field and column names, parameters and automatic recalc
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: References,  Next: Formula syntax for Calc,  Up: The spreadsheet
 | 
						||
 | 
						||
3.5.1 References
 | 
						||
----------------
 | 
						||
 | 
						||
To compute fields in the table from other fields, formulas must
 | 
						||
reference other fields or ranges.  In Org, fields can be referenced by
 | 
						||
name, by absolute coordinates, and by relative coordinates.  To find
 | 
						||
out what the coordinates of a field are, press `C-c ?' in that field,
 | 
						||
or press `C-c }' to toggle the display of a grid.
 | 
						||
 | 
						||
Field references
 | 
						||
................
 | 
						||
 | 
						||
Formulas can reference the value of another field in two ways.  Like in
 | 
						||
any other spreadsheet, you may reference fields with a letter/number
 | 
						||
combination like `B3', meaning the 2nd field in the 3rd row.  However,
 | 
						||
Org prefers(1) to use another, more general representation that looks
 | 
						||
like this:
 | 
						||
     @ROW$COLUMN
 | 
						||
 | 
						||
   Column specifications can be absolute like `$1', `$2',...`$N', or
 | 
						||
relative to the current column (i.e., the column of the field which is
 | 
						||
being computed) like `$+1' or `$-2'.  `$<' and `$>' are immutable
 | 
						||
references to the first and last column, respectively, and you can use
 | 
						||
`$>>>' to indicate the third column from the right.
 | 
						||
 | 
						||
   The row specification only counts data lines and ignores horizontal
 | 
						||
separator lines (hlines).  Like with columns, you can use absolute row
 | 
						||
numbers `@1', `@2',...`@N', and row numbers relative to the current row
 | 
						||
like `@+3' or `@-1'.  `@<' and `@>' are immutable references the first
 | 
						||
and last(2) row in the table, respectively.  You may also specify the
 | 
						||
row relative to one of the hlines: `@I' refers to the first hline,
 | 
						||
`@II' to the second, etc.  `@-I' refers to the first such line above
 | 
						||
the current line, `@+I' to the first such line below the current line.
 | 
						||
You can also write `@III+2' which is the second data line after the
 | 
						||
third hline in the table.
 | 
						||
 | 
						||
   `@0' and `$0' refer to the current row and column, respectively,
 | 
						||
i.e., to the row/column for the field being computed.  Also, if you omit
 | 
						||
either the column or the row part of the reference, the current
 | 
						||
row/column is implied.
 | 
						||
 | 
						||
   Org's references with _unsigned_ numbers are fixed references in the
 | 
						||
sense that if you use the same reference in the formula for two
 | 
						||
different fields, the same field will be referenced each time.  Org's
 | 
						||
references with _signed_ numbers are floating references because the
 | 
						||
same reference operator can reference different fields depending on the
 | 
						||
field being calculated by the formula.
 | 
						||
 | 
						||
   Here are a few examples:
 | 
						||
 | 
						||
     @2$3      2nd row, 3rd column (same as `C2')
 | 
						||
     $5        column 5 in the current row (same as `E&')
 | 
						||
     @2        current column, row 2
 | 
						||
     @-1$-3    the field one row up, three columns to the left
 | 
						||
     @-I$2     field just under hline above current row, column 2
 | 
						||
     @>$5      field in the last row, in column 5
 | 
						||
 | 
						||
Range references
 | 
						||
................
 | 
						||
 | 
						||
You may reference a rectangular range of fields by specifying two field
 | 
						||
references connected by two dots `..'.  If both fields are in the
 | 
						||
current row, you may simply use `$2..$7', but if at least one field is
 | 
						||
in a different row, you need to use the general `@row$column' format at
 | 
						||
least for the first field (i.e the reference must start with `@' in
 | 
						||
order to be interpreted correctly).  Examples:
 | 
						||
 | 
						||
     $1..$3        first three fields in the current row
 | 
						||
     $P..$Q        range, using column names (see under Advanced)
 | 
						||
     $<<<..$>>     start in third column, continue to the last but one
 | 
						||
     @2$1..@4$3    6 fields between these two fields (same as `A2..C4')
 | 
						||
     @-1$-2..@-1   3 fields in the row above, starting from 2 columns on the left
 | 
						||
     @I..II        between first and second hline, short for `@I..@II'
 | 
						||
 | 
						||
Range references return a vector of values that can be fed into Calc
 | 
						||
vector functions.  Empty fields in ranges are normally suppressed, so
 | 
						||
that the vector contains only the non-empty fields.  For other options
 | 
						||
with the mode switches `E', `N' and examples *note Formula syntax for
 | 
						||
Calc::.
 | 
						||
 | 
						||
Field coordinates in formulas
 | 
						||
.............................
 | 
						||
 | 
						||
One of the very first actions during evaluation of Calc formulas and
 | 
						||
Lisp formulas is to substitute `@#' and `$#' in the formula with the
 | 
						||
row or column number of the field where the current result will go to.
 | 
						||
The traditional Lisp formula equivalents are `org-table-current-dline'
 | 
						||
and `org-table-current-column'.  Examples:
 | 
						||
 | 
						||
`if(@# % 2, $#, string(""))'
 | 
						||
     Insert column number on odd rows, set field to empty on even rows.
 | 
						||
 | 
						||
`$2 = '(identity remote(FOO, @@#$1))'
 | 
						||
     Copy text or values of each row of column 1 of the table named
 | 
						||
     `FOO' into column 2 of the current table.
 | 
						||
 | 
						||
`@3 = 2 * remote(FOO, @1$$#)'
 | 
						||
     Insert the doubled value of each column of row 1 of the table named
 | 
						||
     `FOO' into row 3 of the current table.
 | 
						||
 | 
						||
For the second/third example, the table named `FOO' must have at least
 | 
						||
as many rows/columns as the current table.  Note that this is
 | 
						||
inefficient(3) for large number of rows/columns.
 | 
						||
 | 
						||
Named references
 | 
						||
................
 | 
						||
 | 
						||
`$name' is interpreted as the name of a column, parameter or constant.
 | 
						||
Constants are defined globally through the option
 | 
						||
`org-table-formula-constants', and locally (for the file) through a
 | 
						||
line like
 | 
						||
 | 
						||
     #+CONSTANTS: c=299792458. pi=3.14 eps=2.4e-6
 | 
						||
 | 
						||
Also properties (*note Properties and columns::) can be used as
 | 
						||
constants in table formulas: for a property `:Xyz:' use the name
 | 
						||
`$PROP_Xyz', and the property will be searched in the current outline
 | 
						||
entry and in the hierarchy above it.  If you have the `constants.el'
 | 
						||
package, it will also be used to resolve constants, including natural
 | 
						||
constants like `$h' for Planck's constant, and units like `$km' for
 | 
						||
kilometers(4).  Column names and parameters can be specified in special
 | 
						||
table lines.  These are described below, see *note Advanced features::.
 | 
						||
All names must start with a letter, and further consist of letters and
 | 
						||
numbers.
 | 
						||
 | 
						||
Remote references
 | 
						||
.................
 | 
						||
 | 
						||
You may also reference constants, fields and ranges from a different
 | 
						||
table, either in the current file or even in a different file.  The
 | 
						||
syntax is
 | 
						||
 | 
						||
     remote(NAME-OR-ID,REF)
 | 
						||
 | 
						||
where NAME can be the name of a table in the current file as set by a
 | 
						||
`#+NAME: Name' line before the table.  It can also be the ID of an
 | 
						||
entry, even in a different file, and the reference then refers to the
 | 
						||
first table in that entry.  REF is an absolute field or range reference
 | 
						||
as described above for example `@3$3' or `$somename', valid in the
 | 
						||
referenced table.
 | 
						||
 | 
						||
   Indirection of NAME-OR-ID: When NAME-OR-ID has the format
 | 
						||
`@ROW$COLUMN' it will be substituted with the name or ID found in this
 | 
						||
field of the current table.  For example `remote($1, @>$2)' =>
 | 
						||
`remote(year_2013, @>$1)'.  The format `B3' is not supported because it
 | 
						||
can not be distinguished from a plain table name or ID.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Org will understand references typed by the user as `B4', but it
 | 
						||
will not use this syntax when offering a formula for editing.  You can
 | 
						||
customize this behavior using the option
 | 
						||
`org-table-use-standard-references'.
 | 
						||
 | 
						||
   (2) For backward compatibility you can also use special names like
 | 
						||
`$LR5' and `$LR12' to refer in a stable way to the 5th and 12th field
 | 
						||
in the last row of the table.  However, this syntax is deprecated, it
 | 
						||
should not be used for new documents.  Use `@>$' instead.
 | 
						||
 | 
						||
   (3) The computation time scales as O(N^2) because the table named
 | 
						||
`FOO' is parsed for each field to be read.
 | 
						||
 | 
						||
   (4) `constants.el' can supply the values of constants in two
 | 
						||
different unit systems, `SI' and `cgs'.  Which one is used depends on
 | 
						||
the value of the variable `constants-unit-system'.  You can use the
 | 
						||
`#+STARTUP' options `constSI' and `constcgs' to set this value for the
 | 
						||
current buffer.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Formula syntax for Calc,  Next: Formula syntax for Lisp,  Prev: References,  Up: The spreadsheet
 | 
						||
 | 
						||
3.5.2 Formula syntax for Calc
 | 
						||
-----------------------------
 | 
						||
 | 
						||
A formula can be any algebraic expression understood by the Emacs `Calc'
 | 
						||
package.  Note that `calc' has the non-standard convention that `/' has
 | 
						||
lower precedence than `*', so that `a/b*c' is interpreted as `a/(b*c)'.
 | 
						||
Before evaluation by `calc-eval' (*note calc-eval: (calc)Calling Calc
 | 
						||
from Your Programs.), variable substitution takes place according to the
 | 
						||
rules described above.  The range vectors can be directly fed into the
 | 
						||
Calc vector functions like `vmean' and `vsum'.
 | 
						||
 | 
						||
   A formula can contain an optional mode string after a semicolon.
 | 
						||
This string consists of flags to influence Calc and other modes during
 | 
						||
execution.  By default, Org uses the standard Calc modes (precision 12,
 | 
						||
angular units degrees, fraction and symbolic modes off).  The display
 | 
						||
format, however, has been changed to `(float 8)' to keep tables
 | 
						||
compact.  The default settings can be configured using the option
 | 
						||
`org-calc-default-modes'.
 | 
						||
 | 
						||
List of modes:
 | 
						||
 | 
						||
`p20'
 | 
						||
     Set the internal Calc calculation precision to 20 digits.
 | 
						||
 | 
						||
`n3', `s3', `e2', `f4'
 | 
						||
     Normal, scientific, engineering or fixed format of the result of
 | 
						||
     Calc passed back to Org.  Calc formatting is unlimited in
 | 
						||
     precision as long as the Calc calculation precision is greater.
 | 
						||
 | 
						||
`D', `R'
 | 
						||
     Degree and radian angle modes of Calc.
 | 
						||
 | 
						||
`F', `S'
 | 
						||
     Fraction and symbolic modes of Calc.
 | 
						||
 | 
						||
`T', `t'
 | 
						||
     Duration computations in Calc or Lisp, *note Durations and time
 | 
						||
     values::.
 | 
						||
 | 
						||
`E'
 | 
						||
     If and how to consider empty fields.  Without `E' empty fields in
 | 
						||
     range references are suppressed so that the Calc vector or Lisp
 | 
						||
     list contains only the non-empty fields.  With `E' the empty
 | 
						||
     fields are kept.  For empty fields in ranges or empty field
 | 
						||
     references the value `nan' (not a number) is used in Calc formulas
 | 
						||
     and the empty string is used for Lisp formulas.  Add `N' to use 0
 | 
						||
     instead for both formula types.  For the value of a field the mode
 | 
						||
     `N' has higher precedence than `E'.
 | 
						||
 | 
						||
`N'
 | 
						||
     Interpret all fields as numbers, use 0 for non-numbers.  See the
 | 
						||
     next section to see how this is essential for computations with
 | 
						||
     Lisp formulas.  In Calc formulas it is used only occasionally
 | 
						||
     because there number strings are already interpreted as numbers
 | 
						||
     without `N'.
 | 
						||
 | 
						||
`L'
 | 
						||
     Literal, for Lisp formulas only.  See the next section.
 | 
						||
 | 
						||
Unless you use large integer numbers or high-precision-calculation and
 | 
						||
-display for floating point numbers you may alternatively provide a
 | 
						||
`printf' format specifier to reformat the Calc result after it has been
 | 
						||
passed back to Org instead of letting Calc already do the
 | 
						||
formatting(1).  A few examples:
 | 
						||
 | 
						||
     $1+$2                Sum of first and second field
 | 
						||
     $1+$2;%.2f           Same, format result to two decimals
 | 
						||
     exp($2)+exp($1)      Math functions can be used
 | 
						||
     $0;%.1f              Reformat current cell to 1 decimal
 | 
						||
     ($3-32)*5/9          Degrees F -> C conversion
 | 
						||
     $c/$1/$cm            Hz -> cm conversion, using `constants.el'
 | 
						||
     tan($1);Dp3s1        Compute in degrees, precision 3, display SCI 1
 | 
						||
     sin($1);Dp3%.1e      Same, but use printf specifier for display
 | 
						||
     taylor($3,x=7,2)     Taylor series of $3, at x=7, second degree
 | 
						||
 | 
						||
   Calc also contains a complete set of logical operations, (*note
 | 
						||
Logical Operations: (calc)Logical Operations.).  For example
 | 
						||
 | 
						||
`if($1 < 20, teen, string(""))'
 | 
						||
     "teen" if age $1 is less than 20, else the Org table result field
 | 
						||
     is set to empty with the empty string.
 | 
						||
 | 
						||
`if("$1" == "nan" || "$2" == "nan", string(""), $1 + $2); E f-1'
 | 
						||
     Sum of the first two columns.  When at least one of the input
 | 
						||
     fields is empty the Org table result field is set to empty.  `E'
 | 
						||
     is required to not convert empty fields to 0.  `f-1' is an
 | 
						||
     optional Calc format string similar to `%.1f' but leaves empty
 | 
						||
     results empty.
 | 
						||
 | 
						||
`if(typeof(vmean($1..$7)) == 12, string(""), vmean($1..$7); E'
 | 
						||
     Mean value of a range unless there is any empty field.  Every
 | 
						||
     field in the range that is empty is replaced by `nan' which lets
 | 
						||
     `vmean' result in `nan'.  Then `typeof == 12' detects the `nan'
 | 
						||
     from `vmean' and the Org table result field is set to empty.  Use
 | 
						||
     this when the sample set is expected to never have missing values.
 | 
						||
 | 
						||
`if("$1..$7" == "[]", string(""), vmean($1..$7))'
 | 
						||
     Mean value of a range with empty fields skipped.  Every field in
 | 
						||
     the range that is empty is skipped.  When all fields in the range
 | 
						||
     are empty the mean value is not defined and the Org table result
 | 
						||
     field is set to empty.  Use this when the sample set can have a
 | 
						||
     variable size.
 | 
						||
 | 
						||
`vmean($1..$7); EN'
 | 
						||
     To complete the example before: Mean value of a range with empty
 | 
						||
     fields counting as samples with value 0.  Use this only when
 | 
						||
     incomplete sample sets should be padded with 0 to the full size.
 | 
						||
 | 
						||
   You can add your own Calc functions defined in Emacs Lisp with
 | 
						||
`defmath' and use them in formula syntax for Calc.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) The `printf' reformatting is limited in precision because the
 | 
						||
value passed to it is converted into an `integer' or `double'.  The
 | 
						||
`integer' is limited in size by truncating the signed value to 32 bits.
 | 
						||
The `double' is limited in precision to 64 bits overall which leaves
 | 
						||
approximately 16 significant decimal digits.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Formula syntax for Lisp,  Next: Durations and time values,  Prev: Formula syntax for Calc,  Up: The spreadsheet
 | 
						||
 | 
						||
3.5.3 Emacs Lisp forms as formulas
 | 
						||
----------------------------------
 | 
						||
 | 
						||
It is also possible to write a formula in Emacs Lisp.  This can be
 | 
						||
useful for string manipulation and control structures, if Calc's
 | 
						||
functionality is not enough.
 | 
						||
 | 
						||
   If a formula starts with an apostrophe followed by an opening
 | 
						||
parenthesis, then it is evaluated as a Lisp form.  The evaluation
 | 
						||
should return either a string or a number.  Just as with `calc'
 | 
						||
formulas, you can specify modes and a printf format after a semicolon.
 | 
						||
 | 
						||
   With Emacs Lisp forms, you need to be conscious about the way field
 | 
						||
references are interpolated into the form.  By default, a reference
 | 
						||
will be interpolated as a Lisp string (in double-quotes) containing the
 | 
						||
field.  If you provide the `N' mode switch, all referenced elements
 | 
						||
will be numbers (non-number fields will be zero) and interpolated as
 | 
						||
Lisp numbers, without quotes.  If you provide the `L' flag, all fields
 | 
						||
will be interpolated literally, without quotes.  I.e., if you want a
 | 
						||
reference to be interpreted as a string by the Lisp form, enclose the
 | 
						||
reference operator itself in double-quotes, like `"$3"'.  Ranges are
 | 
						||
inserted as space-separated fields, so you can embed them in list or
 | 
						||
vector syntax.
 | 
						||
 | 
						||
   Here are a few examples--note how the `N' mode is used when we do
 | 
						||
computations in Lisp:
 | 
						||
 | 
						||
`'(concat (substring $1 1 2) (substring $1 0 1) (substring $1 2))'
 | 
						||
     Swap the first two characters of the content of column 1.
 | 
						||
 | 
						||
`'(+ $1 $2);N'
 | 
						||
     Add columns 1 and 2, equivalent to Calc's `$1+$2'.
 | 
						||
 | 
						||
`'(apply '+ '($1..$4));N'
 | 
						||
     Compute the sum of columns 1 to 4, like Calc's `vsum($1..$4)'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Durations and time values,  Next: Field and range formulas,  Prev: Formula syntax for Lisp,  Up: The spreadsheet
 | 
						||
 | 
						||
3.5.4 Durations and time values
 | 
						||
-------------------------------
 | 
						||
 | 
						||
If you want to compute time values use the `T' flag, either in Calc
 | 
						||
formulas or Elisp formulas:
 | 
						||
 | 
						||
       |  Task 1 |   Task 2 |    Total |
 | 
						||
       |---------+----------+----------|
 | 
						||
       |    2:12 |     1:47 | 03:59:00 |
 | 
						||
       | 3:02:20 | -2:07:00 |     0.92 |
 | 
						||
       #+TBLFM: @2$3=$1+$2;T::@3$3=$1+$2;t
 | 
						||
 | 
						||
   Input duration values must be of the form `HH:MM[:SS]', where seconds
 | 
						||
are optional.  With the `T' flag, computed durations will be displayed
 | 
						||
as `HH:MM:SS' (see the first formula above).  With the `t' flag,
 | 
						||
computed durations will be displayed according to the value of the
 | 
						||
option `org-table-duration-custom-format', which defaults to `'hours'
 | 
						||
and will display the result as a fraction of hours (see the second
 | 
						||
formula in the example above).
 | 
						||
 | 
						||
   Negative duration values can be manipulated as well, and integers
 | 
						||
will be considered as seconds in addition and subtraction.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Field and range formulas,  Next: Column formulas,  Prev: Durations and time values,  Up: The spreadsheet
 | 
						||
 | 
						||
3.5.5 Field and range formulas
 | 
						||
------------------------------
 | 
						||
 | 
						||
To assign a formula to a particular field, type it directly into the
 | 
						||
field, preceded by `:=', for example `:=vsum(@II..III)'.  When you press
 | 
						||
<TAB> or <RET> or `C-c C-c' with the cursor still in the field, the
 | 
						||
formula will be stored as the formula for this field, evaluated, and the
 | 
						||
current field will be replaced with the result.
 | 
						||
 | 
						||
   Formulas are stored in a special line starting with `#+TBLFM:'
 | 
						||
directly below the table.  If you type the equation in the 4th field of
 | 
						||
the 3rd data line in the table, the formula will look like
 | 
						||
`@3$4=$1+$2'.  When inserting/deleting/swapping columns and rows with
 | 
						||
the appropriate commands, absolute references (but not relative ones)
 | 
						||
in stored formulas are modified in order to still reference the same
 | 
						||
field.  To avoid this, in particular in range references, anchor ranges
 | 
						||
at the table borders (using `@<', `@>', `$<', `$>'), or at hlines using
 | 
						||
the `@I' notation.  Automatic adaptation of field references does of
 | 
						||
course not happen if you edit the table structure with normal editing
 | 
						||
commands--then you must fix the equations yourself.
 | 
						||
 | 
						||
   Instead of typing an equation into the field, you may also use the
 | 
						||
following command
 | 
						||
 | 
						||
`C-u C-c =     (`org-table-eval-formula')'
 | 
						||
     Install a new formula for the current field.  The command prompts
 | 
						||
     for a formula with default taken from the `#+TBLFM:' line, applies
 | 
						||
     it to the current field, and stores it.
 | 
						||
 | 
						||
   The left-hand side of a formula can also be a special expression in
 | 
						||
order to assign the formula to a number of different fields.  There is
 | 
						||
no keyboard shortcut to enter such range formulas.  To add them, use
 | 
						||
the formula editor (*note Editing and debugging formulas::) or edit the
 | 
						||
`#+TBLFM:' line directly.
 | 
						||
 | 
						||
`$2='
 | 
						||
     Column formula, valid for the entire column.  This is so common
 | 
						||
     that Org treats these formulas in a special way, see *note Column
 | 
						||
     formulas::.
 | 
						||
 | 
						||
`@3='
 | 
						||
     Row formula, applies to all fields in the specified row.  `@>='
 | 
						||
     means the last row.
 | 
						||
 | 
						||
`@1$2..@4$3='
 | 
						||
     Range formula, applies to all fields in the given rectangular
 | 
						||
     range.  This can also be used to assign a formula to some but not
 | 
						||
     all fields in a row.
 | 
						||
 | 
						||
`$name='
 | 
						||
     Named field, see *note Advanced features::.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Column formulas,  Next: Lookup functions,  Prev: Field and range formulas,  Up: The spreadsheet
 | 
						||
 | 
						||
3.5.6 Column formulas
 | 
						||
---------------------
 | 
						||
 | 
						||
When you assign a formula to a simple column reference like `$3=', the
 | 
						||
same formula will be used in all fields of that column, with the
 | 
						||
following very convenient exceptions: (i) If the table contains
 | 
						||
horizontal separator hlines with rows above and below, everything
 | 
						||
before the first such hline is considered part of the table _header_
 | 
						||
and will not be modified by column formulas.  Therefore a header is
 | 
						||
mandatory when you use column formulas and want to add hlines to group
 | 
						||
rows, like for example to separate a total row at the bottom from the
 | 
						||
summand rows above.  (ii) Fields that already get a value from a
 | 
						||
field/range formula will be left alone by column formulas.  These
 | 
						||
conditions make column formulas very easy to use.
 | 
						||
 | 
						||
   To assign a formula to a column, type it directly into any field in
 | 
						||
the column, preceded by an equal sign, like `=$1+$2'.  When you press
 | 
						||
<TAB> or <RET> or `C-c C-c' with the cursor still in the field, the
 | 
						||
formula will be stored as the formula for the current column, evaluated
 | 
						||
and the current field replaced with the result.  If the field contains
 | 
						||
only `=', the previously stored formula for this column is used.  For
 | 
						||
each column, Org will only remember the most recently used formula.  In
 | 
						||
the `#+TBLFM:' line, column formulas will look like `$4=$1+$2'.  The
 | 
						||
left-hand side of a column formula cannot be the name of column, it
 | 
						||
must be the numeric column reference or `$>'.
 | 
						||
 | 
						||
   Instead of typing an equation into the field, you may also use the
 | 
						||
following command:
 | 
						||
 | 
						||
`C-c =     (`org-table-eval-formula')'
 | 
						||
     Install a new formula for the current column and replace current
 | 
						||
     field with the result of the formula.  The command prompts for a
 | 
						||
     formula, with default taken from the `#+TBLFM' line, applies it to
 | 
						||
     the current field and stores it.  With a numeric prefix
 | 
						||
     argument(e.g., `C-5 C-c =') the command will apply it to that many
 | 
						||
     consecutive fields in the current column.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Lookup functions,  Next: Editing and debugging formulas,  Prev: Column formulas,  Up: The spreadsheet
 | 
						||
 | 
						||
3.5.7 Lookup functions
 | 
						||
----------------------
 | 
						||
 | 
						||
Org has three predefined Emacs Lisp functions for lookups in tables.
 | 
						||
`(org-lookup-first VAL S-LIST R-LIST &optional PREDICATE)'
 | 
						||
     Searches for the first element `S' in list `S-LIST' for which
 | 
						||
          (PREDICATE VAL S)
 | 
						||
     is `t'; returns the value from the corresponding position in list
 | 
						||
     `R-LIST'.  The default `PREDICATE' is `equal'.  Note that the
 | 
						||
     parameters `VAL' and `S' are passed to `PREDICATE' in the same
 | 
						||
     order as the corresponding parameters are in the call to
 | 
						||
     `org-lookup-first', where `VAL' precedes `S-LIST'.  If `R-LIST' is
 | 
						||
     `nil', the matching element `S' of `S-LIST' is returned.
 | 
						||
 | 
						||
`(org-lookup-last VAL S-LIST R-LIST &optional PREDICATE)'
 | 
						||
     Similar to `org-lookup-first' above, but searches for the last
 | 
						||
     element for which `PREDICATE' is `t'.
 | 
						||
 | 
						||
`(org-lookup-all VAL S-LIST R-LIST &optional PREDICATE)'
 | 
						||
     Similar to `org-lookup-first', but searches for all elements for
 | 
						||
     which `PREDICATE' is `t', and returns all corresponding values.
 | 
						||
     This function can not be used by itself in a formula, because it
 | 
						||
     returns a list of values.  However, powerful lookups can be built
 | 
						||
     when this function is combined with other Emacs Lisp functions.
 | 
						||
 | 
						||
   If the ranges used in these functions contain empty fields, the `E'
 | 
						||
mode for the formula should usually be specified: otherwise empty
 | 
						||
fields will not be included in `S-LIST' and/or `R-LIST' which can, for
 | 
						||
example, result in an incorrect mapping from an element of `S-LIST' to
 | 
						||
the corresponding element of `R-LIST'.
 | 
						||
 | 
						||
   These three functions can be used to implement associative arrays,
 | 
						||
count matching cells, rank results, group data etc.  For practical
 | 
						||
examples see this tutorial on Worg
 | 
						||
(http://orgmode.org/worg/org-tutorials/org-lookups.html).
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Editing and debugging formulas,  Next: Updating the table,  Prev: Lookup functions,  Up: The spreadsheet
 | 
						||
 | 
						||
3.5.8 Editing and debugging formulas
 | 
						||
------------------------------------
 | 
						||
 | 
						||
You can edit individual formulas in the minibuffer or directly in the
 | 
						||
field.  Org can also prepare a special buffer with all active formulas
 | 
						||
of a table.  When offering a formula for editing, Org converts
 | 
						||
references to the standard format (like `B3' or `D&') if possible.  If
 | 
						||
you prefer to only work with the internal format (like `@3$2' or `$4'),
 | 
						||
configure the option `org-table-use-standard-references'.
 | 
						||
 | 
						||
`C-c =  or  C-u C-c =     (`org-table-eval-formula')'
 | 
						||
     Edit the formula associated with the current column/field in the
 | 
						||
     minibuffer.  See *note Column formulas::, and *note Field and
 | 
						||
     range formulas::.  
 | 
						||
 | 
						||
`C-u C-u C-c =     (`org-table-eval-formula')'
 | 
						||
     Re-insert the active formula (either a field formula, or a column
 | 
						||
     formula) into the current field, so that you can edit it directly
 | 
						||
     in the field.  The advantage over editing in the minibuffer is
 | 
						||
     that you can use the command `C-c ?'.  
 | 
						||
 | 
						||
`C-c ?     (`org-table-field-info')'
 | 
						||
     While editing a formula in a table field, highlight the field(s)
 | 
						||
     referenced by the reference at the cursor position in the formula.  
 | 
						||
 | 
						||
`C-c }'
 | 
						||
     Toggle the display of row and column numbers for a table, using
 | 
						||
     overlays (`org-table-toggle-coordinate-overlays').  These are
 | 
						||
     updated each time the table is aligned; you can force it with `C-c
 | 
						||
     C-c'.  
 | 
						||
 | 
						||
`C-c {'
 | 
						||
     Toggle the formula debugger on and off
 | 
						||
     (`org-table-toggle-formula-debugger').  See below.  
 | 
						||
 | 
						||
`C-c '     (`org-table-edit-formulas')'
 | 
						||
     Edit all formulas for the current table in a special buffer, where
 | 
						||
     the formulas will be displayed one per line.  If the current field
 | 
						||
     has an active formula, the cursor in the formula editor will mark
 | 
						||
     it.  While inside the special buffer, Org will automatically
 | 
						||
     highlight any field or range reference at the cursor position.
 | 
						||
     You may edit, remove and add formulas, and use the following
 | 
						||
     commands:
 | 
						||
 | 
						||
    `C-c C-c  or  C-x C-s     (`org-table-fedit-finish')'
 | 
						||
          Exit the formula editor and store the modified formulas.
 | 
						||
          With `C-u' prefix, also apply the new formulas to the entire
 | 
						||
          table.  
 | 
						||
 | 
						||
    `C-c C-q     (`org-table-fedit-abort')'
 | 
						||
          Exit the formula editor without installing changes.  
 | 
						||
 | 
						||
    `C-c C-r     (`org-table-fedit-toggle-ref-type')'
 | 
						||
          Toggle all references in the formula editor between standard
 | 
						||
          (like `B3') and internal (like `@3$2').  
 | 
						||
 | 
						||
    `<TAB>     (`org-table-fedit-lisp-indent')'
 | 
						||
          Pretty-print or indent Lisp formula at point.  When in a line
 | 
						||
          containing a Lisp formula, format the formula according to
 | 
						||
          Emacs Lisp rules.  Another <TAB> collapses the formula back
 | 
						||
          again.  In the open formula, <TAB> re-indents just like in
 | 
						||
          Emacs Lisp mode.  
 | 
						||
 | 
						||
    `M-<TAB>     (`lisp-complete-symbol')'
 | 
						||
          Complete Lisp symbols, just like in Emacs Lisp mode.  
 | 
						||
 | 
						||
    `S-<up>/<down>/<left>/<right>'
 | 
						||
          Shift the reference at point.  For example, if the reference
 | 
						||
          is `B3' and you press `S-<right>', it will become `C3'.  This
 | 
						||
          also works for relative references and for hline references.  
 | 
						||
 | 
						||
    `M-S-<up>     (`org-table-fedit-line-up')'
 | 
						||
    `M-S-<down>     (`org-table-fedit-line-down')'
 | 
						||
          Move the test line for column formulas in the Org buffer up
 | 
						||
          and down.  
 | 
						||
 | 
						||
    `M-<up>     (`org-table-fedit-scroll-down')'
 | 
						||
    `M-<down>     (`org-table-fedit-scroll-up')'
 | 
						||
          Scroll the window displaying the table.  
 | 
						||
 | 
						||
    `C-c }'
 | 
						||
          Turn the coordinate grid in the table on and off.
 | 
						||
 | 
						||
   Making a table field blank does not remove the formula associated
 | 
						||
with the field, because that is stored in a different line (the
 | 
						||
`#+TBLFM' line)--during the next recalculation the field will be filled
 | 
						||
again.  To remove a formula from a field, you have to give an empty
 | 
						||
reply when prompted for the formula, or to edit the `#+TBLFM' line.
 | 
						||
 | 
						||
   You may edit the `#+TBLFM' directly and re-apply the changed
 | 
						||
equations with `C-c C-c' in that line or with the normal recalculation
 | 
						||
commands in the table.
 | 
						||
 | 
						||
Using multiple #+TBLFM lines
 | 
						||
............................
 | 
						||
 | 
						||
You may apply the formula temporarily.  This is useful when you switch
 | 
						||
the formula.  Place multiple `#+TBLFM' lines right after the table, and
 | 
						||
then press `C-c C-c' on the formula to apply.  Here is an example:
 | 
						||
 | 
						||
     | x | y |
 | 
						||
     |---+---|
 | 
						||
     | 1 |   |
 | 
						||
     | 2 |   |
 | 
						||
     #+TBLFM: $2=$1*1
 | 
						||
     #+TBLFM: $2=$1*2
 | 
						||
 | 
						||
Pressing `C-c C-c' in the line of `#+TBLFM: $2=$1*2' yields:
 | 
						||
 | 
						||
     | x | y |
 | 
						||
     |---+---|
 | 
						||
     | 1 | 2 |
 | 
						||
     | 2 | 4 |
 | 
						||
     #+TBLFM: $2=$1*1
 | 
						||
     #+TBLFM: $2=$1*2
 | 
						||
 | 
						||
Note: If you recalculate this table (with `C-u C-c *', for example), you
 | 
						||
will get the following result of applying only the first `#+TBLFM' line.
 | 
						||
 | 
						||
     | x | y |
 | 
						||
     |---+---|
 | 
						||
     | 1 | 1 |
 | 
						||
     | 2 | 2 |
 | 
						||
     #+TBLFM: $2=$1*1
 | 
						||
     #+TBLFM: $2=$1*2
 | 
						||
 | 
						||
Debugging formulas
 | 
						||
..................
 | 
						||
 | 
						||
When the evaluation of a formula leads to an error, the field content
 | 
						||
becomes the string `#ERROR'.  If you would like see what is going on
 | 
						||
during variable substitution and calculation in order to find a bug,
 | 
						||
turn on formula debugging in the `Tbl' menu and repeat the calculation,
 | 
						||
for example by pressing `C-u C-u C-c = <RET>' in a field.  Detailed
 | 
						||
information will be displayed.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Updating the table,  Next: Advanced features,  Prev: Editing and debugging formulas,  Up: The spreadsheet
 | 
						||
 | 
						||
3.5.9 Updating the table
 | 
						||
------------------------
 | 
						||
 | 
						||
Recalculation of a table is normally not automatic, but needs to be
 | 
						||
triggered by a command.  See *note Advanced features::, for a way to
 | 
						||
make recalculation at least semi-automatic.
 | 
						||
 | 
						||
   In order to recalculate a line of a table or the entire table, use
 | 
						||
the following commands:
 | 
						||
 | 
						||
`C-c *     (`org-table-recalculate')'
 | 
						||
     Recalculate the current row by first applying the stored column
 | 
						||
     formulas from left to right, and all field/range formulas in the
 | 
						||
     current row.  
 | 
						||
 | 
						||
`C-u C-c *'
 | 
						||
`C-u C-c C-c'
 | 
						||
     Recompute the entire table, line by line.  Any lines before the
 | 
						||
     first hline are left alone, assuming that these are part of the
 | 
						||
     table header.  
 | 
						||
 | 
						||
`C-u C-u C-c *  or  C-u C-u C-c C-c     (`org-table-iterate')'
 | 
						||
     Iterate the table by recomputing it until no further changes occur.
 | 
						||
     This may be necessary if some computed fields use the value of
 | 
						||
     other fields that are computed later in the calculation sequence.
 | 
						||
 | 
						||
`M-x org-table-recalculate-buffer-tables RET'
 | 
						||
     Recompute all tables in the current buffer.
 | 
						||
 | 
						||
`M-x org-table-iterate-buffer-tables RET'
 | 
						||
     Iterate all tables in the current buffer, in order to converge
 | 
						||
     table-to-table dependencies.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Advanced features,  Prev: Updating the table,  Up: The spreadsheet
 | 
						||
 | 
						||
3.5.10 Advanced features
 | 
						||
------------------------
 | 
						||
 | 
						||
If you want the recalculation of fields to happen automatically, or if
 | 
						||
you want to be able to assign names(1) to fields and columns, you need
 | 
						||
to reserve the first column of the table for special marking characters.
 | 
						||
 | 
						||
`C-#     (`org-table-rotate-recalc-marks')'
 | 
						||
     Rotate the calculation mark in first column through the states ` ',
 | 
						||
     `#', `*', `!', `$'.  When there is an active region, change all
 | 
						||
     marks in the region.
 | 
						||
 | 
						||
   Here is an example of a table that collects exam results of students
 | 
						||
and makes use of these features:
 | 
						||
 | 
						||
     |---+---------+--------+--------+--------+-------+------|
 | 
						||
     |   | Student | Prob 1 | Prob 2 | Prob 3 | Total | Note |
 | 
						||
     |---+---------+--------+--------+--------+-------+------|
 | 
						||
     | ! |         |     P1 |     P2 |     P3 |   Tot |      |
 | 
						||
     | # | Maximum |     10 |     15 |     25 |    50 | 10.0 |
 | 
						||
     | ^ |         |     m1 |     m2 |     m3 |    mt |      |
 | 
						||
     |---+---------+--------+--------+--------+-------+------|
 | 
						||
     | # | Peter   |     10 |      8 |     23 |    41 |  8.2 |
 | 
						||
     | # | Sam     |      2 |      4 |      3 |     9 |  1.8 |
 | 
						||
     |---+---------+--------+--------+--------+-------+------|
 | 
						||
     |   | Average |        |        |        |  25.0 |      |
 | 
						||
     | ^ |         |        |        |        |    at |      |
 | 
						||
     | $ | max=50  |        |        |        |       |      |
 | 
						||
     |---+---------+--------+--------+--------+-------+------|
 | 
						||
     #+TBLFM: $6=vsum($P1..$P3)::$7=10*$Tot/$max;%.1f::$at=vmean(@-II..@-I);%.1f
 | 
						||
 | 
						||
Important: please note that for these special tables, recalculating the
 | 
						||
table with `C-u C-c *' will only affect rows that are marked `#' or
 | 
						||
`*', and fields that have a formula assigned to the field itself.  The
 | 
						||
column formulas are not applied in rows with empty first field.
 | 
						||
 | 
						||
   The marking characters have the following meaning:
 | 
						||
 | 
						||
`!'
 | 
						||
     The fields in this line define names for the columns, so that you
 | 
						||
     may refer to a column as `$Tot' instead of `$6'.
 | 
						||
 | 
						||
`^'
 | 
						||
     This row defines names for the fields _above_ the row.  With such
 | 
						||
     a definition, any formula in the table may use `$m1' to refer to
 | 
						||
     the value `10'.  Also, if you assign a formula to a names field, it
 | 
						||
     will be stored as `$name=...'.
 | 
						||
 | 
						||
`_'
 | 
						||
     Similar to `^', but defines names for the fields in the row
 | 
						||
     _below_.
 | 
						||
 | 
						||
`$'
 | 
						||
     Fields in this row can define _parameters_ for formulas.  For
 | 
						||
     example, if a field in a `$' row contains `max=50', then formulas
 | 
						||
     in this table can refer to the value 50 using `$max'.  Parameters
 | 
						||
     work exactly like constants, only that they can be defined on a
 | 
						||
     per-table basis.
 | 
						||
 | 
						||
`#'
 | 
						||
     Fields in this row are automatically recalculated when pressing
 | 
						||
     <TAB> or <RET> or `S-<TAB>' in this row.  Also, this row is
 | 
						||
     selected for a global recalculation with `C-u C-c *'.  Unmarked
 | 
						||
     lines will be left alone by this command.
 | 
						||
 | 
						||
`*'
 | 
						||
     Selects this line for global recalculation with `C-u C-c *', but
 | 
						||
     not for automatic recalculation.  Use this when automatic
 | 
						||
     recalculation slows down editing too much.
 | 
						||
 | 
						||
` '
 | 
						||
     Unmarked lines are exempt from recalculation with `C-u C-c *'.
 | 
						||
     All lines that should be recalculated should be marked with `#' or
 | 
						||
     `*'.
 | 
						||
 | 
						||
`/'
 | 
						||
     Do not export this line.  Useful for lines that contain the
 | 
						||
     narrowing `<N>' markers or column group markers.
 | 
						||
 | 
						||
   Finally, just to whet your appetite for what can be done with the
 | 
						||
fantastic `calc.el' package, here is a table that computes the Taylor
 | 
						||
series of degree `n' at location `x' for a couple of functions.
 | 
						||
 | 
						||
     |---+-------------+---+-----+--------------------------------------|
 | 
						||
     |   | Func        | n | x   | Result                               |
 | 
						||
     |---+-------------+---+-----+--------------------------------------|
 | 
						||
     | # | exp(x)      | 1 | x   | 1 + x                                |
 | 
						||
     | # | exp(x)      | 2 | x   | 1 + x + x^2 / 2                      |
 | 
						||
     | # | exp(x)      | 3 | x   | 1 + x + x^2 / 2 + x^3 / 6            |
 | 
						||
     | # | x^2+sqrt(x) | 2 | x=0 | x*(0.5 / 0) + x^2 (2 - 0.25 / 0) / 2 |
 | 
						||
     | # | x^2+sqrt(x) | 2 | x=1 | 2 + 2.5 x - 2.5 + 0.875 (x - 1)^2    |
 | 
						||
     | * | tan(x)      | 3 | x   | 0.0175 x + 1.77e-6 x^3               |
 | 
						||
     |---+-------------+---+-----+--------------------------------------|
 | 
						||
     #+TBLFM: $5=taylor($2,$4,$3);n3
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Such names must start by an alphabetic character and use only
 | 
						||
alphanumeric/underscore characters.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Org-Plot,  Prev: The spreadsheet,  Up: Tables
 | 
						||
 | 
						||
3.6 Org-Plot
 | 
						||
============
 | 
						||
 | 
						||
Org-Plot can produce graphs of information stored in org tables, either
 | 
						||
graphically or in ASCII-art.
 | 
						||
 | 
						||
Graphical plots using `Gnuplot'
 | 
						||
-------------------------------
 | 
						||
 | 
						||
Org-Plot produces 2D and 3D graphs using `Gnuplot'
 | 
						||
`http://www.gnuplot.info/' and `gnuplot-mode'
 | 
						||
`http://xafs.org/BruceRavel/GnuplotMode'.  To see this in action, ensure
 | 
						||
that you have both Gnuplot and Gnuplot mode installed on your system,
 | 
						||
then call `C-c " g' or `M-x org-plot/gnuplot <RET>' on the following
 | 
						||
table.
 | 
						||
 | 
						||
     #+PLOT: title:"Citas" ind:1 deps:(3) type:2d with:histograms set:"yrange [0:]"
 | 
						||
     | Sede      | Max cites | H-index |
 | 
						||
     |-----------+-----------+---------|
 | 
						||
     | Chile     |    257.72 |   21.39 |
 | 
						||
     | Leeds     |    165.77 |   19.68 |
 | 
						||
     | Sao Paolo |     71.00 |   11.50 |
 | 
						||
     | Stockholm |    134.19 |   14.33 |
 | 
						||
     | Morelia   |    257.56 |   17.67 |
 | 
						||
 | 
						||
   Notice that Org Plot is smart enough to apply the table's headers as
 | 
						||
labels.  Further control over the labels, type, content, and appearance
 | 
						||
of plots can be exercised through the `#+PLOT:' lines preceding a
 | 
						||
table.  See below for a complete list of Org-plot options.  The
 | 
						||
`#+PLOT:' lines are optional.  For more information and examples see
 | 
						||
the Org-plot tutorial at
 | 
						||
`http://orgmode.org/worg/org-tutorials/org-plot.html'.
 | 
						||
 | 
						||
Plot Options
 | 
						||
............
 | 
						||
 | 
						||
`set'
 | 
						||
     Specify any `gnuplot' option to be set when graphing.
 | 
						||
 | 
						||
`title'
 | 
						||
     Specify the title of the plot.
 | 
						||
 | 
						||
`ind'
 | 
						||
     Specify which column of the table to use as the `x' axis.
 | 
						||
 | 
						||
`deps'
 | 
						||
     Specify the columns to graph as a Lisp style list, surrounded by
 | 
						||
     parentheses and separated by spaces for example `dep:(3 4)' to
 | 
						||
     graph the third and fourth columns (defaults to graphing all other
 | 
						||
     columns aside from the `ind' column).
 | 
						||
 | 
						||
`type'
 | 
						||
     Specify whether the plot will be `2d', `3d', or `grid'.
 | 
						||
 | 
						||
`with'
 | 
						||
     Specify a `with' option to be inserted for every col being plotted
 | 
						||
     (e.g., `lines', `points', `boxes', `impulses', etc...).  Defaults
 | 
						||
     to `lines'.
 | 
						||
 | 
						||
`file'
 | 
						||
     If you want to plot to a file, specify
 | 
						||
     `"PATH/TO/DESIRED/OUTPUT-FILE"'.
 | 
						||
 | 
						||
`labels'
 | 
						||
     List of labels to be used for the `deps' (defaults to the column
 | 
						||
     headers if they exist).
 | 
						||
 | 
						||
`line'
 | 
						||
     Specify an entire line to be inserted in the Gnuplot script.
 | 
						||
 | 
						||
`map'
 | 
						||
     When plotting `3d' or `grid' types, set this to `t' to graph a
 | 
						||
     flat mapping rather than a `3d' slope.
 | 
						||
 | 
						||
`timefmt'
 | 
						||
     Specify format of Org mode timestamps as they will be parsed by
 | 
						||
     Gnuplot.  Defaults to `%Y-%m-%d-%H:%M:%S'.
 | 
						||
 | 
						||
`script'
 | 
						||
     If you want total control, you can specify a script file (place
 | 
						||
     the file name between double-quotes) which will be used to plot.
 | 
						||
     Before plotting, every instance of `$datafile' in the specified
 | 
						||
     script will be replaced with the path to the generated data file.
 | 
						||
     Note: even if you set this option, you may still want to specify
 | 
						||
     the plot type, as that can impact the content of the data file.
 | 
						||
 | 
						||
ASCII bar plots
 | 
						||
---------------
 | 
						||
 | 
						||
While the cursor is on a column, typing `C-c " a' or `M-x
 | 
						||
orgtbl-ascii-plot <RET>' create a new column containing an ASCII-art
 | 
						||
bars plot.  The plot is implemented through a regular column formula.
 | 
						||
When the source column changes, the bar plot may be updated by
 | 
						||
refreshing the table, for example typing `C-u C-c *'.
 | 
						||
 | 
						||
     | Sede          | Max cites |              |
 | 
						||
     |---------------+-----------+--------------|
 | 
						||
     | Chile         |    257.72 | WWWWWWWWWWWW |
 | 
						||
     | Leeds         |    165.77 | WWWWWWWh     |
 | 
						||
     | Sao Paolo     |     71.00 | WWW;         |
 | 
						||
     | Stockholm     |    134.19 | WWWWWW:      |
 | 
						||
     | Morelia       |    257.56 | WWWWWWWWWWWH |
 | 
						||
     | Rochefourchat |      0.00 |              |
 | 
						||
     #+TBLFM: $3='(orgtbl-ascii-draw $2 0.0 257.72 12)
 | 
						||
 | 
						||
   The formula is an elisp call:
 | 
						||
     (orgtbl-ascii-draw COLUMN MIN MAX WIDTH)
 | 
						||
 | 
						||
`COLUMN'
 | 
						||
     is a reference to the source column.
 | 
						||
 | 
						||
`MIN MAX'
 | 
						||
     are the minimal and maximal values displayed.  Sources values
 | 
						||
     outside this range are displayed as `too small'   or `too large'.
 | 
						||
 | 
						||
`WIDTH'
 | 
						||
     is the width in characters of the bar-plot.  It defaults to `12'.
 | 
						||
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Hyperlinks,  Next: TODO items,  Prev: Tables,  Up: Top
 | 
						||
 | 
						||
4 Hyperlinks
 | 
						||
************
 | 
						||
 | 
						||
Like HTML, Org provides links inside a file, external links to other
 | 
						||
files, Usenet articles, emails, and much more.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Link format::                 How links in Org are formatted
 | 
						||
* Internal links::              Links to other places in the current file
 | 
						||
* External links::              URL-like links to the world
 | 
						||
* Handling links::              Creating, inserting and following
 | 
						||
* Using links outside Org::     Linking from my C source code?
 | 
						||
* Link abbreviations::          Shortcuts for writing complex links
 | 
						||
* Search options::              Linking to a specific location
 | 
						||
* Custom searches::             When the default search is not enough
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Link format,  Next: Internal links,  Up: Hyperlinks
 | 
						||
 | 
						||
4.1 Link format
 | 
						||
===============
 | 
						||
 | 
						||
Org will recognize plain URL-like links and activate them as clickable
 | 
						||
links.  The general link format, however, looks like this:
 | 
						||
 | 
						||
     [[link][description]]       or alternatively           [[link]]
 | 
						||
 | 
						||
Once a link in the buffer is complete (all brackets present), Org will
 | 
						||
change the display so that `description' is displayed instead of
 | 
						||
`[[link][description]]' and `link' is displayed instead of `[[link]]'.
 | 
						||
Links will be highlighted in the face `org-link', which by default is
 | 
						||
an underlined face.  You can directly edit the visible part of a link.
 | 
						||
Note that this can be either the `link' part (if there is no
 | 
						||
description) or the `description' part.  To edit also the invisible
 | 
						||
`link' part, use `C-c C-l' with the cursor on the link.
 | 
						||
 | 
						||
   If you place the cursor at the beginning or just behind the end of
 | 
						||
the displayed text and press <BACKSPACE>, you will remove the
 | 
						||
(invisible) bracket at that location.  This makes the link incomplete
 | 
						||
and the internals are again displayed as plain text.  Inserting the
 | 
						||
missing bracket hides the link internals again.  To show the internal
 | 
						||
structure of all links, use the menu entry `Org->Hyperlinks->Literal
 | 
						||
links'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Internal links,  Next: External links,  Prev: Link format,  Up: Hyperlinks
 | 
						||
 | 
						||
4.2 Internal links
 | 
						||
==================
 | 
						||
 | 
						||
If the link does not look like a URL, it is considered to be internal
 | 
						||
in the current file.  The most important case is a link like
 | 
						||
`[[#my-custom-id]]' which will link to the entry with the `CUSTOM_ID'
 | 
						||
property `my-custom-id'.  You are responsible yourself to make sure
 | 
						||
these custom IDs are unique in a file.
 | 
						||
 | 
						||
   Links such as `[[My Target]]' or `[[My Target][Find my target]]'
 | 
						||
lead to a text search in the current file.
 | 
						||
 | 
						||
   The link can be followed with `C-c C-o' when the cursor is on the
 | 
						||
link, or with a mouse click (*note Handling links::).  Links to custom
 | 
						||
IDs will point to the corresponding headline.  The preferred match for
 | 
						||
a text link is a dedicated target: the same string in double angular
 | 
						||
brackets, like `<<My Target>>'.
 | 
						||
 | 
						||
   If no dedicated target exists, the link will then try to match the
 | 
						||
exact name of an element within the buffer.  Naming is done with the
 | 
						||
`#+NAME' keyword, which has to be put in the line before the element it
 | 
						||
refers to, as in the following example
 | 
						||
 | 
						||
     #+NAME: My Target
 | 
						||
     | a  | table      |
 | 
						||
     |----+------------|
 | 
						||
     | of | four cells |
 | 
						||
 | 
						||
   If none of the above succeeds, Org will search for a headline that
 | 
						||
is exactly the link text but may also include a TODO keyword and
 | 
						||
tags(1).
 | 
						||
 | 
						||
   During export, internal links will be used to mark objects and
 | 
						||
assign them a number.  Marked objects will then be referenced by links
 | 
						||
pointing to them.  In particular, links without a description will
 | 
						||
appear as the number assigned to the marked object(2).  In the
 | 
						||
following excerpt from an Org buffer
 | 
						||
 | 
						||
     - one item
 | 
						||
     - <<target>>another item
 | 
						||
     Here we refer to item [[target]].
 | 
						||
 | 
						||
The last sentence will appear as `Here we refer to item 2' when
 | 
						||
exported.
 | 
						||
 | 
						||
   In non-Org files, the search will look for the words in the link
 | 
						||
text.  In the above example the search would be for `my target'.
 | 
						||
 | 
						||
   Following a link pushes a mark onto Org's own mark ring.  You can
 | 
						||
return to the previous position with `C-c &'.  Using this command
 | 
						||
several times in direct succession goes back to positions recorded
 | 
						||
earlier.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Radio targets::               Make targets trigger links in plain text
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) To insert a link targeting a headline, in-buffer completion can
 | 
						||
be used.  Just type a star followed by a few optional letters into the
 | 
						||
buffer and press `M-<TAB>'.  All headlines in the current buffer will
 | 
						||
be offered as completions.
 | 
						||
 | 
						||
   (2) When targeting a `#+NAME' keyword, `#+CAPTION' keyword is
 | 
						||
mandatory in order to get proper numbering (*note Images and tables::).
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Radio targets,  Up: Internal links
 | 
						||
 | 
						||
4.2.1 Radio targets
 | 
						||
-------------------
 | 
						||
 | 
						||
Org can automatically turn any occurrences of certain target names in
 | 
						||
normal text into a link.  So without explicitly creating a link, the
 | 
						||
text connects to the target radioing its position.  Radio targets are
 | 
						||
enclosed by triple angular brackets.  For example, a target `<<<My
 | 
						||
Target>>>' causes each occurrence of `my target' in normal text to
 | 
						||
become activated as a link.  The Org file is scanned automatically for
 | 
						||
radio targets only when the file is first loaded into Emacs.  To update
 | 
						||
the target list during editing, press `C-c C-c' with the cursor on or
 | 
						||
at a target.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: External links,  Next: Handling links,  Prev: Internal links,  Up: Hyperlinks
 | 
						||
 | 
						||
4.3 External links
 | 
						||
==================
 | 
						||
 | 
						||
Org supports links to files, websites, Usenet and email messages, BBDB
 | 
						||
database entries and links to both IRC conversations and their logs.
 | 
						||
External links are URL-like locators.  They start with a short
 | 
						||
identifying string followed by a colon.  There can be no space after
 | 
						||
the colon.  The following list shows examples for each link type.
 | 
						||
 | 
						||
     http://www.astro.uva.nl/~dominik          on the web
 | 
						||
     doi:10.1000/182                           DOI for an electronic resource
 | 
						||
     file:/home/dominik/images/jupiter.jpg     file, absolute path
 | 
						||
     /home/dominik/images/jupiter.jpg          same as above
 | 
						||
     file:papers/last.pdf                      file, relative path
 | 
						||
     ./papers/last.pdf                         same as above
 | 
						||
     file:/myself@some.where:papers/last.pdf   file, path on remote machine
 | 
						||
     /myself@some.where:papers/last.pdf        same as above
 | 
						||
     file:sometextfile::NNN                    file, jump to line number
 | 
						||
     file:projects.org                         another Org file
 | 
						||
     file:projects.org::some words             text search in Org file(1)
 | 
						||
     file:projects.org::*task title heading search in Org
 | 
						||
     file(2)
 | 
						||
     file+sys:/path/to/file                    open via OS, like double-click
 | 
						||
     file+emacs:/path/to/file                  force opening by Emacs
 | 
						||
     docview:papers/last.pdf::NNN              open in doc-view mode at page
 | 
						||
     id:B7423F4D-2E8A-471B-8810-C40F074717E9   Link to heading by ID
 | 
						||
     news:comp.emacs                           Usenet link
 | 
						||
     mailto:adent@galaxy.net                   Mail link
 | 
						||
     mhe:folder                                MH-E folder link
 | 
						||
     mhe:folder#id                             MH-E message link
 | 
						||
     rmail:folder                              RMAIL folder link
 | 
						||
     rmail:folder#id                           RMAIL message link
 | 
						||
     gnus:group                                Gnus group link
 | 
						||
     gnus:group#id                             Gnus article link
 | 
						||
     bbdb:R.*Stallman                          BBDB link (with regexp)
 | 
						||
     irc:/irc.com/#emacs/bob                   IRC link
 | 
						||
     info:org#External links                   Info node or index link
 | 
						||
     shell:ls *.org                            A shell command
 | 
						||
     elisp:org-agenda                          Interactive Elisp command
 | 
						||
     elisp:(find-file-other-frame "Elisp.org") Elisp form to evaluate
 | 
						||
 | 
						||
   On top of these built-in link types, some are available through the
 | 
						||
`contrib/' directory (*note Installation::).  For example, these links
 | 
						||
to VM or Wanderlust messages are available when you load the
 | 
						||
corresponding libraries from the `contrib/' directory:
 | 
						||
 | 
						||
     vm:folder                                 VM folder link
 | 
						||
     vm:folder#id                              VM message link
 | 
						||
     vm://myself@some.where.org/folder#id      VM on remote machine
 | 
						||
     vm-imap:account:folder                    VM IMAP folder link
 | 
						||
     vm-imap:account:folder#id                 VM IMAP message link
 | 
						||
     wl:folder                                 WANDERLUST folder link
 | 
						||
     wl:folder#id                              WANDERLUST message link
 | 
						||
 | 
						||
   For customizing Org to add new link types *note Adding hyperlink
 | 
						||
types::.
 | 
						||
 | 
						||
   A link should be enclosed in double brackets and may contain a
 | 
						||
descriptive text to be displayed instead of the URL (*note Link
 | 
						||
format::), for example:
 | 
						||
 | 
						||
     [[http://www.gnu.org/software/emacs/][GNU Emacs]]
 | 
						||
 | 
						||
If the description is a file name or URL that points to an image, HTML
 | 
						||
export (*note HTML export::) will inline the image as a clickable
 | 
						||
button.  If there is no description at all and the link points to an
 | 
						||
image, that image will be inlined into the exported HTML file.
 | 
						||
 | 
						||
   Org also finds external links in the normal text and activates them
 | 
						||
as links.  If spaces must be part of the link (for example in
 | 
						||
`bbdb:Richard Stallman'), or if you need to remove ambiguities about
 | 
						||
the end of the link, enclose them in square brackets.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) The actual behavior of the search will depend on the value of
 | 
						||
the option `org-link-search-must-match-exact-headline'.  If its value
 | 
						||
is `nil', then a fuzzy text search will be done.  If it is t, then only
 | 
						||
the exact headline will be matched, ignoring spaces and cookies.  If
 | 
						||
the value is `query-to-create', then an exact headline will be
 | 
						||
searched; if it is not found, then the user will be queried to create
 | 
						||
it.
 | 
						||
 | 
						||
   (2)  Headline searches always match the exact headline, ignoring
 | 
						||
spaces and cookies.  If the headline is not found and the value of the
 | 
						||
option `org-link-search-must-match-exact-headline' is `query-to-create',
 | 
						||
then the user will be queried to create it.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Handling links,  Next: Using links outside Org,  Prev: External links,  Up: Hyperlinks
 | 
						||
 | 
						||
4.4 Handling links
 | 
						||
==================
 | 
						||
 | 
						||
Org provides methods to create a link in the correct syntax, to insert
 | 
						||
it into an Org file, and to follow the link.
 | 
						||
 | 
						||
`C-c l     (`org-store-link')'
 | 
						||
     Store a link to the current location.  This is a _global_ command
 | 
						||
     (you must create the key binding yourself) which can be used in
 | 
						||
     any buffer to create a link.  The link will be stored for later
 | 
						||
     insertion into an Org buffer (see below).  What kind of link will
 | 
						||
     be created depends on the current buffer:
 | 
						||
 | 
						||
     Org mode buffers
 | 
						||
     For Org files, if there is a `<<target>>' at the cursor, the link
 | 
						||
     points to the target.  Otherwise it points to the current
 | 
						||
     headline, which will also be the description(1).
 | 
						||
 | 
						||
     If the headline has a `CUSTOM_ID' property, a link to this custom
 | 
						||
     ID will be stored.  In addition or alternatively (depending on the
 | 
						||
     value of `org-id-link-to-org-use-id'), a globally unique `ID'
 | 
						||
     property will be created and/or used to construct a link(2). So
 | 
						||
     using this command in Org buffers will potentially create two
 | 
						||
     links: a human-readable from the custom ID, and one that is
 | 
						||
     globally unique and works even if the entry is moved from file to
 | 
						||
     file.  Later, when inserting the link, you need to decide which
 | 
						||
     one to use.
 | 
						||
 | 
						||
     Email/News clients: VM, Rmail, Wanderlust, MH-E, Gnus
 | 
						||
     Pretty much all Emacs mail clients are supported.  The link will
 | 
						||
     point to the current article, or, in some GNUS buffers, to the
 | 
						||
     group.  The description is constructed from the author and the
 | 
						||
     subject.
 | 
						||
 | 
						||
     Web browsers: W3 and W3M
 | 
						||
     Here the link will be the current URL, with the page title as
 | 
						||
     description.
 | 
						||
 | 
						||
     Contacts: BBDB
 | 
						||
     Links created in a BBDB buffer will point to the current entry.
 | 
						||
 | 
						||
     Chat: IRC
 | 
						||
     For IRC links, if you set the option `org-irc-link-to-logs' to `t',
 | 
						||
     a `file:/' style link to the relevant point in the logs for the
 | 
						||
     current conversation is created.  Otherwise an `irc:/' style link
 | 
						||
     to the user/channel/server under the point will be stored.
 | 
						||
 | 
						||
     Other files
 | 
						||
     For any other files, the link will point to the file, with a
 | 
						||
     search string (*note Search options::) pointing to the contents of
 | 
						||
     the current line.  If there is an active region, the selected
 | 
						||
     words will form the basis of the search string.  If the
 | 
						||
     automatically created link is not working correctly or accurately
 | 
						||
     enough, you can write custom functions to select the search string
 | 
						||
     and to do the search for particular file types--see *note Custom
 | 
						||
     searches::.  The key binding `C-c l' is only a suggestion--see
 | 
						||
     *note Installation::.
 | 
						||
 | 
						||
     Agenda view
 | 
						||
     When the cursor is in an agenda view, the created link points to
 | 
						||
     the entry referenced by the current line.
 | 
						||
 | 
						||
`C-c C-l     (`org-insert-link')'
 | 
						||
     Insert a link(3).  This prompts for a link to be inserted into the
 | 
						||
     buffer.  You can just type a link, using text for an internal
 | 
						||
     link, or one of the link type prefixes mentioned in the examples
 | 
						||
     above.  The link will be inserted into the buffer(4), along with a
 | 
						||
     descriptive text.  If some text was selected when this command is
 | 
						||
     called, the selected text becomes the default description.
 | 
						||
 | 
						||
     Inserting stored links
 | 
						||
     All links stored during the current session are part of the
 | 
						||
     history for this prompt, so you can access them with <up> and
 | 
						||
     <down> (or `M-p/n').
 | 
						||
 | 
						||
     Completion support
 | 
						||
     Completion with <TAB> will help you to insert valid link prefixes
 | 
						||
     like `http:' or `ftp:', including the prefixes defined through
 | 
						||
     link abbreviations (*note Link abbreviations::).  If you press
 | 
						||
     <RET> after inserting only the PREFIX, Org will offer specific
 | 
						||
     completion support for some link types(5)  For example, if you
 | 
						||
     type `file <RET>', file name completion (alternative access: `C-u
 | 
						||
     C-c C-l', see below) will be offered, and after `bbdb <RET>' you
 | 
						||
     can complete contact names.  
 | 
						||
 | 
						||
`C-u C-c C-l'
 | 
						||
     When `C-c C-l' is called with a `C-u' prefix argument, a link to a
 | 
						||
     file will be inserted and you may use file name completion to
 | 
						||
     select the name of the file.  The path to the file is inserted
 | 
						||
     relative to the directory of the current Org file, if the linked
 | 
						||
     file is in the current directory or in a sub-directory of it, or
 | 
						||
     if the path is written relative to the current directory using
 | 
						||
     `../'.  Otherwise an absolute path is used, if possible with `~/'
 | 
						||
     for your home directory.  You can force an absolute path with two
 | 
						||
     `C-u' prefixes.
 | 
						||
 | 
						||
`C-c C-l  (with cursor on existing link)'
 | 
						||
     When the cursor is on an existing link, `C-c C-l' allows you to
 | 
						||
     edit the link and description parts of the link.  
 | 
						||
 | 
						||
`C-c C-o     (`org-open-at-point')'
 | 
						||
     Open link at point.  This will launch a web browser for URLs (using
 | 
						||
     `browse-url-at-point'), run VM/MH-E/Wanderlust/Rmail/Gnus/BBDB for
 | 
						||
     the corresponding links, and execute the command in a shell link.
 | 
						||
     When the cursor is on an internal link, this command runs the
 | 
						||
     corresponding search.  When the cursor is on a TAG list in a
 | 
						||
     headline, it creates the corresponding TAGS view.  If the cursor
 | 
						||
     is on a timestamp, it compiles the agenda for that date.
 | 
						||
     Furthermore, it will visit text and remote files in `file:' links
 | 
						||
     with Emacs and select a suitable application for local non-text
 | 
						||
     files.  Classification of files is based on file extension only.
 | 
						||
     See option `org-file-apps'.  If you want to override the default
 | 
						||
     application and visit the file with Emacs, use a `C-u' prefix.  If
 | 
						||
     you want to avoid opening in Emacs, use a `C-u C-u' prefix.
 | 
						||
     If the cursor is on a headline, but not on a link, offer all links
 | 
						||
     in the headline and entry text.  If you want to setup the frame
 | 
						||
     configuration for following links, customize
 | 
						||
     `org-link-frame-setup'.
 | 
						||
 | 
						||
`<RET>'
 | 
						||
     When `org-return-follows-link' is set, `<RET>' will also follow
 | 
						||
     the link at point.  
 | 
						||
 | 
						||
`mouse-2'
 | 
						||
`mouse-1'
 | 
						||
     On links, `mouse-2' will open the link just as `C-c C-o' would.
 | 
						||
     Under Emacs 22 and later, `mouse-1' will also follow a link.  
 | 
						||
 | 
						||
`mouse-3'
 | 
						||
     Like `mouse-2', but force file links to be opened with Emacs, and
 | 
						||
     internal links to be displayed in another window(6).  
 | 
						||
 | 
						||
`C-c C-x C-v     (`org-toggle-inline-images')'
 | 
						||
     Toggle the inline display of linked images.  Normally this will
 | 
						||
     only inline images that have no description part in the link,
 | 
						||
     i.e., images that will also be inlined during export.  When called
 | 
						||
     with a prefix argument, also display images that do have a link
 | 
						||
     description.  You can ask for inline images to be displayed at
 | 
						||
     startup by configuring the variable
 | 
						||
     `org-startup-with-inline-images'(7).  
 | 
						||
 | 
						||
`C-c %     (`org-mark-ring-push')'
 | 
						||
     Push the current position onto the mark ring, to be able to return
 | 
						||
     easily.  Commands following an internal link do this automatically.  
 | 
						||
 | 
						||
`C-c &     (`org-mark-ring-goto')'
 | 
						||
     Jump back to a recorded position.  A position is recorded by the
 | 
						||
     commands following internal links, and by `C-c %'.  Using this
 | 
						||
     command several times in direct succession moves through a ring of
 | 
						||
     previously recorded positions.  
 | 
						||
 | 
						||
`C-c C-x C-n     (`org-next-link')'
 | 
						||
`C-c C-x C-p     (`org-previous-link')'
 | 
						||
     Move forward/backward to the next link in the buffer.  At the
 | 
						||
     limit of the buffer, the search fails once, and then wraps around.
 | 
						||
     The key bindings for this are really too long; you might want to
 | 
						||
     bind this also to `C-n' and `C-p'
 | 
						||
          (add-hook 'org-load-hook
 | 
						||
            (lambda ()
 | 
						||
              (define-key org-mode-map "\C-n" 'org-next-link)
 | 
						||
              (define-key org-mode-map "\C-p" 'org-previous-link)))
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) If the headline contains a timestamp, it will be removed from
 | 
						||
the link and result in a wrong link--you should avoid putting timestamp
 | 
						||
in the headline.
 | 
						||
 | 
						||
   (2) The library `org-id.el' must first be loaded, either through
 | 
						||
`org-customize' by enabling `org-id' in `org-modules', or by adding
 | 
						||
`(require 'org-id)' in your `.emacs'.
 | 
						||
 | 
						||
   (3) Note that you don't have to use this command to insert a link.
 | 
						||
Links in Org are plain text, and you can type or paste them straight
 | 
						||
into the buffer.  By using this command, the links are automatically
 | 
						||
enclosed in double brackets, and you will be asked for the optional
 | 
						||
descriptive text.
 | 
						||
 | 
						||
   (4) After insertion of a stored link, the link will be removed from
 | 
						||
the list of stored links.  To keep it in the list later use, use a
 | 
						||
triple `C-u' prefix argument to `C-c C-l', or configure the option
 | 
						||
`org-keep-stored-link-after-insertion'.
 | 
						||
 | 
						||
   (5) This works by calling a special function
 | 
						||
`org-PREFIX-complete-link'.
 | 
						||
 | 
						||
   (6) See the option `org-display-internal-link-with-indirect-buffer'
 | 
						||
 | 
						||
   (7) with corresponding `#+STARTUP' keywords `inlineimages' and
 | 
						||
`noinlineimages'
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Using links outside Org,  Next: Link abbreviations,  Prev: Handling links,  Up: Hyperlinks
 | 
						||
 | 
						||
4.5 Using links outside Org
 | 
						||
===========================
 | 
						||
 | 
						||
You can insert and follow links that have Org syntax not only in Org,
 | 
						||
but in any Emacs buffer.  For this, you should create two global
 | 
						||
commands, like this (please select suitable global keys yourself):
 | 
						||
 | 
						||
     (global-set-key "\C-c L" 'org-insert-link-global)
 | 
						||
     (global-set-key "\C-c o" 'org-open-at-point-global)
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Link abbreviations,  Next: Search options,  Prev: Using links outside Org,  Up: Hyperlinks
 | 
						||
 | 
						||
4.6 Link abbreviations
 | 
						||
======================
 | 
						||
 | 
						||
Long URLs can be cumbersome to type, and often many similar links are
 | 
						||
needed in a document.  For this you can use link abbreviations.  An
 | 
						||
abbreviated link looks like this
 | 
						||
 | 
						||
     [[linkword:tag][description]]
 | 
						||
 | 
						||
where the tag is optional.  The linkword must be a word, starting with
 | 
						||
a letter, followed by letters, numbers, `-', and `_'.  Abbreviations
 | 
						||
are resolved according to the information in the variable
 | 
						||
`org-link-abbrev-alist' that relates the linkwords to replacement text.
 | 
						||
Here is an example:
 | 
						||
 | 
						||
     (setq org-link-abbrev-alist
 | 
						||
       '(("bugzilla"  . "http://10.1.2.9/bugzilla/show_bug.cgi?id=")
 | 
						||
         ("url-to-ja" . "http://translate.google.fr/translate?sl=en&tl=ja&u=%h")
 | 
						||
         ("google"    . "http://www.google.com/search?q=")
 | 
						||
         ("gmap"      . "http://maps.google.com/maps?q=%s")
 | 
						||
         ("omap"      . "http://nominatim.openstreetmap.org/search?q=%s&polygon=1")
 | 
						||
         ("ads"       . "http://adsabs.harvard.edu/cgi-bin/nph-abs_connect?author=%s&db_key=AST")))
 | 
						||
 | 
						||
   If the replacement text contains the string `%s', it will be
 | 
						||
replaced with the tag.  Using `%h' instead of `%s' will url-encode the
 | 
						||
tag (see the example above, where we need to encode the URL parameter.)
 | 
						||
Using `%(my-function)' will pass the tag to a custom function, and
 | 
						||
replace it by the resulting string.
 | 
						||
 | 
						||
   If the replacement text doesn't contain any specifier, it will simply
 | 
						||
be appended to the string in order to create the link.
 | 
						||
 | 
						||
   Instead of a string, you may also specify a function that will be
 | 
						||
called with the tag as the only argument to create the link.
 | 
						||
 | 
						||
   With the above setting, you could link to a specific bug with
 | 
						||
`[[bugzilla:129]]', search the web for `OrgMode' with
 | 
						||
`[[google:OrgMode]]', show the map location of the Free Software
 | 
						||
Foundation `[[gmap:51 Franklin Street, Boston]]' or of Carsten office
 | 
						||
`[[omap:Science Park 904, Amsterdam, The Netherlands]]' and find out
 | 
						||
what the Org author is doing besides Emacs hacking with
 | 
						||
`[[ads:Dominik,C]]'.
 | 
						||
 | 
						||
   If you need special abbreviations just for a single Org buffer, you
 | 
						||
can define them in the file with
 | 
						||
 | 
						||
     #+LINK: bugzilla  http://10.1.2.9/bugzilla/show_bug.cgi?id=
 | 
						||
     #+LINK: google    http://www.google.com/search?q=%s
 | 
						||
 | 
						||
In-buffer completion (*note Completion::) can be used after `[' to
 | 
						||
complete link abbreviations.  You may also define a function
 | 
						||
`org-PREFIX-complete-link' that implements special (e.g., completion)
 | 
						||
support for inserting such a link with `C-c C-l'.  Such a function
 | 
						||
should not accept any arguments, and return the full link with prefix.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Search options,  Next: Custom searches,  Prev: Link abbreviations,  Up: Hyperlinks
 | 
						||
 | 
						||
4.7 Search options in file links
 | 
						||
================================
 | 
						||
 | 
						||
File links can contain additional information to make Emacs jump to a
 | 
						||
particular location in the file when following a link.  This can be a
 | 
						||
line number or a search option after a double(1) colon.  For example,
 | 
						||
when the command `C-c l' creates a link (*note Handling links::) to a
 | 
						||
file, it encodes the words in the current line as a search string that
 | 
						||
can be used to find this line back later when following the link with
 | 
						||
`C-c C-o'.
 | 
						||
 | 
						||
   Here is the syntax of the different ways to attach a search to a file
 | 
						||
link, together with an explanation:
 | 
						||
 | 
						||
     [[file:~/code/main.c::255]]
 | 
						||
     [[file:~/xx.org::My Target]]
 | 
						||
     [[file:~/xx.org::*My Target]]
 | 
						||
     [[file:~/xx.org::#my-custom-id]]
 | 
						||
     [[file:~/xx.org::/regexp/]]
 | 
						||
 | 
						||
`255'
 | 
						||
     Jump to line 255.
 | 
						||
 | 
						||
`My Target'
 | 
						||
     Search for a link target `<<My Target>>', or do a text search for
 | 
						||
     `my target', similar to the search in internal links, see *note
 | 
						||
     Internal links::.  In HTML export (*note HTML export::), such a
 | 
						||
     file link will become an HTML reference to the corresponding named
 | 
						||
     anchor in the linked file.
 | 
						||
 | 
						||
`*My Target'
 | 
						||
     In an Org file, restrict search to headlines.
 | 
						||
 | 
						||
`#my-custom-id'
 | 
						||
     Link to a heading with a `CUSTOM_ID' property
 | 
						||
 | 
						||
`/regexp/'
 | 
						||
     Do a regular expression search for `regexp'.  This uses the Emacs
 | 
						||
     command `occur' to list all matches in a separate window.  If the
 | 
						||
     target file is in Org mode, `org-occur' is used to create a sparse
 | 
						||
     tree with the matches.
 | 
						||
 | 
						||
   As a degenerate case, a file link with an empty file name can be used
 | 
						||
to search the current file.  For example, `[[file:::find me]]' does a
 | 
						||
search for `find me' in the current file, just as `[[find me]]' would.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) For backward compatibility, line numbers can also follow a
 | 
						||
single colon.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Custom searches,  Prev: Search options,  Up: Hyperlinks
 | 
						||
 | 
						||
4.8 Custom Searches
 | 
						||
===================
 | 
						||
 | 
						||
The default mechanism for creating search strings and for doing the
 | 
						||
actual search related to a file link may not work correctly in all
 | 
						||
cases.  For example, BibTeX database files have many entries like
 | 
						||
`year="1993"' which would not result in good search strings, because
 | 
						||
the only unique identification for a BibTeX entry is the citation key.
 | 
						||
 | 
						||
   If you come across such a problem, you can write custom functions to
 | 
						||
set the right search string for a particular file type, and to do the
 | 
						||
search for the string in the file.  Using `add-hook', these functions
 | 
						||
need to be added to the hook variables
 | 
						||
`org-create-file-search-functions' and
 | 
						||
`org-execute-file-search-functions'.  See the docstring for these
 | 
						||
variables for more information.  Org actually uses this mechanism for
 | 
						||
BibTeX database files, and you can use the corresponding code as an
 | 
						||
implementation example.  See the file `org-bibtex.el'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: TODO items,  Next: Tags,  Prev: Hyperlinks,  Up: Top
 | 
						||
 | 
						||
5 TODO items
 | 
						||
************
 | 
						||
 | 
						||
Org mode does not maintain TODO lists as separate documents(1).
 | 
						||
Instead, TODO items are an integral part of the notes file, because
 | 
						||
TODO items usually come up while taking notes!  With Org mode, simply
 | 
						||
mark any entry in a tree as being a TODO item.  In this way,
 | 
						||
information is not duplicated, and the entire context from which the
 | 
						||
TODO item emerged is always present.
 | 
						||
 | 
						||
   Of course, this technique for managing TODO items scatters them
 | 
						||
throughout your notes file.  Org mode compensates for this by providing
 | 
						||
methods to give you an overview of all the things that you have to do.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* TODO basics::                 Marking and displaying TODO entries
 | 
						||
* TODO extensions::             Workflow and assignments
 | 
						||
* Progress logging::            Dates and notes for progress
 | 
						||
* Priorities::                  Some things are more important than others
 | 
						||
* Breaking down tasks::         Splitting a task into manageable pieces
 | 
						||
* Checkboxes::                  Tick-off lists
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Of course, you can make a document that contains only long lists
 | 
						||
of TODO items, but this is not required.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: TODO basics,  Next: TODO extensions,  Up: TODO items
 | 
						||
 | 
						||
5.1 Basic TODO functionality
 | 
						||
============================
 | 
						||
 | 
						||
Any headline becomes a TODO item when it starts with the word `TODO',
 | 
						||
for example:
 | 
						||
 | 
						||
     *** TODO Write letter to Sam Fortune
 | 
						||
 | 
						||
The most important commands to work with TODO entries are:
 | 
						||
 | 
						||
`C-c C-t     (`org-todo')'
 | 
						||
     Rotate the TODO state of the current item among
 | 
						||
 | 
						||
          ,-> (unmarked) -> TODO -> DONE --.
 | 
						||
          '--------------------------------'
 | 
						||
 | 
						||
     If TODO keywords have fast access keys (see *note Fast access to
 | 
						||
     TODO states::), you will be prompted for a TODO keyword through
 | 
						||
     the fast selection interface; this is the default behavior when
 | 
						||
     `org-use-fast-todo-selection' is non-`nil'.
 | 
						||
 | 
						||
     The same rotation can also be done "remotely" from the timeline
 | 
						||
     and agenda buffers with the `t' command key (*note Agenda
 | 
						||
     commands::).
 | 
						||
 | 
						||
`C-u C-c C-t'
 | 
						||
     When TODO keywords have no selection keys, select a specific
 | 
						||
     keyword using completion; otherwise force cycling through TODO
 | 
						||
     states with no prompt.  When `org-use-fast-todo-selection' is set
 | 
						||
     to `prefix', use the fast selection interface.
 | 
						||
 | 
						||
`S-<right>  /  S-<left>'
 | 
						||
     Select the following/preceding TODO state, similar to cycling.
 | 
						||
     Useful mostly if more than two TODO states are possible (*note
 | 
						||
     TODO extensions::).  See also *note Conflicts::, for a discussion
 | 
						||
     of the interaction with `shift-selection-mode'.  See also the
 | 
						||
     variable `org-treat-S-cursor-todo-selection-as-state-change'.  
 | 
						||
 | 
						||
`C-c / t     (`org-show-todo-tree')'
 | 
						||
     View TODO items in a _sparse tree_ (*note Sparse trees::).  Folds
 | 
						||
     the entire buffer, but shows all TODO items (with not-DONE state)
 | 
						||
     and the headings hierarchy above them.  With a prefix argument (or
 | 
						||
     by using `C-c / T'), search for a specific TODO.  You will be
 | 
						||
     prompted for the keyword, and you can also give a list of keywords
 | 
						||
     like `KWD1|KWD2|...' to list entries that match any one of these
 | 
						||
     keywords.  With a numeric prefix argument N, show the tree for the
 | 
						||
     Nth keyword in the option `org-todo-keywords'.  With two prefix
 | 
						||
     arguments, find all TODO states, both un-done and done.  
 | 
						||
 | 
						||
`C-c a t     (`org-todo-list')'
 | 
						||
     Show the global TODO list.  Collects the TODO items (with not-DONE
 | 
						||
     states) from all agenda files (*note Agenda views::) into a single
 | 
						||
     buffer.  The new buffer will be in `agenda-mode', which provides
 | 
						||
     commands to examine and manipulate the TODO entries from the new
 | 
						||
     buffer (*note Agenda commands::).  *Note Global TODO list::, for
 | 
						||
     more information.  
 | 
						||
 | 
						||
`S-M-<RET>     (`org-insert-todo-heading')'
 | 
						||
     Insert a new TODO entry below the current one.
 | 
						||
 | 
						||
Changing a TODO state can also trigger tag changes.  See the docstring
 | 
						||
of the option `org-todo-state-tags-triggers' for details.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: TODO extensions,  Next: Progress logging,  Prev: TODO basics,  Up: TODO items
 | 
						||
 | 
						||
5.2 Extended use of TODO keywords
 | 
						||
=================================
 | 
						||
 | 
						||
By default, marked TODO entries have one of only two states: TODO and
 | 
						||
DONE.  Org mode allows you to classify TODO items in more complex ways
 | 
						||
with _TODO keywords_ (stored in `org-todo-keywords').  With special
 | 
						||
setup, the TODO keyword system can work differently in different files.
 | 
						||
 | 
						||
   Note that tags are another way to classify headlines in general and
 | 
						||
TODO items in particular (*note Tags::).
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Workflow states::             From TODO to DONE in steps
 | 
						||
* TODO types::                  I do this, Fred does the rest
 | 
						||
* Multiple sets in one file::   Mixing it all, and still finding your way
 | 
						||
* Fast access to TODO states::  Single letter selection of a state
 | 
						||
* Per-file keywords::           Different files, different requirements
 | 
						||
* Faces for TODO keywords::     Highlighting states
 | 
						||
* TODO dependencies::           When one task needs to wait for others
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Workflow states,  Next: TODO types,  Up: TODO extensions
 | 
						||
 | 
						||
5.2.1 TODO keywords as workflow states
 | 
						||
--------------------------------------
 | 
						||
 | 
						||
You can use TODO keywords to indicate different _sequential_ states in
 | 
						||
the process of working on an item, for example(1):
 | 
						||
 | 
						||
     (setq org-todo-keywords
 | 
						||
       '((sequence "TODO" "FEEDBACK" "VERIFY" "|" "DONE" "DELEGATED")))
 | 
						||
 | 
						||
   The vertical bar separates the TODO keywords (states that _need
 | 
						||
action_) from the DONE states (which need _no further action_).  If you
 | 
						||
don't provide the separator bar, the last state is used as the DONE
 | 
						||
state.  With this setup, the command `C-c C-t' will cycle an entry from
 | 
						||
TODO to FEEDBACK, then to VERIFY, and finally to DONE and DELEGATED.
 | 
						||
You may also use a numeric prefix argument to quickly select a specific
 | 
						||
state.  For example `C-3 C-c C-t' will change the state immediately to
 | 
						||
VERIFY.  Or you can use `S-<left>' to go backward through the sequence.
 | 
						||
If you define many keywords, you can use in-buffer completion (*note
 | 
						||
Completion::) or even a special one-key selection scheme (*note Fast
 | 
						||
access to TODO states::) to insert these words into the buffer.
 | 
						||
Changing a TODO state can be logged with a timestamp, see *note
 | 
						||
Tracking TODO state changes::, for more information.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Changing this variable only becomes effective after restarting
 | 
						||
Org mode in a buffer.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: TODO types,  Next: Multiple sets in one file,  Prev: Workflow states,  Up: TODO extensions
 | 
						||
 | 
						||
5.2.2 TODO keywords as types
 | 
						||
----------------------------
 | 
						||
 | 
						||
The second possibility is to use TODO keywords to indicate different
 | 
						||
_types_ of action items.  For example, you might want to indicate that
 | 
						||
items are for "work" or "home".  Or, when you work with several people
 | 
						||
on a single project, you might want to assign action items directly to
 | 
						||
persons, by using their names as TODO keywords.  This would be set up
 | 
						||
like this:
 | 
						||
 | 
						||
     (setq org-todo-keywords '((type "Fred" "Sara" "Lucy" "|" "DONE")))
 | 
						||
 | 
						||
   In this case, different keywords do not indicate a sequence, but
 | 
						||
rather different types.  So the normal work flow would be to assign a
 | 
						||
task to a person, and later to mark it DONE.  Org mode supports this
 | 
						||
style by adapting the workings of the command `C-c C-t'(1).  When used
 | 
						||
several times in succession, it will still cycle through all names, in
 | 
						||
order to first select the right type for a task.  But when you return
 | 
						||
to the item after some time and execute `C-c C-t' again, it will switch
 | 
						||
from any name directly to DONE.  Use prefix arguments or completion to
 | 
						||
quickly select a specific name.  You can also review the items of a
 | 
						||
specific TODO type in a sparse tree by using a numeric prefix to `C-c /
 | 
						||
t'.  For example, to see all things Lucy has to do, you would use `C-3
 | 
						||
C-c / t'.  To collect Lucy's items from all agenda files into a single
 | 
						||
buffer, you would use the numeric prefix argument as well when creating
 | 
						||
the global TODO list: `C-3 C-c a t'.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) This is also true for the `t' command in the timeline and agenda
 | 
						||
buffers.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Multiple sets in one file,  Next: Fast access to TODO states,  Prev: TODO types,  Up: TODO extensions
 | 
						||
 | 
						||
5.2.3 Multiple keyword sets in one file
 | 
						||
---------------------------------------
 | 
						||
 | 
						||
Sometimes you may want to use different sets of TODO keywords in
 | 
						||
parallel.  For example, you may want to have the basic `TODO'/`DONE',
 | 
						||
but also a workflow for bug fixing, and a separate state indicating
 | 
						||
that an item has been canceled (so it is not DONE, but also does not
 | 
						||
require action).  Your setup would then look like this:
 | 
						||
 | 
						||
     (setq org-todo-keywords
 | 
						||
           '((sequence "TODO" "|" "DONE")
 | 
						||
             (sequence "REPORT" "BUG" "KNOWNCAUSE" "|" "FIXED")
 | 
						||
             (sequence "|" "CANCELED")))
 | 
						||
 | 
						||
   The keywords should all be different, this helps Org mode to keep
 | 
						||
track of which subsequence should be used for a given entry.  In this
 | 
						||
setup, `C-c C-t' only operates within a subsequence, so it switches from
 | 
						||
`DONE' to (nothing) to `TODO', and from `FIXED' to (nothing) to
 | 
						||
`REPORT'.  Therefore you need a mechanism to initially select the
 | 
						||
correct sequence.  Besides the obvious ways like typing a keyword or
 | 
						||
using completion, you may also apply the following commands:
 | 
						||
 | 
						||
`C-u C-u C-c C-t'
 | 
						||
`C-S-<right>'
 | 
						||
`C-S-<left>'
 | 
						||
     These keys jump from one TODO subset to the next.  In the above
 | 
						||
     example, `C-u C-u C-c C-t' or `C-S-<right>' would jump from `TODO'
 | 
						||
     or `DONE' to `REPORT', and any of the words in the second row to
 | 
						||
     `CANCELED'.  Note that the `C-S-' key binding conflict with
 | 
						||
     `shift-selection-mode' (*note Conflicts::).  
 | 
						||
 | 
						||
`S-<right>'
 | 
						||
`S-<left>'
 | 
						||
     `S-<left>' and `S-<right>' and walk through _all_ keywords from
 | 
						||
     all sets, so for example `S-<right>' would switch from `DONE' to
 | 
						||
     `REPORT' in the example above.  See also *note Conflicts::, for a
 | 
						||
     discussion of the interaction with `shift-selection-mode'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Fast access to TODO states,  Next: Per-file keywords,  Prev: Multiple sets in one file,  Up: TODO extensions
 | 
						||
 | 
						||
5.2.4 Fast access to TODO states
 | 
						||
--------------------------------
 | 
						||
 | 
						||
If you would like to quickly change an entry to an arbitrary TODO state
 | 
						||
instead of cycling through the states, you can set up keys for
 | 
						||
single-letter access to the states.  This is done by adding the
 | 
						||
selection character after each keyword, in parentheses(1).  For example:
 | 
						||
 | 
						||
     (setq org-todo-keywords
 | 
						||
           '((sequence "TODO(t)" "|" "DONE(d)")
 | 
						||
             (sequence "REPORT(r)" "BUG(b)" "KNOWNCAUSE(k)" "|" "FIXED(f)")
 | 
						||
             (sequence "|" "CANCELED(c)")))
 | 
						||
 | 
						||
   If you then press `C-c C-t' followed by the selection key, the entry
 | 
						||
will be switched to this state.  `SPC' can be used to remove any TODO
 | 
						||
keyword from an entry.(2)
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) All characters are allowed except `@^!', which have a special
 | 
						||
meaning here.
 | 
						||
 | 
						||
   (2) Check also the option `org-fast-tag-selection-include-todo', it
 | 
						||
allows you to change the TODO state through the tags interface (*note
 | 
						||
Setting tags::), in case you like to mingle the two concepts.  Note
 | 
						||
that this means you need to come up with unique keys across both sets
 | 
						||
of keywords.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Per-file keywords,  Next: Faces for TODO keywords,  Prev: Fast access to TODO states,  Up: TODO extensions
 | 
						||
 | 
						||
5.2.5 Setting up keywords for individual files
 | 
						||
----------------------------------------------
 | 
						||
 | 
						||
It can be very useful to use different aspects of the TODO mechanism in
 | 
						||
different files.  For file-local settings, you need to add special
 | 
						||
lines to the file which set the keywords and interpretation for that
 | 
						||
file only.  For example, to set one of the two examples discussed
 | 
						||
above, you need one of the following lines anywhere in the file:
 | 
						||
 | 
						||
     #+TODO: TODO FEEDBACK VERIFY | DONE CANCELED
 | 
						||
   (you may also write `#+SEQ_TODO' to be explicit about the
 | 
						||
interpretation, but it means the same as `#+TODO'), or
 | 
						||
     #+TYP_TODO: Fred Sara Lucy Mike | DONE
 | 
						||
 | 
						||
   A setup for using several sets in parallel would be:
 | 
						||
 | 
						||
     #+TODO: TODO | DONE
 | 
						||
     #+TODO: REPORT BUG KNOWNCAUSE | FIXED
 | 
						||
     #+TODO: | CANCELED
 | 
						||
 | 
						||
To make sure you are using the correct keyword, type `#+' into the
 | 
						||
buffer and then use `M-<TAB>' completion.
 | 
						||
 | 
						||
   Remember that the keywords after the vertical bar (or the last
 | 
						||
keyword if no bar is there) must always mean that the item is DONE
 | 
						||
(although you may use a different word).  After changing one of these
 | 
						||
lines, use `C-c C-c' with the cursor still in the line to make the
 | 
						||
changes known to Org mode(1).
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Org mode parses these lines only when Org mode is activated
 | 
						||
after visiting a file.  `C-c C-c' with the cursor in a line starting
 | 
						||
with `#+' is simply restarting Org mode for the current buffer.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Faces for TODO keywords,  Next: TODO dependencies,  Prev: Per-file keywords,  Up: TODO extensions
 | 
						||
 | 
						||
5.2.6 Faces for TODO keywords
 | 
						||
-----------------------------
 | 
						||
 | 
						||
Org mode highlights TODO keywords with special faces: `org-todo' for
 | 
						||
keywords indicating that an item still has to be acted upon, and
 | 
						||
`org-done' for keywords indicating that an item is finished.  If you
 | 
						||
are using more than 2 different states, you might want to use special
 | 
						||
faces for some of them.  This can be done using the option
 | 
						||
`org-todo-keyword-faces'.  For example:
 | 
						||
 | 
						||
     (setq org-todo-keyword-faces
 | 
						||
           '(("TODO" . org-warning) ("STARTED" . "yellow")
 | 
						||
             ("CANCELED" . (:foreground "blue" :weight bold))))
 | 
						||
 | 
						||
   While using a list with face properties as shown for CANCELED
 | 
						||
_should_ work, this does not always seem to be the case.  If necessary,
 | 
						||
define a special face and use that.  A string is interpreted as a
 | 
						||
color.  The option `org-faces-easy-properties' determines if that color
 | 
						||
is interpreted as a foreground or a background color.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: TODO dependencies,  Prev: Faces for TODO keywords,  Up: TODO extensions
 | 
						||
 | 
						||
5.2.7 TODO dependencies
 | 
						||
-----------------------
 | 
						||
 | 
						||
The structure of Org files (hierarchy and lists) makes it easy to
 | 
						||
define TODO dependencies.  Usually, a parent TODO task should not be
 | 
						||
marked DONE until all subtasks (defined as children tasks) are marked
 | 
						||
as DONE.  And sometimes there is a logical sequence to a number of
 | 
						||
(sub)tasks, so that one task cannot be acted upon before all siblings
 | 
						||
above it are done.  If you customize the option
 | 
						||
`org-enforce-todo-dependencies', Org will block entries from changing
 | 
						||
state to DONE while they have children that are not DONE.  Furthermore,
 | 
						||
if an entry has a property `ORDERED', each of its children will be
 | 
						||
blocked until all earlier siblings are marked DONE.  Here is an example:
 | 
						||
 | 
						||
     * TODO Blocked until (two) is done
 | 
						||
     ** DONE one
 | 
						||
     ** TODO two
 | 
						||
 | 
						||
     * Parent
 | 
						||
       :PROPERTIES:
 | 
						||
       :ORDERED: t
 | 
						||
       :END:
 | 
						||
     ** TODO a
 | 
						||
     ** TODO b, needs to wait for (a)
 | 
						||
     ** TODO c, needs to wait for (a) and (b)
 | 
						||
 | 
						||
   You can ensure an entry is never blocked by using the `NOBLOCKING'
 | 
						||
property:
 | 
						||
 | 
						||
     * This entry is never blocked
 | 
						||
       :PROPERTIES:
 | 
						||
       :NOBLOCKING: t
 | 
						||
       :END:
 | 
						||
 | 
						||
`C-c C-x o     (`org-toggle-ordered-property')'
 | 
						||
     Toggle the `ORDERED' property of the current entry.  A property is
 | 
						||
     used for this behavior because this should be local to the current
 | 
						||
     entry, not inherited like a tag.  However, if you would like to
 | 
						||
     track the value of this property with a tag for better visibility,
 | 
						||
     customize the option `org-track-ordered-property-with-tag'.  
 | 
						||
 | 
						||
`C-u C-u C-u C-c C-t'
 | 
						||
     Change TODO state, circumventing any state blocking.
 | 
						||
 | 
						||
   If you set the option `org-agenda-dim-blocked-tasks', TODO entries
 | 
						||
that cannot be closed because of such dependencies will be shown in a
 | 
						||
dimmed font or even made invisible in agenda views (*note Agenda
 | 
						||
views::).
 | 
						||
 | 
						||
   You can also block changes of TODO states by looking at checkboxes
 | 
						||
(*note Checkboxes::).  If you set the option
 | 
						||
`org-enforce-todo-checkbox-dependencies', an entry that has unchecked
 | 
						||
checkboxes will be blocked from switching to DONE.
 | 
						||
 | 
						||
   If you need more complex dependency structures, for example
 | 
						||
dependencies between entries in different trees or files, check out the
 | 
						||
contributed module `org-depend.el'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Progress logging,  Next: Priorities,  Prev: TODO extensions,  Up: TODO items
 | 
						||
 | 
						||
5.3 Progress logging
 | 
						||
====================
 | 
						||
 | 
						||
Org mode can automatically record a timestamp and possibly a note when
 | 
						||
you mark a TODO item as DONE, or even each time you change the state of
 | 
						||
a TODO item.  This system is highly configurable; settings can be on a
 | 
						||
per-keyword basis and can be localized to a file or even a subtree.  For
 | 
						||
information on how to clock working time for a task, see *note Clocking
 | 
						||
work time::.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Closing items::               When was this entry marked DONE?
 | 
						||
* Tracking TODO state changes::  When did the status change?
 | 
						||
* Tracking your habits::        How consistent have you been?
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Closing items,  Next: Tracking TODO state changes,  Up: Progress logging
 | 
						||
 | 
						||
5.3.1 Closing items
 | 
						||
-------------------
 | 
						||
 | 
						||
The most basic logging is to keep track of _when_ a certain TODO item
 | 
						||
was finished.  This is achieved with(1)
 | 
						||
 | 
						||
     (setq org-log-done 'time)
 | 
						||
 | 
						||
Then each time you turn an entry from a TODO (not-done) state into any
 | 
						||
of the DONE states, a line `CLOSED: [timestamp]' will be inserted just
 | 
						||
after the headline.  If you turn the entry back into a TODO item
 | 
						||
through further state cycling, that line will be removed again.  If you
 | 
						||
turn the entry back to a non-TODO state (by pressing <C-c C-t SPC> for
 | 
						||
example), that line will also be removed, unless you set
 | 
						||
`org-closed-keep-when-no-todo' to non-`nil'.  If you want to record a
 | 
						||
note along with the timestamp, use(2)
 | 
						||
 | 
						||
     (setq org-log-done 'note)
 | 
						||
 | 
						||
You will then be prompted for a note, and that note will be stored below
 | 
						||
the entry with a `Closing Note' heading.
 | 
						||
 | 
						||
   In the timeline (*note Timeline::) and in the agenda (*note
 | 
						||
Weekly/daily agenda::), you can then use the `l' key to display the
 | 
						||
TODO items with a `CLOSED' timestamp on each day, giving you an
 | 
						||
overview of what has been done.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) The corresponding in-buffer setting is: `#+STARTUP: logdone'
 | 
						||
 | 
						||
   (2) The corresponding in-buffer setting is: `#+STARTUP: lognotedone'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Tracking TODO state changes,  Next: Tracking your habits,  Prev: Closing items,  Up: Progress logging
 | 
						||
 | 
						||
5.3.2 Tracking TODO state changes
 | 
						||
---------------------------------
 | 
						||
 | 
						||
When TODO keywords are used as workflow states (*note Workflow
 | 
						||
states::), you might want to keep track of when a state change occurred
 | 
						||
and maybe take a note about this change.  You can either record just a
 | 
						||
timestamp, or a time-stamped note for a change.  These records will be
 | 
						||
inserted after the headline as an itemized list, newest first(1).  When
 | 
						||
taking a lot of notes, you might want to get the notes out of the way
 | 
						||
into a drawer (*note Drawers::).  Customize `org-log-into-drawer' to
 | 
						||
get this behavior--the recommended drawer for this is called
 | 
						||
`LOGBOOK'(2).  You can also overrule the setting of this variable for a
 | 
						||
subtree by setting a `LOG_INTO_DRAWER' property.
 | 
						||
 | 
						||
   Since it is normally too much to record a note for every state, Org
 | 
						||
mode expects configuration on a per-keyword basis for this.  This is
 | 
						||
achieved by adding special markers `!' (for a timestamp) or `@' (for a
 | 
						||
note with timestamp) in parentheses after each keyword.  For example,
 | 
						||
with the setting
 | 
						||
 | 
						||
     (setq org-todo-keywords
 | 
						||
       '((sequence "TODO(t)" "WAIT(w@/!)" "|" "DONE(d!)" "CANCELED(c@)")))
 | 
						||
 | 
						||
   To record a timestamp without a note for TODO keywords configured
 | 
						||
with `@', just type `C-c C-c' to enter a blank note when prompted.
 | 
						||
 | 
						||
You not only define global TODO keywords and fast access keys, but also
 | 
						||
request that a time is recorded when the entry is set to DONE(3), and
 | 
						||
that a note is recorded when switching to WAIT or CANCELED.  The
 | 
						||
setting for WAIT is even more special: the `!' after the slash means
 | 
						||
that in addition to the note taken when entering the state, a timestamp
 | 
						||
should be recorded when leaving the WAIT state, if and only if the
 | 
						||
target state does not configure logging for entering it.  So it has no
 | 
						||
effect when switching from WAIT to DONE, because DONE is configured to
 | 
						||
record a timestamp only.  But when switching from WAIT back to TODO,
 | 
						||
the `/!' in the WAIT setting now triggers a timestamp even though TODO
 | 
						||
has no logging configured.
 | 
						||
 | 
						||
   You can use the exact same syntax for setting logging preferences
 | 
						||
local to a buffer:
 | 
						||
     #+TODO: TODO(t) WAIT(w@/!) | DONE(d!) CANCELED(c@)
 | 
						||
 | 
						||
   In order to define logging settings that are local to a subtree or a
 | 
						||
single item, define a LOGGING property in this entry.  Any non-empty
 | 
						||
LOGGING property resets all logging settings to `nil'.  You may then
 | 
						||
turn on logging for this specific tree using STARTUP keywords like
 | 
						||
`lognotedone' or `logrepeat', as well as adding state specific settings
 | 
						||
like `TODO(!)'.  For example
 | 
						||
 | 
						||
     * TODO Log each state with only a time
 | 
						||
       :PROPERTIES:
 | 
						||
       :LOGGING: TODO(!) WAIT(!) DONE(!) CANCELED(!)
 | 
						||
       :END:
 | 
						||
     * TODO Only log when switching to WAIT, and when repeating
 | 
						||
       :PROPERTIES:
 | 
						||
       :LOGGING: WAIT(@) logrepeat
 | 
						||
       :END:
 | 
						||
     * TODO No logging at all
 | 
						||
       :PROPERTIES:
 | 
						||
       :LOGGING: nil
 | 
						||
       :END:
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) See the option `org-log-states-order-reversed'
 | 
						||
 | 
						||
   (2) Note that the `LOGBOOK' drawer is unfolded when pressing <SPC>
 | 
						||
in the agenda to show an entry--use <C-u SPC> to keep it folded here
 | 
						||
 | 
						||
   (3) It is possible that Org mode will record two timestamps when you
 | 
						||
are using both `org-log-done' and state change logging.  However, it
 | 
						||
will never prompt for two notes--if you have configured both, the state
 | 
						||
change recording note will take precedence and cancel the `Closing
 | 
						||
Note'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Tracking your habits,  Prev: Tracking TODO state changes,  Up: Progress logging
 | 
						||
 | 
						||
5.3.3 Tracking your habits
 | 
						||
--------------------------
 | 
						||
 | 
						||
Org has the ability to track the consistency of a special category of
 | 
						||
TODOs, called "habits".  A habit has the following properties:
 | 
						||
 | 
						||
  1. You have enabled the `habits' module by customizing `org-modules'.
 | 
						||
 | 
						||
  2. The habit is a TODO item, with a TODO keyword representing an open
 | 
						||
     state.
 | 
						||
 | 
						||
  3. The property `STYLE' is set to the value `habit'.
 | 
						||
 | 
						||
  4. The TODO has a scheduled date, usually with a `.+' style repeat
 | 
						||
     interval.  A `++' style may be appropriate for habits with time
 | 
						||
     constraints, e.g., must be done on weekends, or a `+' style for an
 | 
						||
     unusual habit that can have a backlog, e.g., weekly reports.
 | 
						||
 | 
						||
  5. The TODO may also have minimum and maximum ranges specified by
 | 
						||
     using the syntax `.+2d/3d', which says that you want to do the
 | 
						||
     task at least every three days, but at most every two days.
 | 
						||
 | 
						||
  6. You must also have state logging for the `DONE' state enabled
 | 
						||
     (*note Tracking TODO state changes::), in order for historical
 | 
						||
     data to be represented in the consistency graph.  If it is not
 | 
						||
     enabled it is not an error, but the consistency graphs will be
 | 
						||
     largely meaningless.
 | 
						||
 | 
						||
   To give you an idea of what the above rules look like in action,
 | 
						||
here's an actual habit with some history:
 | 
						||
 | 
						||
     ** TODO Shave
 | 
						||
        SCHEDULED: <2009-10-17 Sat .+2d/4d>
 | 
						||
        :PROPERTIES:
 | 
						||
        :STYLE:    habit
 | 
						||
        :LAST_REPEAT: [2009-10-19 Mon 00:36]
 | 
						||
        :END:
 | 
						||
        - State "DONE"       from "TODO"       [2009-10-15 Thu]
 | 
						||
        - State "DONE"       from "TODO"       [2009-10-12 Mon]
 | 
						||
        - State "DONE"       from "TODO"       [2009-10-10 Sat]
 | 
						||
        - State "DONE"       from "TODO"       [2009-10-04 Sun]
 | 
						||
        - State "DONE"       from "TODO"       [2009-10-02 Fri]
 | 
						||
        - State "DONE"       from "TODO"       [2009-09-29 Tue]
 | 
						||
        - State "DONE"       from "TODO"       [2009-09-25 Fri]
 | 
						||
        - State "DONE"       from "TODO"       [2009-09-19 Sat]
 | 
						||
        - State "DONE"       from "TODO"       [2009-09-16 Wed]
 | 
						||
        - State "DONE"       from "TODO"       [2009-09-12 Sat]
 | 
						||
 | 
						||
   What this habit says is: I want to shave at most every 2 days (given
 | 
						||
by the `SCHEDULED' date and repeat interval) and at least every 4 days.
 | 
						||
If today is the 15th, then the habit first appears in the agenda on Oct
 | 
						||
17, after the minimum of 2 days has elapsed, and will appear overdue on
 | 
						||
Oct 19, after four days have elapsed.
 | 
						||
 | 
						||
   What's really useful about habits is that they are displayed along
 | 
						||
with a consistency graph, to show how consistent you've been at getting
 | 
						||
that task done in the past.  This graph shows every day that the task
 | 
						||
was done over the past three weeks, with colors for each day.  The
 | 
						||
colors used are:
 | 
						||
 | 
						||
`Blue'
 | 
						||
     If the task wasn't to be done yet on that day.
 | 
						||
 | 
						||
`Green'
 | 
						||
     If the task could have been done on that day.
 | 
						||
 | 
						||
`Yellow'
 | 
						||
     If the task was going to be overdue the next day.
 | 
						||
 | 
						||
`Red'
 | 
						||
     If the task was overdue on that day.
 | 
						||
 | 
						||
   In addition to coloring each day, the day is also marked with an
 | 
						||
asterisk if the task was actually done that day, and an exclamation
 | 
						||
mark to show where the current day falls in the graph.
 | 
						||
 | 
						||
   There are several configuration variables that can be used to change
 | 
						||
the way habits are displayed in the agenda.
 | 
						||
 | 
						||
`org-habit-graph-column'
 | 
						||
     The buffer column at which the consistency graph should be drawn.
 | 
						||
     This will overwrite any text in that column, so it is a good idea
 | 
						||
     to keep your habits' titles brief and to the point.
 | 
						||
 | 
						||
`org-habit-preceding-days'
 | 
						||
     The amount of history, in days before today, to appear in
 | 
						||
     consistency graphs.
 | 
						||
 | 
						||
`org-habit-following-days'
 | 
						||
     The number of days after today that will appear in consistency
 | 
						||
     graphs.
 | 
						||
 | 
						||
`org-habit-show-habits-only-for-today'
 | 
						||
     If non-`nil', only show habits in today's agenda view.  This is
 | 
						||
     set to true by default.
 | 
						||
 | 
						||
   Lastly, pressing `K' in the agenda buffer will cause habits to
 | 
						||
temporarily be disabled and they won't appear at all.  Press `K' again
 | 
						||
to bring them back.  They are also subject to tag filtering, if you
 | 
						||
have habits which should only be done in certain contexts, for example.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Priorities,  Next: Breaking down tasks,  Prev: Progress logging,  Up: TODO items
 | 
						||
 | 
						||
5.4 Priorities
 | 
						||
==============
 | 
						||
 | 
						||
If you use Org mode extensively, you may end up with enough TODO items
 | 
						||
that it starts to make sense to prioritize them.  Prioritizing can be
 | 
						||
done by placing a _priority cookie_ into the headline of a TODO item,
 | 
						||
like this
 | 
						||
 | 
						||
     *** TODO [#A] Write letter to Sam Fortune
 | 
						||
 | 
						||
By default, Org mode supports three priorities: `A', `B', and `C'.  `A'
 | 
						||
is the highest priority.  An entry without a cookie is treated just
 | 
						||
like priority `B'.  Priorities make a difference only for sorting in
 | 
						||
the agenda (*note Weekly/daily agenda::); outside the agenda, they have
 | 
						||
no inherent meaning to Org mode.  The cookies can be highlighted with
 | 
						||
special faces by customizing `org-priority-faces'.
 | 
						||
 | 
						||
   Priorities can be attached to any outline node; they do not need to
 | 
						||
be TODO items.
 | 
						||
 | 
						||
`C-c ,'
 | 
						||
     Set the priority of the current headline (`org-priority').  The
 | 
						||
     command prompts for a priority character `A', `B' or `C'.  When
 | 
						||
     you press <SPC> instead, the priority cookie is removed from the
 | 
						||
     headline.  The priorities can also be changed "remotely" from the
 | 
						||
     timeline and agenda buffer with the `,' command (*note Agenda
 | 
						||
     commands::).  
 | 
						||
 | 
						||
`S-<up>     (`org-priority-up')'
 | 
						||
`S-<down>     (`org-priority-down')'
 | 
						||
     Increase/decrease priority of current headline(1).  Note that
 | 
						||
     these keys are also used to modify timestamps (*note Creating
 | 
						||
     timestamps::).  See also *note Conflicts::, for a discussion of
 | 
						||
     the interaction with `shift-selection-mode'.
 | 
						||
 | 
						||
   You can change the range of allowed priorities by setting the options
 | 
						||
`org-highest-priority', `org-lowest-priority', and
 | 
						||
`org-default-priority'.  For an individual buffer, you may set these
 | 
						||
values (highest, lowest, default) like this (please make sure that the
 | 
						||
highest priority is earlier in the alphabet than the lowest priority):
 | 
						||
 | 
						||
     #+PRIORITIES: A C B
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) See also the option `org-priority-start-cycle-with-default'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Breaking down tasks,  Next: Checkboxes,  Prev: Priorities,  Up: TODO items
 | 
						||
 | 
						||
5.5 Breaking tasks down into subtasks
 | 
						||
=====================================
 | 
						||
 | 
						||
It is often advisable to break down large tasks into smaller, manageable
 | 
						||
subtasks.  You can do this by creating an outline tree below a TODO
 | 
						||
item, with detailed subtasks on the tree(1).  To keep the overview over
 | 
						||
the fraction of subtasks that are already completed, insert either
 | 
						||
`[/]' or `[%]' anywhere in the headline.  These cookies will be updated
 | 
						||
each time the TODO status of a child changes, or when pressing `C-c
 | 
						||
C-c' on the cookie.  For example:
 | 
						||
 | 
						||
     * Organize Party [33%]
 | 
						||
     ** TODO Call people [1/2]
 | 
						||
     *** TODO Peter
 | 
						||
     *** DONE Sarah
 | 
						||
     ** TODO Buy food
 | 
						||
     ** DONE Talk to neighbor
 | 
						||
 | 
						||
   If a heading has both checkboxes and TODO children below it, the
 | 
						||
meaning of the statistics cookie become ambiguous.  Set the property
 | 
						||
`COOKIE_DATA' to either `checkbox' or `todo' to resolve this issue.
 | 
						||
 | 
						||
   If you would like to have the statistics cookie count any TODO
 | 
						||
entries in the subtree (not just direct children), configure
 | 
						||
`org-hierarchical-todo-statistics'.  To do this for a single subtree,
 | 
						||
include the word `recursive' into the value of the `COOKIE_DATA'
 | 
						||
property.
 | 
						||
 | 
						||
     * Parent capturing statistics [2/20]
 | 
						||
       :PROPERTIES:
 | 
						||
       :COOKIE_DATA: todo recursive
 | 
						||
       :END:
 | 
						||
 | 
						||
   If you would like a TODO entry to automatically change to DONE when
 | 
						||
all children are done, you can use the following setup:
 | 
						||
 | 
						||
     (defun org-summary-todo (n-done n-not-done)
 | 
						||
       "Switch entry to DONE when all subentries are done, to TODO otherwise."
 | 
						||
       (let (org-log-done org-log-states)   ; turn off logging
 | 
						||
         (org-todo (if (= n-not-done 0) "DONE" "TODO"))))
 | 
						||
 | 
						||
     (add-hook 'org-after-todo-statistics-hook 'org-summary-todo)
 | 
						||
 | 
						||
   Another possibility is the use of checkboxes to identify (a
 | 
						||
hierarchy of) a large number of subtasks (*note Checkboxes::).
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) To keep subtasks out of the global TODO list, see the
 | 
						||
`org-agenda-todo-list-sublevels'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Checkboxes,  Prev: Breaking down tasks,  Up: TODO items
 | 
						||
 | 
						||
5.6 Checkboxes
 | 
						||
==============
 | 
						||
 | 
						||
Every item in a plain list(1) (*note Plain lists::) can be made into a
 | 
						||
checkbox by starting it with the string `[ ]'.  This feature is similar
 | 
						||
to TODO items (*note TODO items::), but is more lightweight.
 | 
						||
Checkboxes are not included in the global TODO list, so they are often
 | 
						||
great to split a task into a number of simple steps.  Or you can use
 | 
						||
them in a shopping list.  To toggle a checkbox, use `C-c C-c', or use
 | 
						||
the mouse (thanks to Piotr Zielinski's `org-mouse.el').
 | 
						||
 | 
						||
   Here is an example of a checkbox list.
 | 
						||
 | 
						||
     * TODO Organize party [2/4]
 | 
						||
       - [-] call people [1/3]
 | 
						||
         - [ ] Peter
 | 
						||
         - [X] Sarah
 | 
						||
         - [ ] Sam
 | 
						||
       - [X] order food
 | 
						||
       - [ ] think about what music to play
 | 
						||
       - [X] talk to the neighbors
 | 
						||
 | 
						||
   Checkboxes work hierarchically, so if a checkbox item has children
 | 
						||
that are checkboxes, toggling one of the children checkboxes will make
 | 
						||
the parent checkbox reflect if none, some, or all of the children are
 | 
						||
checked.
 | 
						||
 | 
						||
   The `[2/4]' and `[1/3]' in the first and second line are cookies
 | 
						||
indicating how many checkboxes present in this entry have been checked
 | 
						||
off, and the total number of checkboxes present.  This can give you an
 | 
						||
idea on how many checkboxes remain, even without opening a folded
 | 
						||
entry.  The cookies can be placed into a headline or into (the first
 | 
						||
line of) a plain list item.  Each cookie covers checkboxes of direct
 | 
						||
children structurally below the headline/item on which the cookie
 | 
						||
appears(2).  You have to insert the cookie yourself by typing either
 | 
						||
`[/]' or `[%]'.  With `[/]' you get an `n out of m' result, as in the
 | 
						||
examples above.  With `[%]' you get information about the percentage of
 | 
						||
checkboxes checked (in the above example, this would be `[50%]' and
 | 
						||
`[33%]', respectively).  In a headline, a cookie can count either
 | 
						||
checkboxes below the heading or TODO states of children, and it will
 | 
						||
display whatever was changed last.  Set the property `COOKIE_DATA' to
 | 
						||
either `checkbox' or `todo' to resolve this issue.
 | 
						||
 | 
						||
   If the current outline node has an `ORDERED' property, checkboxes
 | 
						||
must be checked off in sequence, and an error will be thrown if you try
 | 
						||
to check off a box while there are unchecked boxes above it.
 | 
						||
 | 
						||
The following commands work with checkboxes:
 | 
						||
 | 
						||
`C-c C-c     (`org-toggle-checkbox')'
 | 
						||
     Toggle checkbox status or (with prefix arg) checkbox presence at
 | 
						||
     point.  With a single prefix argument, add an empty checkbox or
 | 
						||
     remove the current one(3).  With a double prefix argument, set it
 | 
						||
     to `[-]', which is considered to be an intermediate state.  
 | 
						||
 | 
						||
`C-c C-x C-b     (`org-toggle-checkbox')'
 | 
						||
     Toggle checkbox status or (with prefix arg) checkbox presence at
 | 
						||
     point.  With double prefix argument, set it to `[-]', which is
 | 
						||
     considered to be an intermediate state.
 | 
						||
        - If there is an active region, toggle the first checkbox in
 | 
						||
          the region and set all remaining boxes to the same status as
 | 
						||
          the first.  With a prefix arg, add or remove the checkbox for
 | 
						||
          all items in the region.
 | 
						||
 | 
						||
        - If the cursor is in a headline, toggle checkboxes in the
 | 
						||
          region between this headline and the next (so _not_ the
 | 
						||
          entire subtree).
 | 
						||
 | 
						||
        - If there is no active region, just toggle the checkbox at
 | 
						||
          point.
 | 
						||
     
 | 
						||
`M-S-<RET>     (`org-insert-todo-heading')'
 | 
						||
     Insert a new item with a checkbox.  This works only if the cursor
 | 
						||
     is already in a plain list item (*note Plain lists::).  
 | 
						||
 | 
						||
`C-c C-x o     (`org-toggle-ordered-property')'
 | 
						||
     Toggle the `ORDERED' property of the entry, to toggle if
 | 
						||
     checkboxes must be checked off in sequence.  A property is used
 | 
						||
     for this behavior because this should be local to the current
 | 
						||
     entry, not inherited like a tag.  However, if you would like to
 | 
						||
     track the value of this property with a tag for better visibility,
 | 
						||
     customize `org-track-ordered-property-with-tag'.  
 | 
						||
 | 
						||
`C-c #     (`org-update-statistics-cookies')'
 | 
						||
     Update the statistics cookie in the current outline entry.  When
 | 
						||
     called with a `C-u' prefix, update the entire file.  Checkbox
 | 
						||
     statistic cookies are updated automatically if you toggle
 | 
						||
     checkboxes with `C-c C-c' and make new ones with `M-S-<RET>'.
 | 
						||
     TODO statistics cookies update when changing TODO states.  If you
 | 
						||
     delete boxes/entries or add/change them by hand, use this command
 | 
						||
     to get things back into sync.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) With the exception of description lists.  But you can allow it
 | 
						||
by modifying `org-list-automatic-rules' accordingly.
 | 
						||
 | 
						||
   (2) Set the option `org-checkbox-hierarchical-statistics' if you
 | 
						||
want such cookies to count all checkboxes below the cookie, not just
 | 
						||
those belonging to direct children.
 | 
						||
 | 
						||
   (3) `C-u C-c C-c' on the _first_ item of a list with no checkbox
 | 
						||
will add checkboxes to the rest of the list.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Tags,  Next: Properties and columns,  Prev: TODO items,  Up: Top
 | 
						||
 | 
						||
6 Tags
 | 
						||
******
 | 
						||
 | 
						||
An excellent way to implement labels and contexts for cross-correlating
 | 
						||
information is to assign tags to headlines.  Org mode has extensive
 | 
						||
support for tags.
 | 
						||
 | 
						||
   Every headline can contain a list of tags; they occur at the end of
 | 
						||
the headline.  Tags are normal words containing letters, numbers, `_',
 | 
						||
and `@'.  Tags must be preceded and followed by a single colon, e.g.,
 | 
						||
`:work:'.  Several tags can be specified, as in `:work:urgent:'.  Tags
 | 
						||
will by default be in bold face with the same color as the headline.
 | 
						||
You may specify special faces for specific tags using the option
 | 
						||
`org-tag-faces', in much the same way as you can for TODO keywords
 | 
						||
(*note Faces for TODO keywords::).
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Tag inheritance::             Tags use the tree structure of the outline
 | 
						||
* Setting tags::                How to assign tags to a headline
 | 
						||
* Tag hierarchy::               Create a hierarchy of tags
 | 
						||
* Tag searches::                Searching for combinations of tags
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Tag inheritance,  Next: Setting tags,  Up: Tags
 | 
						||
 | 
						||
6.1 Tag inheritance
 | 
						||
===================
 | 
						||
 | 
						||
Tags make use of the hierarchical structure of outline trees.  If a
 | 
						||
heading has a certain tag, all subheadings will inherit the tag as
 | 
						||
well.  For example, in the list
 | 
						||
 | 
						||
     * Meeting with the French group      :work:
 | 
						||
     ** Summary by Frank                  :boss:notes:
 | 
						||
     *** TODO Prepare slides for him      :action:
 | 
						||
 | 
						||
the final heading will have the tags `:work:', `:boss:', `:notes:', and
 | 
						||
`:action:' even though the final heading is not explicitly marked with
 | 
						||
those tags.  You can also set tags that all entries in a file should
 | 
						||
inherit just as if these tags were defined in a hypothetical level zero
 | 
						||
that surrounds the entire file.  Use a line like this(1):
 | 
						||
 | 
						||
     #+FILETAGS: :Peter:Boss:Secret:
 | 
						||
 | 
						||
To limit tag inheritance to specific tags, use
 | 
						||
`org-tags-exclude-from-inheritance'.  To turn it off entirely, use
 | 
						||
`org-use-tag-inheritance'.
 | 
						||
 | 
						||
   When a headline matches during a tags search while tag inheritance
 | 
						||
is turned on, all the sublevels in the same tree will (for a simple
 | 
						||
match form) match as well(2).  The list of matches may then become very
 | 
						||
long.  If you only want to see the first tags match in a subtree,
 | 
						||
configure `org-tags-match-list-sublevels' (not recommended).
 | 
						||
 | 
						||
   Tag inheritance is relevant when the agenda search tries to match a
 | 
						||
tag, either in the `tags' or `tags-todo' agenda types.  In other agenda
 | 
						||
types, `org-use-tag-inheritance' has no effect.  Still, you may want to
 | 
						||
have your tags correctly set in the agenda, so that tag filtering works
 | 
						||
fine, with inherited tags.  Set `org-agenda-use-tag-inheritance' to
 | 
						||
control this: the default value includes all agenda types, but setting
 | 
						||
this to `nil' can really speed up agenda generation.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) As with all these in-buffer settings, pressing `C-c C-c'
 | 
						||
activates any changes in the line.
 | 
						||
 | 
						||
   (2) This is only true if the search does not involve more complex
 | 
						||
tests including properties (*note Property searches::).
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Setting tags,  Next: Tag hierarchy,  Prev: Tag inheritance,  Up: Tags
 | 
						||
 | 
						||
6.2 Setting tags
 | 
						||
================
 | 
						||
 | 
						||
Tags can simply be typed into the buffer at the end of a headline.
 | 
						||
After a colon, `M-<TAB>' offers completion on tags.  There is also a
 | 
						||
special command for inserting tags:
 | 
						||
 | 
						||
`C-c C-q     (`org-set-tags-command')'
 | 
						||
     Enter new tags for the current headline.  Org mode will either
 | 
						||
     offer completion or a special single-key interface for setting
 | 
						||
     tags, see below.  After pressing <RET>, the tags will be inserted
 | 
						||
     and aligned to `org-tags-column'.  When called with a `C-u'
 | 
						||
     prefix, all tags in the current buffer will be aligned to that
 | 
						||
     column, just to make things look nice.  TAGS are automatically
 | 
						||
     realigned after promotion, demotion, and TODO state changes (*note
 | 
						||
     TODO basics::).
 | 
						||
 | 
						||
`C-c C-c     (`org-set-tags-command')'
 | 
						||
     When the cursor is in a headline, this does the same as `C-c C-q'.
 | 
						||
 | 
						||
   Org supports tag insertion based on a _list of tags_.  By default
 | 
						||
this list is constructed dynamically, containing all tags currently
 | 
						||
used in the buffer.  You may also globally specify a hard list of tags
 | 
						||
with the variable `org-tag-alist'.  Finally you can set the default
 | 
						||
tags for a given file with lines like
 | 
						||
 | 
						||
     #+TAGS: @work @home @tennisclub
 | 
						||
     #+TAGS: laptop car pc sailboat
 | 
						||
 | 
						||
   If you have globally defined your preferred set of tags using the
 | 
						||
variable `org-tag-alist', but would like to use a dynamic tag list in a
 | 
						||
specific file, add an empty TAGS option line to that file:
 | 
						||
 | 
						||
     #+TAGS:
 | 
						||
 | 
						||
   If you have a preferred set of tags that you would like to use in
 | 
						||
every file, in addition to those defined on a per-file basis by TAGS
 | 
						||
option lines, then you may specify a list of tags with the variable
 | 
						||
`org-tag-persistent-alist'.  You may turn this off on a per-file basis
 | 
						||
by adding a STARTUP option line to that file:
 | 
						||
 | 
						||
     #+STARTUP: noptag
 | 
						||
 | 
						||
   By default Org mode uses the standard minibuffer completion
 | 
						||
facilities for entering tags.  However, it also implements another,
 | 
						||
quicker, tag selection method called _fast tag selection_.  This allows
 | 
						||
you to select and deselect tags with just a single key press.  For this
 | 
						||
to work well you should assign unique letters to most of your commonly
 | 
						||
used tags.  You can do this globally by configuring the variable
 | 
						||
`org-tag-alist' in your `.emacs' file.  For example, you may find the
 | 
						||
need to tag many items in different files with `:@home:'.  In this case
 | 
						||
you can set something like:
 | 
						||
 | 
						||
     (setq org-tag-alist '(("@work" . ?w) ("@home" . ?h) ("laptop" . ?l)))
 | 
						||
 | 
						||
If the tag is only relevant to the file you are working on, then you
 | 
						||
can instead set the TAGS option line as:
 | 
						||
 | 
						||
     #+TAGS: @work(w)  @home(h)  @tennisclub(t)  laptop(l)  pc(p)
 | 
						||
 | 
						||
The tags interface will show the available tags in a splash window.  If
 | 
						||
you want to start a new line after a specific tag, insert `\n' into the
 | 
						||
tag list
 | 
						||
 | 
						||
     #+TAGS: @work(w)  @home(h)  @tennisclub(t) \n laptop(l)  pc(p)
 | 
						||
 | 
						||
or write them in two lines:
 | 
						||
 | 
						||
     #+TAGS: @work(w)  @home(h)  @tennisclub(t)
 | 
						||
     #+TAGS: laptop(l)  pc(p)
 | 
						||
 | 
						||
You can also group together tags that are mutually exclusive by using
 | 
						||
braces, as in:
 | 
						||
 | 
						||
     #+TAGS: { @work(w)  @home(h)  @tennisclub(t) }  laptop(l)  pc(p)
 | 
						||
 | 
						||
you indicate that at most one of `@work', `@home', and `@tennisclub'
 | 
						||
should be selected.  Multiple such groups are allowed.
 | 
						||
 | 
						||
Don't forget to press `C-c C-c' with the cursor in one of these lines
 | 
						||
to activate any changes.
 | 
						||
 | 
						||
To set these mutually exclusive groups in the variable `org-tag-alist',
 | 
						||
you must use the dummy tags `:startgroup' and `:endgroup' instead of
 | 
						||
the braces.  Similarly, you can use `:newline' to indicate a line
 | 
						||
break.  The previous example would be set globally by the following
 | 
						||
configuration:
 | 
						||
 | 
						||
     (setq org-tag-alist '((:startgroup . nil)
 | 
						||
                           ("@work" . ?w) ("@home" . ?h)
 | 
						||
                           ("@tennisclub" . ?t)
 | 
						||
                           (:endgroup . nil)
 | 
						||
                           ("laptop" . ?l) ("pc" . ?p)))
 | 
						||
 | 
						||
   If at least one tag has a selection key then pressing `C-c C-c' will
 | 
						||
automatically present you with a special interface, listing inherited
 | 
						||
tags, the tags of the current headline, and a list of all valid tags
 | 
						||
with corresponding keys(1).  In this interface, you can use the
 | 
						||
following keys:
 | 
						||
 | 
						||
`a-z...'
 | 
						||
     Pressing keys assigned to tags will add or remove them from the
 | 
						||
     list of tags in the current line.  Selecting a tag in a group of
 | 
						||
     mutually exclusive tags will turn off any other tags from that
 | 
						||
     group.  
 | 
						||
 | 
						||
`<TAB>'
 | 
						||
     Enter a tag in the minibuffer, even if the tag is not in the
 | 
						||
     predefined list.  You will be able to complete on all tags present
 | 
						||
     in the buffer.  You can also add several tags: just separate them
 | 
						||
     with a comma.
 | 
						||
 | 
						||
`<SPC>'
 | 
						||
     Clear all tags for this line.  
 | 
						||
 | 
						||
`<RET>'
 | 
						||
     Accept the modified set.
 | 
						||
 | 
						||
`C-g'
 | 
						||
     Abort without installing changes.
 | 
						||
 | 
						||
`q'
 | 
						||
     If `q' is not assigned to a tag, it aborts like `C-g'.
 | 
						||
 | 
						||
`!'
 | 
						||
     Turn off groups of mutually exclusive tags.  Use this to (as an
 | 
						||
     exception) assign several tags from such a group.
 | 
						||
 | 
						||
`C-c'
 | 
						||
     Toggle auto-exit after the next change (see below).  If you are
 | 
						||
     using expert mode, the first `C-c' will display the selection
 | 
						||
     window.
 | 
						||
 | 
						||
This method lets you assign tags to a headline with very few keys.  With
 | 
						||
the above setup, you could clear the current tags and set `@home',
 | 
						||
`laptop' and `pc' tags with just the following keys: `C-c C-c <SPC> h l
 | 
						||
p <RET>'.  Switching from `@home' to `@work' would be done with `C-c
 | 
						||
C-c w <RET>' or alternatively with `C-c C-c C-c w'.  Adding the
 | 
						||
non-predefined tag `Sarah' could be done with `C-c C-c <TAB> S a r a h
 | 
						||
<RET> <RET>'.
 | 
						||
 | 
						||
   If you find that most of the time you need only a single key press to
 | 
						||
modify your list of tags, set `org-fast-tag-selection-single-key'.
 | 
						||
Then you no longer have to press <RET> to exit fast tag selection--it
 | 
						||
will immediately exit after the first change.  If you then occasionally
 | 
						||
need more keys, press `C-c' to turn off auto-exit for the current tag
 | 
						||
selection process (in effect: start selection with `C-c C-c C-c'
 | 
						||
instead of `C-c C-c').  If you set the variable to the value `expert',
 | 
						||
the special window is not even shown for single-key tag selection, it
 | 
						||
comes up only when you press an extra `C-c'.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Keys will automatically be assigned to tags which have no
 | 
						||
configured keys.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Tag hierarchy,  Next: Tag searches,  Prev: Setting tags,  Up: Tags
 | 
						||
 | 
						||
6.3 Tag hierarchy
 | 
						||
=================
 | 
						||
 | 
						||
Tags can be defined in hierarchies.  A tag can be defined as a _group
 | 
						||
tag_ for a set of other tags.  The group tag can be seen as the "broader
 | 
						||
term" for its set of tags.  Defining multiple _group tags_ and nesting
 | 
						||
them creates a tag hierarchy.
 | 
						||
 | 
						||
   One use-case is to create a taxonomy of terms (tags) that can be
 | 
						||
used to classify nodes in a document or set of documents.
 | 
						||
 | 
						||
   When you search for a group tag, it will return matches for all
 | 
						||
members in the group and its subgroup.  In an agenda view, filtering by
 | 
						||
a group tag will display or hide headlines tagged with at least one of
 | 
						||
the members of the group or any of its subgroups.  This makes tag
 | 
						||
searches and filters even more flexible.
 | 
						||
 | 
						||
   You can set group tags by using brackets and inserting a colon
 | 
						||
between the group tag and its related tags--beware that all whitespaces
 | 
						||
are mandatory so that Org can parse this line correctly:
 | 
						||
 | 
						||
     #+TAGS: [ GTD : Control Persp ]
 | 
						||
 | 
						||
   In this example, `GTD' is the _group tag_ and it is related to two
 | 
						||
other tags: `Control', `Persp'.  Defining `Control' and `Persp' as
 | 
						||
group tags creates an hierarchy of tags:
 | 
						||
 | 
						||
     #+TAGS: [ Control : Context Task ]
 | 
						||
     #+TAGS: [ Persp : Vision Goal AOF Project ]
 | 
						||
 | 
						||
   That can conceptually be seen as a hierarchy of tags:
 | 
						||
 | 
						||
     - GTD
 | 
						||
       - Persp
 | 
						||
         - Vision
 | 
						||
         - Goal
 | 
						||
         - AOF
 | 
						||
         - Project
 | 
						||
       - Control
 | 
						||
         - Context
 | 
						||
         - Task
 | 
						||
 | 
						||
   You can use the `:startgrouptag', `:grouptags' and `:endgrouptag'
 | 
						||
keyword directly when setting `org-tag-alist' directly:
 | 
						||
 | 
						||
     (setq org-tag-alist '((:startgrouptag)
 | 
						||
                           ("GTD")
 | 
						||
                           (:grouptags)
 | 
						||
                           ("Control")
 | 
						||
                           ("Persp")
 | 
						||
                           (:endgrouptag)
 | 
						||
                           (:startgrouptag)
 | 
						||
                           ("Control")
 | 
						||
                           (:grouptags)
 | 
						||
                           ("Context")
 | 
						||
                           ("Task")
 | 
						||
                           (:endgrouptag)))
 | 
						||
 | 
						||
   The tags in a group can be mutually exclusive if using the same
 | 
						||
group syntax as is used for grouping mutually exclusive tags together;
 | 
						||
using curly brackets.
 | 
						||
 | 
						||
     #+TAGS: { Context : @Home @Work @Call }
 | 
						||
 | 
						||
   When setting `org-tag-alist' you can use `:startgroup' & `:endgroup'
 | 
						||
instead of `:startgrouptag' & `:endgrouptag' to make the tags mutually
 | 
						||
exclusive.
 | 
						||
 | 
						||
   Furthermore; The members of a _group tag_ can also be regular
 | 
						||
expression, creating the possibility of more dynamic and rule-based
 | 
						||
tag-structure.  The regular expressions in the group must be marked up
 | 
						||
within { }.  Example use, to expand on the example given above:
 | 
						||
 | 
						||
     #+TAGS: [ Vision : {V.+} ]
 | 
						||
     #+TAGS: [ Goal : {G.+} ]
 | 
						||
     #+TAGS: [ AOF : {AOF.+} ]
 | 
						||
     #+TAGS: [ Project : {P.+} ]
 | 
						||
 | 
						||
   Searching for the tag `Project' will now list all tags also including
 | 
						||
regular expression matches for `P@.+'.  Similar for tag-searches on
 | 
						||
`Vision', `Goal' and `AOF'.  This can be good for example if tags for a
 | 
						||
certain project is tagged with a common project-identifier, i.e.
 | 
						||
`P@2014_OrgTags'.
 | 
						||
 | 
						||
   If you want to ignore group tags temporarily, toggle group tags
 | 
						||
support with `org-toggle-tags-groups', bound to `C-c C-x q'.  If you
 | 
						||
want to disable tag groups completely, set `org-group-tags' to `nil'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Tag searches,  Prev: Tag hierarchy,  Up: Tags
 | 
						||
 | 
						||
6.4 Tag searches
 | 
						||
================
 | 
						||
 | 
						||
Once a system of tags has been set up, it can be used to collect related
 | 
						||
information into special lists.
 | 
						||
 | 
						||
`C-c / m  or  C-c \     (`org-match-sparse-tree')'
 | 
						||
     Create a sparse tree with all headlines matching a
 | 
						||
     tags/property/TODO search.  With a `C-u' prefix argument, ignore
 | 
						||
     headlines that are not a TODO line.  *Note Matching tags and
 | 
						||
     properties::.  
 | 
						||
 | 
						||
`C-c a m     (`org-tags-view')'
 | 
						||
     Create a global list of tag matches from all agenda files.  *Note
 | 
						||
     Matching tags and properties::.  
 | 
						||
 | 
						||
`C-c a M     (`org-tags-view')'
 | 
						||
     Create a global list of tag matches from all agenda files, but
 | 
						||
     check only TODO items and force checking subitems (see the option
 | 
						||
     `org-tags-match-list-sublevels').
 | 
						||
 | 
						||
   These commands all prompt for a match string which allows basic
 | 
						||
Boolean logic like `+boss+urgent-project1', to find entries with tags
 | 
						||
`boss' and `urgent', but not `project1', or `Kathy|Sally' to find
 | 
						||
entries which are tagged, like `Kathy' or `Sally'.  The full syntax of
 | 
						||
the search string is rich and allows also matching against TODO
 | 
						||
keywords, entry levels and properties.  For a complete description with
 | 
						||
many examples, see *note Matching tags and properties::.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Properties and columns,  Next: Dates and times,  Prev: Tags,  Up: Top
 | 
						||
 | 
						||
7 Properties and columns
 | 
						||
************************
 | 
						||
 | 
						||
A property is a key-value pair associated with an entry.  Properties
 | 
						||
can be set so they are associated with a single entry, with every entry
 | 
						||
in a tree, or with every entry in an Org mode file.
 | 
						||
 | 
						||
   There are two main applications for properties in Org mode.  First,
 | 
						||
properties are like tags, but with a value.  Imagine maintaining a file
 | 
						||
where you document bugs and plan releases for a piece of software.
 | 
						||
Instead of using tags like `:release_1:', `:release_2:', you can use a
 | 
						||
property, say `:Release:', that in different subtrees has different
 | 
						||
values, such as `1.0' or `2.0'.  Second, you can use properties to
 | 
						||
implement (very basic) database capabilities in an Org buffer.  Imagine
 | 
						||
keeping track of your music CDs, where properties could be things such
 | 
						||
as the album, artist, date of release, number of tracks, and so on.
 | 
						||
 | 
						||
   Properties can be conveniently edited and viewed in column view
 | 
						||
(*note Column view::).
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Property syntax::             How properties are spelled out
 | 
						||
* Special properties::          Access to other Org mode features
 | 
						||
* Property searches::           Matching property values
 | 
						||
* Property inheritance::        Passing values down the tree
 | 
						||
* Column view::                 Tabular viewing and editing
 | 
						||
* Property API::                Properties for Lisp programmers
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Property syntax,  Next: Special properties,  Up: Properties and columns
 | 
						||
 | 
						||
7.1 Property syntax
 | 
						||
===================
 | 
						||
 | 
						||
Properties are key-value pairs.  When they are associated with a single
 | 
						||
entry or with a tree they need to be inserted into a special drawer
 | 
						||
(*note Drawers::) with the name `PROPERTIES', which has to be located
 | 
						||
right below a headline, and its planning line (*note Deadlines and
 | 
						||
scheduling::) when applicable.  Each property is specified on a single
 | 
						||
line, with the key (surrounded by colons) first, and the value after
 | 
						||
it.  Keys are case-insensitives.  Here is an example:
 | 
						||
 | 
						||
     * CD collection
 | 
						||
     ** Classic
 | 
						||
     *** Goldberg Variations
 | 
						||
         :PROPERTIES:
 | 
						||
         :Title:     Goldberg Variations
 | 
						||
         :Composer:  J.S. Bach
 | 
						||
         :Artist:    Glen Gould
 | 
						||
         :Publisher: Deutsche Grammophon
 | 
						||
         :NDisks:    1
 | 
						||
         :END:
 | 
						||
 | 
						||
   Depending on the value of `org-use-property-inheritance', a property
 | 
						||
set this way will either be associated with a single entry, or the
 | 
						||
subtree defined by the entry, see *note Property inheritance::.
 | 
						||
 | 
						||
   You may define the allowed values for a particular property `:Xyz:'
 | 
						||
by setting a property `:Xyz_ALL:'.  This special property is
 | 
						||
_inherited_, so if you set it in a level 1 entry, it will apply to the
 | 
						||
entire tree.  When allowed values are defined, setting the
 | 
						||
corresponding property becomes easier and is less prone to typing
 | 
						||
errors.  For the example with the CD collection, we can predefine
 | 
						||
publishers and the number of disks in a box like this:
 | 
						||
 | 
						||
     * CD collection
 | 
						||
       :PROPERTIES:
 | 
						||
       :NDisks_ALL:  1 2 3 4
 | 
						||
       :Publisher_ALL: "Deutsche Grammophon" Philips EMI
 | 
						||
       :END:
 | 
						||
 | 
						||
   If you want to set properties that can be inherited by any entry in a
 | 
						||
file, use a line like 
 | 
						||
     #+PROPERTY: NDisks_ALL 1 2 3 4
 | 
						||
 | 
						||
   Contrary to properties set from a special drawer, you have to
 | 
						||
refresh the buffer with `C-c C-c' to activate this change.
 | 
						||
 | 
						||
   If you want to add to the value of an existing property, append a
 | 
						||
`+' to the property name.  The following results in the property `var'
 | 
						||
having the value "foo=1 bar=2".  
 | 
						||
     #+PROPERTY: var  foo=1
 | 
						||
     #+PROPERTY: var+ bar=2
 | 
						||
 | 
						||
   It is also possible to add to the values of inherited properties.
 | 
						||
The following results in the `genres' property having the value "Classic
 | 
						||
Baroque" under the `Goldberg Variations' subtree.  
 | 
						||
     * CD collection
 | 
						||
     ** Classic
 | 
						||
         :PROPERTIES:
 | 
						||
         :GENRES: Classic
 | 
						||
         :END:
 | 
						||
     *** Goldberg Variations
 | 
						||
         :PROPERTIES:
 | 
						||
         :Title:     Goldberg Variations
 | 
						||
         :Composer:  J.S. Bach
 | 
						||
         :Artist:    Glen Gould
 | 
						||
         :Publisher: Deutsche Grammophon
 | 
						||
         :NDisks:    1
 | 
						||
         :GENRES+:   Baroque
 | 
						||
         :END:
 | 
						||
   Note that a property can only have one entry per Drawer.
 | 
						||
 | 
						||
   Property values set with the global variable `org-global-properties'
 | 
						||
can be inherited by all entries in all Org files.
 | 
						||
 | 
						||
The following commands help to work with properties:
 | 
						||
 | 
						||
`M-<TAB>     (`pcomplete')'
 | 
						||
     After an initial colon in a line, complete property keys.  All
 | 
						||
     keys used in the current file will be offered as possible
 | 
						||
     completions.  
 | 
						||
 | 
						||
`C-c C-x p     (`org-set-property')'
 | 
						||
     Set a property.  This prompts for a property name and a value.  If
 | 
						||
     necessary, the property drawer is created as well.
 | 
						||
 | 
						||
`C-u M-x org-insert-drawer RET'
 | 
						||
     Insert a property drawer into the current entry.  The drawer will
 | 
						||
     be inserted early in the entry, but after the lines with planning
 | 
						||
     information like deadlines.  
 | 
						||
 | 
						||
`C-c C-c     (`org-property-action')'
 | 
						||
     With the cursor in a property drawer, this executes property
 | 
						||
     commands.  
 | 
						||
 | 
						||
`C-c C-c s     (`org-set-property')'
 | 
						||
     Set a property in the current entry.  Both the property and the
 | 
						||
     value can be inserted using completion.  
 | 
						||
 | 
						||
`S-<right>     (`org-property-next-allowed-value')'
 | 
						||
`S-<left>     (`org-property-previous-allowed-value')'
 | 
						||
     Switch property at point to the next/previous allowed value.  
 | 
						||
 | 
						||
`C-c C-c d     (`org-delete-property')'
 | 
						||
     Remove a property from the current entry.  
 | 
						||
 | 
						||
`C-c C-c D     (`org-delete-property-globally')'
 | 
						||
     Globally remove a property, from all entries in the current file.  
 | 
						||
 | 
						||
`C-c C-c c     (`org-compute-property-at-point')'
 | 
						||
     Compute the property at point, using the operator and scope from
 | 
						||
     the nearest column format definition.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Special properties,  Next: Property searches,  Prev: Property syntax,  Up: Properties and columns
 | 
						||
 | 
						||
7.2 Special properties
 | 
						||
======================
 | 
						||
 | 
						||
Special properties provide an alternative access method to Org mode
 | 
						||
features, like the TODO state or the priority of an entry, discussed in
 | 
						||
the previous chapters.  This interface exists so that you can include
 | 
						||
these states in a column view (*note Column view::), or to use them in
 | 
						||
queries.  The following property names are special and should not be
 | 
						||
used as keys in the properties drawer:
 | 
						||
 | 
						||
     ALLTAGS      All tags, including inherited ones.
 | 
						||
     BLOCKED      "t" if task is currently blocked by children or siblings.
 | 
						||
     CLOCKSUM     The sum of CLOCK intervals in the subtree.  `org-clock-sum'
 | 
						||
                  must be run first to compute the values in the current buffer.
 | 
						||
     CLOCKSUM_T   The sum of CLOCK intervals in the subtree for today.
 | 
						||
                  `org-clock-sum-today' must be run first to compute the
 | 
						||
                  values in the current buffer.
 | 
						||
     CLOSED       When was this entry closed?
 | 
						||
     DEADLINE     The deadline time string, without the angular brackets.
 | 
						||
     FILE         The filename the entry is located in.
 | 
						||
     ITEM         The headline of the entry, with stars.
 | 
						||
     PRIORITY     The priority of the entry, a string with a single letter.
 | 
						||
     SCHEDULED    The scheduling timestamp, without the angular brackets.
 | 
						||
     TAGS         The tags defined directly in the headline.
 | 
						||
     TIMESTAMP    The first keyword-less timestamp in the entry.
 | 
						||
     TIMESTAMP_IA The first inactive timestamp in the entry.
 | 
						||
     TODO         The TODO keyword of the entry.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Property searches,  Next: Property inheritance,  Prev: Special properties,  Up: Properties and columns
 | 
						||
 | 
						||
7.3 Property searches
 | 
						||
=====================
 | 
						||
 | 
						||
To create sparse trees and special lists with selection based on
 | 
						||
properties, the same commands are used as for tag searches (*note Tag
 | 
						||
searches::).
 | 
						||
 | 
						||
`C-c / m  or  C-c \     (`org-match-sparse-tree')'
 | 
						||
     Create a sparse tree with all matching entries.  With a `C-u'
 | 
						||
     prefix argument, ignore headlines that are not a TODO line.  
 | 
						||
 | 
						||
`C-c a m     (`org-tags-view')'
 | 
						||
     Create a global list of tag/property  matches from all agenda
 | 
						||
     files.  *Note Matching tags and properties::.  
 | 
						||
 | 
						||
`C-c a M     (`org-tags-view')'
 | 
						||
     Create a global list of tag matches from all agenda files, but
 | 
						||
     check only TODO items and force checking of subitems (see the
 | 
						||
     option `org-tags-match-list-sublevels').
 | 
						||
 | 
						||
   The syntax for the search string is described in *note Matching tags
 | 
						||
and properties::.
 | 
						||
 | 
						||
   There is also a special command for creating sparse trees based on a
 | 
						||
single property:
 | 
						||
 | 
						||
`C-c / p'
 | 
						||
     Create a sparse tree based on the value of a property.  This first
 | 
						||
     prompts for the name of a property, and then for a value.  A
 | 
						||
     sparse tree is created with all entries that define this property
 | 
						||
     with the given value.  If you enclose the value in curly braces,
 | 
						||
     it is interpreted as a regular expression and matched against the
 | 
						||
     property values.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Property inheritance,  Next: Column view,  Prev: Property searches,  Up: Properties and columns
 | 
						||
 | 
						||
7.4 Property Inheritance
 | 
						||
========================
 | 
						||
 | 
						||
The outline structure of Org mode documents lends itself to an
 | 
						||
inheritance model of properties: if the parent in a tree has a certain
 | 
						||
property, the children can inherit this property.  Org mode does not
 | 
						||
turn this on by default, because it can slow down property searches
 | 
						||
significantly and is often not needed.  However, if you find inheritance
 | 
						||
useful, you can turn it on by setting the variable
 | 
						||
`org-use-property-inheritance'.  It may be set to `t' to make all
 | 
						||
properties inherited from the parent, to a list of properties that
 | 
						||
should be inherited, or to a regular expression that matches inherited
 | 
						||
properties.  If a property has the value `nil', this is interpreted as
 | 
						||
an explicit undefine of the property, so that inheritance search will
 | 
						||
stop at this value and return `nil'.
 | 
						||
 | 
						||
   Org mode has a few properties for which inheritance is hard-coded, at
 | 
						||
least for the special applications for which they are used:
 | 
						||
 | 
						||
`COLUMNS'
 | 
						||
     The `:COLUMNS:' property defines the format of column view (*note
 | 
						||
     Column view::).  It is inherited in the sense that the level where
 | 
						||
     a `:COLUMNS:' property is defined is used as the starting point
 | 
						||
     for a column view table, independently of the location in the
 | 
						||
     subtree from where columns view is turned on.
 | 
						||
 | 
						||
`CATEGORY'
 | 
						||
     For agenda view, a category set through a `:CATEGORY:' property
 | 
						||
     applies to the entire subtree.
 | 
						||
 | 
						||
`ARCHIVE'
 | 
						||
     For archiving, the `:ARCHIVE:' property may define the archive
 | 
						||
     location for the entire subtree (*note Moving subtrees::).
 | 
						||
 | 
						||
`LOGGING'
 | 
						||
     The LOGGING property may define logging settings for an entry or a
 | 
						||
     subtree (*note Tracking TODO state changes::).
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Column view,  Next: Property API,  Prev: Property inheritance,  Up: Properties and columns
 | 
						||
 | 
						||
7.5 Column view
 | 
						||
===============
 | 
						||
 | 
						||
A great way to view and edit properties in an outline tree is _column
 | 
						||
view_.  In column view, each outline node is turned into a table row.
 | 
						||
Columns in this table provide access to properties of the entries.  Org
 | 
						||
mode implements columns by overlaying a tabular structure over the
 | 
						||
headline of each item.  While the headlines have been turned into a
 | 
						||
table row, you can still change the visibility of the outline tree.
 | 
						||
For example, you get a compact table by switching to CONTENTS view
 | 
						||
(`S-<TAB> S-<TAB>', or simply `c' while column view is active), but you
 | 
						||
can still open, read, and edit the entry below each headline.  Or, you
 | 
						||
can switch to column view after executing a sparse tree command and in
 | 
						||
this way get a table only for the selected items.  Column view also
 | 
						||
works in agenda buffers (*note Agenda views::) where queries have
 | 
						||
collected selected items, possibly from a number of files.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Defining columns::            The COLUMNS format property
 | 
						||
* Using column view::           How to create and use column view
 | 
						||
* Capturing column view::       A dynamic block for column view
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Defining columns,  Next: Using column view,  Up: Column view
 | 
						||
 | 
						||
7.5.1 Defining columns
 | 
						||
----------------------
 | 
						||
 | 
						||
Setting up a column view first requires defining the columns.  This is
 | 
						||
done by defining a column format line.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Scope of column definitions::  Where defined, where valid?
 | 
						||
* Column attributes::           Appearance and content of a column
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Scope of column definitions,  Next: Column attributes,  Up: Defining columns
 | 
						||
 | 
						||
7.5.1.1 Scope of column definitions
 | 
						||
...................................
 | 
						||
 | 
						||
To define a column format for an entire file, use a line like
 | 
						||
 | 
						||
     #+COLUMNS: %25ITEM %TAGS %PRIORITY %TODO
 | 
						||
 | 
						||
   To specify a format that only applies to a specific tree, add a
 | 
						||
`:COLUMNS:' property to the top node of that tree, for example:
 | 
						||
 | 
						||
     ** Top node for columns view
 | 
						||
        :PROPERTIES:
 | 
						||
        :COLUMNS: %25ITEM %TAGS %PRIORITY %TODO
 | 
						||
        :END:
 | 
						||
 | 
						||
   If a `:COLUMNS:' property is present in an entry, it defines columns
 | 
						||
for the entry itself, and for the entire subtree below it.  Since the
 | 
						||
column definition is part of the hierarchical structure of the document,
 | 
						||
you can define columns on level 1 that are general enough for all
 | 
						||
sublevels, and more specific columns further down, when you edit a
 | 
						||
deeper part of the tree.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Column attributes,  Prev: Scope of column definitions,  Up: Defining columns
 | 
						||
 | 
						||
7.5.1.2 Column attributes
 | 
						||
.........................
 | 
						||
 | 
						||
A column definition sets the attributes of a column.  The general
 | 
						||
definition looks like this:
 | 
						||
 | 
						||
      %[WIDTH]PROPERTY[(TITLE)][{SUMMARY-TYPE}]
 | 
						||
 | 
						||
Except for the percent sign and the property name, all items are
 | 
						||
optional.  The individual parts have the following meaning:
 | 
						||
 | 
						||
     WIDTH           An integer specifying the width of the column in characters.
 | 
						||
                     If omitted, the width will be determined automatically.
 | 
						||
     PROPERTY        The property that should be edited in this column.
 | 
						||
                     Special properties representing meta data are allowed here
 | 
						||
                     as well (*note Special properties::)
 | 
						||
     TITLE           The header text for the column.  If omitted, the property
 | 
						||
                     name is used.
 | 
						||
     {SUMMARY-TYPE}  The summary type.  If specified, the column values for
 | 
						||
                     parent nodes are computed from the children.
 | 
						||
                     Supported summary types are:
 | 
						||
                     {+}       Sum numbers in this column.
 | 
						||
                     {+;%.1f}  Like `+', but format result with `%.1f'.
 | 
						||
                     {$}       Currency, short for `+;%.2f'.
 | 
						||
                     {:}       Sum times, HH:MM, plain numbers are hours.
 | 
						||
                     {X}       Checkbox status, `[X]' if all children are `[X]'.
 | 
						||
                     {X/}      Checkbox status, `[n/m]'.
 | 
						||
                     {X%}      Checkbox status, `[n%]'.
 | 
						||
                     {min}     Smallest number in column.
 | 
						||
                     {max}     Largest number.
 | 
						||
                     {mean}    Arithmetic mean of numbers.
 | 
						||
                     {:min}    Smallest time value in column.
 | 
						||
                     {:max}    Largest time value.
 | 
						||
                     {:mean}   Arithmetic mean of time values.
 | 
						||
                     {@min}    Minimum age (in days/hours/mins/seconds).
 | 
						||
                     {@max}    Maximum age (in days/hours/mins/seconds).
 | 
						||
                     {@mean}   Arithmetic mean of ages (in days/hours/mins/seconds).
 | 
						||
                     {est+}    Add `low-high' estimates.
 | 
						||
 | 
						||
Be aware that you can only have one summary type for any property you
 | 
						||
include.  Subsequent columns referencing the same property will all
 | 
						||
display the same summary information.
 | 
						||
 | 
						||
   The `est+' summary type requires further explanation.  It is used for
 | 
						||
combining estimates, expressed as `low-high' ranges or plain numbers.
 | 
						||
For example, instead of estimating a particular task will take 5 days,
 | 
						||
you might estimate it as 5-6 days if you're fairly confident you know
 | 
						||
how much work is required, or 1-10 days if you don't really know what
 | 
						||
needs to be done.  Both ranges average at 5.5 days, but the first
 | 
						||
represents a more predictable delivery.
 | 
						||
 | 
						||
   When combining a set of such estimates, simply adding the lows and
 | 
						||
highs produces an unrealistically wide result.  Instead, `est+' adds the
 | 
						||
statistical mean and variance of the sub-tasks, generating a final
 | 
						||
estimate from the sum.  For example, suppose you had ten tasks, each of
 | 
						||
which was estimated at 0.5 to 2 days of work.  Straight addition
 | 
						||
produces an estimate of 5 to 20 days, representing what to expect if
 | 
						||
everything goes either extremely well or extremely poorly.  In
 | 
						||
contrast, `est+' estimates the full job more realistically, at 10-15
 | 
						||
days.
 | 
						||
 | 
						||
   Numbers are right-aligned when a format specifier with an explicit
 | 
						||
width like `%5d' or `%5.1f' is used.
 | 
						||
 | 
						||
   Here is an example for a complete columns definition, along with
 | 
						||
allowed values.
 | 
						||
 | 
						||
     :COLUMNS:  %25ITEM %9Approved(Approved?){X} %Owner %11Status \(1)
 | 
						||
                        %10Time_Estimate{:} %CLOCKSUM %CLOCKSUM_T
 | 
						||
     :Owner_ALL:    Tammy Mark Karl Lisa Don
 | 
						||
     :Status_ALL:   "In progress" "Not started yet" "Finished" ""
 | 
						||
     :Approved_ALL: "[ ]" "[X]"
 | 
						||
 | 
						||
The first column, `%25ITEM', means the first 25 characters of the item
 | 
						||
itself, i.e., of the headline.  You probably always should start the
 | 
						||
column definition with the `ITEM' specifier.  The other specifiers
 | 
						||
create columns `Owner' with a list of names as allowed values, for
 | 
						||
`Status' with four different possible values, and for a checkbox field
 | 
						||
`Approved'.  When no width is given after the `%' character, the column
 | 
						||
will be exactly as wide as it needs to be in order to fully display all
 | 
						||
values.  The `Approved' column does have a modified title (`Approved?',
 | 
						||
with a question mark).  Summaries will be created for the
 | 
						||
`Time_Estimate' column by adding time duration expressions like HH:MM,
 | 
						||
and for the `Approved' column, by providing an `[X]' status if all
 | 
						||
children have been checked.  The `CLOCKSUM' and `CLOCKSUM_T' columns
 | 
						||
are special, they lists the sums of CLOCK intervals in the subtree,
 | 
						||
either for all clocks or just for today.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Please note that the COLUMNS definition must be on a single
 | 
						||
line--it is wrapped here only because of formatting constraints.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Using column view,  Next: Capturing column view,  Prev: Defining columns,  Up: Column view
 | 
						||
 | 
						||
7.5.2 Using column view
 | 
						||
-----------------------
 | 
						||
 | 
						||
Turning column view on and off
 | 
						||
..............................
 | 
						||
 | 
						||
`C-c C-x C-c     (`org-columns')'
 | 
						||
     Turn on column view.  If the cursor is before the first headline
 | 
						||
     in the file, column view is turned on for the entire file, using
 | 
						||
     the `#+COLUMNS' definition.  If the cursor is somewhere inside the
 | 
						||
     outline, this command searches the hierarchy, up from point, for a
 | 
						||
     `:COLUMNS:' property that defines a format.  When one is found,
 | 
						||
     the column view table is established for the tree starting at the
 | 
						||
     entry that contains the `:COLUMNS:' property.  If no such property
 | 
						||
     is found, the format is taken from the `#+COLUMNS' line or from
 | 
						||
     the variable `org-columns-default-format', and column view is
 | 
						||
     established for the current entry and its subtree.  
 | 
						||
 | 
						||
`r     (`org-columns-redo')'
 | 
						||
     Recreate the column view, to include recent changes made in the
 | 
						||
     buffer.  
 | 
						||
 | 
						||
`g     (`org-columns-redo')'
 | 
						||
     Same as `r'.  
 | 
						||
 | 
						||
`q     (`org-columns-quit')'
 | 
						||
     Exit column view.
 | 
						||
 | 
						||
Editing values
 | 
						||
..............
 | 
						||
 | 
						||
`<left> <right> <up> <down>'
 | 
						||
     Move through the column view from field to field.  
 | 
						||
 | 
						||
`S-<left>/<right>'
 | 
						||
     Switch to the next/previous allowed value of the field.  For this,
 | 
						||
     you have to have specified allowed values for a property.
 | 
						||
 | 
						||
`1..9,0'
 | 
						||
     Directly select the Nth allowed value, `0' selects the 10th value.  
 | 
						||
 | 
						||
`n     (`org-columns-next-allowed-value')'
 | 
						||
`p     (`org-columns-previous-allowed-value')'
 | 
						||
     Same as `S-<left>/<right>' 
 | 
						||
 | 
						||
`e     (`org-columns-edit-value')'
 | 
						||
     Edit the property at point.  For the special properties, this will
 | 
						||
     invoke the same interface that you normally use to change that
 | 
						||
     property.  For example, when editing a TAGS property, the tag
 | 
						||
     completion or fast selection interface will pop up.  
 | 
						||
 | 
						||
`C-c C-c     (`org-columns-set-tags-or-toggle')'
 | 
						||
     When there is a checkbox at point, toggle it.  
 | 
						||
 | 
						||
`v     (`org-columns-show-value')'
 | 
						||
     View the full value of this property.  This is useful if the width
 | 
						||
     of the column is smaller than that of the value.  
 | 
						||
 | 
						||
`a     (`org-columns-edit-allowed')'
 | 
						||
     Edit the list of allowed values for this property.  If the list is
 | 
						||
     found in the hierarchy, the modified value is stored there.  If no
 | 
						||
     list is found, the new value is stored in the first entry that is
 | 
						||
     part of the current column view.
 | 
						||
 | 
						||
Modifying the table structure
 | 
						||
.............................
 | 
						||
 | 
						||
`<     (`org-columns-narrow')'
 | 
						||
`>     (`org-columns-widen')'
 | 
						||
     Make the column narrower/wider by one character.  
 | 
						||
 | 
						||
`S-M-<right>     (`org-columns-new')'
 | 
						||
     Insert a new column, to the left of the current column.  
 | 
						||
 | 
						||
`S-M-<left>     (`org-columns-delete')'
 | 
						||
     Delete the current column.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Capturing column view,  Prev: Using column view,  Up: Column view
 | 
						||
 | 
						||
7.5.3 Capturing column view
 | 
						||
---------------------------
 | 
						||
 | 
						||
Since column view is just an overlay over a buffer, it cannot be
 | 
						||
exported or printed directly.  If you want to capture a column view, use
 | 
						||
a `columnview' dynamic block (*note Dynamic blocks::).  The frame of
 | 
						||
this block looks like this:
 | 
						||
 | 
						||
     * The column view
 | 
						||
     #+BEGIN: columnview :hlines 1 :id "label"
 | 
						||
 | 
						||
     #+END:
 | 
						||
 | 
						||
This dynamic block has the following parameters:
 | 
						||
 | 
						||
`:id'
 | 
						||
     This is the most important parameter.  Column view is a feature
 | 
						||
     that is often localized to a certain (sub)tree, and the capture
 | 
						||
     block might be at a different location in the file.  To identify
 | 
						||
     the tree whose view to capture, you can use 4 values: 
 | 
						||
          local     use the tree in which the capture block is located
 | 
						||
          global    make a global view, including all headings in the file
 | 
						||
          "file:PATH-TO-FILE"
 | 
						||
                    run column view at the top of this file
 | 
						||
          "ID"      call column view in the tree that has an `:ID:'
 | 
						||
                    property with the value label.  You can use
 | 
						||
                    `M-x org-id-copy RET' to create a globally unique ID for
 | 
						||
                    the current entry and copy it to the kill-ring.
 | 
						||
 | 
						||
`:hlines'
 | 
						||
     When `t', insert an hline after every line.  When a number N,
 | 
						||
     insert an hline before each headline with level `<= N'.
 | 
						||
 | 
						||
`:vlines'
 | 
						||
     When set to `t', force column groups to get vertical lines.
 | 
						||
 | 
						||
`:maxlevel'
 | 
						||
     When set to a number, don't capture entries below this level.
 | 
						||
 | 
						||
`:skip-empty-rows'
 | 
						||
     When set to `t', skip rows where the only non-empty specifier of
 | 
						||
     the column view is `ITEM'.
 | 
						||
 | 
						||
 | 
						||
The following commands insert or update the dynamic block:
 | 
						||
 | 
						||
`C-c C-x i     (`org-insert-columns-dblock')'
 | 
						||
     Insert a dynamic block capturing a column view.  You will be
 | 
						||
     prompted for the scope or ID of the view.  
 | 
						||
 | 
						||
`C-c C-c  or  C-c C-x C-u     (`org-dblock-update')'
 | 
						||
     Update dynamic block at point.  The cursor needs to be in the
 | 
						||
     `#+BEGIN' line of the dynamic block.  
 | 
						||
 | 
						||
`C-u C-c C-x C-u     (`org-update-all-dblocks')'
 | 
						||
     Update all dynamic blocks (*note Dynamic blocks::).  This is
 | 
						||
     useful if you have several clock table blocks, column-capturing
 | 
						||
     blocks or other dynamic blocks in a buffer.
 | 
						||
 | 
						||
   You can add formulas to the column view table and you may add
 | 
						||
plotting instructions in front of the table--these will survive an
 | 
						||
update of the block.  If there is a `#+TBLFM:' after the table, the
 | 
						||
table will actually be recalculated automatically after an update.
 | 
						||
 | 
						||
   An alternative way to capture and process property values into a
 | 
						||
table is provided by Eric Schulte's `org-collector.el' which is a
 | 
						||
contributed package(1).  It provides a general API to collect
 | 
						||
properties from entries in a certain scope, and arbitrary Lisp
 | 
						||
expressions to process these values before inserting them into a table
 | 
						||
or a dynamic block.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Contributed packages are not part of Emacs, but are distributed
 | 
						||
with the main distribution of Org (visit `http://orgmode.org').
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Property API,  Prev: Column view,  Up: Properties and columns
 | 
						||
 | 
						||
7.6 The Property API
 | 
						||
====================
 | 
						||
 | 
						||
There is a full API for accessing and changing properties.  This API can
 | 
						||
be used by Emacs Lisp programs to work with properties and to implement
 | 
						||
features based on them.  For more information see *note Using the
 | 
						||
property API::.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Dates and times,  Next: Capture - Refile - Archive,  Prev: Properties and columns,  Up: Top
 | 
						||
 | 
						||
8 Dates and times
 | 
						||
*****************
 | 
						||
 | 
						||
To assist project planning, TODO items can be labeled with a date and/or
 | 
						||
a time.  The specially formatted string carrying the date and time
 | 
						||
information is called a _timestamp_ in Org mode.  This may be a little
 | 
						||
confusing because timestamp is often used to indicate when something
 | 
						||
was created or last changed.  However, in Org mode this term is used in
 | 
						||
a much wider sense.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Timestamps::                  Assigning a time to a tree entry
 | 
						||
* Creating timestamps::         Commands which insert timestamps
 | 
						||
* Deadlines and scheduling::    Planning your work
 | 
						||
* Clocking work time::          Tracking how long you spend on a task
 | 
						||
* Effort estimates::            Planning work effort in advance
 | 
						||
* Timers::                      Notes with a running timer
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Timestamps,  Next: Creating timestamps,  Up: Dates and times
 | 
						||
 | 
						||
8.1 Timestamps, deadlines, and scheduling
 | 
						||
=========================================
 | 
						||
 | 
						||
A timestamp is a specification of a date (possibly with a time or a
 | 
						||
range of times) in a special format, either `<2003-09-16 Tue>'(1) or
 | 
						||
`<2003-09-16 Tue 09:39>' or `<2003-09-16 Tue 12:00-12:30>'(2).  A
 | 
						||
timestamp can appear anywhere in the headline or body of an Org tree
 | 
						||
entry.  Its presence causes entries to be shown on specific dates in the
 | 
						||
agenda (*note Weekly/daily agenda::).  We distinguish:
 | 
						||
 | 
						||
PLAIN TIMESTAMP; EVENT; APPOINTMENT
 | 
						||
     A simple timestamp just assigns a date/time to an item.  This is
 | 
						||
     just like writing down an appointment or event in a paper agenda.
 | 
						||
     In the timeline and agenda displays, the headline of an entry
 | 
						||
     associated with a plain timestamp will be shown exactly on that
 | 
						||
     date.
 | 
						||
 | 
						||
          * Meet Peter at the movies
 | 
						||
            <2006-11-01 Wed 19:15>
 | 
						||
          * Discussion on climate change
 | 
						||
            <2006-11-02 Thu 20:00-22:00>
 | 
						||
 | 
						||
TIMESTAMP WITH REPEATER INTERVAL
 | 
						||
     A timestamp may contain a _repeater interval_, indicating that it
 | 
						||
     applies not only on the given date, but again and again after a
 | 
						||
     certain interval of N days (d), weeks (w), months (m), or years
 | 
						||
     (y).  The following will show up in the agenda every Wednesday:
 | 
						||
 | 
						||
          * Pick up Sam at school
 | 
						||
            <2007-05-16 Wed 12:30 +1w>
 | 
						||
 | 
						||
DIARY-STYLE SEXP ENTRIES
 | 
						||
     For more complex date specifications, Org mode supports using the
 | 
						||
     special sexp diary entries implemented in the Emacs calendar/diary
 | 
						||
     package(3).  For example with optional time
 | 
						||
 | 
						||
          * 22:00-23:00 The nerd meeting on every 2nd Thursday of the month
 | 
						||
            <%%(diary-float t 4 2)>
 | 
						||
 | 
						||
TIME/DATE RANGE
 | 
						||
     Two timestamps connected by `--' denote a range.  The headline
 | 
						||
     will be shown on the first and last day of the range, and on any
 | 
						||
     dates that are displayed and fall in the range.  Here is an
 | 
						||
     example:
 | 
						||
 | 
						||
          ** Meeting in Amsterdam
 | 
						||
             <2004-08-23 Mon>--<2004-08-26 Thu>
 | 
						||
 | 
						||
INACTIVE TIMESTAMP
 | 
						||
     Just like a plain timestamp, but with square brackets instead of
 | 
						||
     angular ones.  These timestamps are inactive in the sense that
 | 
						||
     they do _not_ trigger an entry to show up in the agenda.
 | 
						||
 | 
						||
          * Gillian comes late for the fifth time
 | 
						||
            [2006-11-01 Wed]
 | 
						||
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) In this simplest form, the day name is optional when you type
 | 
						||
the date yourself.  However, any dates inserted or modified by Org will
 | 
						||
add that day name, for reading convenience.
 | 
						||
 | 
						||
   (2) This is inspired by the standard ISO 8601 date/time format.  To
 | 
						||
use an alternative format, see *note Custom time format::.
 | 
						||
 | 
						||
   (3) When working with the standard diary sexp functions, you need to
 | 
						||
be very careful with the order of the arguments.  That order depends
 | 
						||
evilly on the variable `calendar-date-style' (or, for older Emacs
 | 
						||
versions, `european-calendar-style').  For example, to specify a date
 | 
						||
December 1, 2005, the call might look like `(diary-date 12 1 2005)' or
 | 
						||
`(diary-date 1 12 2005)' or `(diary-date 2005 12 1)', depending on the
 | 
						||
settings.  This has been the source of much confusion.  Org mode users
 | 
						||
can resort to special versions of these functions like `org-date' or
 | 
						||
`org-anniversary'.  These work just like the corresponding `diary-'
 | 
						||
functions, but with stable ISO order of arguments (year, month, day)
 | 
						||
wherever applicable, independent of the value of `calendar-date-style'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Creating timestamps,  Next: Deadlines and scheduling,  Prev: Timestamps,  Up: Dates and times
 | 
						||
 | 
						||
8.2 Creating timestamps
 | 
						||
=======================
 | 
						||
 | 
						||
For Org mode to recognize timestamps, they need to be in the specific
 | 
						||
format.  All commands listed below produce timestamps in the correct
 | 
						||
format.
 | 
						||
 | 
						||
`C-c .     (`org-time-stamp')'
 | 
						||
     Prompt for a date and insert a corresponding timestamp.  When the
 | 
						||
     cursor is at an existing timestamp in the buffer, the command is
 | 
						||
     used to modify this timestamp instead of inserting a new one.
 | 
						||
     When this command is used twice in succession, a time range is
 | 
						||
     inserted.  
 | 
						||
 | 
						||
`C-c !     (`org-time-stamp-inactive')'
 | 
						||
     Like `C-c .', but insert an inactive timestamp that will not cause
 | 
						||
     an agenda entry.  
 | 
						||
 | 
						||
`C-u C-c .'
 | 
						||
`C-u C-c !'
 | 
						||
     Like `C-c .' and `C-c !', but use the alternative format which
 | 
						||
     contains date and time.  The default time can be rounded to
 | 
						||
     multiples of 5 minutes, see the option
 | 
						||
     `org-time-stamp-rounding-minutes'.  
 | 
						||
 | 
						||
`C-c C-c'
 | 
						||
     Normalize timestamp, insert/fix day name if missing or wrong.  
 | 
						||
 | 
						||
`C-c <     (`org-date-from-calendar')'
 | 
						||
     Insert a timestamp corresponding to the cursor date in the
 | 
						||
     Calendar.  
 | 
						||
 | 
						||
`C-c >     (`org-goto-calendar')'
 | 
						||
     Access the Emacs calendar for the current date.  If there is a
 | 
						||
     timestamp in the current line, go to the corresponding date
 | 
						||
     instead.  
 | 
						||
 | 
						||
`C-c C-o     (`org-open-at-point')'
 | 
						||
     Access the agenda for the date given by the timestamp or -range at
 | 
						||
     point (*note Weekly/daily agenda::).  
 | 
						||
 | 
						||
`S-<left>     (`org-timestamp-down-day')'
 | 
						||
`S-<right>     (`org-timestamp-up-day')'
 | 
						||
     Change date at cursor by one day.  These key bindings conflict with
 | 
						||
     shift-selection and related modes (*note Conflicts::).  
 | 
						||
 | 
						||
`S-<up>     (`org-timestamp-up')'
 | 
						||
`S-<down>     (`org-timestamp-down-down')'
 | 
						||
     Change the item under the cursor in a timestamp.  The cursor can
 | 
						||
     be on a year, month, day, hour or minute.  When the timestamp
 | 
						||
     contains a time range like `15:30-16:30', modifying the first time
 | 
						||
     will also shift the second, shifting the time block with constant
 | 
						||
     length.  To change the length, modify the second time.  Note that
 | 
						||
     if the cursor is in a headline and not at a timestamp, these same
 | 
						||
     keys modify the priority of an item.  (*note Priorities::).  The
 | 
						||
     key bindings also conflict with shift-selection and related modes
 | 
						||
     (*note Conflicts::).  
 | 
						||
 | 
						||
`C-c C-y     (`org-evaluate-time-range')'
 | 
						||
     Evaluate a time range by computing the difference between start
 | 
						||
     and end.  With a prefix argument, insert result after the time
 | 
						||
     range (in a table: into the following column).
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* The date/time prompt::        How Org mode helps you entering date and time
 | 
						||
* Custom time format::          Making dates look different
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: The date/time prompt,  Next: Custom time format,  Up: Creating timestamps
 | 
						||
 | 
						||
8.2.1 The date/time prompt
 | 
						||
--------------------------
 | 
						||
 | 
						||
When Org mode prompts for a date/time, the default is shown in default
 | 
						||
date/time format, and the prompt therefore seems to ask for a specific
 | 
						||
format.  But it will in fact accept date/time information in a variety
 | 
						||
of formats.  Generally, the information should start at the beginning
 | 
						||
of the string.  Org mode will find whatever information is in there and
 | 
						||
derive anything you have not specified from the _default date and
 | 
						||
time_.  The default is usually the current date and time, but when
 | 
						||
modifying an existing timestamp, or when entering the second stamp of a
 | 
						||
range, it is taken from the stamp in the buffer.  When filling in
 | 
						||
information, Org mode assumes that most of the time you will want to
 | 
						||
enter a date in the future: if you omit the month/year and the given
 | 
						||
day/month is before today, it will assume that you mean a future
 | 
						||
date(1).  If the date has been automatically shifted into the future,
 | 
						||
the time prompt will show this with `(=>F).'
 | 
						||
 | 
						||
   For example, let's assume that today is June 13, 2006.  Here is how
 | 
						||
various inputs will be interpreted, the items filled in by Org mode are
 | 
						||
in bold.
 | 
						||
 | 
						||
     3-2-5         => 2003-02-05
 | 
						||
     2/5/3         => 2003-02-05
 | 
						||
     14            => 2006-06-14
 | 
						||
     12            => 2006-07-12
 | 
						||
     2/5           => 2007-02-05
 | 
						||
     Fri           => nearest Friday after the default date
 | 
						||
     sep 15        => 2006-09-15
 | 
						||
     feb 15        => 2007-02-15
 | 
						||
     sep 12 9      => 2009-09-12
 | 
						||
     12:45         => 2006-06-13 12:45
 | 
						||
     22 sept 0:34  => 2006-09-22 00:34
 | 
						||
     w4            => ISO week for of the current year 2006
 | 
						||
     2012 w4 fri   => Friday of ISO week 4 in 2012
 | 
						||
     2012-w04-5    => Same as above
 | 
						||
 | 
						||
   Furthermore you can specify a relative date by giving, as the _first_
 | 
						||
thing in the input: a plus/minus sign, a number and a letter ([hdwmy])
 | 
						||
to indicate change in hours, days, weeks, months, or years.  With a
 | 
						||
single plus or minus, the date is always relative to today.  With a
 | 
						||
double plus or minus, it is relative to the default date.  If instead
 | 
						||
of a single letter, you use the abbreviation of day name, the date will
 | 
						||
be the Nth such day, e.g.:
 | 
						||
 | 
						||
     +0            => today
 | 
						||
     .             => today
 | 
						||
     +4d           => four days from today
 | 
						||
     +4            => same as above
 | 
						||
     +2w           => two weeks from today
 | 
						||
     ++5           => five days from default date
 | 
						||
     +2tue         => second Tuesday from now
 | 
						||
     -wed          => last Wednesday
 | 
						||
 | 
						||
   The function understands English month and weekday abbreviations.  If
 | 
						||
you want to use unabbreviated names and/or other languages, configure
 | 
						||
the variables `parse-time-months' and `parse-time-weekdays'.
 | 
						||
 | 
						||
   Not all dates can be represented in a given Emacs implementation.
 | 
						||
By default Org mode forces dates into the compatibility range 1970-2037
 | 
						||
which works on all Emacs implementations.  If you want to use dates
 | 
						||
outside of this range, read the docstring of the variable
 | 
						||
`org-read-date-force-compatible-dates'.
 | 
						||
 | 
						||
   You can specify a time range by giving start and end times or by
 | 
						||
giving a start time and a duration (in HH:MM format).  Use one or two
 | 
						||
dash(es) as the separator in the former case and use '+' as the
 | 
						||
separator in the latter case, e.g.:
 | 
						||
 | 
						||
     11am-1:15pm    => 11:00-13:15
 | 
						||
     11am--1:15pm   => same as above
 | 
						||
     11am+2:15      => same as above
 | 
						||
 | 
						||
   Parallel to the minibuffer prompt, a calendar is popped up(2).  When
 | 
						||
you exit the date prompt, either by clicking on a date in the calendar,
 | 
						||
or by pressing <RET>, the date selected in the calendar will be
 | 
						||
combined with the information entered at the prompt.  You can control
 | 
						||
the calendar fully from the minibuffer:
 | 
						||
 | 
						||
     <RET>              Choose date at cursor in calendar.
 | 
						||
     mouse-1            Select date by clicking on it.
 | 
						||
     S-<right>/<left>   One day forward/backward.
 | 
						||
     S-<down>/<up>      One week forward/backward.
 | 
						||
     M-S-<right>/<left> One month forward/backward.
 | 
						||
     > / <              Scroll calendar forward/backward by one month.
 | 
						||
     M-v / C-v          Scroll calendar forward/backward by 3 months.
 | 
						||
     M-S-<down>/<up>    Scroll calendar forward/backward by one year.
 | 
						||
 | 
						||
   The actions of the date/time prompt may seem complex, but I assure
 | 
						||
you they will grow on you, and you will start getting annoyed by pretty
 | 
						||
much any other way of entering a date/time out there.  To help you
 | 
						||
understand what is going on, the current interpretation of your input
 | 
						||
will be displayed live in the minibuffer(3).
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) See the variable `org-read-date-prefer-future'.  You may set
 | 
						||
that variable to the symbol `time' to even make a time before now shift
 | 
						||
the date to tomorrow.
 | 
						||
 | 
						||
   (2) If you don't need/want the calendar, configure the variable
 | 
						||
`org-popup-calendar-for-date-prompt'.
 | 
						||
 | 
						||
   (3) If you find this distracting, turn the display off with
 | 
						||
`org-read-date-display-live'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Custom time format,  Prev: The date/time prompt,  Up: Creating timestamps
 | 
						||
 | 
						||
8.2.2 Custom time format
 | 
						||
------------------------
 | 
						||
 | 
						||
Org mode uses the standard ISO notation for dates and times as it is
 | 
						||
defined in ISO 8601.  If you cannot get used to this and require another
 | 
						||
representation of date and time to keep you happy, you can get it by
 | 
						||
customizing the options `org-display-custom-times' and
 | 
						||
`org-time-stamp-custom-formats'.
 | 
						||
 | 
						||
`C-c C-x C-t     (`org-toggle-time-stamp-overlays')'
 | 
						||
     Toggle the display of custom formats for dates and times.
 | 
						||
 | 
						||
Org mode needs the default format for scanning, so the custom date/time
 | 
						||
format does not _replace_ the default format--instead it is put _over_
 | 
						||
the default format using text properties.  This has the following
 | 
						||
consequences:
 | 
						||
   * You cannot place the cursor onto a timestamp anymore, only before
 | 
						||
     or after.
 | 
						||
 | 
						||
   * The `S-<up>/<down>' keys can no longer be used to adjust each
 | 
						||
     component of a timestamp.  If the cursor is at the beginning of
 | 
						||
     the stamp, `S-<up>/<down>' will change the stamp by one day, just
 | 
						||
     like `S-<left>/<right>'.  At the end of the stamp, the time will
 | 
						||
     be changed by one minute.
 | 
						||
 | 
						||
   * If the timestamp contains a range of clock times or a repeater,
 | 
						||
     these will not be overlaid, but remain in the buffer as they were.
 | 
						||
 | 
						||
   * When you delete a timestamp character-by-character, it will only
 | 
						||
     disappear from the buffer after _all_ (invisible) characters
 | 
						||
     belonging to the ISO timestamp have been removed.
 | 
						||
 | 
						||
   * If the custom timestamp format is longer than the default and you
 | 
						||
     are using dates in tables, table alignment will be messed up.  If
 | 
						||
     the custom format is shorter, things do work as expected.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Deadlines and scheduling,  Next: Clocking work time,  Prev: Creating timestamps,  Up: Dates and times
 | 
						||
 | 
						||
8.3 Deadlines and scheduling
 | 
						||
============================
 | 
						||
 | 
						||
A timestamp may be preceded by special keywords to facilitate planning:
 | 
						||
 | 
						||
DEADLINE
 | 
						||
     Meaning: the task (most likely a TODO item, though not
 | 
						||
     necessarily) is supposed to be finished on that date.
 | 
						||
 | 
						||
     On the deadline date, the task will be listed in the agenda.  In
 | 
						||
     addition, the agenda for _today_ will carry a warning about the
 | 
						||
     approaching or missed deadline, starting
 | 
						||
     `org-deadline-warning-days' before the due date, and continuing
 | 
						||
     until the entry is marked DONE.  An example:
 | 
						||
 | 
						||
          *** TODO write article about the Earth for the Guide
 | 
						||
              DEADLINE: <2004-02-29 Sun>
 | 
						||
              The editor in charge is [[bbdb:Ford Prefect]]
 | 
						||
 | 
						||
     You can specify a different lead time for warnings for a specific
 | 
						||
     deadline using the following syntax.  Here is an example with a
 | 
						||
     warning period of 5 days `DEADLINE: <2004-02-29 Sun -5d>'.  This
 | 
						||
     warning is deactivated if the task gets scheduled and you set
 | 
						||
     `org-agenda-skip-deadline-prewarning-if-scheduled' to `t'.
 | 
						||
 | 
						||
SCHEDULED
 | 
						||
     Meaning: you are planning to start working on that task on the
 | 
						||
     given date.
 | 
						||
 | 
						||
     The headline will be listed under the given date(1).  In addition,
 | 
						||
     a reminder that the scheduled date has passed will be present in
 | 
						||
     the compilation for _today_, until the entry is marked DONE, i.e.,
 | 
						||
     the task will automatically be forwarded until completed.
 | 
						||
 | 
						||
          *** TODO Call Trillian for a date on New Years Eve.
 | 
						||
              SCHEDULED: <2004-12-25 Sat>
 | 
						||
 | 
						||
     If you want to _delay_ the display of this task in the agenda, use
 | 
						||
     `SCHEDULED: <2004-12-25 Sat -2d>': the task is still scheduled on
 | 
						||
     the 25th but will appear two days later.  In case the task
 | 
						||
     contains a repeater, the delay is considered to affect all
 | 
						||
     occurrences; if you want the delay to only affect the first
 | 
						||
     scheduled occurrence of the task, use `--2d' instead.  See
 | 
						||
     `org-scheduled-delay-days' and
 | 
						||
     `org-agenda-skip-scheduled-delay-if-deadline' for details on how to
 | 
						||
     control this globally or per agenda.
 | 
						||
 | 
						||
     Important: Scheduling an item in Org mode should not be understood
 | 
						||
     in the same way that we understand scheduling a meeting.  Setting
 | 
						||
     a date for a meeting is just a simple appointment, you should mark
 | 
						||
     this entry with a simple plain timestamp, to get this item shown
 | 
						||
     on the date where it applies.  This is a frequent misunderstanding
 | 
						||
     by Org users.  In Org mode, scheduling means setting a date when
 | 
						||
     you want to start working on an action item.
 | 
						||
 | 
						||
   You may use timestamps with repeaters in scheduling and deadline
 | 
						||
entries.  Org mode will issue early and late warnings based on the
 | 
						||
assumption that the timestamp represents the nearest instance of the
 | 
						||
repeater.  However, the use of diary sexp entries like `<%%(diary-float
 | 
						||
t 42)>' in scheduling and deadline timestamps is limited.  Org mode
 | 
						||
does not know enough about the internals of each sexp function to issue
 | 
						||
early and late warnings.  However, it will show the item on each day
 | 
						||
where the sexp entry matches.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Inserting deadline/schedule::  Planning items
 | 
						||
* Repeated tasks::              Items that show up again and again
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) It will still be listed on that date after it has been marked
 | 
						||
DONE.  If you don't like this, set the variable
 | 
						||
`org-agenda-skip-scheduled-if-done'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Inserting deadline/schedule,  Next: Repeated tasks,  Up: Deadlines and scheduling
 | 
						||
 | 
						||
8.3.1 Inserting deadlines or schedules
 | 
						||
--------------------------------------
 | 
						||
 | 
						||
The following commands allow you to quickly insert(1) a deadline or to
 | 
						||
schedule an item:
 | 
						||
 | 
						||
`C-c C-d     (`org-deadline')'
 | 
						||
     Insert `DEADLINE' keyword along with a stamp.  The insertion will
 | 
						||
     happen in the line directly following the headline.  Any CLOSED
 | 
						||
     timestamp will be removed.  When called with a prefix arg, an
 | 
						||
     existing deadline will be removed from the entry.  Depending on
 | 
						||
     the variable `org-log-redeadline'(2), a note will be taken when
 | 
						||
     changing an existing deadline.
 | 
						||
 | 
						||
`C-c C-s     (`org-schedule')'
 | 
						||
     Insert `SCHEDULED' keyword along with a stamp.  The insertion will
 | 
						||
     happen in the line directly following the headline.  Any CLOSED
 | 
						||
     timestamp will be removed.  When called with a prefix argument,
 | 
						||
     remove the scheduling date from the entry.  Depending on the
 | 
						||
     variable `org-log-reschedule'(3), a note will be taken when
 | 
						||
     changing an existing scheduling time.  
 | 
						||
 | 
						||
`C-c / d     (`org-check-deadlines')'
 | 
						||
     Create a sparse tree with all deadlines that are either past-due,
 | 
						||
     or which will become due within `org-deadline-warning-days'.  With
 | 
						||
     `C-u' prefix, show all deadlines in the file.  With a numeric
 | 
						||
     prefix, check that many days.  For example, `C-1 C-c / d' shows
 | 
						||
     all deadlines due tomorrow.  
 | 
						||
 | 
						||
`C-c / b     (`org-check-before-date')'
 | 
						||
     Sparse tree for deadlines and scheduled items before a given date.  
 | 
						||
 | 
						||
`C-c / a     (`org-check-after-date')'
 | 
						||
     Sparse tree for deadlines and scheduled items after a given date.
 | 
						||
 | 
						||
   Note that `org-schedule' and `org-deadline' supports setting the
 | 
						||
date by indicating a relative time: e.g., +1d will set the date to the
 | 
						||
next day after today, and -1w will set the date to the previous week
 | 
						||
before any current timestamp.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) The `SCHEDULED' and `DEADLINE' dates are inserted on the line
 | 
						||
right below the headline.  Don't put any text between this line and the
 | 
						||
headline.
 | 
						||
 | 
						||
   (2) with corresponding `#+STARTUP' keywords `logredeadline',
 | 
						||
`lognoteredeadline', and `nologredeadline'
 | 
						||
 | 
						||
   (3) with corresponding `#+STARTUP' keywords `logreschedule',
 | 
						||
`lognotereschedule', and `nologreschedule'
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Repeated tasks,  Prev: Inserting deadline/schedule,  Up: Deadlines and scheduling
 | 
						||
 | 
						||
8.3.2 Repeated tasks
 | 
						||
--------------------
 | 
						||
 | 
						||
Some tasks need to be repeated again and again.  Org mode helps to
 | 
						||
organize such tasks using a so-called repeater in a DEADLINE, SCHEDULED,
 | 
						||
or plain timestamp.  In the following example
 | 
						||
     ** TODO Pay the rent
 | 
						||
        DEADLINE: <2005-10-01 Sat +1m>
 | 
						||
   the `+1m' is a repeater; the intended interpretation is that the task
 | 
						||
has a deadline on <2005-10-01> and repeats itself every (one) month
 | 
						||
starting from that time.  You can use yearly, monthly, weekly, daily
 | 
						||
and hourly repeat cookies by using the `y/w/m/d/h' letters.  If you
 | 
						||
need both a repeater and a special warning period in a deadline entry,
 | 
						||
the repeater should come first and the warning period last: `DEADLINE:
 | 
						||
<2005-10-01 Sat +1m -3d>'.
 | 
						||
 | 
						||
   Deadlines and scheduled items produce entries in the agenda when
 | 
						||
they are over-due, so it is important to be able to mark such an entry
 | 
						||
as completed once you have done so.  When you mark a DEADLINE or a
 | 
						||
SCHEDULE with the TODO keyword DONE, it will no longer produce entries
 | 
						||
in the agenda.  The problem with this is, however, that then also the
 | 
						||
_next_ instance of the repeated entry will not be active.  Org mode
 | 
						||
deals with this in the following way: When you try to mark such an
 | 
						||
entry DONE (using `C-c C-t'), it will shift the base date of the
 | 
						||
repeating timestamp by the repeater interval, and immediately set the
 | 
						||
entry state back to TODO(1).  In the example above, setting the state
 | 
						||
to DONE would actually switch the date like this:
 | 
						||
 | 
						||
     ** TODO Pay the rent
 | 
						||
        DEADLINE: <2005-11-01 Tue +1m>
 | 
						||
 | 
						||
   To mark a task with a repeater as `DONE', use `C-- 1 C-c C-t' (i.e.,
 | 
						||
`org-todo' with a numeric prefix argument of -1.)
 | 
						||
 | 
						||
   A timestamp(2) will be added under the deadline, to keep a record
 | 
						||
that you actually acted on the previous instance of this deadline.
 | 
						||
 | 
						||
   As a consequence of shifting the base date, this entry will no
 | 
						||
longer be visible in the agenda when checking past dates, but all
 | 
						||
future instances will be visible.
 | 
						||
 | 
						||
   With the `+1m' cookie, the date shift will always be exactly one
 | 
						||
month.  So if you have not paid the rent for three months, marking this
 | 
						||
entry DONE will still keep it as an overdue deadline.  Depending on the
 | 
						||
task, this may not be the best way to handle it.  For example, if you
 | 
						||
forgot to call your father for 3 weeks, it does not make sense to call
 | 
						||
him 3 times in a single day to make up for it.  Finally, there are tasks
 | 
						||
like changing batteries which should always repeat a certain time after
 | 
						||
the last time you did it.  For these tasks, Org mode has special
 | 
						||
repeaters  `++' and `.+'.  For example:
 | 
						||
 | 
						||
     ** TODO Call Father
 | 
						||
        DEADLINE: <2008-02-10 Sun ++1w>
 | 
						||
        Marking this DONE will shift the date by at least one week,
 | 
						||
        but also by as many weeks as it takes to get this date into
 | 
						||
        the future.  However, it stays on a Sunday, even if you called
 | 
						||
        and marked it done on Saturday.
 | 
						||
     ** TODO Check the batteries in the smoke detectors
 | 
						||
        DEADLINE: <2005-11-01 Tue .+1m>
 | 
						||
        Marking this DONE will shift the date to one month after
 | 
						||
        today.
 | 
						||
 | 
						||
   You may have both scheduling and deadline information for a specific
 | 
						||
task.  If the repeater is set for the scheduling information only, you
 | 
						||
probably want the repeater to be ignored after the deadline.  If so,
 | 
						||
set the variable `org-agenda-skip-scheduled-if-deadline-is-shown' to
 | 
						||
`repeated-after-deadline'.  If you want both scheduling and deadline
 | 
						||
information to repeat after the same interval, set the same repeater
 | 
						||
for both timestamps.
 | 
						||
 | 
						||
   An alternative to using a repeater is to create a number of copies
 | 
						||
of a task subtree, with dates shifted in each copy.  The command `C-c
 | 
						||
C-x c' was created for this purpose, it is described in *note Structure
 | 
						||
editing::.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) In fact, the target state is taken from, in this sequence, the
 | 
						||
`REPEAT_TO_STATE' property or the variable `org-todo-repeat-to-state'.
 | 
						||
If neither of these is specified, the target state defaults to the
 | 
						||
first state of the TODO state sequence.
 | 
						||
 | 
						||
   (2) You can change this using the option `org-log-repeat', or the
 | 
						||
`#+STARTUP' options `logrepeat', `lognoterepeat', and `nologrepeat'.
 | 
						||
With `lognoterepeat', you will also be prompted for a note.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Clocking work time,  Next: Effort estimates,  Prev: Deadlines and scheduling,  Up: Dates and times
 | 
						||
 | 
						||
8.4 Clocking work time
 | 
						||
======================
 | 
						||
 | 
						||
Org mode allows you to clock the time you spend on specific tasks in a
 | 
						||
project.  When you start working on an item, you can start the clock.
 | 
						||
When you stop working on that task, or when you mark the task done, the
 | 
						||
clock is stopped and the corresponding time interval is recorded.  It
 | 
						||
also computes the total time spent on each subtree(1) of a project.
 | 
						||
And it remembers a history or tasks recently clocked, so that you can
 | 
						||
jump quickly between a number of tasks absorbing your time.
 | 
						||
 | 
						||
   To save the clock history across Emacs sessions, use
 | 
						||
     (setq org-clock-persist 'history)
 | 
						||
     (org-clock-persistence-insinuate)
 | 
						||
   When you clock into a new task after resuming Emacs, the incomplete
 | 
						||
clock(2) will be found (*note Resolving idle time::) and you will be
 | 
						||
prompted about what to do with it.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Clocking commands::           Starting and stopping a clock
 | 
						||
* The clock table::             Detailed reports
 | 
						||
* Resolving idle time::         Resolving time when you've been idle
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Clocking only works if all headings are indented with less than
 | 
						||
30 stars.  This is a hardcoded limitation of `lmax' in `org-clock-sum'.
 | 
						||
 | 
						||
   (2) To resume the clock under the assumption that you have worked on
 | 
						||
this task while outside Emacs, use `(setq org-clock-persist t)'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Clocking commands,  Next: The clock table,  Up: Clocking work time
 | 
						||
 | 
						||
8.4.1 Clocking commands
 | 
						||
-----------------------
 | 
						||
 | 
						||
`C-c C-x C-i     (`org-clock-in')'
 | 
						||
     Start the clock on the current item (clock-in).  This inserts the
 | 
						||
     CLOCK keyword together with a timestamp.  If this is not the first
 | 
						||
     clocking of this item, the multiple CLOCK lines will be wrapped
 | 
						||
     into a `:LOGBOOK:' drawer (see also the variable
 | 
						||
     `org-clock-into-drawer').  You can also overrule the setting of
 | 
						||
     this variable for a subtree by setting a `CLOCK_INTO_DRAWER' or
 | 
						||
     `LOG_INTO_DRAWER' property.  When called with a `C-u' prefix
 | 
						||
     argument, select the task from a list of recently clocked tasks.
 | 
						||
     With two `C-u C-u' prefixes, clock into the task at point and mark
 | 
						||
     it as the default task; the default task will then always be
 | 
						||
     available with letter `d' when selecting a clocking task.  With
 | 
						||
     three `C-u C-u C-u' prefixes, force continuous clocking by
 | 
						||
     starting the clock when the last clock stopped.
 | 
						||
     While the clock is running, the current clocking time is shown in
 | 
						||
     the mode line, along with the title of the task.  The clock time
 | 
						||
     shown will be all time ever clocked for this task and its
 | 
						||
     children.  If the task has an effort estimate (*note Effort
 | 
						||
     estimates::), the mode line displays the current clocking time
 | 
						||
     against it(1)  If the task is a repeating one (*note Repeated
 | 
						||
     tasks::), only the time since the last reset of the task (2) will
 | 
						||
     be shown.  More control over what time is shown can be exercised
 | 
						||
     with the `CLOCK_MODELINE_TOTAL' property.  It may have the values
 | 
						||
     `current' to show only the current clocking instance, `today' to
 | 
						||
     show all time clocked on this task today (see also the variable
 | 
						||
     `org-extend-today-until'), `all' to include all time, or `auto'
 | 
						||
     which is the default(3).
 | 
						||
     Clicking with `mouse-1' onto the mode line entry will pop up a
 | 
						||
     menu with clocking options.  
 | 
						||
 | 
						||
`C-c C-x C-o     (`org-clock-out')'
 | 
						||
     Stop the clock (clock-out).  This inserts another timestamp at the
 | 
						||
     same location where the clock was last started.  It also directly
 | 
						||
     computes the resulting time and inserts it after the time range as
 | 
						||
     `=> HH:MM'.  See the variable `org-log-note-clock-out' for the
 | 
						||
     possibility to record an additional note together with the
 | 
						||
     clock-out timestamp(4).  
 | 
						||
 | 
						||
`C-c C-x C-x     (`org-clock-in-last')'
 | 
						||
     Reclock the last clocked task.  With one `C-u' prefix argument,
 | 
						||
     select the task from the clock history.  With two `C-u' prefixes,
 | 
						||
     force continuous clocking by starting the clock when the last clock
 | 
						||
     stopped.  
 | 
						||
 | 
						||
`C-c C-x C-e     (`org-clock-modify-effort-estimate')'
 | 
						||
     Update the effort estimate for the current clock task.  
 | 
						||
 | 
						||
`C-c C-c  or  C-c C-y     (`org-evaluate-time-range')'
 | 
						||
     Recompute the time interval after changing one of the timestamps.
 | 
						||
     This is only necessary if you edit the timestamps directly.  If
 | 
						||
     you change them with `S-<cursor>' keys, the update is automatic.  
 | 
						||
 | 
						||
`C-S-<up/down>     (`org-clock-timestamps-up/down')'
 | 
						||
     On `CLOCK' log lines, increase/decrease both timestamps so that the
 | 
						||
     clock duration keeps the same.  
 | 
						||
 | 
						||
`S-M-<up/down>     (`org-timestamp-up/down')'
 | 
						||
     On `CLOCK' log lines, increase/decrease the timestamp at point and
 | 
						||
     the one of the previous (or the next clock) timestamp by the same
 | 
						||
     duration.  For example, if you hit `S-M-<up>' to increase a
 | 
						||
     clocked-out timestamp by five minutes, then the clocked-in
 | 
						||
     timestamp of the next clock will be increased by five minutes.  
 | 
						||
 | 
						||
`C-c C-t     (`org-todo')'
 | 
						||
     Changing the TODO state of an item to DONE automatically stops the
 | 
						||
     clock if it is running in this same item.  
 | 
						||
 | 
						||
`C-c C-x C-q     (`org-clock-cancel')'
 | 
						||
     Cancel the current clock.  This is useful if a clock was started by
 | 
						||
     mistake, or if you ended up working on something else.  
 | 
						||
 | 
						||
`C-c C-x C-j     (`org-clock-goto')'
 | 
						||
     Jump to the headline of the currently clocked in task.  With a
 | 
						||
     `C-u' prefix arg, select the target task from a list of recently
 | 
						||
     clocked tasks.  
 | 
						||
 | 
						||
`C-c C-x C-d     (`org-clock-display')'
 | 
						||
     Display time summaries for each subtree in the current buffer.
 | 
						||
     This puts overlays at the end of each headline, showing the total
 | 
						||
     time recorded under that heading, including the time of any
 | 
						||
     subheadings.  You can use visibility cycling to study the tree,
 | 
						||
     but the overlays disappear when you change the buffer (see
 | 
						||
     variable `org-remove-highlights-with-change') or press `C-c C-c'.
 | 
						||
 | 
						||
   The `l' key may be used in the timeline (*note Timeline::) and in
 | 
						||
the agenda (*note Weekly/daily agenda::) to show which tasks have been
 | 
						||
worked on or closed during a day.
 | 
						||
 | 
						||
   *Important:* note that both `org-clock-out' and `org-clock-in-last'
 | 
						||
can have a global keybinding and will not modify the window disposition.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) To add an effort estimate "on the fly", hook a function doing
 | 
						||
this to `org-clock-in-prepare-hook'.
 | 
						||
 | 
						||
   (2) as recorded by the `LAST_REPEAT' property
 | 
						||
 | 
						||
   (3) See also the variable `org-clock-modeline-total'.
 | 
						||
 | 
						||
   (4) The corresponding in-buffer setting is: `#+STARTUP:
 | 
						||
lognoteclock-out'
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: The clock table,  Next: Resolving idle time,  Prev: Clocking commands,  Up: Clocking work time
 | 
						||
 | 
						||
8.4.2 The clock table
 | 
						||
---------------------
 | 
						||
 | 
						||
Org mode can produce quite complex reports based on the time clocking
 | 
						||
information.  Such a report is called a _clock table_, because it is
 | 
						||
formatted as one or several Org tables.
 | 
						||
 | 
						||
`C-c C-x C-r     (`org-clock-report')'
 | 
						||
     Insert a dynamic block (*note Dynamic blocks::) containing a clock
 | 
						||
     report as an Org mode table into the current file.  When the
 | 
						||
     cursor is at an existing clock table, just update it.  When called
 | 
						||
     with a prefix argument, jump to the first clock report in the
 | 
						||
     current document and update it.  The clock table always includes
 | 
						||
     also trees with `:ARCHIVE:' tag.  
 | 
						||
 | 
						||
`C-c C-c  or  C-c C-x C-u     (`org-dblock-update')'
 | 
						||
     Update dynamic block at point.  The cursor needs to be in the
 | 
						||
     `#+BEGIN' line of the dynamic block.  
 | 
						||
 | 
						||
`C-u C-c C-x C-u'
 | 
						||
     Update all dynamic blocks (*note Dynamic blocks::).  This is
 | 
						||
     useful if you have several clock table blocks in a buffer.  
 | 
						||
 | 
						||
`S-<left>'
 | 
						||
`S-<right>     (`org-clocktable-try-shift')'
 | 
						||
     Shift the current `:block' interval and update the table.  The
 | 
						||
     cursor needs to be in the `#+BEGIN: clocktable' line for this
 | 
						||
     command.  If `:block' is `today', it will be shifted to `today-1'
 | 
						||
     etc.
 | 
						||
 | 
						||
   Here is an example of the frame for a clock table as it is inserted
 | 
						||
into the buffer with the `C-c C-x C-r' command:
 | 
						||
 | 
						||
     #+BEGIN: clocktable :maxlevel 2 :emphasize nil :scope file
 | 
						||
     #+END: clocktable
 | 
						||
   The `BEGIN' line specifies a number of options to define the scope,
 | 
						||
structure, and formatting of the report.  Defaults for all these
 | 
						||
options can be configured in the variable `org-clocktable-defaults'.
 | 
						||
 | 
						||
First there are options that determine which clock entries are to be
 | 
						||
selected:
 | 
						||
     :maxlevel    Maximum level depth to which times are listed in the table.
 | 
						||
                  Clocks at deeper levels will be summed into the upper level.
 | 
						||
     :scope       The scope to consider.  This can be any of the following:
 | 
						||
                  nil        the current buffer or narrowed region
 | 
						||
                  file       the full current buffer
 | 
						||
                  subtree    the subtree where the clocktable is located
 | 
						||
                  treeN      the surrounding level N tree, for example `tree3'
 | 
						||
                  tree       the surrounding level 1 tree
 | 
						||
                  agenda     all agenda files
 | 
						||
                  ("file"..) scan these files
 | 
						||
                  file-with-archives    current file and its archives
 | 
						||
                  agenda-with-archives  all agenda files, including archives
 | 
						||
     :block       The time block to consider.  This block is specified either
 | 
						||
                  absolutely, or relative to the current time and may be any of
 | 
						||
                  these formats:
 | 
						||
                  2007-12-31    New year eve 2007
 | 
						||
                  2007-12       December 2007
 | 
						||
                  2007-W50      ISO-week 50 in 2007
 | 
						||
                  2007-Q2       2nd quarter in 2007
 | 
						||
                  2007          the year 2007
 | 
						||
                  today, yesterday, today-N          a relative day
 | 
						||
                  thisweek, lastweek, thisweek-N     a relative week
 | 
						||
                  thismonth, lastmonth, thismonth-N  a relative month
 | 
						||
                  thisyear, lastyear, thisyear-N     a relative year
 | 
						||
                  untilnow
 | 
						||
                  Use `S-<left>/<right>' keys to shift the time interval.
 | 
						||
     :tstart      A time string specifying when to start considering times.
 | 
						||
                  Relative times like `"<-2w>"' can also be used.  See
 | 
						||
                  *note Matching tags and properties:: for relative time syntax.
 | 
						||
     :tend        A time string specifying when to stop considering times.
 | 
						||
                  Relative times like `"<now>"' can also be used.  See
 | 
						||
                  *note Matching tags and properties:: for relative time syntax.
 | 
						||
     :wstart      The starting day of the week.  The default is 1 for monday.
 | 
						||
     :mstart      The starting day of the month.  The default 1 is for the first
 | 
						||
                  day of the month.
 | 
						||
     :step        `week' or `day', to split the table into chunks.
 | 
						||
                  To use this, `:block' or `:tstart', `:tend' are needed.
 | 
						||
     :stepskip0   Do not show steps that have zero time.
 | 
						||
     :fileskip0   Do not show table sections from files which did not contribute.
 | 
						||
     :tags        A tags match to select entries that should contribute.  See
 | 
						||
                  *note Matching tags and properties:: for the match syntax.
 | 
						||
 | 
						||
   Then there are options which determine the formatting of the table.
 | 
						||
These options are interpreted by the function
 | 
						||
`org-clocktable-write-default', but you can specify your own function
 | 
						||
using the `:formatter' parameter.
 | 
						||
     :emphasize   When `t', emphasize level one and level two items.
 | 
						||
     :lang        Language(1) to use for descriptive cells like "Task".
 | 
						||
     :link        Link the item headlines in the table to their origins.
 | 
						||
     :narrow      An integer to limit the width of the headline column in
 | 
						||
                  the org table.  If you write it like `50!', then the
 | 
						||
                  headline will also be shortened in export.
 | 
						||
     :indent      Indent each headline field according to its level.
 | 
						||
     :tcolumns    Number of columns to be used for times.  If this is smaller
 | 
						||
                  than `:maxlevel', lower levels will be lumped into one column.
 | 
						||
     :level       Should a level number column be included?
 | 
						||
     :sort        A cons cell like containing the column to sort and a sorting type.
 | 
						||
                  E.g., `:sort (1 . ?a)' sorts the first column alphabetically.
 | 
						||
     :compact     Abbreviation for `:level nil :indent t :narrow 40! :tcolumns 1'
 | 
						||
                  All are overwritten except if there is an explicit `:narrow'
 | 
						||
     :timestamp   A timestamp for the entry, when available.  Look for SCHEDULED,
 | 
						||
                  DEADLINE, TIMESTAMP and TIMESTAMP_IA, in this order.
 | 
						||
     :properties  List of properties that should be shown in the table.  Each
 | 
						||
                  property will get its own column.
 | 
						||
     :inherit-props When this flag is `t', the values for `:properties' will be inherited.
 | 
						||
     :formula     Content of a `#+TBLFM' line to be added and evaluated.
 | 
						||
                  As a special case, `:formula %' adds a column with % time.
 | 
						||
                  If you do not specify a formula here, any existing formula
 | 
						||
                  below the clock table will survive updates and be evaluated.
 | 
						||
     :formatter   A function to format clock data and insert it into the buffer.
 | 
						||
   To get a clock summary of the current level 1 tree, for the current
 | 
						||
day, you could write
 | 
						||
     #+BEGIN: clocktable :maxlevel 2 :block today :scope tree1 :link t
 | 
						||
     #+END: clocktable
 | 
						||
   and to use a specific time range you could write(2)
 | 
						||
     #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>"
 | 
						||
                         :tend "<2006-08-10 Thu 12:00>"
 | 
						||
     #+END: clocktable
 | 
						||
   A range starting a week ago and ending right now could be written as
 | 
						||
     #+BEGIN: clocktable :tstart "<-1w>" :tend "<now>"
 | 
						||
     #+END: clocktable
 | 
						||
   A summary of the current subtree with % times would be
 | 
						||
     #+BEGIN: clocktable :scope subtree :link t :formula %
 | 
						||
     #+END: clocktable
 | 
						||
   A horizontally compact representation of everything clocked during
 | 
						||
last week would be
 | 
						||
     #+BEGIN: clocktable :scope agenda :block lastweek :compact t
 | 
						||
     #+END: clocktable
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Language terms can be set through the variable
 | 
						||
`org-clock-clocktable-language-setup'.
 | 
						||
 | 
						||
   (2) Note that all parameters must be specified in a single line--the
 | 
						||
line is broken here only to fit it into the manual.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Resolving idle time,  Prev: The clock table,  Up: Clocking work time
 | 
						||
 | 
						||
8.4.3 Resolving idle time and continuous clocking
 | 
						||
-------------------------------------------------
 | 
						||
 | 
						||
Resolving idle time
 | 
						||
...................
 | 
						||
 | 
						||
If you clock in on a work item, and then walk away from your
 | 
						||
computer--perhaps to take a phone call--you often need to "resolve" the
 | 
						||
time you were away by either subtracting it from the current clock, or
 | 
						||
applying it to another one.
 | 
						||
 | 
						||
   By customizing the variable `org-clock-idle-time' to some integer,
 | 
						||
such as 10 or 15, Emacs can alert you when you get back to your
 | 
						||
computer after being idle for that many minutes(1), and ask what you
 | 
						||
want to do with the idle time.  There will be a question waiting for
 | 
						||
you when you get back, indicating how much idle time has passed
 | 
						||
(constantly updated with the current amount), as well as a set of
 | 
						||
choices to correct the discrepancy:
 | 
						||
 | 
						||
`k'
 | 
						||
     To keep some or all of the minutes and stay clocked in, press `k'.
 | 
						||
     Org will ask how many of the minutes to keep.  Press <RET> to keep
 | 
						||
     them all, effectively changing nothing, or enter a number to keep
 | 
						||
     that many minutes.
 | 
						||
 | 
						||
`K'
 | 
						||
     If you use the shift key and press `K', it will keep however many
 | 
						||
     minutes you request and then immediately clock out of that task.
 | 
						||
     If you keep all of the minutes, this is the same as just clocking
 | 
						||
     out of the current task.
 | 
						||
 | 
						||
`s'
 | 
						||
     To keep none of the minutes, use `s' to subtract all the away time
 | 
						||
     from the clock, and then check back in from the moment you
 | 
						||
     returned.
 | 
						||
 | 
						||
`S'
 | 
						||
     To keep none of the minutes and just clock out at the start of the
 | 
						||
     away time, use the shift key and press `S'.  Remember that using
 | 
						||
     shift will always leave you clocked out, no matter which option
 | 
						||
     you choose.
 | 
						||
 | 
						||
`C'
 | 
						||
     To cancel the clock altogether, use `C'.  Note that if instead of
 | 
						||
     canceling you subtract the away time, and the resulting clock
 | 
						||
     amount is less than a minute, the clock will still be canceled
 | 
						||
     rather than clutter up the log with an empty entry.
 | 
						||
 | 
						||
   What if you subtracted those away minutes from the current clock,
 | 
						||
and now want to apply them to a new clock?  Simply clock in to any task
 | 
						||
immediately after the subtraction.  Org will notice that you have
 | 
						||
subtracted time "on the books", so to speak, and will ask if you want
 | 
						||
to apply those minutes to the next task you clock in on.
 | 
						||
 | 
						||
   There is one other instance when this clock resolution magic occurs.
 | 
						||
Say you were clocked in and hacking away, and suddenly your cat chased
 | 
						||
a mouse who scared a hamster that crashed into your UPS's power button!
 | 
						||
You suddenly lose all your buffers, but thanks to auto-save you still
 | 
						||
have your recent Org mode changes, including your last clock in.
 | 
						||
 | 
						||
   If you restart Emacs and clock into any task, Org will notice that
 | 
						||
you have a dangling clock which was never clocked out from your last
 | 
						||
session.  Using that clock's starting time as the beginning of the
 | 
						||
unaccounted-for period, Org will ask how you want to resolve that time.
 | 
						||
The logic and behavior is identical to dealing with away time due to
 | 
						||
idleness; it is just happening due to a recovery event rather than a
 | 
						||
set amount of idle time.
 | 
						||
 | 
						||
   You can also check all the files visited by your Org agenda for
 | 
						||
dangling clocks at any time using `M-x org-resolve-clocks RET' (or `C-c
 | 
						||
C-x C-z').
 | 
						||
 | 
						||
Continuous clocking
 | 
						||
...................
 | 
						||
 | 
						||
You may want to start clocking from the time when you clocked out the
 | 
						||
previous task.  To enable this systematically, set
 | 
						||
`org-clock-continuously' to `t'.  Each time you clock in, Org retrieves
 | 
						||
the clock-out time of the last clocked entry for this session, and
 | 
						||
start the new clock from there.
 | 
						||
 | 
						||
   If you only want this from time to time, use three universal prefix
 | 
						||
arguments with `org-clock-in' and two `C-u C-u' with
 | 
						||
`org-clock-in-last'.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) On computers using Mac OS X, idleness is based on actual user
 | 
						||
idleness, not just Emacs' idle time.  For X11, you can install a
 | 
						||
utility program `x11idle.c', available in the `contrib/scripts'
 | 
						||
directory of the Org git distribution, or install the `xprintidle'
 | 
						||
package and set it to the variable `org-clock-x11idle-program-name' if
 | 
						||
you are running Debian, to get the same general treatment of idleness.
 | 
						||
On other systems, idle time refers to Emacs idle time only.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Effort estimates,  Next: Timers,  Prev: Clocking work time,  Up: Dates and times
 | 
						||
 | 
						||
8.5 Effort estimates
 | 
						||
====================
 | 
						||
 | 
						||
If you want to plan your work in a very detailed way, or if you need to
 | 
						||
produce offers with quotations of the estimated work effort, you may
 | 
						||
want to assign effort estimates to entries.  If you are also clocking
 | 
						||
your work, you may later want to compare the planned effort with the
 | 
						||
actual working time, a great way to improve planning estimates.  Effort
 | 
						||
estimates are stored in a special property `EFFORT'.  You can set the
 | 
						||
effort for an entry with the following commands:
 | 
						||
 | 
						||
`C-c C-x e     (`org-set-effort')'
 | 
						||
     Set the effort estimate for the current entry.  With a numeric
 | 
						||
     prefix argument, set it to the Nth allowed value (see below).
 | 
						||
     This command is also accessible from the agenda with the `e' key.  
 | 
						||
 | 
						||
`C-c C-x C-e     (`org-clock-modify-effort-estimate')'
 | 
						||
     Modify the effort estimate of the item currently being clocked.
 | 
						||
 | 
						||
   Clearly the best way to work with effort estimates is through column
 | 
						||
view (*note Column view::).  You should start by setting up discrete
 | 
						||
values for effort estimates, and a `COLUMNS' format that displays these
 | 
						||
values together with clock sums (if you want to clock your time).  For
 | 
						||
a specific buffer you can use
 | 
						||
 | 
						||
     #+PROPERTY: Effort_ALL 0 0:10 0:30 1:00 2:00 3:00 4:00 5:00 6:00 7:00
 | 
						||
     #+COLUMNS: %40ITEM(Task) %17Effort(Estimated Effort){:} %CLOCKSUM
 | 
						||
 | 
						||
or, even better, you can set up these values globally by customizing the
 | 
						||
variables `org-global-properties' and `org-columns-default-format'.  In
 | 
						||
particular if you want to use this setup also in the agenda, a global
 | 
						||
setup may be advised.
 | 
						||
 | 
						||
   The way to assign estimates to individual items is then to switch to
 | 
						||
column mode, and to use `S-<right>' and `S-<left>' to change the value.
 | 
						||
The values you enter will immediately be summed up in the hierarchy.
 | 
						||
In the column next to it, any clocked time will be displayed.
 | 
						||
 | 
						||
   If you switch to column view in the daily/weekly agenda, the effort
 | 
						||
column will summarize the estimated work effort for each day(1), and
 | 
						||
you can use this to find space in your schedule.  To get an overview of
 | 
						||
the entire part of the day that is committed, you can set the option
 | 
						||
`org-agenda-columns-add-appointments-to-effort-sum'.  The appointments
 | 
						||
on a day that take place over a specified time interval will then also
 | 
						||
be added to the load estimate of the day.
 | 
						||
 | 
						||
   Effort estimates can be used in secondary agenda filtering that is
 | 
						||
triggered with the `/' key in the agenda (*note Agenda commands::).  If
 | 
						||
you have these estimates defined consistently, two or three key presses
 | 
						||
will narrow down the list to stuff that fits into an available time
 | 
						||
slot.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Please note the pitfalls of summing hierarchical data in a flat
 | 
						||
list (*note Agenda column view::).
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Timers,  Prev: Effort estimates,  Up: Dates and times
 | 
						||
 | 
						||
8.6 Taking notes with a timer
 | 
						||
=============================
 | 
						||
 | 
						||
Org provides two types of timers.  There is a relative timer that
 | 
						||
counts up, which can be useful when taking notes during, for example, a
 | 
						||
meeting or a video viewing.  There is also a countdown timer.
 | 
						||
 | 
						||
   The relative and countdown are started with separate commands.
 | 
						||
 | 
						||
`C-c C-x 0     (`org-timer-start')'
 | 
						||
     Start or reset the relative timer.  By default, the timer is set
 | 
						||
     to 0.  When called with a `C-u' prefix, prompt the user for a
 | 
						||
     starting offset.  If there is a timer string at point, this is
 | 
						||
     taken as the default, providing a convenient way to restart taking
 | 
						||
     notes after a break in the process.  When called with a double
 | 
						||
     prefix argument `C-u C-u', change all timer strings in the active
 | 
						||
     region by a certain amount.  This can be used to fix timer strings
 | 
						||
     if the timer was not started at exactly the right moment.  
 | 
						||
 | 
						||
`C-c C-x ;     (`org-timer-set-timer')'
 | 
						||
     Start a countdown timer.  The user is prompted for a duration.
 | 
						||
     `org-timer-default-timer' sets the default countdown value.
 | 
						||
     Giving a prefix numeric argument overrides this default value.
 | 
						||
     This command is available as `;' in agenda buffers.
 | 
						||
 | 
						||
   Once started, relative and countdown timers are controlled with the
 | 
						||
same commands.
 | 
						||
 | 
						||
`C-c C-x .     (`org-timer')'
 | 
						||
     Insert the value of the current relative or countdown timer into
 | 
						||
     the buffer.  If no timer is running, the relative timer will be
 | 
						||
     started.  When called with a prefix argument, the relative timer
 | 
						||
     is restarted.  
 | 
						||
 | 
						||
`C-c C-x -     (`org-timer-item')'
 | 
						||
     Insert a description list item with the value of the current
 | 
						||
     relative or countdown timer.  With a prefix argument, first reset
 | 
						||
     the relative timer to 0.  
 | 
						||
 | 
						||
`M-<RET>     (`org-insert-heading')'
 | 
						||
     Once the timer list is started, you can also use `M-<RET>' to
 | 
						||
     insert new timer items.  
 | 
						||
 | 
						||
`C-c C-x ,     (`org-timer-pause-or-continue')'
 | 
						||
     Pause the timer, or continue it if it is already paused.  
 | 
						||
 | 
						||
`C-c C-x _     (`org-timer-stop')'
 | 
						||
     Stop the timer.  After this, you can only start a new timer, not
 | 
						||
     continue the old one.  This command also removes the timer from
 | 
						||
     the mode line.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Capture - Refile - Archive,  Next: Agenda views,  Prev: Dates and times,  Up: Top
 | 
						||
 | 
						||
9 Capture - Refile - Archive
 | 
						||
****************************
 | 
						||
 | 
						||
An important part of any organization system is the ability to quickly
 | 
						||
capture new ideas and tasks, and to associate reference material with
 | 
						||
them.  Org does this using a process called capture.  It also can store
 | 
						||
files related to a task (attachments) in a special directory.  Once in
 | 
						||
the system, tasks and projects need to be moved around.  Moving
 | 
						||
completed project trees to an archive file keeps the system compact and
 | 
						||
fast.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Capture::                     Capturing new stuff
 | 
						||
* Attachments::                 Add files to tasks
 | 
						||
* RSS feeds::                   Getting input from RSS feeds
 | 
						||
* Protocols::                   External (e.g., Browser) access to Emacs and Org
 | 
						||
* Refile and copy::             Moving/copying a tree from one place to another
 | 
						||
* Archiving::                   What to do with finished projects
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Capture,  Next: Attachments,  Up: Capture - Refile - Archive
 | 
						||
 | 
						||
9.1 Capture
 | 
						||
===========
 | 
						||
 | 
						||
Capture lets you quickly store notes with little interruption of your
 | 
						||
work flow.  Org's method for capturing new items is heavily inspired by
 | 
						||
John Wiegley excellent `remember.el' package.  Up to version 6.36, Org
 | 
						||
used a special setup for `remember.el', then replaced it with
 | 
						||
`org-remember.el'.  As of version 8.0, `org-remember.el' has been
 | 
						||
completely replaced by `org-capture.el'.
 | 
						||
 | 
						||
   If your configuration depends on `org-remember.el', you need to
 | 
						||
update it and use the setup described below.  To convert your
 | 
						||
`org-remember-templates', run the command
 | 
						||
     M-x org-capture-import-remember-templates RET
 | 
						||
   and then customize the new variable with `M-x customize-variable
 | 
						||
org-capture-templates', check the result, and save the customization.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Setting up capture::          Where notes will be stored
 | 
						||
* Using capture::               Commands to invoke and terminate capture
 | 
						||
* Capture templates::           Define the outline of different note types
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Setting up capture,  Next: Using capture,  Up: Capture
 | 
						||
 | 
						||
9.1.1 Setting up capture
 | 
						||
------------------------
 | 
						||
 | 
						||
The following customization sets a default target file for notes, and
 | 
						||
defines a global key(1)  for capturing new material.
 | 
						||
 | 
						||
     (setq org-default-notes-file (concat org-directory "/notes.org"))
 | 
						||
     (define-key global-map "\C-cc" 'org-capture)
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Please select your own key, `C-c c' is only a suggestion.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Using capture,  Next: Capture templates,  Prev: Setting up capture,  Up: Capture
 | 
						||
 | 
						||
9.1.2 Using capture
 | 
						||
-------------------
 | 
						||
 | 
						||
`C-c c     (`org-capture')'
 | 
						||
     Call the command `org-capture'.  Note that this keybinding is
 | 
						||
     global and not active by default: you need to install it.  If you
 | 
						||
     have templates defined *note Capture templates::, it will offer
 | 
						||
     these templates for selection or use a new Org outline node as the
 | 
						||
     default template.  It will insert the template into the target
 | 
						||
     file and switch to an indirect buffer narrowed to this new node.
 | 
						||
     You may then insert the information you want.
 | 
						||
 | 
						||
`C-c C-c     (`org-capture-finalize')'
 | 
						||
     Once you have finished entering information into the capture
 | 
						||
     buffer, `C-c C-c' will return you to the window configuration
 | 
						||
     before the capture process, so that you can resume your work
 | 
						||
     without further distraction.  When called with a prefix arg,
 | 
						||
     finalize and then jump to the captured item.
 | 
						||
 | 
						||
`C-c C-w     (`org-capture-refile')'
 | 
						||
     Finalize the capture process by refiling (*note Refile and copy::)
 | 
						||
     the note to a different place.  Please realize that this is a
 | 
						||
     normal refiling command that will be executed--so the cursor
 | 
						||
     position at the moment you run this command is important.  If you
 | 
						||
     have inserted a tree with a parent and children, first move the
 | 
						||
     cursor back to the parent.  Any prefix argument given to this
 | 
						||
     command will be passed on to the `org-refile' command.
 | 
						||
 | 
						||
`C-c C-k     (`org-capture-kill')'
 | 
						||
     Abort the capture process and return to the previous state.
 | 
						||
 | 
						||
 | 
						||
   You can also call `org-capture' in a special way from the agenda,
 | 
						||
using the `k c' key combination.  With this access, any timestamps
 | 
						||
inserted by the selected capture template will default to the cursor
 | 
						||
date in the agenda, rather than to the current date.
 | 
						||
 | 
						||
   To find the locations of the last stored capture, use `org-capture'
 | 
						||
with prefix commands:
 | 
						||
 | 
						||
`C-u C-c c'
 | 
						||
     Visit the target location of a capture template.  You get to
 | 
						||
     select the template in the usual way.  
 | 
						||
 | 
						||
`C-u C-u C-c c'
 | 
						||
     Visit the last stored capture item in its buffer.
 | 
						||
 | 
						||
   You can also jump to the bookmark `org-capture-last-stored', which
 | 
						||
will automatically be created unless you set `org-capture-bookmark' to
 | 
						||
`nil'.
 | 
						||
 | 
						||
   To insert the capture at point in an Org buffer, call `org-capture'
 | 
						||
with a `C-0' prefix argument.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Capture templates,  Prev: Using capture,  Up: Capture
 | 
						||
 | 
						||
9.1.3 Capture templates
 | 
						||
-----------------------
 | 
						||
 | 
						||
You can use templates for different types of capture items, and for
 | 
						||
different target locations.  The easiest way to create such templates is
 | 
						||
through the customize interface.
 | 
						||
 | 
						||
`C-c c C'
 | 
						||
     Customize the variable `org-capture-templates'.
 | 
						||
 | 
						||
   Before we give the formal description of template definitions, let's
 | 
						||
look at an example.  Say you would like to use one template to create
 | 
						||
general TODO entries, and you want to put these entries under the
 | 
						||
heading `Tasks' in your file `~/org/gtd.org'.  Also, a date tree in the
 | 
						||
file `journal.org' should capture journal entries.  A possible
 | 
						||
configuration would look like:
 | 
						||
 | 
						||
     (setq org-capture-templates
 | 
						||
      '(("t" "Todo" entry (file+headline "~/org/gtd.org" "Tasks")
 | 
						||
             "* TODO %?\n  %i\n  %a")
 | 
						||
        ("j" "Journal" entry (file+datetree "~/org/journal.org")
 | 
						||
             "* %?\nEntered on %U\n  %i\n  %a")))
 | 
						||
 | 
						||
If you then press `C-c c t', Org will prepare the template for you like
 | 
						||
this:
 | 
						||
     * TODO
 | 
						||
       [[file:LINK TO WHERE YOU INITIATED CAPTURE]]
 | 
						||
 | 
						||
During expansion of the template, `%a' has been replaced by a link to
 | 
						||
the location from where you called the capture command.  This can be
 | 
						||
extremely useful for deriving tasks from emails, for example.  You fill
 | 
						||
in the task definition, press `C-c C-c' and Org returns you to the same
 | 
						||
place where you started the capture process.
 | 
						||
 | 
						||
   To define special keys to capture to a particular template without
 | 
						||
going through the interactive template selection, you can create your
 | 
						||
key binding like this:
 | 
						||
 | 
						||
     (define-key global-map "\C-cx"
 | 
						||
        (lambda () (interactive) (org-capture nil "x")))
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Template elements::           What is needed for a complete template entry
 | 
						||
* Template expansion::          Filling in information about time and context
 | 
						||
* Templates in contexts::       Only show a template in a specific context
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Template elements,  Next: Template expansion,  Up: Capture templates
 | 
						||
 | 
						||
9.1.3.1 Template elements
 | 
						||
.........................
 | 
						||
 | 
						||
Now lets look at the elements of a template definition.  Each entry in
 | 
						||
`org-capture-templates' is a list with the following items:
 | 
						||
 | 
						||
KEYS
 | 
						||
     The keys that will select the template, as a string, characters
 | 
						||
     only, for example `"a"' for a template to be selected with a
 | 
						||
     single key, or `"bt"' for selection with two keys.  When using
 | 
						||
     several keys, keys using the same prefix key must be sequential in
 | 
						||
     the list and preceded by a 2-element entry explaining the prefix
 | 
						||
     key, for example
 | 
						||
                   ("b" "Templates for marking stuff to buy")
 | 
						||
     If you do not define a template for the `C' key, this key will be
 | 
						||
     used to open the customize buffer for this complex variable.
 | 
						||
 | 
						||
DESCRIPTION
 | 
						||
     A short string describing the template, which will be shown during
 | 
						||
     selection.
 | 
						||
 | 
						||
TYPE
 | 
						||
     The type of entry, a symbol.  Valid values are:
 | 
						||
 | 
						||
    `entry'
 | 
						||
          An Org mode node, with a headline.  Will be filed as the
 | 
						||
          child of the target entry or as a top-level entry.  The
 | 
						||
          target file should be an Org mode file.
 | 
						||
 | 
						||
    `item'
 | 
						||
          A plain list item, placed in the first plain  list at the
 | 
						||
          target location.  Again the target file should be an Org file.
 | 
						||
 | 
						||
    `checkitem'
 | 
						||
          A checkbox item.  This only differs from the plain list item
 | 
						||
          by the default template.
 | 
						||
 | 
						||
    `table-line'
 | 
						||
          a new line in the first table at the target location.  Where
 | 
						||
          exactly the line will be inserted depends on the properties
 | 
						||
          `:prepend' and `:table-line-pos' (see below).
 | 
						||
 | 
						||
    `plain'
 | 
						||
          Text to be inserted as it is.
 | 
						||
 | 
						||
TARGET
 | 
						||
     Specification of where the captured item should be placed.  In Org
 | 
						||
     mode files, targets usually define a node.  Entries will become
 | 
						||
     children of this node.  Other types will be added to the table or
 | 
						||
     list in the body of this node.  Most target specifications contain
 | 
						||
     a file name.  If that file name is the empty string, it defaults
 | 
						||
     to `org-default-notes-file'.  A file can also be given as a
 | 
						||
     variable, function, or Emacs Lisp form.  When an absolute path is
 | 
						||
     not specified for a target, it is taken as relative to
 | 
						||
     `org-directory'.
 | 
						||
 | 
						||
     Valid values are:
 | 
						||
 | 
						||
    `(file "path/to/file")'
 | 
						||
          Text will be placed at the beginning or end of that file.
 | 
						||
 | 
						||
    `(id "id of existing org entry")'
 | 
						||
          Filing as child of this entry, or in the body of the entry.
 | 
						||
 | 
						||
    `(file+headline "path/to/file" "node headline")'
 | 
						||
          Fast configuration if the target heading is unique in the
 | 
						||
          file.
 | 
						||
 | 
						||
    `(file+olp "path/to/file" "Level 1 heading" "Level 2" ...)'
 | 
						||
          For non-unique headings, the full path is safer.
 | 
						||
 | 
						||
    `(file+regexp  "path/to/file" "regexp to find location")'
 | 
						||
          Use a regular expression to position the cursor.
 | 
						||
 | 
						||
    `(file+datetree "path/to/file")'
 | 
						||
          Will create a heading in a date tree for today's date(1).
 | 
						||
 | 
						||
    `(file+datetree+prompt "path/to/file")'
 | 
						||
          Will create a heading in a date tree, but will prompt for the
 | 
						||
          date.
 | 
						||
 | 
						||
    `(file+function "path/to/file" function-finding-location)'
 | 
						||
          A function to find the right location in the file.
 | 
						||
 | 
						||
    `(clock)'
 | 
						||
          File to the entry that is currently being clocked.
 | 
						||
 | 
						||
    `(function function-finding-location)'
 | 
						||
          Most general way: write your own function which both visits
 | 
						||
          the file and moves point to the right location.
 | 
						||
 | 
						||
TEMPLATE
 | 
						||
     The template for creating the capture item.  If you leave this
 | 
						||
     empty, an appropriate default template will be used.  Otherwise
 | 
						||
     this is a string with escape codes, which will be replaced
 | 
						||
     depending on time and context of the capture call.  The string
 | 
						||
     with escapes may be loaded from a template file, using the special
 | 
						||
     syntax `(file "path/to/template")'.  See below for more details.
 | 
						||
 | 
						||
PROPERTIES
 | 
						||
     The rest of the entry is a property list of additional options.
 | 
						||
     Recognized properties are:
 | 
						||
 | 
						||
    `:prepend'
 | 
						||
          Normally new captured information will be appended at the
 | 
						||
          target location (last child, last table line, last list
 | 
						||
          item...).  Setting this property will change that.
 | 
						||
 | 
						||
    `:immediate-finish'
 | 
						||
          When set, do not offer to edit the information, just file it
 | 
						||
          away immediately.  This makes sense if the template only needs
 | 
						||
          information that can be added automatically.
 | 
						||
 | 
						||
    `:empty-lines'
 | 
						||
          Set this to the number of lines to insert before and after
 | 
						||
          the new item.  Default 0, only common other value is 1.
 | 
						||
 | 
						||
    `:clock-in'
 | 
						||
          Start the clock in this item.
 | 
						||
 | 
						||
    `:clock-keep'
 | 
						||
          Keep the clock running when filing the captured entry.
 | 
						||
 | 
						||
    `:clock-resume'
 | 
						||
          If starting the capture interrupted a clock, restart that
 | 
						||
          clock when finished with the capture.  Note that
 | 
						||
          `:clock-keep' has precedence over `:clock-resume'.  When
 | 
						||
          setting both to `t', the current clock will run and the
 | 
						||
          previous one will not be resumed.
 | 
						||
 | 
						||
    `:unnarrowed'
 | 
						||
          Do not narrow the target buffer, simply show the full buffer.
 | 
						||
          Default is to narrow it so that you only see the new material.
 | 
						||
 | 
						||
    `:table-line-pos'
 | 
						||
          Specification of the location in the table where the new line
 | 
						||
          should be inserted. It can be a string, a variable holding a
 | 
						||
          string or a function returning a string. The string should
 | 
						||
          look like `"II-3"' meaning that the new line should become
 | 
						||
          the third line before the second horizontal separator line.
 | 
						||
 | 
						||
    `:kill-buffer'
 | 
						||
          If the target file was not yet visited when capture was
 | 
						||
          invoked, kill the buffer again after capture is completed.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Datetree headlines for years accept tags, so if you use both `*
 | 
						||
2013 :noexport:' and `* 2013' in your file, the capture will refile the
 | 
						||
note to the first one matched.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Template expansion,  Next: Templates in contexts,  Prev: Template elements,  Up: Capture templates
 | 
						||
 | 
						||
9.1.3.2 Template expansion
 | 
						||
..........................
 | 
						||
 | 
						||
In the template itself, special `%'-escapes(1) allow dynamic insertion
 | 
						||
of content.  The templates are expanded in the order given here:
 | 
						||
 | 
						||
     %[FILE]     Insert the contents of the file given by FILE.
 | 
						||
     %(SEXP)     Evaluate Elisp SEXP and replace with the result.
 | 
						||
                       For convenience, %:keyword (see below) placeholders
 | 
						||
                       within the expression will be expanded prior to this.
 | 
						||
                       The sexp must return a string.
 | 
						||
     %<...>      The result of format-time-string on the ... format specification.
 | 
						||
     %t          Timestamp, date only.
 | 
						||
     %T          Timestamp, with date and time.
 | 
						||
     %u, %U      Like the above, but inactive timestamps.
 | 
						||
     %i          Initial content, the region when capture is called while the
 | 
						||
                 region is active.
 | 
						||
                 The entire text will be indented like `%i' itself.
 | 
						||
     %a          Annotation, normally the link created with `org-store-link'.
 | 
						||
     %A          Like `%a', but prompt for the description part.
 | 
						||
     %l          Like %a, but only insert the literal link.
 | 
						||
     %c          Current kill ring head.
 | 
						||
     %x          Content of the X clipboard.
 | 
						||
     %k          Title of the currently clocked task.
 | 
						||
     %K          Link to the currently clocked task.
 | 
						||
     %n          User name (taken from `user-full-name').
 | 
						||
     %f          File visited by current buffer when org-capture was called.
 | 
						||
     %F          Full path of the file or directory visited by current buffer.
 | 
						||
     %:keyword   Specific information for certain link types, see below.
 | 
						||
     %^g         Prompt for tags, with completion on tags in target file.
 | 
						||
     %^G         Prompt for tags, with completion all tags in all agenda files.
 | 
						||
     %^t         Like `%t', but prompt for date.  Similarly `%^T', `%^u', `%^U'.
 | 
						||
                 You may define a prompt like `%^{Birthday}t'.
 | 
						||
     %^C         Interactive selection of which kill or clip to use.
 | 
						||
     %^L         Like `%^C', but insert as link.
 | 
						||
     %^{PROP}p   Prompt the user for a value for property PROP.
 | 
						||
     %^{PROMPT}  prompt the user for a string and replace this sequence with it.
 | 
						||
                 You may specify a default value and a completion table with
 | 
						||
                 %^{prompt|default|completion2|completion3...}.
 | 
						||
                 The arrow keys access a prompt-specific history.
 | 
						||
     %\\n        Insert the text entered at the nth %^{PROMPT}, where `n' is
 | 
						||
                 a number, starting from 1.
 | 
						||
     %?          After completing the template, position cursor here.
 | 
						||
 | 
						||
For specific link types, the following keywords will be defined(2):
 | 
						||
 | 
						||
     Link type                        |  Available keywords
 | 
						||
     ---------------------------------+----------------------------------------------
 | 
						||
     bbdb                             |  %:name %:company
 | 
						||
     irc                              |  %:server %:port %:nick
 | 
						||
     vm, vm-imap, wl, mh, mew, rmail  |  %:type %:subject %:message-id
 | 
						||
                                      |  %:from %:fromname %:fromaddress
 | 
						||
                                      |  %:to   %:toname   %:toaddress
 | 
						||
                                      |  %:date (message date header field)
 | 
						||
                                      |  %:date-timestamp (date as active timestamp)
 | 
						||
                                      |  %:date-timestamp-inactive (date as inactive timestamp)
 | 
						||
                                      |  %:fromto (either "to NAME" or "from NAME")(3)
 | 
						||
     gnus                             |  %:group, for messages also all email fields
 | 
						||
     w3, w3m                          |  %:url
 | 
						||
     info                             |  %:file %:node
 | 
						||
     calendar                         |  %:date
 | 
						||
 | 
						||
To place the cursor after template expansion use:
 | 
						||
 | 
						||
     %?          After completing the template, position cursor here.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) If you need one of these sequences literally, escape the `%'
 | 
						||
with a backslash.
 | 
						||
 | 
						||
   (2) If you define your own link types (*note Adding hyperlink
 | 
						||
types::), any property you store with `org-store-link-props' can be
 | 
						||
accessed in capture templates in a similar way.
 | 
						||
 | 
						||
   (3) This will always be the other, not the user.  See the variable
 | 
						||
`org-from-is-user-regexp'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Templates in contexts,  Prev: Template expansion,  Up: Capture templates
 | 
						||
 | 
						||
9.1.3.3 Templates in contexts
 | 
						||
.............................
 | 
						||
 | 
						||
To control whether a capture template should be accessible from a
 | 
						||
specific context, you can customize `org-capture-templates-contexts'.
 | 
						||
Let's say for example that you have a capture template `"p"' for
 | 
						||
storing Gnus emails containing patches.  Then you would configure this
 | 
						||
option like this:
 | 
						||
 | 
						||
     (setq org-capture-templates-contexts
 | 
						||
           '(("p" (in-mode . "message-mode"))))
 | 
						||
 | 
						||
   You can also tell that the command key `"p"' should refer to another
 | 
						||
template.  In that case, add this command key like this:
 | 
						||
 | 
						||
     (setq org-capture-templates-contexts
 | 
						||
           '(("p" "q" (in-mode . "message-mode"))))
 | 
						||
 | 
						||
   See the docstring of the variable for more information.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Attachments,  Next: RSS feeds,  Prev: Capture,  Up: Capture - Refile - Archive
 | 
						||
 | 
						||
9.2 Attachments
 | 
						||
===============
 | 
						||
 | 
						||
It is often useful to associate reference material with an outline
 | 
						||
node/task.  Small chunks of plain text can simply be stored in the
 | 
						||
subtree of a project.  Hyperlinks (*note Hyperlinks::) can establish
 | 
						||
associations with files that live elsewhere on your computer or in the
 | 
						||
cloud, like emails or source code files belonging to a project.
 | 
						||
Another method is attachments, which are files located in a directory
 | 
						||
belonging to an outline node.  Org uses directories named by the unique
 | 
						||
ID of each entry.  These directories are located in the `data'
 | 
						||
directory which lives in the same directory where your Org file
 | 
						||
lives(1).  If you initialize this directory with `git init', Org will
 | 
						||
automatically commit changes when it sees them.  The attachment system
 | 
						||
has been contributed to Org by John Wiegley.
 | 
						||
 | 
						||
   In cases where it seems better to do so, you can also attach a
 | 
						||
directory of your choice to an entry.  You can also make children
 | 
						||
inherit the attachment directory from a parent, so that an entire
 | 
						||
subtree uses the same attached directory.
 | 
						||
 | 
						||
The following commands deal with attachments:
 | 
						||
 | 
						||
`C-c C-a     (`org-attach')'
 | 
						||
     The dispatcher for commands related to the attachment system.
 | 
						||
     After these keys, a list of commands is displayed and you must
 | 
						||
     press an additional key to select a command:
 | 
						||
 | 
						||
    `a     (`org-attach-attach')'
 | 
						||
          Select a file and move it into the task's attachment
 | 
						||
          directory.  The file will be copied, moved, or linked,
 | 
						||
          depending on `org-attach-method'.  Note that hard links are
 | 
						||
          not supported on all systems.
 | 
						||
 | 
						||
    `c/m/l'
 | 
						||
          Attach a file using the copy/move/link method.  Note that
 | 
						||
          hard links are not supported on all systems.
 | 
						||
 | 
						||
    `n     (`org-attach-new')'
 | 
						||
          Create a new attachment as an Emacs buffer.
 | 
						||
 | 
						||
    `z     (`org-attach-sync')'
 | 
						||
          Synchronize the current task with its attachment directory,
 | 
						||
          in case you added attachments yourself.
 | 
						||
 | 
						||
    `o     (`org-attach-open')'
 | 
						||
          Open current task's attachment.  If there is more than one,
 | 
						||
          prompt for a file name first.  Opening will follow the rules
 | 
						||
          set by `org-file-apps'.  For more details, see the
 | 
						||
          information on following hyperlinks (*note Handling links::).
 | 
						||
 | 
						||
    `O     (`org-attach-open-in-emacs')'
 | 
						||
          Also open the attachment, but force opening the file in Emacs.
 | 
						||
 | 
						||
    `f     (`org-attach-reveal')'
 | 
						||
          Open the current task's attachment directory.
 | 
						||
 | 
						||
    `F     (`org-attach-reveal-in-emacs')'
 | 
						||
          Also open the directory, but force using `dired' in Emacs.
 | 
						||
 | 
						||
    `d     (`org-attach-delete-one')'
 | 
						||
          Select and delete a single attachment.
 | 
						||
 | 
						||
    `D     (`org-attach-delete-all')'
 | 
						||
          Delete all of a task's attachments.  A safer way is to open
 | 
						||
          the directory in `dired' and delete from there.
 | 
						||
 | 
						||
    `s     (`org-attach-set-directory')'
 | 
						||
          Set a specific directory as the entry's attachment directory.
 | 
						||
          This works by putting the directory path into the
 | 
						||
          `ATTACH_DIR' property.
 | 
						||
 | 
						||
    `i     (`org-attach-set-inherit')'
 | 
						||
          Set the `ATTACH_DIR_INHERIT' property, so that children will
 | 
						||
          use the same directory for attachments as the parent does.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) If you move entries or Org files from one directory to another,
 | 
						||
you may want to configure `org-attach-directory' to contain an absolute
 | 
						||
path.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: RSS feeds,  Next: Protocols,  Prev: Attachments,  Up: Capture - Refile - Archive
 | 
						||
 | 
						||
9.3 RSS feeds
 | 
						||
=============
 | 
						||
 | 
						||
Org can add and change entries based on information found in RSS feeds
 | 
						||
and Atom feeds.  You could use this to make a task out of each new
 | 
						||
podcast in a podcast feed.  Or you could use a phone-based
 | 
						||
note-creating service on the web to import tasks into Org.  To access
 | 
						||
feeds, configure the variable `org-feed-alist'.  The docstring of this
 | 
						||
variable has detailed information.  Here is just an example:
 | 
						||
 | 
						||
     (setq org-feed-alist
 | 
						||
          '(("Slashdot"
 | 
						||
              "http://rss.slashdot.org/Slashdot/slashdot"
 | 
						||
              "~/txt/org/feeds.org" "Slashdot Entries")))
 | 
						||
 | 
						||
will configure that new items from the feed provided by
 | 
						||
`rss.slashdot.org' will result in new entries in the file
 | 
						||
`~/org/feeds.org' under the heading `Slashdot Entries', whenever the
 | 
						||
following command is used:
 | 
						||
 | 
						||
`C-c C-x g     (`org-feed-update-all')'
 | 
						||
 | 
						||
`C-c C-x g'
 | 
						||
     Collect items from the feeds configured in `org-feed-alist' and
 | 
						||
     act upon them.  
 | 
						||
 | 
						||
`C-c C-x G     (`org-feed-goto-inbox')'
 | 
						||
     Prompt for a feed name and go to the inbox configured for this
 | 
						||
     feed.
 | 
						||
 | 
						||
   Under the same headline, Org will create a drawer `FEEDSTATUS' in
 | 
						||
which it will store information about the status of items in the feed,
 | 
						||
to avoid adding the same item several times.
 | 
						||
 | 
						||
   For more information, including how to read atom feeds, see
 | 
						||
`org-feed.el' and the docstring of `org-feed-alist'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Protocols,  Next: Refile and copy,  Prev: RSS feeds,  Up: Capture - Refile - Archive
 | 
						||
 | 
						||
9.4 Protocols for external access
 | 
						||
=================================
 | 
						||
 | 
						||
You can set up Org for handling protocol calls from outside
 | 
						||
applications that are passed to Emacs through the `emacsserver'.  For
 | 
						||
example, you can configure bookmarks in your web browser to send a link
 | 
						||
to the current page to Org and create a note from it using capture
 | 
						||
(*note Capture::).  Or you could create a bookmark that will tell Emacs
 | 
						||
to open the local source file of a remote website you are looking at
 | 
						||
with the browser.  See
 | 
						||
`http://orgmode.org/worg/org-contrib/org-protocol.php' for detailed
 | 
						||
documentation and setup instructions.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Refile and copy,  Next: Archiving,  Prev: Protocols,  Up: Capture - Refile - Archive
 | 
						||
 | 
						||
9.5 Refile and copy
 | 
						||
===================
 | 
						||
 | 
						||
When reviewing the captured data, you may want to refile or to copy
 | 
						||
some of the entries into a different list, for example into a project.
 | 
						||
Cutting, finding the right location, and then pasting the note is
 | 
						||
cumbersome.  To simplify this process, you can use the following
 | 
						||
special command:
 | 
						||
 | 
						||
`C-c M-w     (`org-copy')'
 | 
						||
     Copying works like refiling, except that the original note is not
 | 
						||
     deleted.  
 | 
						||
 | 
						||
`C-c C-w     (`org-refile')'
 | 
						||
     Refile the entry or region at point.  This command offers possible
 | 
						||
     locations for refiling the entry and lets you select one with
 | 
						||
     completion.  The item (or all items in the region) is filed below
 | 
						||
     the target heading as a subitem.  Depending on
 | 
						||
     `org-reverse-note-order', it will be either the first or last
 | 
						||
     subitem.
 | 
						||
     By default, all level 1 headlines in the current buffer are
 | 
						||
     considered to be targets, but you can have more complex
 | 
						||
     definitions across a number of files.  See the variable
 | 
						||
     `org-refile-targets' for details.  If you would like to select a
 | 
						||
     location via a file-path-like completion along the outline path,
 | 
						||
     see the variables `org-refile-use-outline-path' and
 | 
						||
     `org-outline-path-complete-in-steps'.  If you would like to be
 | 
						||
     able to create new nodes as new parents for refiling on the fly,
 | 
						||
     check the variable `org-refile-allow-creating-parent-nodes'.  When
 | 
						||
     the variable `org-log-refile'(1) is set, a timestamp or a note
 | 
						||
     will be recorded when an entry has been refiled.  
 | 
						||
 | 
						||
`C-u C-c C-w'
 | 
						||
     Use the refile interface to jump to a heading.  
 | 
						||
 | 
						||
`C-u C-u C-c C-w     (`org-refile-goto-last-stored')'
 | 
						||
     Jump to the location where `org-refile' last moved a tree to.
 | 
						||
 | 
						||
`C-2 C-c C-w'
 | 
						||
     Refile as the child of the item currently being clocked.
 | 
						||
 | 
						||
`C-3 C-c C-w'
 | 
						||
     Refile and keep the entry in place.  Also see `org-refile-keep' to
 | 
						||
     make this the default behavior, and beware that this may result in
 | 
						||
     duplicated `ID' properties.  
 | 
						||
 | 
						||
`C-0 C-c C-w  or  C-u C-u C-u C-c C-w     (`org-refile-cache-clear')'
 | 
						||
     Clear the target cache.  Caching of refile targets can be turned
 | 
						||
     on by setting `org-refile-use-cache'.  To make the command see new
 | 
						||
     possible targets, you have to clear the cache with this command.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) with corresponding `#+STARTUP' keywords `logrefile',
 | 
						||
`lognoterefile', and `nologrefile'
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Archiving,  Prev: Refile and copy,  Up: Capture - Refile - Archive
 | 
						||
 | 
						||
9.6 Archiving
 | 
						||
=============
 | 
						||
 | 
						||
When a project represented by a (sub)tree is finished, you may want to
 | 
						||
move the tree out of the way and to stop it from contributing to the
 | 
						||
agenda.  Archiving is important to keep your working files compact and
 | 
						||
global searches like the construction of agenda views fast.
 | 
						||
 | 
						||
`C-c C-x C-a     (`org-archive-subtree-default')'
 | 
						||
     Archive the current entry using the command specified in the
 | 
						||
     variable `org-archive-default-command'.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Moving subtrees::             Moving a tree to an archive file
 | 
						||
* Internal archiving::          Switch off a tree but keep it in the file
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Moving subtrees,  Next: Internal archiving,  Up: Archiving
 | 
						||
 | 
						||
9.6.1 Moving a tree to the archive file
 | 
						||
---------------------------------------
 | 
						||
 | 
						||
The most common archiving action is to move a project tree to another
 | 
						||
file, the archive file.
 | 
						||
 | 
						||
`C-c C-x C-s  or short  C-c $     (`org-archive-subtree')'
 | 
						||
     Archive the subtree starting at the cursor position to the location
 | 
						||
     given by `org-archive-location'.  
 | 
						||
 | 
						||
`C-u C-c C-x C-s'
 | 
						||
     Check if any direct children of the current headline could be
 | 
						||
     moved to the archive.  To do this, each subtree is checked for
 | 
						||
     open TODO entries.  If none are found, the command offers to move
 | 
						||
     it to the archive location.  If the cursor is _not_ on a headline
 | 
						||
     when this command is invoked, the level 1 trees will be checked.  
 | 
						||
 | 
						||
`C-u C-u C-c C-x C-s'
 | 
						||
     As above, but check subtree for timestamps instead of TODO
 | 
						||
     entries.  The command will offer to archive the subtree if it
 | 
						||
     _does_ contain a timestamp, and that timestamp is in the past.
 | 
						||
 | 
						||
   The default archive location is a file in the same directory as the
 | 
						||
current file, with the name derived by appending `_archive' to the
 | 
						||
current file name.  You can also choose what heading to file archived
 | 
						||
items under, with the possibility to add them to a datetree in a file.
 | 
						||
For information and examples on how to specify the file and the heading,
 | 
						||
see the documentation string of the variable `org-archive-location'.
 | 
						||
 | 
						||
   There is also an in-buffer option for setting this variable, for
 | 
						||
example:
 | 
						||
 | 
						||
     #+ARCHIVE: %s_done::
 | 
						||
 | 
						||
If you would like to have a special ARCHIVE location for a single entry
 | 
						||
or a (sub)tree, give the entry an `:ARCHIVE:' property with the
 | 
						||
location as the value (*note Properties and columns::).
 | 
						||
 | 
						||
   When a subtree is moved, it receives a number of special properties
 | 
						||
that record context information like the file from where the entry
 | 
						||
came, its outline path the archiving time etc.  Configure the variable
 | 
						||
`org-archive-save-context-info' to adjust the amount of information
 | 
						||
added.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Internal archiving,  Prev: Moving subtrees,  Up: Archiving
 | 
						||
 | 
						||
9.6.2 Internal archiving
 | 
						||
------------------------
 | 
						||
 | 
						||
If you want to just switch off (for agenda views) certain subtrees
 | 
						||
without moving them to a different file, you can use the `ARCHIVE tag'.
 | 
						||
 | 
						||
   A headline that is marked with the ARCHIVE tag (*note Tags::) stays
 | 
						||
at its location in the outline tree, but behaves in the following way:
 | 
						||
   - It does not open when you attempt to do so with a visibility
 | 
						||
     cycling command (*note Visibility cycling::).  You can force
 | 
						||
     cycling archived subtrees with `C-<TAB>', or by setting the option
 | 
						||
     `org-cycle-open-archived-trees'.  Also normal outline commands like
 | 
						||
     `show-all' will open archived subtrees.
 | 
						||
 | 
						||
   - During sparse tree construction (*note Sparse trees::), matches in
 | 
						||
     archived subtrees are not exposed, unless you configure the option
 | 
						||
     `org-sparse-tree-open-archived-trees'.
 | 
						||
 | 
						||
   - During agenda view construction (*note Agenda views::), the
 | 
						||
     content of archived trees is ignored unless you configure the
 | 
						||
     option `org-agenda-skip-archived-trees', in which case these trees
 | 
						||
     will always be included.  In the agenda you can press `v a' to get
 | 
						||
     archives temporarily included.
 | 
						||
 | 
						||
   - Archived trees are not exported (*note Exporting::), only the
 | 
						||
     headline is.  Configure the details using the variable
 | 
						||
     `org-export-with-archived-trees'.
 | 
						||
 | 
						||
   - Archived trees are excluded from column view unless the variable
 | 
						||
     `org-columns-skip-archived-trees' is configured to `nil'.
 | 
						||
 | 
						||
   The following commands help manage the ARCHIVE tag:
 | 
						||
 | 
						||
`C-c C-x a     (`org-toggle-archive-tag')'
 | 
						||
     Toggle the ARCHIVE tag for the current headline.  When the tag is
 | 
						||
     set, the headline changes to a shadowed face, and the subtree
 | 
						||
     below it is hidden.  
 | 
						||
 | 
						||
`C-u C-c C-x a'
 | 
						||
     Check if any direct children of the current headline should be
 | 
						||
     archived.  To do this, each subtree is checked for open TODO
 | 
						||
     entries.  If none are found, the command offers to set the ARCHIVE
 | 
						||
     tag for the child.  If the cursor is _not_ on a headline when this
 | 
						||
     command is invoked, the level 1 trees will be checked.  
 | 
						||
 | 
						||
`C-TAB     (`org-force-cycle-archived')'
 | 
						||
     Cycle a tree even if it is tagged with ARCHIVE.  
 | 
						||
 | 
						||
`C-c C-x A     (`org-archive-to-archive-sibling')'
 | 
						||
     Move the current entry to the _Archive Sibling_.  This is a
 | 
						||
     sibling of the entry with the heading `Archive' and the tag
 | 
						||
     `ARCHIVE'.  The entry becomes a child of that sibling and in this
 | 
						||
     way retains a lot of its original context, including inherited
 | 
						||
     tags and approximate position in the outline.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Agenda views,  Next: Markup,  Prev: Capture - Refile - Archive,  Up: Top
 | 
						||
 | 
						||
10 Agenda views
 | 
						||
***************
 | 
						||
 | 
						||
Due to the way Org works, TODO items, time-stamped items, and tagged
 | 
						||
headlines can be scattered throughout a file or even a number of files.
 | 
						||
To get an overview of open action items, or of events that are
 | 
						||
important for a particular date, this information must be collected,
 | 
						||
sorted and displayed in an organized way.
 | 
						||
 | 
						||
   Org can select items based on various criteria and display them in a
 | 
						||
separate buffer.  Seven different view types are provided:
 | 
						||
 | 
						||
   * an _agenda_ that is like a calendar and shows information for
 | 
						||
     specific dates,
 | 
						||
 | 
						||
   * a _TODO list_ that covers all unfinished action items,
 | 
						||
 | 
						||
   * a _match view_, showings headlines based on the tags, properties,
 | 
						||
     and TODO state associated with them,
 | 
						||
 | 
						||
   * a _timeline view_ that shows all events in a single Org file, in
 | 
						||
     time-sorted view,
 | 
						||
 | 
						||
   * a _text search view_ that shows all entries from multiple files
 | 
						||
     that contain specified keywords,
 | 
						||
 | 
						||
   * a _stuck projects view_ showing projects that currently don't move
 | 
						||
     along, and
 | 
						||
 | 
						||
   * _custom views_ that are special searches and combinations of
 | 
						||
     different views.
 | 
						||
 | 
						||
The extracted information is displayed in a special _agenda buffer_.
 | 
						||
This buffer is read-only, but provides commands to visit the
 | 
						||
corresponding locations in the original Org files, and even to edit
 | 
						||
these files remotely.
 | 
						||
 | 
						||
   Two variables control how the agenda buffer is displayed and whether
 | 
						||
the window configuration is restored when the agenda exits:
 | 
						||
`org-agenda-window-setup' and `org-agenda-restore-windows-after-quit'.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Agenda files::                Files being searched for agenda information
 | 
						||
* Agenda dispatcher::           Keyboard access to agenda views
 | 
						||
* Built-in agenda views::       What is available out of the box?
 | 
						||
* Presentation and sorting::    How agenda items are prepared for display
 | 
						||
* Agenda commands::             Remote editing of Org trees
 | 
						||
* Custom agenda views::         Defining special searches and views
 | 
						||
* Exporting agenda views::      Writing a view to a file
 | 
						||
* Agenda column view::          Using column view for collected entries
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Agenda files,  Next: Agenda dispatcher,  Up: Agenda views
 | 
						||
 | 
						||
10.1 Agenda files
 | 
						||
=================
 | 
						||
 | 
						||
The information to be shown is normally collected from all _agenda
 | 
						||
files_, the files listed in the variable `org-agenda-files'(1).  If a
 | 
						||
directory is part of this list, all files with the extension `.org' in
 | 
						||
this directory will be part of the list.
 | 
						||
 | 
						||
   Thus, even if you only work with a single Org file, that file should
 | 
						||
be put into the list(2).  You can customize `org-agenda-files', but the
 | 
						||
easiest way to maintain it is through the following commands
 | 
						||
 | 
						||
`C-c [     (`org-agenda-file-to-front')'
 | 
						||
     Add current file to the list of agenda files.  The file is added to
 | 
						||
     the front of the list.  If it was already in the list, it is moved
 | 
						||
     to the front.  With a prefix argument, file is added/moved to the
 | 
						||
     end.  
 | 
						||
 | 
						||
`C-c ]     (`org-remove-file')'
 | 
						||
     Remove current file from the list of agenda files.  
 | 
						||
 | 
						||
`C-'     (`org-cycle-agenda-files')'
 | 
						||
`C-,'
 | 
						||
     Cycle through agenda file list, visiting one file after the other.  
 | 
						||
 | 
						||
`M-x org-iswitchb RET'
 | 
						||
     Command to use an `iswitchb'-like interface to switch to and
 | 
						||
     between Org buffers.
 | 
						||
 | 
						||
The Org menu contains the current list of files and can be used to
 | 
						||
visit any of them.
 | 
						||
 | 
						||
   If you would like to focus the agenda temporarily on a file not in
 | 
						||
this list, or on just one file in the list, or even on only a subtree
 | 
						||
in a file, then this can be done in different ways.  For a single
 | 
						||
agenda command, you may press `<' once or several times in the
 | 
						||
dispatcher (*note Agenda dispatcher::).  To restrict the agenda scope
 | 
						||
for an extended period, use the following commands:
 | 
						||
 | 
						||
`C-c C-x <     (`org-agenda-set-restriction-lock')'
 | 
						||
     Permanently restrict the agenda to the current subtree.  When with
 | 
						||
     a prefix argument, or with the cursor before the first headline in
 | 
						||
     a file, the agenda scope is set to the entire file.  This
 | 
						||
     restriction remains in effect until removed with `C-c C-x >', or
 | 
						||
     by typing either `<' or `>' in the agenda dispatcher.  If there is
 | 
						||
     a window displaying an agenda view, the new restriction takes
 | 
						||
     effect immediately.  
 | 
						||
 | 
						||
`C-c C-x >     (`org-agenda-remove-restriction-lock')'
 | 
						||
     Remove the permanent restriction created by `C-c C-x <'.
 | 
						||
 | 
						||
When working with `speedbar.el', you can use the following commands in
 | 
						||
the Speedbar frame:
 | 
						||
 | 
						||
`< in the speedbar frame     (`org-speedbar-set-agenda-restriction')'
 | 
						||
     Permanently restrict the agenda to the item--either an Org file or
 | 
						||
     a subtree in such a file--at the cursor in the Speedbar frame.  If
 | 
						||
     there is a window displaying an agenda view, the new restriction
 | 
						||
     takes effect immediately.  
 | 
						||
 | 
						||
`> in the speedbar frame     (`org-agenda-remove-restriction-lock')'
 | 
						||
     Lift the restriction.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) If the value of that variable is not a list, but a single file
 | 
						||
name, then the list of agenda files will be maintained in that external
 | 
						||
file.
 | 
						||
 | 
						||
   (2) When using the dispatcher, pressing `<' before selecting a
 | 
						||
command will actually limit the command to the current file, and ignore
 | 
						||
`org-agenda-files' until the next dispatcher command.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Agenda dispatcher,  Next: Built-in agenda views,  Prev: Agenda files,  Up: Agenda views
 | 
						||
 | 
						||
10.2 The agenda dispatcher
 | 
						||
==========================
 | 
						||
 | 
						||
The views are created through a dispatcher, which should be bound to a
 | 
						||
global key--for example `C-c a' (*note Activation::).  In the following
 | 
						||
we will assume that `C-c a' is indeed how the dispatcher is accessed
 | 
						||
and list keyboard access to commands accordingly.  After pressing `C-c
 | 
						||
a', an additional letter is required to execute a command.  The
 | 
						||
dispatcher offers the following default commands:
 | 
						||
 | 
						||
`a'
 | 
						||
     Create the calendar-like agenda (*note Weekly/daily agenda::).
 | 
						||
 | 
						||
`t / T'
 | 
						||
     Create a list of all TODO items (*note Global TODO list::).
 | 
						||
 | 
						||
`m / M'
 | 
						||
     Create a list of headlines matching a TAGS expression (*note
 | 
						||
     Matching tags and properties::).
 | 
						||
 | 
						||
`L'
 | 
						||
     Create the timeline view for the current buffer (*note Timeline::).
 | 
						||
 | 
						||
`s'
 | 
						||
     Create a list of entries selected by a boolean expression of
 | 
						||
     keywords and/or regular expressions that must or must not occur in
 | 
						||
     the entry.
 | 
						||
 | 
						||
`/'
 | 
						||
     Search for a regular expression in all agenda files and
 | 
						||
     additionally in the files listed in
 | 
						||
     `org-agenda-text-search-extra-files'.  This uses the Emacs command
 | 
						||
     `multi-occur'.  A prefix argument can be used to specify the
 | 
						||
     number of context lines for each match, default is 1.
 | 
						||
 | 
						||
`# / !'
 | 
						||
     Create a list of stuck projects (*note Stuck projects::).
 | 
						||
 | 
						||
`<'
 | 
						||
     Restrict an agenda command to the current buffer(1).  After
 | 
						||
     pressing `<', you still need to press the character selecting the
 | 
						||
     command.
 | 
						||
 | 
						||
`< <'
 | 
						||
     If there is an active region, restrict the following agenda
 | 
						||
     command to the region.  Otherwise, restrict it to the current
 | 
						||
     subtree(2).  After pressing `< <', you still need to press the
 | 
						||
     character selecting the command.
 | 
						||
 | 
						||
`*'
 | 
						||
     Toggle sticky agenda views.  By default, Org maintains only a
 | 
						||
     single agenda buffer and rebuilds it each time you change the
 | 
						||
     view, to make sure everything is always up to date.  If you often
 | 
						||
     switch between agenda views and the build time bothers you, you
 | 
						||
     can turn on sticky agenda buffers or make this the default by
 | 
						||
     customizing the variable `org-agenda-sticky'.  With sticky
 | 
						||
     agendas, the agenda dispatcher will not recreate agenda views from
 | 
						||
     scratch, it will only switch to the selected one, and you need to
 | 
						||
     update the agenda by hand with `r' or `g' when needed.  You can
 | 
						||
     toggle sticky agenda view any time with `org-toggle-sticky-agenda'.
 | 
						||
 | 
						||
   You can also define custom commands that will be accessible through
 | 
						||
the dispatcher, just like the default commands.  This includes the
 | 
						||
possibility to create extended agenda buffers that contain several
 | 
						||
blocks together, for example the weekly agenda, the global TODO list and
 | 
						||
a number of special tags matches.  *Note Custom agenda views::.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) For backward compatibility, you can also press `1' to restrict
 | 
						||
to the current buffer.
 | 
						||
 | 
						||
   (2) For backward compatibility, you can also press `0' to restrict
 | 
						||
to the current region/subtree.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Built-in agenda views,  Next: Presentation and sorting,  Prev: Agenda dispatcher,  Up: Agenda views
 | 
						||
 | 
						||
10.3 The built-in agenda views
 | 
						||
==============================
 | 
						||
 | 
						||
In this section we describe the built-in views.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Weekly/daily agenda::         The calendar page with current tasks
 | 
						||
* Global TODO list::            All unfinished action items
 | 
						||
* Matching tags and properties::  Structured information with fine-tuned search
 | 
						||
* Timeline::                    Time-sorted view for single file
 | 
						||
* Search view::                 Find entries by searching for text
 | 
						||
* Stuck projects::              Find projects you need to review
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Weekly/daily agenda,  Next: Global TODO list,  Up: Built-in agenda views
 | 
						||
 | 
						||
10.3.1 The weekly/daily agenda
 | 
						||
------------------------------
 | 
						||
 | 
						||
The purpose of the weekly/daily _agenda_ is to act like a page of a
 | 
						||
paper agenda, showing all the tasks for the current week or day.
 | 
						||
 | 
						||
`C-c a a     (`org-agenda-list')'
 | 
						||
     Compile an agenda for the current week from a list of Org files.
 | 
						||
     The agenda shows the entries for each day.  With a numeric
 | 
						||
     prefix(1)  (like `C-u 2 1 C-c a a') you may set the number of days
 | 
						||
     to be displayed.
 | 
						||
 | 
						||
   The default number of days displayed in the agenda is set by the
 | 
						||
variable `org-agenda-span' (or the obsolete `org-agenda-ndays').  This
 | 
						||
variable can be set to any number of days you want to see by default in
 | 
						||
the agenda, or to a span name, such as `day', `week', `month' or
 | 
						||
`year'.  For weekly agendas, the default is to start on the previous
 | 
						||
monday (see `org-agenda-start-on-weekday').  You can also set the start
 | 
						||
date using a date shift: `(setq org-agenda-start-day "+10d")' will
 | 
						||
start the agenda ten days from today in the future.
 | 
						||
 | 
						||
   Remote editing from the agenda buffer means, for example, that you
 | 
						||
can change the dates of deadlines and appointments from the agenda
 | 
						||
buffer.  The commands available in the Agenda buffer are listed in
 | 
						||
*note Agenda commands::.
 | 
						||
 | 
						||
Calendar/Diary integration
 | 
						||
..........................
 | 
						||
 | 
						||
Emacs contains the calendar and diary by Edward M. Reingold.  The
 | 
						||
calendar displays a three-month calendar with holidays from different
 | 
						||
countries and cultures.  The diary allows you to keep track of
 | 
						||
anniversaries, lunar phases, sunrise/set, recurrent appointments
 | 
						||
(weekly, monthly) and more.  In this way, it is quite complementary to
 | 
						||
Org.  It can be very useful to combine output from Org with the diary.
 | 
						||
 | 
						||
   In order to include entries from the Emacs diary into Org mode's
 | 
						||
agenda, you only need to customize the variable
 | 
						||
 | 
						||
     (setq org-agenda-include-diary t)
 | 
						||
 | 
						||
After that, everything will happen automatically.  All diary entries
 | 
						||
including holidays, anniversaries, etc., will be included in the agenda
 | 
						||
buffer created by Org mode.  <SPC>, <TAB>, and <RET> can be used from
 | 
						||
the agenda buffer to jump to the diary file in order to edit existing
 | 
						||
diary entries.  The `i' command to insert new entries for the current
 | 
						||
date works in the agenda buffer, as well as the commands `S', `M', and
 | 
						||
`C' to display Sunrise/Sunset times, show lunar phases and to convert
 | 
						||
to other calendars, respectively.  `c' can be used to switch back and
 | 
						||
forth between calendar and agenda.
 | 
						||
 | 
						||
   If you are using the diary only for sexp entries and holidays, it is
 | 
						||
faster to not use the above setting, but instead to copy or even move
 | 
						||
the entries into an Org file.  Org mode evaluates diary-style sexp
 | 
						||
entries, and does it faster because there is no overhead for first
 | 
						||
creating the diary display.  Note that the sexp entries must start at
 | 
						||
the left margin, no whitespace is allowed before them.  For example,
 | 
						||
the following segment of an Org file will be processed and entries will
 | 
						||
be made in the agenda:
 | 
						||
 | 
						||
     * Holidays
 | 
						||
       :PROPERTIES:
 | 
						||
       :CATEGORY: Holiday
 | 
						||
       :END:
 | 
						||
     %%(org-calendar-holiday)   ; special function for holiday names
 | 
						||
 | 
						||
     * Birthdays
 | 
						||
       :PROPERTIES:
 | 
						||
       :CATEGORY: Ann
 | 
						||
       :END:
 | 
						||
     %%(org-anniversary 1956  5 14)(2) Arthur Dent is %d years old
 | 
						||
     %%(org-anniversary 1869 10  2) Mahatma Gandhi would be %d years old
 | 
						||
 | 
						||
Anniversaries from BBDB
 | 
						||
.......................
 | 
						||
 | 
						||
If you are using the Big Brothers Database to store your contacts, you
 | 
						||
will very likely prefer to store anniversaries in BBDB rather than in a
 | 
						||
separate Org or diary file.  Org supports this and will show BBDB
 | 
						||
anniversaries as part of the agenda.  All you need to do is to add the
 | 
						||
following to one of your agenda files:
 | 
						||
 | 
						||
     * Anniversaries
 | 
						||
       :PROPERTIES:
 | 
						||
       :CATEGORY: Anniv
 | 
						||
       :END:
 | 
						||
     %%(org-bbdb-anniversaries)
 | 
						||
 | 
						||
   You can then go ahead and define anniversaries for a BBDB record.
 | 
						||
Basically, you need to press `C-o anniversary <RET>' with the cursor in
 | 
						||
a BBDB record and then add the date in the format `YYYY-MM-DD' or
 | 
						||
`MM-DD', followed by a space and the class of the anniversary
 | 
						||
(`birthday' or `wedding', or a format string).  If you omit the class,
 | 
						||
it will default to `birthday'.  Here are a few examples, the header for
 | 
						||
the file `org-bbdb.el' contains more detailed information.
 | 
						||
 | 
						||
     1973-06-22
 | 
						||
     06-22
 | 
						||
     1955-08-02 wedding
 | 
						||
     2008-04-14 %s released version 6.01 of org mode, %d years ago
 | 
						||
 | 
						||
   After a change to BBDB, or for the first agenda display during an
 | 
						||
Emacs session, the agenda display will suffer a short delay as Org
 | 
						||
updates its hash with anniversaries.  However, from then on things will
 | 
						||
be very fast--much faster in fact than a long list of
 | 
						||
`%%(diary-anniversary)' entries in an Org or Diary file.
 | 
						||
 | 
						||
Appointment reminders
 | 
						||
.....................
 | 
						||
 | 
						||
Org can interact with Emacs appointments notification facility.  To add
 | 
						||
the appointments of your agenda files, use the command
 | 
						||
`org-agenda-to-appt'.  This command lets you filter through the list of
 | 
						||
your appointments and add only those belonging to a specific category
 | 
						||
or matching a regular expression.  It also reads a `APPT_WARNTIME'
 | 
						||
property which will then override the value of
 | 
						||
`appt-message-warning-time' for this appointment.  See the docstring
 | 
						||
for details.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) For backward compatibility, the universal prefix `C-u' causes
 | 
						||
all TODO entries to be listed before the agenda.  This feature is
 | 
						||
deprecated, use the dedicated TODO list, or a block agenda instead
 | 
						||
(*note Block agenda::).
 | 
						||
 | 
						||
   (2) `org-anniversary' is just like `diary-anniversary', but the
 | 
						||
argument order is always according to ISO and therefore independent of
 | 
						||
the value of `calendar-date-style'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Global TODO list,  Next: Matching tags and properties,  Prev: Weekly/daily agenda,  Up: Built-in agenda views
 | 
						||
 | 
						||
10.3.2 The global TODO list
 | 
						||
---------------------------
 | 
						||
 | 
						||
The global TODO list contains all unfinished TODO items formatted and
 | 
						||
collected into a single place.
 | 
						||
 | 
						||
`C-c a t     (`org-todo-list')'
 | 
						||
     Show the global TODO list.  This collects the TODO items from all
 | 
						||
     agenda files (*note Agenda views::) into a single buffer.  By
 | 
						||
     default, this lists items with a state the is not a DONE state.
 | 
						||
     The buffer is in `agenda-mode', so there are commands to examine
 | 
						||
     and manipulate the TODO entries directly from that buffer (*note
 | 
						||
     Agenda commands::).  
 | 
						||
 | 
						||
`C-c a T     (`org-todo-list')'
 | 
						||
     Like the above, but allows selection of a specific TODO keyword.
 | 
						||
     You can also do this by specifying a prefix argument to `C-c a t'.
 | 
						||
     You are prompted for a keyword, and you may also specify several
 | 
						||
     keywords by separating them with `|' as the boolean OR operator.
 | 
						||
     With a numeric prefix, the Nth keyword in `org-todo-keywords' is
 | 
						||
     selected.  The `r' key in the agenda buffer regenerates it, and
 | 
						||
     you can give a prefix argument to this command to change the
 | 
						||
     selected TODO keyword, for example `3 r'.  If you often need a
 | 
						||
     search for a specific keyword, define a custom command for it
 | 
						||
     (*note Agenda dispatcher::).
 | 
						||
     Matching specific TODO keywords can also be done as part of a tags
 | 
						||
     search (*note Tag searches::).
 | 
						||
 | 
						||
   Remote editing of TODO items means that you can change the state of a
 | 
						||
TODO entry with a single key press.  The commands available in the TODO
 | 
						||
list are described in *note Agenda commands::.
 | 
						||
 | 
						||
   Normally the global TODO list simply shows all headlines with TODO
 | 
						||
keywords.  This list can become very long.  There are two ways to keep
 | 
						||
it more compact:
 | 
						||
   - Some people view a TODO item that has been _scheduled_ for
 | 
						||
     execution or have a _deadline_ (*note Timestamps::) as no longer
 | 
						||
     _open_.  Configure the variables
 | 
						||
     `org-agenda-todo-ignore-scheduled',
 | 
						||
     `org-agenda-todo-ignore-deadlines',
 | 
						||
     `org-agenda-todo-ignore-timestamp' and/or
 | 
						||
     `org-agenda-todo-ignore-with-date' to exclude such items from the
 | 
						||
     global TODO list.
 | 
						||
 | 
						||
   - TODO items may have sublevels to break up the task into subtasks.
 | 
						||
     In such cases it may be enough to list only the highest level TODO
 | 
						||
     headline and omit the sublevels from the global list.  Configure
 | 
						||
     the variable `org-agenda-todo-list-sublevels' to get this behavior.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Matching tags and properties,  Next: Timeline,  Prev: Global TODO list,  Up: Built-in agenda views
 | 
						||
 | 
						||
10.3.3 Matching tags and properties
 | 
						||
-----------------------------------
 | 
						||
 | 
						||
If headlines in the agenda files are marked with _tags_ (*note Tags::),
 | 
						||
or have properties (*note Properties and columns::), you can select
 | 
						||
headlines based on this metadata and collect them into an agenda
 | 
						||
buffer.  The match syntax described here also applies when creating
 | 
						||
sparse trees with `C-c / m'.
 | 
						||
 | 
						||
`C-c a m     (`org-tags-view')'
 | 
						||
     Produce a list of all headlines that match a given set of tags.
 | 
						||
     The command prompts for a selection criterion, which is a boolean
 | 
						||
     logic expression with tags, like `+work+urgent-withboss' or
 | 
						||
     `work|home' (*note Tags::).  If you often need a specific search,
 | 
						||
     define a custom command for it (*note Agenda dispatcher::).  
 | 
						||
 | 
						||
`C-c a M     (`org-tags-view')'
 | 
						||
     Like `C-c a m', but only select headlines that are also TODO items
 | 
						||
     in a not-DONE state and force checking subitems (see variable
 | 
						||
     `org-tags-match-list-sublevels').  To exclude scheduled/deadline
 | 
						||
     items, see the variable
 | 
						||
     `org-agenda-tags-todo-honor-ignore-options'.  Matching specific
 | 
						||
     TODO keywords together with a tags match is also possible, see
 | 
						||
     *note Tag searches::.
 | 
						||
 | 
						||
   The commands available in the tags list are described in *note
 | 
						||
Agenda commands::.
 | 
						||
 | 
						||
Match syntax
 | 
						||
............
 | 
						||
 | 
						||
A search string can use Boolean operators `&' for `AND' and `|' for
 | 
						||
`OR'.  `&' binds more strongly than `|'.  Parentheses are not
 | 
						||
implemented.  Each element in the search is either a tag, a regular
 | 
						||
expression matching tags, or an expression like `PROPERTY OPERATOR
 | 
						||
VALUE' with a comparison operator, accessing a property value.  Each
 | 
						||
element may be preceded by `-', to select against it, and `+' is
 | 
						||
syntactic sugar for positive selection.  The `AND' operator `&' is
 | 
						||
optional when `+' or `-' is present.  Here are some examples, using
 | 
						||
only tags.
 | 
						||
 | 
						||
`work'
 | 
						||
     Select headlines tagged `:work:'.
 | 
						||
 | 
						||
`work&boss'
 | 
						||
     Select headlines tagged `:work:' and `:boss:'.
 | 
						||
 | 
						||
`+work-boss'
 | 
						||
     Select headlines tagged `:work:', but discard those also tagged
 | 
						||
     `:boss:'.
 | 
						||
 | 
						||
`work|laptop'
 | 
						||
     Selects lines tagged `:work:' or `:laptop:'.
 | 
						||
 | 
						||
`work|laptop+night'
 | 
						||
     Like before, but require the `:laptop:' lines to be tagged also
 | 
						||
     `:night:'.
 | 
						||
 | 
						||
   Instead of a tag, you may also specify a regular expression enclosed
 | 
						||
in curly braces.  For example, `work+{^boss.*}' matches headlines that
 | 
						||
contain the tag `:work:' and any tag starting with `boss'.
 | 
						||
 | 
						||
   Group tags (*note Tag hierarchy::) are expanded as regular
 | 
						||
expressions.  E.g., if `:work:' is a group tag for the group
 | 
						||
`:work:lab:conf:', then searching for `work' will search for
 | 
						||
`{\(?:work\|lab\|conf\)}' and searching for `-work' will search for all
 | 
						||
headlines but those with one of the tags in the group (i.e.,
 | 
						||
`-{\(?:work\|lab\|conf\)}').
 | 
						||
 | 
						||
   You may also test for properties (*note Properties and columns::) at
 | 
						||
the same time as matching tags.  The properties may be real properties,
 | 
						||
or special properties that represent other metadata (*note Special
 | 
						||
properties::).  For example, the "property" `TODO' represents the TODO
 | 
						||
keyword of the entry and the "property" `PRIORITY' represents the
 | 
						||
PRIORITY keyword of the entry.
 | 
						||
 | 
						||
   In addition to the *note Special properties::, one other "property"
 | 
						||
can also be used. `LEVEL' represents the level of an entry.  So a search
 | 
						||
`+LEVEL=3+boss-TODO="DONE"' lists all level three headlines that have
 | 
						||
the tag `boss' and are _not_ marked with the TODO keyword DONE.  In
 | 
						||
buffers with `org-odd-levels-only' set, `LEVEL' does not count the
 | 
						||
number of stars, but `LEVEL=2' will correspond to 3 stars etc.
 | 
						||
 | 
						||
   Here are more examples:
 | 
						||
 | 
						||
`work+TODO="WAITING"'
 | 
						||
     Select `:work:'-tagged TODO lines with the specific TODO keyword
 | 
						||
     `WAITING'.
 | 
						||
 | 
						||
`work+TODO="WAITING"|home+TODO="WAITING"'
 | 
						||
     Waiting tasks both at work and at home.
 | 
						||
 | 
						||
   When matching properties, a number of different operators can be
 | 
						||
used to test the value of a property.  Here is a complex example:
 | 
						||
 | 
						||
     +work-boss+PRIORITY="A"+Coffee="unlimited"+Effort<2         \
 | 
						||
              +With={Sarah\|Denny}+SCHEDULED>="<2008-10-11>"
 | 
						||
 | 
						||
The type of comparison will depend on how the comparison value is
 | 
						||
written:
 | 
						||
   - If the comparison value is a plain number, a numerical comparison
 | 
						||
     is done, and the allowed operators are `<', `=', `>', `<=', `>=',
 | 
						||
     and `<>'.
 | 
						||
 | 
						||
   - If the comparison value is enclosed in double-quotes, a string
 | 
						||
     comparison is done, and the same operators are allowed.
 | 
						||
 | 
						||
   - If the comparison value is enclosed in double-quotes _and_ angular
 | 
						||
     brackets (like `DEADLINE<="<2008-12-24 18:30>"'), both values are
 | 
						||
     assumed to be date/time specifications in the standard Org way,
 | 
						||
     and the comparison will be done accordingly.  Special values that
 | 
						||
     will be recognized are `"<now>"' for now (including time), and
 | 
						||
     `"<today>"', and `"<tomorrow>"' for these days at 00:00 hours,
 | 
						||
     i.e., without a time specification.  Also strings like `"<+5d>"'
 | 
						||
     or `"<-2m>"' with units `d', `w', `m', and `y' for day, week,
 | 
						||
     month, and year, respectively, can be used.
 | 
						||
 | 
						||
   - If the comparison value is enclosed in curly braces, a regexp
 | 
						||
     match is performed, with `=' meaning that the regexp matches the
 | 
						||
     property value, and `<>' meaning that it does not match.
 | 
						||
 | 
						||
   So the search string in the example finds entries tagged `:work:' but
 | 
						||
not `:boss:', which also have a priority value `A', a `:Coffee:'
 | 
						||
property with the value `unlimited', an `Effort' property that is
 | 
						||
numerically smaller than 2, a `:With:' property that is matched by the
 | 
						||
regular expression `Sarah\|Denny', and that are scheduled on or after
 | 
						||
October 11, 2008.
 | 
						||
 | 
						||
   You can configure Org mode to use property inheritance during a
 | 
						||
search, but beware that this can slow down searches considerably.  See
 | 
						||
*note Property inheritance::, for details.
 | 
						||
 | 
						||
   For backward compatibility, and also for typing speed, there is also
 | 
						||
a different way to test TODO states in a search.  For this, terminate
 | 
						||
the tags/property part of the search string (which may include several
 | 
						||
terms connected with `|') with a `/' and then specify a Boolean
 | 
						||
expression just for TODO keywords.  The syntax is then similar to that
 | 
						||
for tags, but should be applied with care: for example, a positive
 | 
						||
selection on several TODO keywords cannot meaningfully be combined with
 | 
						||
boolean AND.  However, _negative selection_ combined with AND can be
 | 
						||
meaningful.  To make sure that only lines are checked that actually
 | 
						||
have any TODO keyword (resulting in a speed-up), use `C-c a M', or
 | 
						||
equivalently start the TODO part after the slash with `!'.  Using `C-c
 | 
						||
a M' or `/!' will not match TODO keywords in a DONE state.  Examples:
 | 
						||
 | 
						||
`work/WAITING'
 | 
						||
     Same as `work+TODO="WAITING"'
 | 
						||
 | 
						||
`work/!-WAITING-NEXT'
 | 
						||
     Select `:work:'-tagged TODO lines that are neither `WAITING' nor
 | 
						||
     `NEXT'
 | 
						||
 | 
						||
`work/!+WAITING|+NEXT'
 | 
						||
     Select `:work:'-tagged TODO lines that are either `WAITING' or
 | 
						||
     `NEXT'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Timeline,  Next: Search view,  Prev: Matching tags and properties,  Up: Built-in agenda views
 | 
						||
 | 
						||
10.3.4 Timeline for a single file
 | 
						||
---------------------------------
 | 
						||
 | 
						||
The timeline summarizes all time-stamped items from a single Org mode
 | 
						||
file in a _time-sorted view_.  The main purpose of this command is to
 | 
						||
give an overview over events in a project.
 | 
						||
 | 
						||
`C-c a L     (`org-timeline')'
 | 
						||
     Show a time-sorted view of the Org file, with all time-stamped
 | 
						||
     items.  When called with a `C-u' prefix, all unfinished TODO
 | 
						||
     entries (scheduled or not) are also listed under the current date.
 | 
						||
 | 
						||
The commands available in the timeline buffer are listed in *note
 | 
						||
Agenda commands::.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Search view,  Next: Stuck projects,  Prev: Timeline,  Up: Built-in agenda views
 | 
						||
 | 
						||
10.3.5 Search view
 | 
						||
------------------
 | 
						||
 | 
						||
This agenda view is a general text search facility for Org mode entries.
 | 
						||
It is particularly useful to find notes.
 | 
						||
 | 
						||
`C-c a s     (`org-search-view')'
 | 
						||
     This is a special search that lets you select entries by matching
 | 
						||
     a substring or specific words using a boolean logic.
 | 
						||
   For example, the search string `computer equipment' will find entries
 | 
						||
that contain `computer equipment' as a substring.  If the two words are
 | 
						||
separated by more space or a line break, the search will still match.
 | 
						||
Search view can also search for specific keywords in the entry, using
 | 
						||
Boolean logic.  The search string `+computer +wifi -ethernet
 | 
						||
-{8\.11[bg]}' will search for note entries that contain the keywords
 | 
						||
`computer' and `wifi', but not the keyword `ethernet', and which are
 | 
						||
also not matched by the regular expression `8\.11[bg]', meaning to
 | 
						||
exclude both 8.11b and 8.11g.  The first `+' is necessary to turn on
 | 
						||
word search, other `+' characters are optional.  For more details, see
 | 
						||
the docstring of the command `org-search-view'.
 | 
						||
 | 
						||
   Note that in addition to the agenda files, this command will also
 | 
						||
search the files listed in `org-agenda-text-search-extra-files'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Stuck projects,  Prev: Search view,  Up: Built-in agenda views
 | 
						||
 | 
						||
10.3.6 Stuck projects
 | 
						||
---------------------
 | 
						||
 | 
						||
If you are following a system like David Allen's GTD to organize your
 | 
						||
work, one of the "duties" you have is a regular review to make sure
 | 
						||
that all projects move along.  A _stuck_ project is a project that has
 | 
						||
no defined next actions, so it will never show up in the TODO lists Org
 | 
						||
mode produces.  During the review, you need to identify such projects
 | 
						||
and define next actions for them.
 | 
						||
 | 
						||
`C-c a #     (`org-agenda-list-stuck-projects')'
 | 
						||
     List projects that are stuck.  
 | 
						||
 | 
						||
`C-c a !'
 | 
						||
     Customize the variable `org-stuck-projects' to define what a stuck
 | 
						||
     project is and how to find it.
 | 
						||
 | 
						||
   You almost certainly will have to configure this view before it will
 | 
						||
work for you.  The built-in default assumes that all your projects are
 | 
						||
level-2 headlines, and that a project is not stuck if it has at least
 | 
						||
one entry marked with a TODO keyword TODO or NEXT or NEXTACTION.
 | 
						||
 | 
						||
   Let's assume that you, in your own way of using Org mode, identify
 | 
						||
projects with a tag PROJECT, and that you use a TODO keyword MAYBE to
 | 
						||
indicate a project that should not be considered yet.  Let's further
 | 
						||
assume that the TODO keyword DONE marks finished projects, and that NEXT
 | 
						||
and TODO indicate next actions.  The tag @SHOP indicates shopping and
 | 
						||
is a next action even without the NEXT tag.  Finally, if the project
 | 
						||
contains the special word IGNORE anywhere, it should not be listed
 | 
						||
either.  In this case you would start by identifying eligible projects
 | 
						||
with a tags/todo match(1) `+PROJECT/-MAYBE-DONE', and then check for
 | 
						||
TODO, NEXT, @SHOP, and IGNORE in the subtree to identify projects that
 | 
						||
are not stuck.  The correct customization for this is
 | 
						||
 | 
						||
     (setq org-stuck-projects
 | 
						||
           '("+PROJECT/-MAYBE-DONE" ("NEXT" "TODO") ("@SHOP")
 | 
						||
                                    "\\<IGNORE\\>"))
 | 
						||
 | 
						||
   Note that if a project is identified as non-stuck, the subtree of
 | 
						||
this entry will still be searched for stuck projects.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) *Note Tag searches::.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Presentation and sorting,  Next: Agenda commands,  Prev: Built-in agenda views,  Up: Agenda views
 | 
						||
 | 
						||
10.4 Presentation and sorting
 | 
						||
=============================
 | 
						||
 | 
						||
Before displaying items in an agenda view, Org mode visually prepares
 | 
						||
the items and sorts them.  Each item occupies a single line.  The line
 | 
						||
starts with a _prefix_ that contains the _category_ (*note Categories::)
 | 
						||
of the item and other important information.  You can customize in which
 | 
						||
column tags will be displayed through `org-agenda-tags-column'.  You can
 | 
						||
also customize the prefix using the option `org-agenda-prefix-format'.
 | 
						||
This prefix is followed by a cleaned-up version of the outline headline
 | 
						||
associated with the item.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Categories::                  Not all tasks are equal
 | 
						||
* Time-of-day specifications::  How the agenda knows the time
 | 
						||
* Sorting agenda items::        The order of things
 | 
						||
* Filtering/limiting agenda items::  Dynamically narrow the agenda
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Categories,  Next: Time-of-day specifications,  Up: Presentation and sorting
 | 
						||
 | 
						||
10.4.1 Categories
 | 
						||
-----------------
 | 
						||
 | 
						||
The category is a broad label assigned to each agenda item.  By
 | 
						||
default, the category is simply derived from the file name, but you can
 | 
						||
also specify it with a special line in the buffer, like this:
 | 
						||
 | 
						||
     #+CATEGORY: Thesis
 | 
						||
 | 
						||
If you would like to have a special CATEGORY for a single entry or a
 | 
						||
(sub)tree, give the entry a `:CATEGORY:' property with the special
 | 
						||
category you want to apply as the value.
 | 
						||
 | 
						||
The display in the agenda buffer looks best if the category is not
 | 
						||
longer than 10 characters.
 | 
						||
 | 
						||
You can set up icons for category by customizing the
 | 
						||
`org-agenda-category-icon-alist' variable.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Time-of-day specifications,  Next: Sorting agenda items,  Prev: Categories,  Up: Presentation and sorting
 | 
						||
 | 
						||
10.4.2 Time-of-day specifications
 | 
						||
---------------------------------
 | 
						||
 | 
						||
Org mode checks each agenda item for a time-of-day specification.  The
 | 
						||
time can be part of the timestamp that triggered inclusion into the
 | 
						||
agenda, for example as in `<2005-05-10 Tue 19:00>'.  Time ranges can be
 | 
						||
specified with two timestamps, like
 | 
						||
`<2005-05-10 Tue 20:30>--<2005-05-10 Tue 22:15>'.
 | 
						||
 | 
						||
   In the headline of the entry itself, a time(range) may also appear as
 | 
						||
plain text (like `12:45' or a `8:30-1pm').  If the agenda integrates
 | 
						||
the Emacs diary (*note Weekly/daily agenda::), time specifications in
 | 
						||
diary entries are recognized as well.
 | 
						||
 | 
						||
   For agenda display, Org mode extracts the time and displays it in a
 | 
						||
standard 24 hour format as part of the prefix.  The example times in
 | 
						||
the previous paragraphs would end up in the agenda like this:
 | 
						||
 | 
						||
         8:30-13:00 Arthur Dent lies in front of the bulldozer
 | 
						||
        12:45...... Ford Prefect arrives and takes Arthur to the pub
 | 
						||
        19:00...... The Vogon reads his poem
 | 
						||
        20:30-22:15 Marvin escorts the Hitchhikers to the bridge
 | 
						||
 | 
						||
   If the agenda is in single-day mode, or for the display of today, the
 | 
						||
timed entries are embedded in a time grid, like
 | 
						||
 | 
						||
         8:00...... ------------------
 | 
						||
         8:30-13:00 Arthur Dent lies in front of the bulldozer
 | 
						||
        10:00...... ------------------
 | 
						||
        12:00...... ------------------
 | 
						||
        12:45...... Ford Prefect arrives and takes Arthur to the pub
 | 
						||
        14:00...... ------------------
 | 
						||
        16:00...... ------------------
 | 
						||
        18:00...... ------------------
 | 
						||
        19:00...... The Vogon reads his poem
 | 
						||
        20:00...... ------------------
 | 
						||
        20:30-22:15 Marvin escorts the Hitchhikers to the bridge
 | 
						||
 | 
						||
   The time grid can be turned on and off with the variable
 | 
						||
`org-agenda-use-time-grid', and can be configured with
 | 
						||
`org-agenda-time-grid'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Sorting agenda items,  Next: Filtering/limiting agenda items,  Prev: Time-of-day specifications,  Up: Presentation and sorting
 | 
						||
 | 
						||
10.4.3 Sorting agenda items
 | 
						||
---------------------------
 | 
						||
 | 
						||
Before being inserted into a view, the items are sorted.  How this is
 | 
						||
done depends on the type of view.
 | 
						||
   * For the daily/weekly agenda, the items for each day are sorted.
 | 
						||
     The default order is to first collect all items containing an
 | 
						||
     explicit time-of-day specification.  These entries will be shown
 | 
						||
     at the beginning of the list, as a _schedule_ for the day.  After
 | 
						||
     that, items remain grouped in categories, in the sequence given by
 | 
						||
     `org-agenda-files'.  Within each category, items are sorted by
 | 
						||
     priority (*note Priorities::), which is composed of the base
 | 
						||
     priority (2000 for priority `A', 1000 for `B', and 0 for `C'),
 | 
						||
     plus additional increments for overdue scheduled or deadline items.
 | 
						||
 | 
						||
   * For the TODO list, items remain in the order of categories, but
 | 
						||
     within each category, sorting takes place according to priority
 | 
						||
     (*note Priorities::).  The priority used for sorting derives from
 | 
						||
     the priority cookie, with additions depending on how close an item
 | 
						||
     is to its due or scheduled date.
 | 
						||
 | 
						||
   * For tags matches, items are not sorted at all, but just appear in
 | 
						||
     the sequence in which they are found in the agenda files.
 | 
						||
 | 
						||
   Sorting can be customized using the variable
 | 
						||
`org-agenda-sorting-strategy', and may also include criteria based on
 | 
						||
the estimated effort of an entry (*note Effort estimates::).
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Filtering/limiting agenda items,  Prev: Sorting agenda items,  Up: Presentation and sorting
 | 
						||
 | 
						||
10.4.4 Filtering/limiting agenda items
 | 
						||
--------------------------------------
 | 
						||
 | 
						||
Agenda built-in or customized commands are statically defined.  Agenda
 | 
						||
filters and limits provide two ways of dynamically narrowing down the
 | 
						||
list of agenda entries: _filters_ and _limits_.  Filters only act on the
 | 
						||
display of the items, while limits take effect before the list of agenda
 | 
						||
entries is built.  Filters are more often used interactively, while
 | 
						||
limits are mostly useful when defined as local variables within custom
 | 
						||
agenda commands.
 | 
						||
 | 
						||
Filtering in the agenda
 | 
						||
.......................
 | 
						||
 | 
						||
`/     (`org-agenda-filter-by-tag')'
 | 
						||
     Filter the agenda view with respect to a tag and/or effort
 | 
						||
     estimates.  The difference between this and a custom agenda
 | 
						||
     command is that filtering is very fast, so that you can switch
 | 
						||
     quickly between different filters without having to recreate the
 | 
						||
     agenda.(1)
 | 
						||
 | 
						||
     You will be prompted for a tag selection letter; <SPC> will mean
 | 
						||
     any tag at all.  Pressing <TAB> at that prompt will offer use
 | 
						||
     completion to select a tag (including any tags that do not have a
 | 
						||
     selection character).  The command then hides all entries that do
 | 
						||
     not contain or inherit this tag.  When called with prefix arg,
 | 
						||
     remove the entries that _do_ have the tag.  A second `/' at the
 | 
						||
     prompt will turn off the filter and unhide any hidden entries.  If
 | 
						||
     the first key you press is either `+' or `-', the previous filter
 | 
						||
     will be narrowed by requiring or forbidding the selected
 | 
						||
     additional tag.  Instead of pressing `+' or `-' after `/', you can
 | 
						||
     also immediately use the `\' command.
 | 
						||
 | 
						||
     Org also supports automatic, context-aware tag filtering.  If the
 | 
						||
     variable `org-agenda-auto-exclude-function' is set to a
 | 
						||
     user-defined function, that function can decide which tags should
 | 
						||
     be excluded from the agenda automatically.  Once this is set, the
 | 
						||
     `/' command then accepts `RET' as a sub-option key and runs the
 | 
						||
     auto exclusion logic.  For example, let's say you use a `Net' tag
 | 
						||
     to identify tasks which need network access, an `Errand' tag for
 | 
						||
     errands in town, and a `Call' tag for making phone calls.  You
 | 
						||
     could auto-exclude these tags based on the availability of the
 | 
						||
     Internet, and outside of business hours, with something like this:
 | 
						||
 | 
						||
          (defun org-my-auto-exclude-function (tag)
 | 
						||
            (and (cond
 | 
						||
                  ((string= tag "Net")
 | 
						||
                   (/= 0 (call-process "/sbin/ping" nil nil nil
 | 
						||
                                       "-c1" "-q" "-t1" "mail.gnu.org")))
 | 
						||
                  ((or (string= tag "Errand") (string= tag "Call"))
 | 
						||
                   (let ((hour (nth 2 (decode-time))))
 | 
						||
                     (or (< hour 8) (> hour 21)))))
 | 
						||
                 (concat "-" tag)))
 | 
						||
 | 
						||
          (setq org-agenda-auto-exclude-function 'org-my-auto-exclude-function)
 | 
						||
 | 
						||
`\     (`org-agenda-filter-by-tag-refine')'
 | 
						||
     Narrow the current agenda filter by an additional condition.  When
 | 
						||
     called with prefix arg, remove the entries that _do_ have the tag,
 | 
						||
     or that do match the effort criterion.  You can achieve the same
 | 
						||
     effect by pressing `+' or `-' as the first key after the `/'
 | 
						||
     command.
 | 
						||
 | 
						||
`[ ] { }'
 | 
						||
 | 
						||
    in search view
 | 
						||
          add new search words (`[' and `]') or new regular expressions
 | 
						||
          (`{' and `}') to the query string.  The opening bracket/brace
 | 
						||
          will add a positive search term prefixed by `+', indicating
 | 
						||
          that this search term must occur/match in the entry.  The
 | 
						||
          closing bracket/brace will add a negative search term which
 | 
						||
          must not occur/match in the entry for it to be selected.
 | 
						||
 | 
						||
`<     (`org-agenda-filter-by-category')'
 | 
						||
     Filter the current agenda view with respect to the category of the
 | 
						||
     item at point.  Pressing `<' another time will remove this filter.
 | 
						||
     When called with a prefix argument exclude the category of the
 | 
						||
     item at point from the agenda.  You can add a filter preset
 | 
						||
     through the option `org-agenda-category-filter-preset' (see below.)
 | 
						||
 | 
						||
`^     (`org-agenda-filter-by-top-headline')'
 | 
						||
     Filter the current agenda view and only display the siblings and
 | 
						||
     the parent headline of the one at point.
 | 
						||
 | 
						||
`=     (`org-agenda-filter-by-regexp')'
 | 
						||
     Filter the agenda view by a regular expression: only show agenda
 | 
						||
     entries matching the regular expression the user entered.  When
 | 
						||
     called with a prefix argument, it will filter _out_ entries
 | 
						||
     matching the regexp.  With two universal prefix arguments, it will
 | 
						||
     remove all the regexp filters, which can be accumulated.  You can
 | 
						||
     add a filter preset through the option
 | 
						||
     `org-agenda-category-filter-preset' (see below.)
 | 
						||
 | 
						||
`_     (`org-agenda-filter-by-effort')'
 | 
						||
     Filter the agenda view with respect to effort estimates.  You
 | 
						||
     first need to set up allowed efforts globally, for example
 | 
						||
          (setq org-global-properties
 | 
						||
              '(("Effort_ALL". "0 0:10 0:30 1:00 2:00 3:00 4:00")))
 | 
						||
     You can then filter for an effort by first typing an operator, one
 | 
						||
     of `<', `>', and `=', and then the one-digit index of an effort
 | 
						||
     estimate in your array of allowed values, where `0' means the 10th
 | 
						||
     value.  The filter will then restrict to entries with effort
 | 
						||
     smaller-or-equal, equal, or larger-or-equal than the selected
 | 
						||
     value.  For application of the operator, entries without a defined
 | 
						||
     effort will be treated according to the value of
 | 
						||
     `org-sort-agenda-noeffort-is-high'.
 | 
						||
 | 
						||
`|     (`org-agenda-filter-remove-all')'
 | 
						||
     Remove all filters in the current agenda view.
 | 
						||
 | 
						||
Setting limits for the agenda
 | 
						||
.............................
 | 
						||
 | 
						||
Here is a list of options that you can set, either globally, or locally
 | 
						||
in your custom agenda views (*note Custom agenda views::).
 | 
						||
 | 
						||
`org-agenda-max-entries'
 | 
						||
     Limit the number of entries.
 | 
						||
 | 
						||
`org-agenda-max-effort'
 | 
						||
     Limit the duration of accumulated efforts (as minutes).
 | 
						||
 | 
						||
`org-agenda-max-todos'
 | 
						||
     Limit the number of entries with TODO keywords.
 | 
						||
 | 
						||
`org-agenda-max-tags'
 | 
						||
     Limit the number of tagged entries.
 | 
						||
 | 
						||
   When set to a positive integer, each option will exclude entries
 | 
						||
from other categories: for example, `(setq org-agenda-max-effort 100)'
 | 
						||
will limit the agenda to 100 minutes of effort and exclude any entry
 | 
						||
that has no effort property.  If you want to include entries with no
 | 
						||
effort property, use a negative value for `org-agenda-max-effort'.
 | 
						||
 | 
						||
   One useful setup is to use `org-agenda-max-entries' locally in a
 | 
						||
custom command.  For example, this custom command will display the next
 | 
						||
five entries with a `NEXT' TODO keyword.
 | 
						||
 | 
						||
     (setq org-agenda-custom-commands
 | 
						||
           '(("n" todo "NEXT"
 | 
						||
              ((org-agenda-max-entries 5)))))
 | 
						||
 | 
						||
   Once you mark one of these five entry as `DONE', rebuilding the
 | 
						||
agenda will again the next five entries again, including the first
 | 
						||
entry that was excluded so far.
 | 
						||
 | 
						||
   You can also dynamically set temporary limits, which will be lost
 | 
						||
when rebuilding the agenda:
 | 
						||
 | 
						||
`~     (`org-agenda-limit-interactively')'
 | 
						||
     This prompts for the type of limit to apply and its value.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Custom commands can preset a filter by binding the variable
 | 
						||
`org-agenda-tag-filter-preset' as an option.  This filter will then be
 | 
						||
applied to the view and persist as a basic filter through refreshes and
 | 
						||
more secondary filtering.  The filter is a global property of the
 | 
						||
entire agenda view--in a block agenda, you should only set this in the
 | 
						||
global options section, not in the section of an individual block.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Agenda commands,  Next: Custom agenda views,  Prev: Presentation and sorting,  Up: Agenda views
 | 
						||
 | 
						||
10.5 Commands in the agenda buffer
 | 
						||
==================================
 | 
						||
 | 
						||
Entries in the agenda buffer are linked back to the Org file or diary
 | 
						||
file where they originate.  You are not allowed to edit the agenda
 | 
						||
buffer itself, but commands are provided to show and jump to the
 | 
						||
original entry location, and to edit the Org files "remotely" from the
 | 
						||
agenda buffer.  In this way, all information is stored only once,
 | 
						||
removing the risk that your agenda and note files may diverge.
 | 
						||
 | 
						||
   Some commands can be executed with mouse clicks on agenda lines.  For
 | 
						||
the other commands, the cursor needs to be in the desired line.
 | 
						||
 | 
						||
Motion
 | 
						||
......
 | 
						||
 | 
						||
`n     (`org-agenda-next-line')'
 | 
						||
     Next line (same as <down> and `C-n').  
 | 
						||
 | 
						||
`p     (`org-agenda-previous-line')'
 | 
						||
     Previous line (same as <up> and `C-p').  
 | 
						||
 | 
						||
`N     (`org-agenda-next-item')'
 | 
						||
     Next item: same as next line, but only consider items.  
 | 
						||
 | 
						||
`P     (`org-agenda-previous-item')'
 | 
						||
     Previous item: same as previous line, but only consider items.
 | 
						||
 | 
						||
View/Go to Org file
 | 
						||
...................
 | 
						||
 | 
						||
`<SPC>  or  mouse-3     (`org-agenda-show-and-scroll-up')'
 | 
						||
     Display the original location of the item in another window.  With
 | 
						||
     prefix arg, make sure that the entire entry is made visible in the
 | 
						||
     outline, not only the heading.  
 | 
						||
 | 
						||
`L     (`org-agenda-recenter')'
 | 
						||
     Display original location and recenter that window.  
 | 
						||
 | 
						||
`<TAB>  or  mouse-2     (`org-agenda-goto')'
 | 
						||
     Go to the original location of the item in another window.  
 | 
						||
 | 
						||
`<RET>     (`org-agenda-switch-to')'
 | 
						||
     Go to the original location of the item and delete other windows.  
 | 
						||
 | 
						||
`F     (`org-agenda-follow-mode')'
 | 
						||
     Toggle Follow mode.  In Follow mode, as you move the cursor through
 | 
						||
     the agenda buffer, the other window always shows the corresponding
 | 
						||
     location in the Org file.  The initial setting for this mode in new
 | 
						||
     agenda buffers can be set with the variable
 | 
						||
     `org-agenda-start-with-follow-mode'.  
 | 
						||
 | 
						||
`C-c C-x b     (`org-agenda-tree-to-indirect-buffer')'
 | 
						||
     Display the entire subtree of the current item in an indirect
 | 
						||
     buffer.  With a numeric prefix argument N, go up to level N and
 | 
						||
     then take that tree.  If N is negative, go up that many levels.
 | 
						||
     With a `C-u' prefix, do not remove the previously used indirect
 | 
						||
     buffer.
 | 
						||
 | 
						||
`C-c C-o     (`org-agenda-open-link')'
 | 
						||
     Follow a link in the entry.  This will offer a selection of any
 | 
						||
     links in the text belonging to the referenced Org node.  If there
 | 
						||
     is only one link, it will be followed without a selection prompt.
 | 
						||
 | 
						||
Change display
 | 
						||
..............
 | 
						||
 | 
						||
`A'
 | 
						||
     Interactively select another agenda view and append it to the
 | 
						||
     current view.  
 | 
						||
 | 
						||
`o'
 | 
						||
     Delete other windows.  
 | 
						||
 | 
						||
`v d  or short  d     (`org-agenda-day-view')'
 | 
						||
`v w  or short  w     (`org-agenda-week-view')'
 | 
						||
`v t     (`org-agenda-fortnight-view')'
 | 
						||
`v m     (`org-agenda-month-view')'
 | 
						||
`v y     (`org-agenda-year-view')'
 | 
						||
`v SPC     (`org-agenda-reset-view')'
 | 
						||
     Switch to day/week/month/year view.  When switching to day or week
 | 
						||
     view, this setting becomes the default for subsequent agenda
 | 
						||
     refreshes.  Since month and year views are slow to create, they do
 | 
						||
     not become the default.  A numeric prefix argument may be used to
 | 
						||
     jump directly to a specific day of the year, ISO week, month, or
 | 
						||
     year, respectively.  For example, `32 d' jumps to February 1st, `9
 | 
						||
     w' to ISO week number 9.  When setting day, week, or month view, a
 | 
						||
     year may be encoded in the prefix argument as well.  For example,
 | 
						||
     `200712 w' will jump to week 12 in 2007.  If such a year
 | 
						||
     specification has only one or two digits, it will be mapped to the
 | 
						||
     interval 1938-2037.  `v <SPC>' will reset to what is set in
 | 
						||
     `org-agenda-span'.  
 | 
						||
 | 
						||
`f     (`org-agenda-later')'
 | 
						||
     Go forward in time to display the following
 | 
						||
     `org-agenda-current-span' days.  For example, if the display
 | 
						||
     covers a week, switch to the following week.  With prefix arg, go
 | 
						||
     forward that many times `org-agenda-current-span' days.  
 | 
						||
 | 
						||
`b     (`org-agenda-earlier')'
 | 
						||
     Go backward in time to display earlier dates.  
 | 
						||
 | 
						||
`.     (`org-agenda-goto-today')'
 | 
						||
     Go to today.  
 | 
						||
 | 
						||
`j     (`org-agenda-goto-date')'
 | 
						||
     Prompt for a date and go there.  
 | 
						||
 | 
						||
`J     (`org-agenda-clock-goto')'
 | 
						||
     Go to the currently clocked-in task in the agenda buffer.  
 | 
						||
 | 
						||
`D     (`org-agenda-toggle-diary')'
 | 
						||
     Toggle the inclusion of diary entries.  See *note Weekly/daily
 | 
						||
     agenda::.  
 | 
						||
 | 
						||
`v l  or short  l     (`org-agenda-log-mode')'
 | 
						||
     Toggle Logbook mode.  In Logbook mode, entries that were marked
 | 
						||
     DONE while logging was on (variable `org-log-done') are shown in
 | 
						||
     the agenda, as are entries that have been clocked on that day.
 | 
						||
     You can configure the entry types that should be included in log
 | 
						||
     mode using the variable `org-agenda-log-mode-items'.  When called
 | 
						||
     with a `C-u' prefix, show all possible logbook entries, including
 | 
						||
     state changes.  When called with two prefix arguments `C-u C-u',
 | 
						||
     show only logging information, nothing else.  `v L' is equivalent
 | 
						||
     to `C-u v l'.  
 | 
						||
 | 
						||
`v [  or short  [     (`org-agenda-manipulate-query-add')'
 | 
						||
     Include inactive timestamps into the current view.  Only for
 | 
						||
     weekly/daily agenda and timeline views.  
 | 
						||
 | 
						||
`v a     (`org-agenda-archives-mode')'
 | 
						||
`v A     (`org-agenda-archives-mode 'files')'
 | 
						||
     Toggle Archives mode.  In Archives mode, trees that are marked
 | 
						||
     `ARCHIVED' are also scanned when producing the agenda.  When you
 | 
						||
     use the capital `A', even all archive files are included.  To exit
 | 
						||
     archives mode, press `v a' again.  
 | 
						||
 | 
						||
`v R  or short  R     (`org-agenda-clockreport-mode')'
 | 
						||
     Toggle Clockreport mode.  In Clockreport mode, the daily/weekly
 | 
						||
     agenda will always show a table with the clocked times for the
 | 
						||
     time span and file scope covered by the current agenda view.  The
 | 
						||
     initial setting for this mode in new agenda buffers can be set
 | 
						||
     with the variable `org-agenda-start-with-clockreport-mode'.  By
 | 
						||
     using a prefix argument when toggling this mode (i.e., `C-u R'),
 | 
						||
     the clock table will not show contributions from entries that are
 | 
						||
     hidden by agenda filtering(1).  See also the variable
 | 
						||
     `org-clock-report-include-clocking-task'.  
 | 
						||
 | 
						||
`v c'
 | 
						||
     Show overlapping clock entries, clocking gaps, and other clocking
 | 
						||
     problems in the current agenda range.  You can then visit clocking
 | 
						||
     lines and fix them manually.  See the variable
 | 
						||
     `org-agenda-clock-consistency-checks' for information on how to
 | 
						||
     customize the definition of what constituted a clocking problem.
 | 
						||
     To return to normal agenda display, press `l' to exit Logbook mode.  
 | 
						||
 | 
						||
`v E  or short  E     (`org-agenda-entry-text-mode')'
 | 
						||
     Toggle entry text mode.  In entry text mode, a number of lines
 | 
						||
     from the Org outline node referenced by an agenda line will be
 | 
						||
     displayed below the line.  The maximum number of lines is given by
 | 
						||
     the variable `org-agenda-entry-text-maxlines'.  Calling this
 | 
						||
     command with a numeric prefix argument will temporarily modify
 | 
						||
     that number to the prefix value.  
 | 
						||
 | 
						||
`G     (`org-agenda-toggle-time-grid')'
 | 
						||
     Toggle the time grid on and off.  See also the variables
 | 
						||
     `org-agenda-use-time-grid' and `org-agenda-time-grid'.  
 | 
						||
 | 
						||
`r     (`org-agenda-redo')'
 | 
						||
     Recreate the agenda buffer, for example to reflect the changes
 | 
						||
     after modification of the timestamps of items with `S-<left>' and
 | 
						||
     `S-<right>'.  When the buffer is the global TODO list, a prefix
 | 
						||
     argument is interpreted to create a selective list for a specific
 | 
						||
     TODO keyword.  
 | 
						||
 | 
						||
`g     (`org-agenda-redo')'
 | 
						||
     Same as `r'.  
 | 
						||
 | 
						||
`C-x C-s  or short  s     (`org-save-all-org-buffers')'
 | 
						||
     Save all Org buffers in the current Emacs session, and also the
 | 
						||
     locations of IDs.  
 | 
						||
 | 
						||
`C-c C-x C-c     (`org-agenda-columns')'
 | 
						||
     Invoke column view (*note Column view::) in the agenda buffer.
 | 
						||
     The column view format is taken from the entry at point, or (if
 | 
						||
     there is no entry at point), from the first entry in the agenda
 | 
						||
     view.  So whatever the format for that entry would be in the
 | 
						||
     original buffer (taken from a property, from a `#+COLUMNS' line,
 | 
						||
     or from the default variable `org-columns-default-format'), will
 | 
						||
     be used in the agenda.
 | 
						||
 | 
						||
`C-c C-x >     (`org-agenda-remove-restriction-lock')'
 | 
						||
     Remove the restriction lock on the agenda, if it is currently
 | 
						||
     restricted to a file or subtree (*note Agenda files::).
 | 
						||
 | 
						||
Secondary filtering and query editing
 | 
						||
.....................................
 | 
						||
 | 
						||
     For a detailed description of these commands, see *note
 | 
						||
     Filtering/limiting agenda items::.
 | 
						||
 | 
						||
`/     (`org-agenda-filter-by-tag')'
 | 
						||
     Filter the agenda view with respect to a tag and/or effort
 | 
						||
     estimates.
 | 
						||
 | 
						||
`\     (`org-agenda-filter-by-tag-refine')'
 | 
						||
     Narrow the current agenda filter by an additional condition.
 | 
						||
 | 
						||
`<     (`org-agenda-filter-by-category')'
 | 
						||
     Filter the current agenda view with respect to the category of the
 | 
						||
     item at point.  Pressing `<' another time will remove this filter.
 | 
						||
 | 
						||
`^     (`org-agenda-filter-by-top-headline')'
 | 
						||
     Filter the current agenda view and only display the siblings and
 | 
						||
     the parent headline of the one at point.
 | 
						||
 | 
						||
`=     (`org-agenda-filter-by-regexp')'
 | 
						||
     Filter the agenda view by a regular expression: only show agenda
 | 
						||
     entries matching the regular expression the user entered.  When
 | 
						||
     called with a prefix argument, it will filter _out_ entries
 | 
						||
     matching the regexp.  With two universal prefix arguments, it will
 | 
						||
     remove all the regexp filters, which can be accumulated.  You can
 | 
						||
     add a filter preset through the option
 | 
						||
     `org-agenda-category-filter-preset' (see below.)
 | 
						||
 | 
						||
`|     (`org-agenda-filter-remove-all')'
 | 
						||
     Remove all filters in the current agenda view.
 | 
						||
 | 
						||
Remote editing
 | 
						||
..............
 | 
						||
 | 
						||
`0--9'
 | 
						||
     Digit argument.  
 | 
						||
 | 
						||
`C-_     (`org-agenda-undo')'
 | 
						||
     Undo a change due to a remote editing command.  The change is
 | 
						||
     undone both in the agenda buffer and in the remote buffer.  
 | 
						||
 | 
						||
`t     (`org-agenda-todo')'
 | 
						||
     Change the TODO state of the item, both in the agenda and in the
 | 
						||
     original org file.  
 | 
						||
 | 
						||
`C-S-<right>     (`org-agenda-todo-nextset')'
 | 
						||
 | 
						||
`C-S-<left>     (`org-agenda-todo-previousset')'
 | 
						||
     Switch to the next/previous set of TODO keywords.  
 | 
						||
 | 
						||
`C-k     (`org-agenda-kill')'
 | 
						||
     Delete the current agenda item along with the entire subtree
 | 
						||
     belonging to it in the original Org file.  If the text to be
 | 
						||
     deleted remotely is longer than one line, the kill needs to be
 | 
						||
     confirmed by the user.  See variable `org-agenda-confirm-kill'.  
 | 
						||
 | 
						||
`C-c C-w     (`org-agenda-refile')'
 | 
						||
     Refile the entry at point.  
 | 
						||
 | 
						||
`C-c C-x C-a  or short  a     (`org-agenda-archive-default-with-confirmation')'
 | 
						||
     Archive the subtree corresponding to the entry at point using the
 | 
						||
     default archiving command set in `org-archive-default-command'.
 | 
						||
     When using the `a' key, confirmation will be required.  
 | 
						||
 | 
						||
`C-c C-x a     (`org-agenda-toggle-archive-tag')'
 | 
						||
     Toggle the ARCHIVE tag for the current headline.  
 | 
						||
 | 
						||
`C-c C-x A     (`org-agenda-archive-to-archive-sibling')'
 | 
						||
     Move the subtree corresponding to the current entry to its _archive
 | 
						||
     sibling_.  
 | 
						||
 | 
						||
`C-c C-x C-s  or short  $     (`org-agenda-archive')'
 | 
						||
     Archive the subtree corresponding to the current headline.  This
 | 
						||
     means the entry will be moved to the configured archive location,
 | 
						||
     most likely a different file.  
 | 
						||
 | 
						||
`T     (`org-agenda-show-tags')'
 | 
						||
     Show all tags associated with the current item.  This is useful if
 | 
						||
     you have turned off `org-agenda-show-inherited-tags', but still
 | 
						||
     want to see all tags of a headline occasionally.  
 | 
						||
 | 
						||
`:     (`org-agenda-set-tags')'
 | 
						||
     Set tags for the current headline.  If there is an active region
 | 
						||
     in the agenda, change a tag for all headings in the region.  
 | 
						||
 | 
						||
`,'
 | 
						||
     Set the priority for the current item (`org-agenda-priority').
 | 
						||
     Org mode prompts for the priority character.  If you reply with
 | 
						||
     <SPC>, the priority cookie is removed from the entry.  
 | 
						||
 | 
						||
`P     (`org-agenda-show-priority')'
 | 
						||
     Display weighted priority of current item.  
 | 
						||
 | 
						||
`+  or  S-<up>     (`org-agenda-priority-up')'
 | 
						||
     Increase the priority of the current item.  The priority is
 | 
						||
     changed in the original buffer, but the agenda is not resorted.
 | 
						||
     Use the `r' key for this.  
 | 
						||
 | 
						||
`-  or  S-<down>     (`org-agenda-priority-down')'
 | 
						||
     Decrease the priority of the current item.  
 | 
						||
 | 
						||
`z  or  C-c C-z     (`org-agenda-add-note')'
 | 
						||
     Add a note to the entry.  This note will be recorded, and then
 | 
						||
     filed to the same location where state change notes are put.
 | 
						||
     Depending on `org-log-into-drawer', this may be inside a drawer.  
 | 
						||
 | 
						||
`C-c C-a     (`org-attach')'
 | 
						||
     Dispatcher for all command related to attachments.  
 | 
						||
 | 
						||
`C-c C-s     (`org-agenda-schedule')'
 | 
						||
     Schedule this item.  With prefix arg remove the scheduling
 | 
						||
     timestamp 
 | 
						||
 | 
						||
`C-c C-d     (`org-agenda-deadline')'
 | 
						||
     Set a deadline for this item.  With prefix arg remove the deadline.  
 | 
						||
 | 
						||
`S-<right>     (`org-agenda-do-date-later')'
 | 
						||
     Change the timestamp associated with the current line by one day
 | 
						||
     into the future.  If the date is in the past, the first call to
 | 
						||
     this command will move it to today.
 | 
						||
     With a numeric prefix argument, change it by that many days.  For
 | 
						||
     example, `3 6 5 S-<right>' will change it by a year.  With a `C-u'
 | 
						||
     prefix, change the time by one hour.  If you immediately repeat
 | 
						||
     the command, it will continue to change hours even without the
 | 
						||
     prefix arg.  With a double `C-u C-u' prefix, do the same for
 | 
						||
     changing minutes.
 | 
						||
     The stamp is changed in the original Org file, but the change is
 | 
						||
     not directly reflected in the agenda buffer.  Use `r' or `g' to
 | 
						||
     update the buffer.  
 | 
						||
 | 
						||
`S-<left>     (`org-agenda-do-date-earlier')'
 | 
						||
     Change the timestamp associated with the current line by one day
 | 
						||
     into the past.  
 | 
						||
 | 
						||
`>     (`org-agenda-date-prompt')'
 | 
						||
     Change the timestamp associated with the current line.  The key
 | 
						||
     `>' has been chosen, because it is the same as `S-.'  on my
 | 
						||
     keyboard.  
 | 
						||
 | 
						||
`I     (`org-agenda-clock-in')'
 | 
						||
     Start the clock on the current item.  If a clock is running
 | 
						||
     already, it is stopped first.  
 | 
						||
 | 
						||
`O     (`org-agenda-clock-out')'
 | 
						||
     Stop the previously started clock.  
 | 
						||
 | 
						||
`X     (`org-agenda-clock-cancel')'
 | 
						||
     Cancel the currently running clock.  
 | 
						||
 | 
						||
`J     (`org-agenda-clock-goto')'
 | 
						||
     Jump to the running clock in another window.  
 | 
						||
 | 
						||
`k     (`org-agenda-capture')'
 | 
						||
     Like `org-capture', but use the date at point as the default date
 | 
						||
     for the capture template.  See `org-capture-use-agenda-date' to
 | 
						||
     make this the default behavior of `org-capture'.  
 | 
						||
 | 
						||
Dragging agenda lines forward/backward
 | 
						||
......................................
 | 
						||
 | 
						||
`M-<up>     (`org-agenda-drag-line-backward')'
 | 
						||
     Drag the line at point backward one line(2).  With a numeric
 | 
						||
     prefix argument, drag backward by that many lines.
 | 
						||
 | 
						||
`M-<down>     (`org-agenda-drag-line-forward')'
 | 
						||
     Drag the line at point forward one line.  With a numeric prefix
 | 
						||
     argument, drag forward by that many lines.
 | 
						||
 | 
						||
Bulk remote editing selected entries
 | 
						||
....................................
 | 
						||
 | 
						||
`m     (`org-agenda-bulk-mark')'
 | 
						||
     Mark the entry at point for bulk action.  With numeric prefix
 | 
						||
     argument, mark that many successive entries.  
 | 
						||
 | 
						||
`*     (`org-agenda-bulk-mark-all')'
 | 
						||
     Mark all visible agenda entries for bulk action.  
 | 
						||
 | 
						||
`u     (`org-agenda-bulk-unmark')'
 | 
						||
     Unmark entry at point for bulk action.  
 | 
						||
 | 
						||
`U     (`org-agenda-bulk-remove-all-marks')'
 | 
						||
     Unmark all marked entries for bulk action.  
 | 
						||
 | 
						||
`M-m     (`org-agenda-bulk-toggle')'
 | 
						||
     Toggle mark of the entry at point for bulk action.  
 | 
						||
 | 
						||
`M-*     (`org-agenda-bulk-toggle-all')'
 | 
						||
     Toggle marks of all visible entries for bulk action.  
 | 
						||
 | 
						||
`%     (`org-agenda-bulk-mark-regexp')'
 | 
						||
     Mark entries matching a regular expression for bulk action.  
 | 
						||
 | 
						||
`B     (`org-agenda-bulk-action')'
 | 
						||
     Bulk action: act on all marked entries in the agenda.  This will
 | 
						||
     prompt for another key to select the action to be applied.  The
 | 
						||
     prefix arg to `B' will be passed through to the `s' and `d'
 | 
						||
     commands, to bulk-remove these special timestamps.  By default,
 | 
						||
     marks are removed after the bulk.  If you want them to persist,
 | 
						||
     set `org-agenda-persistent-marks' to `t' or hit `p' at the prompt.
 | 
						||
 | 
						||
    `*'
 | 
						||
          Toggle persistent marks.
 | 
						||
 | 
						||
    `$'
 | 
						||
          Archive all selected entries.
 | 
						||
 | 
						||
    `A'
 | 
						||
          Archive entries by moving them to their respective archive
 | 
						||
          siblings.
 | 
						||
 | 
						||
    `t'
 | 
						||
          Change TODO state.  This prompts for a single TODO keyword
 | 
						||
          and changes the state of all selected entries, bypassing
 | 
						||
          blocking and suppressing logging notes (but not timestamps).
 | 
						||
 | 
						||
    `+'
 | 
						||
          Add a tag to all selected entries.
 | 
						||
 | 
						||
    `-'
 | 
						||
          Remove a tag from all selected entries.
 | 
						||
 | 
						||
    `s'
 | 
						||
          Schedule all items to a new date.  To shift existing schedule
 | 
						||
          dates by a fixed number of days, use something starting with
 | 
						||
          double plus at the prompt, for example `++8d' or `++2w'.
 | 
						||
 | 
						||
    `d'
 | 
						||
          Set deadline to a specific date.
 | 
						||
 | 
						||
    `r'
 | 
						||
          Prompt for a single refile target and move all entries.  The
 | 
						||
          entries will no longer be in the agenda; refresh (`g') to
 | 
						||
          bring them back.
 | 
						||
 | 
						||
    `S'
 | 
						||
          Reschedule randomly into the coming N days.  N will be
 | 
						||
          prompted for.  With prefix arg (`C-u B S'), scatter only
 | 
						||
          across weekdays.
 | 
						||
 | 
						||
    `f'
 | 
						||
          Apply a function(3) to marked entries.  For example, the
 | 
						||
          function below sets the CATEGORY property of the entries to
 | 
						||
          web.
 | 
						||
 | 
						||
               (defun set-category ()
 | 
						||
                 (interactive "P")
 | 
						||
                 (let* ((marker (or (org-get-at-bol 'org-hd-marker)
 | 
						||
                                    (org-agenda-error)))
 | 
						||
                        (buffer (marker-buffer marker)))
 | 
						||
                   (with-current-buffer buffer
 | 
						||
                     (save-excursion
 | 
						||
                       (save-restriction
 | 
						||
                         (widen)
 | 
						||
                         (goto-char marker)
 | 
						||
                         (org-back-to-heading t)
 | 
						||
                         (org-set-property "CATEGORY" "web"))))))
 | 
						||
 | 
						||
Calendar commands
 | 
						||
.................
 | 
						||
 | 
						||
`c     (`org-agenda-goto-calendar')'
 | 
						||
     Open the Emacs calendar and move to the date at the agenda cursor.  
 | 
						||
 | 
						||
`c     (`org-calendar-goto-agenda')'
 | 
						||
     When in the calendar, compute and show the Org mode agenda for the
 | 
						||
     date at the cursor.  
 | 
						||
 | 
						||
`i     (`org-agenda-diary-entry')'
 | 
						||
     Insert a new entry into the diary, using the date at the cursor
 | 
						||
     and (for block entries) the date at the mark.  This will add to
 | 
						||
     the Emacs diary file(4), in a way similar to the `i' command in
 | 
						||
     the calendar.  The diary file will pop up in another window, where
 | 
						||
     you can add the entry.
 | 
						||
 | 
						||
     If you configure `org-agenda-diary-file' to point to an Org mode
 | 
						||
     file, Org will create entries (in Org mode syntax) in that file
 | 
						||
     instead.  Most entries will be stored in a date-based outline tree
 | 
						||
     that will later make it easy to archive appointments from previous
 | 
						||
     months/years.  The tree will be built under an entry with a
 | 
						||
     `DATE_TREE' property, or else with years as top-level entries.
 | 
						||
     Emacs will prompt you for the entry text--if you specify it, the
 | 
						||
     entry will be created in `org-agenda-diary-file' without further
 | 
						||
     interaction.  If you directly press <RET> at the prompt without
 | 
						||
     typing text, the target file will be shown in another window for
 | 
						||
     you to finish the entry there.  See also the `k r' command.  
 | 
						||
 | 
						||
`M     (`org-agenda-phases-of-moon')'
 | 
						||
     Show the phases of the moon for the three months around current
 | 
						||
     date.  
 | 
						||
 | 
						||
`S     (`org-agenda-sunrise-sunset')'
 | 
						||
     Show sunrise and sunset times.  The geographical location must be
 | 
						||
     set with calendar variables, see the documentation for the Emacs
 | 
						||
     calendar.  
 | 
						||
 | 
						||
`C     (`org-agenda-convert-date')'
 | 
						||
     Convert the date at cursor into many other cultural and historic
 | 
						||
     calendars.  
 | 
						||
 | 
						||
`H     (`org-agenda-holidays')'
 | 
						||
     Show holidays for three months around the cursor date.
 | 
						||
 | 
						||
`M-x org-icalendar-combine-agenda-files RET'
 | 
						||
     Export a single iCalendar file containing entries from all agenda
 | 
						||
     files.  This is a globally available command, and also available
 | 
						||
     in the agenda menu.
 | 
						||
 | 
						||
Exporting to a file
 | 
						||
...................
 | 
						||
 | 
						||
`C-x C-w     (`org-agenda-write')'
 | 
						||
     Write the agenda view to a file.  Depending on the extension of
 | 
						||
     the selected file name, the view will be exported as HTML (`.html'
 | 
						||
     or `.htm'), Postscript (`.ps'), PDF (`.pdf'), Org (`.org') and
 | 
						||
     plain text (any other extension).  When exporting to Org, only the
 | 
						||
     body of original headlines are exported, not subtrees or inherited
 | 
						||
     tags.  When called with a `C-u' prefix argument, immediately open
 | 
						||
     the newly created file.  Use the variable
 | 
						||
     `org-agenda-exporter-settings' to set options for `ps-print' and
 | 
						||
     for `htmlize' to be used during export.
 | 
						||
 | 
						||
Quit and Exit
 | 
						||
.............
 | 
						||
 | 
						||
`q     (`org-agenda-quit')'
 | 
						||
     Quit agenda, remove the agenda buffer.  
 | 
						||
 | 
						||
`x     (`org-agenda-exit')'
 | 
						||
     Exit agenda, remove the agenda buffer and all buffers loaded by
 | 
						||
     Emacs for the compilation of the agenda.  Buffers created by the
 | 
						||
     user to visit Org files will not be removed.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Only tags filtering will be respected here, effort filtering is
 | 
						||
ignored.
 | 
						||
 | 
						||
   (2) Moving agenda lines does not persist after an agenda refresh and
 | 
						||
does not modify the contributing `.org' files
 | 
						||
 | 
						||
   (3) You can also create persistent custom functions through
 | 
						||
`org-agenda-bulk-custom-functions'.
 | 
						||
 | 
						||
   (4) This file is parsed for the agenda when
 | 
						||
`org-agenda-include-diary' is set.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Custom agenda views,  Next: Exporting agenda views,  Prev: Agenda commands,  Up: Agenda views
 | 
						||
 | 
						||
10.6 Custom agenda views
 | 
						||
========================
 | 
						||
 | 
						||
Custom agenda commands serve two purposes: to store and quickly access
 | 
						||
frequently used TODO and tags searches, and to create special composite
 | 
						||
agenda buffers.  Custom agenda commands will be accessible through the
 | 
						||
dispatcher (*note Agenda dispatcher::), just like the default commands.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Storing searches::            Type once, use often
 | 
						||
* Block agenda::                All the stuff you need in a single buffer
 | 
						||
* Setting options::             Changing the rules
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Storing searches,  Next: Block agenda,  Up: Custom agenda views
 | 
						||
 | 
						||
10.6.1 Storing searches
 | 
						||
-----------------------
 | 
						||
 | 
						||
The first application of custom searches is the definition of keyboard
 | 
						||
shortcuts for frequently used searches, either creating an agenda
 | 
						||
buffer, or a sparse tree (the latter covering of course only the current
 | 
						||
buffer).  
 | 
						||
 | 
						||
   Custom commands are configured in the variable
 | 
						||
`org-agenda-custom-commands'.  You can customize this variable, for
 | 
						||
example by pressing `C-c a C'.  You can also directly set it with Emacs
 | 
						||
Lisp in `.emacs'.  The following example contains all valid agenda
 | 
						||
views:
 | 
						||
 | 
						||
     (setq org-agenda-custom-commands
 | 
						||
           '(("x" agenda)
 | 
						||
             ("y" agenda*)
 | 
						||
             ("w" todo "WAITING")
 | 
						||
             ("W" todo-tree "WAITING")
 | 
						||
             ("u" tags "+boss-urgent")
 | 
						||
             ("v" tags-todo "+boss-urgent")
 | 
						||
             ("U" tags-tree "+boss-urgent")
 | 
						||
             ("f" occur-tree "\\<FIXME\\>")
 | 
						||
             ("h" . "HOME+Name tags searches") ; description for "h" prefix
 | 
						||
             ("hl" tags "+home+Lisa")
 | 
						||
             ("hp" tags "+home+Peter")
 | 
						||
             ("hk" tags "+home+Kim")))
 | 
						||
 | 
						||
The initial string in each entry defines the keys you have to press
 | 
						||
after the dispatcher command `C-c a' in order to access the command.
 | 
						||
Usually this will be just a single character, but if you have many
 | 
						||
similar commands, you can also define two-letter combinations where the
 | 
						||
first character is the same in several combinations and serves as a
 | 
						||
prefix key(1).  The second parameter is the search type, followed by
 | 
						||
the string or regular expression to be used for the matching.  The
 | 
						||
example above will therefore define:
 | 
						||
 | 
						||
`C-c a x'
 | 
						||
     as a global search for agenda entries planned(2) this week/day.
 | 
						||
 | 
						||
`C-c a y'
 | 
						||
     as a global search for agenda entries planned this week/day, but
 | 
						||
     only those with an hour specification like `[h]h:mm'--think of
 | 
						||
     them as appointments.
 | 
						||
 | 
						||
`C-c a w'
 | 
						||
     as a global search for TODO entries with `WAITING' as the TODO
 | 
						||
     keyword
 | 
						||
 | 
						||
`C-c a W'
 | 
						||
     as the same search, but only in the current buffer and displaying
 | 
						||
     the results as a sparse tree
 | 
						||
 | 
						||
`C-c a u'
 | 
						||
     as a global tags search for headlines marked `:boss:' but not
 | 
						||
     `:urgent:'
 | 
						||
 | 
						||
`C-c a v'
 | 
						||
     as the same search as `C-c a u', but limiting the search to
 | 
						||
     headlines that are also TODO items
 | 
						||
 | 
						||
`C-c a U'
 | 
						||
     as the same search as `C-c a u', but only in the current buffer and
 | 
						||
     displaying the result as a sparse tree
 | 
						||
 | 
						||
`C-c a f'
 | 
						||
     to create a sparse tree (again: current buffer only) with all
 | 
						||
     entries containing the word `FIXME'
 | 
						||
 | 
						||
`C-c a h'
 | 
						||
     as a prefix command for a HOME tags search where you have to press
 | 
						||
     an additional key (`l', `p' or `k') to select a name (Lisa, Peter,
 | 
						||
     or Kim) as additional tag to match.
 | 
						||
 | 
						||
   Note that the `*-tree' agenda views need to be called from an Org
 | 
						||
buffer as they operate on the current buffer only.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) You can provide a description for a prefix key by inserting a
 | 
						||
cons cell with the prefix and the description.
 | 
						||
 | 
						||
   (2) _Planned_ means here that these entries have some planning
 | 
						||
information attached to them, like a time-stamp, a scheduled or a
 | 
						||
deadline string.  See `org-agenda-entry-types' on how to set what
 | 
						||
planning information will be taken into account.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Block agenda,  Next: Setting options,  Prev: Storing searches,  Up: Custom agenda views
 | 
						||
 | 
						||
10.6.2 Block agenda
 | 
						||
-------------------
 | 
						||
 | 
						||
Another possibility is the construction of agenda views that comprise
 | 
						||
the results of _several_ commands, each of which creates a block in the
 | 
						||
agenda buffer.  The available commands include `agenda' for the daily
 | 
						||
or weekly agenda (as created with `C-c a a'), `alltodo' for the global
 | 
						||
TODO list (as constructed with `C-c a t'), and the matching commands
 | 
						||
discussed above: `todo', `tags', and `tags-todo'.  Here are two
 | 
						||
examples:
 | 
						||
 | 
						||
     (setq org-agenda-custom-commands
 | 
						||
           '(("h" "Agenda and Home-related tasks"
 | 
						||
              ((agenda "")
 | 
						||
               (tags-todo "home")
 | 
						||
               (tags "garden")))
 | 
						||
             ("o" "Agenda and Office-related tasks"
 | 
						||
              ((agenda "")
 | 
						||
               (tags-todo "work")
 | 
						||
               (tags "office")))))
 | 
						||
 | 
						||
This will define `C-c a h' to create a multi-block view for stuff you
 | 
						||
need to attend to at home.  The resulting agenda buffer will contain
 | 
						||
your agenda for the current week, all TODO items that carry the tag
 | 
						||
`home', and also all lines tagged with `garden'.  Finally the command
 | 
						||
`C-c a o' provides a similar view for office tasks.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Setting options,  Prev: Block agenda,  Up: Custom agenda views
 | 
						||
 | 
						||
10.6.3 Setting options for custom commands
 | 
						||
------------------------------------------
 | 
						||
 | 
						||
Org mode contains a number of variables regulating agenda construction
 | 
						||
and display.  The global variables define the behavior for all agenda
 | 
						||
commands, including the custom commands.  However, if you want to change
 | 
						||
some settings just for a single custom view, you can do so.  Setting
 | 
						||
options requires inserting a list of variable names and values at the
 | 
						||
right spot in `org-agenda-custom-commands'.  For example:
 | 
						||
 | 
						||
     (setq org-agenda-custom-commands
 | 
						||
           '(("w" todo "WAITING"
 | 
						||
              ((org-agenda-sorting-strategy '(priority-down))
 | 
						||
               (org-agenda-prefix-format "  Mixed: ")))
 | 
						||
             ("U" tags-tree "+boss-urgent"
 | 
						||
              ((org-show-context-detail 'minimal)))
 | 
						||
             ("N" search ""
 | 
						||
              ((org-agenda-files '("~org/notes.org"))
 | 
						||
               (org-agenda-text-search-extra-files nil)))))
 | 
						||
 | 
						||
Now the `C-c a w' command will sort the collected entries only by
 | 
						||
priority, and the prefix format is modified to just say `  Mixed: '
 | 
						||
instead of giving the category of the entry.  The sparse tags tree of
 | 
						||
`C-c a U' will now turn out ultra-compact, because neither the headline
 | 
						||
hierarchy above the match, nor the headline following the match will be
 | 
						||
shown.  The command `C-c a N' will do a text search limited to only a
 | 
						||
single file.
 | 
						||
 | 
						||
   For command sets creating a block agenda,
 | 
						||
`org-agenda-custom-commands' has two separate spots for setting
 | 
						||
options.  You can add options that should be valid for just a single
 | 
						||
command in the set, and options that should be valid for all commands in
 | 
						||
the set.  The former are just added to the command entry; the latter
 | 
						||
must come after the list of command entries.  Going back to the block
 | 
						||
agenda example (*note Block agenda::), let's change the sorting strategy
 | 
						||
for the `C-c a h' commands to `priority-down', but let's sort the
 | 
						||
results for GARDEN tags query in the opposite order, `priority-up'.
 | 
						||
This would look like this:
 | 
						||
 | 
						||
     (setq org-agenda-custom-commands
 | 
						||
           '(("h" "Agenda and Home-related tasks"
 | 
						||
              ((agenda)
 | 
						||
               (tags-todo "home")
 | 
						||
               (tags "garden"
 | 
						||
                     ((org-agenda-sorting-strategy '(priority-up)))))
 | 
						||
              ((org-agenda-sorting-strategy '(priority-down))))
 | 
						||
             ("o" "Agenda and Office-related tasks"
 | 
						||
              ((agenda)
 | 
						||
               (tags-todo "work")
 | 
						||
               (tags "office")))))
 | 
						||
 | 
						||
   As you see, the values and parentheses setting is a little complex.
 | 
						||
When in doubt, use the customize interface to set this variable--it
 | 
						||
fully supports its structure.  Just one caveat: when setting options in
 | 
						||
this interface, the _values_ are just Lisp expressions.  So if the
 | 
						||
value is a string, you need to add the double-quotes around the value
 | 
						||
yourself.
 | 
						||
 | 
						||
   To control whether an agenda command should be accessible from a
 | 
						||
specific context, you can customize
 | 
						||
`org-agenda-custom-commands-contexts'.  Let's say for example that you
 | 
						||
have an agenda command `"o"' displaying a view that you only need when
 | 
						||
reading emails.  Then you would configure this option like this:
 | 
						||
 | 
						||
     (setq org-agenda-custom-commands-contexts
 | 
						||
           '(("o" (in-mode . "message-mode"))))
 | 
						||
 | 
						||
   You can also tell that the command key `"o"' should refer to another
 | 
						||
command key `"r"'.  In that case, add this command key like this:
 | 
						||
 | 
						||
     (setq org-agenda-custom-commands-contexts
 | 
						||
           '(("o" "r" (in-mode . "message-mode"))))
 | 
						||
 | 
						||
   See the docstring of the variable for more information.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Exporting agenda views,  Next: Agenda column view,  Prev: Custom agenda views,  Up: Agenda views
 | 
						||
 | 
						||
10.7 Exporting agenda views
 | 
						||
===========================
 | 
						||
 | 
						||
If you are away from your computer, it can be very useful to have a
 | 
						||
printed version of some agenda views to carry around.  Org mode can
 | 
						||
export custom agenda views as plain text, HTML(1), Postscript, PDF(2),
 | 
						||
and iCalendar files.  If you want to do this only occasionally, use the
 | 
						||
command
 | 
						||
 | 
						||
`C-x C-w     (`org-agenda-write')'
 | 
						||
     Write the agenda view to a file.  Depending on the extension of
 | 
						||
     the selected file name, the view will be exported as HTML
 | 
						||
     (extension `.html' or `.htm'), Postscript (extension `.ps'),
 | 
						||
     iCalendar (extension `.ics'), or plain text (any other extension).
 | 
						||
     Use the variable `org-agenda-exporter-settings' to set options for
 | 
						||
     `ps-print' and for `htmlize' to be used during export, for example
 | 
						||
 | 
						||
          (setq org-agenda-exporter-settings
 | 
						||
                '((ps-number-of-columns 2)
 | 
						||
                  (ps-landscape-mode t)
 | 
						||
                  (org-agenda-add-entry-text-maxlines 5)
 | 
						||
                  (htmlize-output-type 'css)))
 | 
						||
 | 
						||
   If you need to export certain agenda views frequently, you can
 | 
						||
associate any custom agenda command with a list of output file names
 | 
						||
(3).  Here is an example that first defines custom commands for the
 | 
						||
agenda and the global TODO list, together with a number of files to
 | 
						||
which to export them.  Then we define two block agenda commands and
 | 
						||
specify file names for them as well.  File names can be relative to the
 | 
						||
current working directory, or absolute.
 | 
						||
 | 
						||
     (setq org-agenda-custom-commands
 | 
						||
           '(("X" agenda "" nil ("agenda.html" "agenda.ps"))
 | 
						||
             ("Y" alltodo "" nil ("todo.html" "todo.txt" "todo.ps"))
 | 
						||
             ("h" "Agenda and Home-related tasks"
 | 
						||
              ((agenda "")
 | 
						||
               (tags-todo "home")
 | 
						||
               (tags "garden"))
 | 
						||
              nil
 | 
						||
              ("~/views/home.html"))
 | 
						||
             ("o" "Agenda and Office-related tasks"
 | 
						||
              ((agenda)
 | 
						||
               (tags-todo "work")
 | 
						||
               (tags "office"))
 | 
						||
              nil
 | 
						||
              ("~/views/office.ps" "~/calendars/office.ics"))))
 | 
						||
 | 
						||
   The extension of the file name determines the type of export.  If it
 | 
						||
is `.html', Org mode will use the `htmlize.el' package to convert the
 | 
						||
buffer to HTML and save it to this file name.  If the extension is
 | 
						||
`.ps', `ps-print-buffer-with-faces' is used to produce Postscript
 | 
						||
output.  If the extension is `.ics', iCalendar export is run export
 | 
						||
over all files that were used to construct the agenda, and limit the
 | 
						||
export to entries listed in the agenda.  Any other extension produces a
 | 
						||
plain ASCII file.
 | 
						||
 | 
						||
   The export files are _not_ created when you use one of those
 | 
						||
commands interactively because this might use too much overhead.
 | 
						||
Instead, there is a special command to produce _all_ specified files in
 | 
						||
one step:
 | 
						||
 | 
						||
`C-c a e     (`org-store-agenda-views')'
 | 
						||
     Export all agenda views that have export file names associated with
 | 
						||
     them.
 | 
						||
 | 
						||
   You can use the options section of the custom agenda commands to also
 | 
						||
set options for the export commands.  For example:
 | 
						||
 | 
						||
     (setq org-agenda-custom-commands
 | 
						||
           '(("X" agenda ""
 | 
						||
              ((ps-number-of-columns 2)
 | 
						||
               (ps-landscape-mode t)
 | 
						||
               (org-agenda-prefix-format " [ ] ")
 | 
						||
               (org-agenda-with-colors nil)
 | 
						||
               (org-agenda-remove-tags t))
 | 
						||
              ("theagenda.ps"))))
 | 
						||
 | 
						||
This command sets two options for the Postscript exporter, to make it
 | 
						||
print in two columns in landscape format--the resulting page can be cut
 | 
						||
in two and then used in a paper agenda.  The remaining settings modify
 | 
						||
the agenda prefix to omit category and scheduling information, and
 | 
						||
instead include a checkbox to check off items.  We also remove the tags
 | 
						||
to make the lines compact, and we don't want to use colors for the
 | 
						||
black-and-white printer.  Settings specified in
 | 
						||
`org-agenda-exporter-settings' will also apply, but the settings in
 | 
						||
`org-agenda-custom-commands' take precedence.
 | 
						||
 | 
						||
From the command line you may also use
 | 
						||
     emacs -eval (org-batch-store-agenda-views) -kill
 | 
						||
   or, if you need to modify some parameters(4)
 | 
						||
     emacs -eval '(org-batch-store-agenda-views                      \
 | 
						||
                   org-agenda-span (quote month)                     \
 | 
						||
                   org-agenda-start-day "2007-11-01"                 \
 | 
						||
                   org-agenda-include-diary nil                      \
 | 
						||
                   org-agenda-files (quote ("~/org/project.org")))'  \
 | 
						||
           -kill
 | 
						||
   which will create the agenda views restricted to the file
 | 
						||
`~/org/project.org', without diary entries and with a 30-day extent.
 | 
						||
 | 
						||
   You can also extract agenda information in a way that allows further
 | 
						||
processing by other programs.  See *note Extracting agenda
 | 
						||
information::, for more information.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) You need to install Hrvoje Niksic's `htmlize.el'.
 | 
						||
 | 
						||
   (2) To create PDF output, the ghostscript `ps2pdf' utility must be
 | 
						||
installed on the system.  Selecting a PDF file will also create the
 | 
						||
postscript file.
 | 
						||
 | 
						||
   (3) If you want to store standard views like the weekly agenda or
 | 
						||
the global TODO list as well, you need to define custom commands for
 | 
						||
them in order to be able to specify file names.
 | 
						||
 | 
						||
   (4) Quoting depends on the system you use, please check the FAQ for
 | 
						||
examples.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Agenda column view,  Prev: Exporting agenda views,  Up: Agenda views
 | 
						||
 | 
						||
10.8 Using column view in the agenda
 | 
						||
====================================
 | 
						||
 | 
						||
Column view (*note Column view::) is normally used to view and edit
 | 
						||
properties embedded in the hierarchical structure of an Org file.  It
 | 
						||
can be quite useful to use column view also from the agenda, where
 | 
						||
entries are collected by certain criteria.
 | 
						||
 | 
						||
`C-c C-x C-c     (`org-agenda-columns')'
 | 
						||
     Turn on column view in the agenda.
 | 
						||
 | 
						||
   To understand how to use this properly, it is important to realize
 | 
						||
that the entries in the agenda are no longer in their proper outline
 | 
						||
environment.  This causes the following issues:
 | 
						||
 | 
						||
  1. Org needs to make a decision which `COLUMNS' format to use.  Since
 | 
						||
     the entries in the agenda are collected from different files, and
 | 
						||
     different files may have different `COLUMNS' formats, this is a
 | 
						||
     non-trivial problem.  Org first checks if the variable
 | 
						||
     `org-agenda-overriding-columns-format' is currently set, and if
 | 
						||
     so, takes the format from there.  Otherwise it takes the format
 | 
						||
     associated with the first item in the agenda, or, if that item
 | 
						||
     does not have a specific format (defined in a property, or in its
 | 
						||
     file), it uses `org-columns-default-format'.
 | 
						||
 | 
						||
  2. If any of the columns has a summary type defined (*note Column
 | 
						||
     attributes::), turning on column view in the agenda will visit all
 | 
						||
     relevant agenda files and make sure that the computations of this
 | 
						||
     property are up to date.  This is also true for the special
 | 
						||
     `CLOCKSUM' property.  Org will then sum the values displayed in
 | 
						||
     the agenda.  In the daily/weekly agenda, the sums will cover a
 | 
						||
     single day; in all other views they cover the entire block.  It is
 | 
						||
     vital to realize that the agenda may show the same entry _twice_
 | 
						||
     (for example as scheduled and as a deadline), and it may show two
 | 
						||
     entries from the same hierarchy (for example a _parent_ and its
 | 
						||
     _child_).  In these cases, the summation in the agenda will lead
 | 
						||
     to incorrect results because some values will count double.
 | 
						||
 | 
						||
  3. When the column view in the agenda shows the `CLOCKSUM', that is
 | 
						||
     always the entire clocked time for this item.  So even in the
 | 
						||
     daily/weekly agenda, the clocksum listed in column view may
 | 
						||
     originate from times outside the current view.  This has the
 | 
						||
     advantage that you can compare these values with a column listing
 | 
						||
     the planned total effort for a task--one of the major applications
 | 
						||
     for column view in the agenda.  If you want information about
 | 
						||
     clocked time in the displayed period use clock table mode (press
 | 
						||
     `R' in the agenda).
 | 
						||
 | 
						||
  4. When the column view in the agenda shows the `CLOCKSUM_T', that is
 | 
						||
     always today's clocked time for this item.  So even in the weekly
 | 
						||
     agenda, the clocksum listed in column view only originates from
 | 
						||
     today.  This lets you compare the time you spent on a task for
 | 
						||
     today, with the time already spent (via `CLOCKSUM') and with the
 | 
						||
     planned total effort for it.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Markup,  Next: Exporting,  Prev: Agenda views,  Up: Top
 | 
						||
 | 
						||
11 Markup for rich export
 | 
						||
*************************
 | 
						||
 | 
						||
When exporting Org mode documents, the exporter tries to reflect the
 | 
						||
structure of the document as accurately as possible in the back-end.
 | 
						||
Since export targets like HTML and LaTeX allow much richer formatting,
 | 
						||
Org mode has rules on how to prepare text for rich export.  This
 | 
						||
section summarizes the markup rules used in an Org mode buffer.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Structural markup elements::  The basic structure as seen by the exporter
 | 
						||
* Images and tables::           Images, tables and caption mechanism
 | 
						||
* Literal examples::            Source code examples with special formatting
 | 
						||
* Include files::               Include additional files into a document
 | 
						||
* Index entries::               Making an index
 | 
						||
* Macro replacement::           Use macros to create templates
 | 
						||
* Embedded LaTeX::           LaTeX can be freely used inside Org documents
 | 
						||
* Special blocks::              Containers targeted at export back-ends
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Structural markup elements,  Next: Images and tables,  Up: Markup
 | 
						||
 | 
						||
11.1 Structural markup elements
 | 
						||
===============================
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Document title::              Where the title is taken from
 | 
						||
* Headings and sections::       The document structure as seen by the exporter
 | 
						||
* Table of contents::           The if and where of the table of contents
 | 
						||
* Lists::                       Lists
 | 
						||
* Paragraphs::                  Paragraphs
 | 
						||
* Footnote markup::             Footnotes
 | 
						||
* Emphasis and monospace::      Bold, italic, etc.
 | 
						||
* Horizontal rules::            Make a line
 | 
						||
* Comment lines::               What will *not* be exported
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Document title,  Next: Headings and sections,  Up: Structural markup elements
 | 
						||
 | 
						||
Document title
 | 
						||
--------------
 | 
						||
 | 
						||
The title of the exported document is taken from the special line
 | 
						||
 | 
						||
     #+TITLE: This is the title of the document
 | 
						||
 | 
						||
   If you are exporting only a subtree, its heading will become the
 | 
						||
title of the document.  If the subtree has a property `EXPORT_TITLE',
 | 
						||
that will take precedence.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Headings and sections,  Next: Table of contents,  Prev: Document title,  Up: Structural markup elements
 | 
						||
 | 
						||
Headings and sections
 | 
						||
---------------------
 | 
						||
 | 
						||
The outline structure of the document as described in *note Document
 | 
						||
structure::, forms the basis for defining sections of the exported
 | 
						||
document.  However, since the outline structure is also used for (for
 | 
						||
example) lists of tasks, only the first three outline levels will be
 | 
						||
used as headings.  Deeper levels will become itemized lists.  You can
 | 
						||
change the location of this switch globally by setting the variable
 | 
						||
`org-export-headline-levels', or on a per-file basis with a line
 | 
						||
 | 
						||
     #+OPTIONS: H:4
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Table of contents,  Next: Lists,  Prev: Headings and sections,  Up: Structural markup elements
 | 
						||
 | 
						||
Table of contents
 | 
						||
-----------------
 | 
						||
 | 
						||
The table of contents is normally inserted directly before the first
 | 
						||
headline of the file.  The depth of the table is by default the same as
 | 
						||
the number of headline levels, but you can choose a smaller number, or
 | 
						||
turn off the table of contents entirely, by configuring the variable
 | 
						||
`org-export-with-toc', or on a per-file basis with a line like
 | 
						||
 | 
						||
     #+OPTIONS: toc:2          only inlcude two levels in TOC
 | 
						||
     #+OPTIONS: toc:nil        no default TOC at all
 | 
						||
 | 
						||
   If you would like to move the table of contents to a different
 | 
						||
location, you should turn off the default table using
 | 
						||
`org-export-with-toc' or `#+OPTIONS' and insert `#+TOC: headlines N' at
 | 
						||
the desired location(s).
 | 
						||
 | 
						||
     #+OPTIONS: toc:nil        no default TOC
 | 
						||
     ...
 | 
						||
     #+TOC: headlines 2        insert TOC here, with two headline levels
 | 
						||
 | 
						||
   Moreover, if you append `local' parameter, the table contains only
 | 
						||
entries for the children of the current section(1).  In this case, any
 | 
						||
depth parameter becomes relative to the current level.
 | 
						||
 | 
						||
     * Section
 | 
						||
     #+TOC: headlines 1 local  insert local TOC, with direct children only
 | 
						||
 | 
						||
   The same `TOC' keyword can also generate a list of all tables (resp.
 | 
						||
all listings) with a caption in the document.
 | 
						||
 | 
						||
     #+TOC: listings           build a list of listings
 | 
						||
     #+TOC: tables             build a list of tables
 | 
						||
 | 
						||
   The headline's title usually determines its corresponding entry in a
 | 
						||
table of contents.  However, it is possible to specify an alternative
 | 
						||
title by setting `ALT_TITLE' property accordingly.  It will then be
 | 
						||
used when building the table.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) For LaTeX export, this feature requires the `titletoc' package.
 | 
						||
Note that `titletoc' must be loaded _before_ `hyperref'.  Thus, you may
 | 
						||
have to customize `org-latex-default-packages-alist'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Lists,  Next: Paragraphs,  Prev: Table of contents,  Up: Structural markup elements
 | 
						||
 | 
						||
Lists
 | 
						||
-----
 | 
						||
 | 
						||
Plain lists as described in *note Plain lists::, are translated to the
 | 
						||
back-end's syntax for such lists.  Most back-ends support unordered,
 | 
						||
ordered, and description lists.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Paragraphs,  Next: Footnote markup,  Prev: Lists,  Up: Structural markup elements
 | 
						||
 | 
						||
Paragraphs, line breaks, and quoting
 | 
						||
------------------------------------
 | 
						||
 | 
						||
Paragraphs are separated by at least one empty line.  If you need to
 | 
						||
enforce a line break within a paragraph, use `\\' at the end of a line.
 | 
						||
 | 
						||
   To keep the line breaks in a region, but otherwise use normal
 | 
						||
formatting, you can use this construct, which can also be used to
 | 
						||
format poetry.
 | 
						||
 | 
						||
     #+BEGIN_VERSE
 | 
						||
      Great clouds overhead
 | 
						||
      Tiny black birds rise and fall
 | 
						||
      Snow covers Emacs
 | 
						||
 | 
						||
          -- AlexSchroeder
 | 
						||
     #+END_VERSE
 | 
						||
 | 
						||
   When quoting a passage from another document, it is customary to
 | 
						||
format this as a paragraph that is indented on both the left and the
 | 
						||
right margin.  You can include quotations in Org mode documents like
 | 
						||
this:
 | 
						||
 | 
						||
     #+BEGIN_QUOTE
 | 
						||
     Everything should be made as simple as possible,
 | 
						||
     but not any simpler -- Albert Einstein
 | 
						||
     #+END_QUOTE
 | 
						||
 | 
						||
   If you would like to center some text, do it like this: 
 | 
						||
     #+BEGIN_CENTER
 | 
						||
     Everything should be made as simple as possible, \\
 | 
						||
     but not any simpler
 | 
						||
     #+END_CENTER
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Footnote markup,  Next: Emphasis and monospace,  Prev: Paragraphs,  Up: Structural markup elements
 | 
						||
 | 
						||
Footnote markup
 | 
						||
---------------
 | 
						||
 | 
						||
Footnotes defined in the way described in *note Footnotes::, will be
 | 
						||
exported by all back-ends.  Org allows multiple references to the same
 | 
						||
note, and multiple footnotes side by side.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Emphasis and monospace,  Next: Horizontal rules,  Prev: Footnote markup,  Up: Structural markup elements
 | 
						||
 | 
						||
Emphasis and monospace
 | 
						||
----------------------
 | 
						||
 | 
						||
You can make words *bold*, /italic/, _underlined_, `=verbatim=' and
 | 
						||
`~code~', and, if you must, `+strike-through+'.  Text in the code and
 | 
						||
verbatim string is not processed for Org mode specific syntax, it is
 | 
						||
exported verbatim.
 | 
						||
 | 
						||
   To turn off fontification for marked up text, you can set
 | 
						||
`org-fontify-emphasized-text' to `nil'.  To narrow down the list of
 | 
						||
available markup syntax, you can customize `org-emphasis-alist'.  To
 | 
						||
fine tune what characters are allowed before and after the markup
 | 
						||
characters, you can tweak `org-emphasis-regexp-components'.  Beware
 | 
						||
that changing one of the above variables will no take effect until you
 | 
						||
reload Org, for which you may need to restart Emacs.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Horizontal rules,  Next: Comment lines,  Prev: Emphasis and monospace,  Up: Structural markup elements
 | 
						||
 | 
						||
Horizontal rules
 | 
						||
----------------
 | 
						||
 | 
						||
A line consisting of only dashes, and at least 5 of them, will be
 | 
						||
exported as a horizontal line.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Comment lines,  Prev: Horizontal rules,  Up: Structural markup elements
 | 
						||
 | 
						||
Comment lines
 | 
						||
-------------
 | 
						||
 | 
						||
Lines starting with zero or more whitespace characters followed by one
 | 
						||
`#' and a whitespace are treated as comments and, as such, are not
 | 
						||
exported.
 | 
						||
 | 
						||
   Likewise, regions surrounded by `#+BEGIN_COMMENT' ...
 | 
						||
`#+END_COMMENT' are not exported.
 | 
						||
 | 
						||
   Finally, a `COMMENT' keyword at the beginning of an entry, but after
 | 
						||
any other keyword or priority cookie, comments out the entire subtree.
 | 
						||
In this case, the subtree is not exported and no code block within it
 | 
						||
is executed either(1).  The command below helps changing the comment
 | 
						||
status of a headline.
 | 
						||
 | 
						||
`C-c ;'
 | 
						||
     Toggle the `COMMENT' keyword at the beginning of an entry.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) For a less drastic behavior, consider using a select tag (*note
 | 
						||
Export settings::) instead.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Images and tables,  Next: Literal examples,  Prev: Structural markup elements,  Up: Markup
 | 
						||
 | 
						||
11.2 Images and Tables
 | 
						||
======================
 | 
						||
 | 
						||
Both the native Org mode tables (*note Tables::) and tables formatted
 | 
						||
with the `table.el' package will be exported properly.  For Org mode
 | 
						||
tables, the lines before the first horizontal separator line will
 | 
						||
become table header lines.  You can use the following lines somewhere
 | 
						||
before the table to assign a caption and a label for cross references,
 | 
						||
and in the text you can refer to the object with `[[tab:basic-data]]'
 | 
						||
(*note Internal links::):
 | 
						||
 | 
						||
     #+CAPTION: This is the caption for the next table (or link)
 | 
						||
     #+NAME:   tab:basic-data
 | 
						||
        | ... | ...|
 | 
						||
        |-----|----|
 | 
						||
 | 
						||
   Optionally, the caption can take the form:
 | 
						||
     #+CAPTION[Caption for list of tables]: Caption for table.
 | 
						||
 | 
						||
   Some back-ends allow you to directly include images into the exported
 | 
						||
document.  Org does this, if a link to an image files does not have a
 | 
						||
description part, for example `[[./img/a.jpg]]'.  If you wish to define
 | 
						||
a caption for the image and maybe a label for internal cross
 | 
						||
references, make sure that the link is on a line by itself and precede
 | 
						||
it with `#+CAPTION' and `#+NAME' as follows:
 | 
						||
 | 
						||
     #+CAPTION: This is the caption for the next figure link (or table)
 | 
						||
     #+NAME:   fig:SED-HR4049
 | 
						||
     [[./img/a.jpg]]
 | 
						||
 | 
						||
Such images can be displayed within the buffer.  *Note the discussion
 | 
						||
of image links: Handling links.
 | 
						||
 | 
						||
   Even though images and tables are prominent examples of captioned
 | 
						||
structures, the same caption mechanism can apply to many others (e.g.,
 | 
						||
LaTeX equations, source code blocks).  Depending on the export
 | 
						||
back-end, those may or may not be handled.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Literal examples,  Next: Include files,  Prev: Images and tables,  Up: Markup
 | 
						||
 | 
						||
11.3 Literal examples
 | 
						||
=====================
 | 
						||
 | 
						||
You can include literal examples that should not be subjected to
 | 
						||
markup.  Such examples will be typeset in monospace, so this is well
 | 
						||
suited for source code and similar examples.  
 | 
						||
 | 
						||
     #+BEGIN_EXAMPLE
 | 
						||
     Some example from a text file.
 | 
						||
     #+END_EXAMPLE
 | 
						||
 | 
						||
   Note that such blocks may be indented in order to align nicely with
 | 
						||
indented text and in particular with plain list structure (*note Plain
 | 
						||
lists::).  For simplicity when using small examples, you can also start
 | 
						||
the example lines with a colon followed by a space.  There may also be
 | 
						||
additional whitespace before the colon:
 | 
						||
 | 
						||
     Here is an example
 | 
						||
        : Some example from a text file.
 | 
						||
 | 
						||
   If the example is source code from a programming language, or any
 | 
						||
other text that can be marked up by font-lock in Emacs, you can ask for
 | 
						||
the example to look like the fontified Emacs buffer(1).  This is done
 | 
						||
with the `src' block, where you also need to specify the name of the
 | 
						||
major mode that should be used to fontify the example(2), see *note
 | 
						||
Easy templates:: for shortcuts to easily insert code blocks.  
 | 
						||
 | 
						||
     #+BEGIN_SRC emacs-lisp
 | 
						||
       (defun org-xor (a b)
 | 
						||
          "Exclusive or."
 | 
						||
          (if a (not b) b))
 | 
						||
     #+END_SRC
 | 
						||
 | 
						||
   Both in `example' and in `src' snippets, you can add a `-n' switch
 | 
						||
to the end of the `BEGIN' line, to get the lines of the example
 | 
						||
numbered.  If you use a `+n' switch, the numbering from the previous
 | 
						||
numbered snippet will be continued in the current one.  In literal
 | 
						||
examples, Org will interpret strings like `(ref:name)' as labels, and
 | 
						||
use them as targets for special hyperlinks like `[[(name)]]' (i.e., the
 | 
						||
reference name enclosed in single parenthesis).  In HTML, hovering the
 | 
						||
mouse over such a link will remote-highlight the corresponding code
 | 
						||
line, which is kind of cool.
 | 
						||
 | 
						||
   You can also add a `-r' switch which removes the labels from the
 | 
						||
source code(3).  With the `-n' switch, links to these references will
 | 
						||
be labeled by the line numbers from the code listing, otherwise links
 | 
						||
will use the labels with no parentheses.  Here is an example:
 | 
						||
 | 
						||
     #+BEGIN_SRC emacs-lisp -n -r
 | 
						||
     (save-excursion                  (ref:sc)
 | 
						||
        (goto-char (point-min)))      (ref:jump)
 | 
						||
     #+END_SRC
 | 
						||
     In line [[(sc)]] we remember the current position.  [[(jump)][Line (jump)]]
 | 
						||
     jumps to point-min.
 | 
						||
 | 
						||
   Finally, you can use `-i' to preserve the indentation of a specific
 | 
						||
code block (*note Editing source code::).
 | 
						||
 | 
						||
   If the syntax for the label format conflicts with the language
 | 
						||
syntax, use a `-l' switch to change the format, for example
 | 
						||
`#+BEGIN_SRC pascal -n -r -l "((%s))"'.  See also the variable
 | 
						||
`org-coderef-label-format'.
 | 
						||
 | 
						||
   HTML export also allows examples to be published as text areas
 | 
						||
(*note Text areas in HTML export::).
 | 
						||
 | 
						||
   Because the `#+BEGIN_...' and `#+END_...' patterns need to be added
 | 
						||
so often, shortcuts are provided using the Easy templates facility
 | 
						||
(*note Easy templates::).
 | 
						||
 | 
						||
`C-c ''
 | 
						||
     Edit the source code example at point in its native mode.  This
 | 
						||
     works by switching to a temporary buffer with the source code.
 | 
						||
     You need to exit by pressing `C-c '' again(4).  The edited version
 | 
						||
     will then replace the old version in the Org buffer.  Fixed-width
 | 
						||
     regions (where each line starts with a colon followed by a space)
 | 
						||
     will be edited using `artist-mode'(5) to allow creating ASCII
 | 
						||
     drawings easily.  Using this command in an empty line will create
 | 
						||
     a new fixed-width region.  
 | 
						||
 | 
						||
`C-c l'
 | 
						||
     Calling `org-store-link' while editing a source code example in a
 | 
						||
     temporary buffer created with `C-c '' will prompt for a label.
 | 
						||
     Make sure that it is unique in the current buffer, and insert it
 | 
						||
     with the proper formatting like `(ref:label)' at the end of the
 | 
						||
     current line.  Then the label is stored as a link `(label)', for
 | 
						||
     retrieval with `C-c C-l'.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) This works automatically for the HTML back-end (it requires
 | 
						||
version 1.34 of the `htmlize.el' package, which is distributed with
 | 
						||
Org).  Fontified code chunks in LaTeX can be achieved using either the
 | 
						||
listings
 | 
						||
(https://www.ctan.org/tex-archive/macros/latex/contrib/listings/?lang=en)
 | 
						||
or the minted (https://github.com/gpoore/minted) package.  If you use
 | 
						||
minted or listing, you must load the packages manually, for example by
 | 
						||
adding the desired package to `org-latex-packages-alist'.  Refer to
 | 
						||
`org-latex-listings' for details.
 | 
						||
 | 
						||
   (2) Code in `src' blocks may also be evaluated either interactively
 | 
						||
or on export.  See *note Working with source code:: for more
 | 
						||
information on evaluating code blocks.
 | 
						||
 | 
						||
   (3) Adding `-k' to `-n -r' will keep the labels in the source code
 | 
						||
while using line numbers for the links, which might be useful to
 | 
						||
explain those in an Org mode example code.
 | 
						||
 | 
						||
   (4) Upon exit, lines starting with `*', `,*', `#+' and `,#+' will
 | 
						||
get a comma prepended, to keep them from being interpreted by Org as
 | 
						||
outline nodes or special syntax.  These commas will be stripped for
 | 
						||
editing with `C-c '', and also for export.
 | 
						||
 | 
						||
   (5) You may select a different-mode with the variable
 | 
						||
`org-edit-fixed-width-region-mode'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Include files,  Next: Index entries,  Prev: Literal examples,  Up: Markup
 | 
						||
 | 
						||
11.4 Include files
 | 
						||
==================
 | 
						||
 | 
						||
During export, you can include the content of another file.  For
 | 
						||
example, to include your `.emacs' file, you could use: 
 | 
						||
 | 
						||
     #+INCLUDE: "~/.emacs" src emacs-lisp
 | 
						||
 | 
						||
The first parameter names the the file to include.  The optional second
 | 
						||
and third parameter specify the markup (i.e., `example' or `src'), and,
 | 
						||
if the markup is `src', the language for formatting the contents.
 | 
						||
 | 
						||
   If markup is requested, the included content will be placed within an
 | 
						||
appropriate block(1).  No changes to the included content are made and
 | 
						||
it is the responsibility of the user to ensure that the result is valid
 | 
						||
Org syntax.  For markup `example' and `src', which is requesting a
 | 
						||
literal example, the content will be code-escaped before inclusion.
 | 
						||
 | 
						||
   If no markup is requested, the text will be assumed to be in Org
 | 
						||
mode format and will be processed normally.  However, footnote labels
 | 
						||
(*note Footnotes::) in the file will be made local to that file.
 | 
						||
Contents of the included file will belong to the same structure
 | 
						||
(headline, item) containing the `INCLUDE' keyword.  In particular,
 | 
						||
headlines within the file will become children of the current section.
 | 
						||
That behavior can be changed by providing an additional keyword
 | 
						||
parameter, `:minlevel'.  In that case, all headlines in the included
 | 
						||
file will be shifted so the one with the lowest level reaches that
 | 
						||
specified level.  For example, to make a file become a sibling of the
 | 
						||
current top-level headline, use
 | 
						||
 | 
						||
     #+INCLUDE: "~/my-book/chapter2.org" :minlevel 1
 | 
						||
 | 
						||
   You can also include a portion of a file by specifying a lines range
 | 
						||
using the `:lines' keyword parameter.  The line at the upper end of the
 | 
						||
range will not be included.  The start and/or the end of the range may
 | 
						||
be omitted to use the obvious defaults.
 | 
						||
 | 
						||
     #+INCLUDE: "~/.emacs" :lines "5-10"   Include lines 5 to 10, 10 excluded
 | 
						||
     #+INCLUDE: "~/.emacs" :lines "-10"    Include lines 1 to 10, 10 excluded
 | 
						||
     #+INCLUDE: "~/.emacs" :lines "10-"    Include lines from 10 to EOF
 | 
						||
 | 
						||
   Finally, you may use a file-link to extract an object as matched by
 | 
						||
`org-link-search'(2) (*note Search options::).  If the `:only-contents'
 | 
						||
property is non-`nil', only the contents of the requested element will
 | 
						||
be included, omitting properties drawer and planning-line if present.
 | 
						||
The `:lines' keyword operates locally with respect to the requested
 | 
						||
element.  Some examples:
 | 
						||
 | 
						||
     #+INCLUDE: "./paper.org::#theory" :only-contents t
 | 
						||
        Include the body of the heading with the custom id `theory'
 | 
						||
     #+INCLUDE: "./paper.org::mytable"  Include named element.
 | 
						||
     #+INCLUDE: "./paper.org::*conclusion" :lines 1-20
 | 
						||
        Include the first 20 lines of the headline named conclusion.
 | 
						||
 | 
						||
`C-c ''
 | 
						||
     Visit the include file at point.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) While you can request paragraphs (`verse', `quote', `center'),
 | 
						||
but this places severe restrictions on the type of content that is
 | 
						||
permissible
 | 
						||
 | 
						||
   (2) Note that `org-link-search-must-match-exact-headline' is locally
 | 
						||
bound to non-`nil'.  Therefore, `org-link-search' only matches
 | 
						||
headlines and named elements.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Index entries,  Next: Macro replacement,  Prev: Include files,  Up: Markup
 | 
						||
 | 
						||
11.5 Index entries
 | 
						||
==================
 | 
						||
 | 
						||
You can specify entries that will be used for generating an index during
 | 
						||
publishing.  This is done by lines starting with `#+INDEX'.  An entry
 | 
						||
the contains an exclamation mark will create a sub item.  See *note
 | 
						||
Generating an index:: for more information.
 | 
						||
 | 
						||
     * Curriculum Vitae
 | 
						||
     #+INDEX: CV
 | 
						||
     #+INDEX: Application!CV
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Macro replacement,  Next: Embedded LaTeX,  Prev: Index entries,  Up: Markup
 | 
						||
 | 
						||
11.6 Macro replacement
 | 
						||
======================
 | 
						||
 | 
						||
You can define text snippets with
 | 
						||
 | 
						||
     #+MACRO: name   replacement text $1, $2 are arguments
 | 
						||
 | 
						||
which can be referenced `{{{name(arg1, arg2)}}}'(1).
 | 
						||
 | 
						||
   These references, called macros, can be inserted anywhere Org markup
 | 
						||
is recognized: paragraphs, headlines, verse blocks, tables cells and
 | 
						||
lists.  They can also be used in keywords accepting Org syntax, e.g.,
 | 
						||
`#+CAPTION', `#+TITLE', `#+AUTHOR', `#+DATE' and some others, export
 | 
						||
back-end specific, ones.
 | 
						||
 | 
						||
   In addition to user-defined macros, a set of predefined macros can
 | 
						||
be used:
 | 
						||
 | 
						||
`{{{title}}}'
 | 
						||
`{{{author}}}'
 | 
						||
`{{{email}}}'
 | 
						||
     These macros are replaced with the information available at the
 | 
						||
     time of export.
 | 
						||
 | 
						||
`{{{date}}}'
 | 
						||
`{{{date(FORMAT)}}}'
 | 
						||
     This macro refers to the `#+DATE' keyword. FORMAT is an optional
 | 
						||
     argument to the `{{{date}}}' macro that will be used only if
 | 
						||
     `#+DATE' is a single timestamp.  FORMAT should be a format string
 | 
						||
     understood by `format-time-string'.
 | 
						||
 | 
						||
`{{{time(FORMAT)}}}'
 | 
						||
`{{{modification-time(FORMAT)}}}'
 | 
						||
     These macros refer to the date and time when the document is
 | 
						||
     exported and to the modification date and time of the file being
 | 
						||
     exported, respectively.  FORMAT should be a format string
 | 
						||
     understood by `format-time-string'.
 | 
						||
 | 
						||
`{{{input-file}}}'
 | 
						||
     This macro refers to the filename of the exported file, if any.
 | 
						||
 | 
						||
`{{{property(PROPERTY-NAME)}}}'
 | 
						||
`{{{property(PROPERTY-NAME,SEARCH-OPTION)}}}'
 | 
						||
     This macro returns the value of property PROPERTY-NAME in current
 | 
						||
     entry.  If SEARCH-OPTION (*note Search options::) refers to a
 | 
						||
     remote entry, it will be used instead.
 | 
						||
 | 
						||
   The surrounding brackets can be made invisible by setting
 | 
						||
`org-hide-macro-markers' non-`nil'.
 | 
						||
 | 
						||
   Macro expansion takes place during the very beginning of the export
 | 
						||
process.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Since commas separate arguments, commas within arguments have to
 | 
						||
be escaped with a backslash character.  Conversely, backslash
 | 
						||
characters before a comma, and only them, need to be escaped with
 | 
						||
another backslash character.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Embedded LaTeX,  Next: Special blocks,  Prev: Macro replacement,  Up: Markup
 | 
						||
 | 
						||
11.7 Embedded LaTeX
 | 
						||
===================
 | 
						||
 | 
						||
Plain ASCII is normally sufficient for almost all note taking.
 | 
						||
Exceptions include scientific notes, which often require mathematical
 | 
						||
symbols and the occasional formula.  LaTeX(1)  is widely used to
 | 
						||
typeset scientific documents.  Org mode supports embedding LaTeX code
 | 
						||
into its files, because many academics are used to writing and reading
 | 
						||
LaTeX source code, and because it can be readily processed to produce
 | 
						||
pretty output for a number of export back-ends.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Special symbols::             Greek letters and other symbols
 | 
						||
* Subscripts and superscripts::  Simple syntax for raising/lowering text
 | 
						||
* LaTeX fragments::          Complex formulas made easy
 | 
						||
* Previewing LaTeX fragments::  What will this snippet look like?
 | 
						||
* CDLaTeX mode::                Speed up entering of formulas
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) LaTeX is a macro system based on Donald E. Knuth's TeX system.
 | 
						||
Many of the features described here as "LaTeX" are really from TeX, but
 | 
						||
for simplicity I am blurring this distinction.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Special symbols,  Next: Subscripts and superscripts,  Up: Embedded LaTeX
 | 
						||
 | 
						||
11.7.1 Special symbols
 | 
						||
----------------------
 | 
						||
 | 
						||
You can use LaTeX-like syntax to insert special symbols like `\alpha'
 | 
						||
to indicate the Greek letter, or `\to' to indicate an arrow.  Completion
 | 
						||
for these symbols is available, just type `\' and maybe a few letters,
 | 
						||
and press `M-<TAB>' to see possible completions.  Unlike LaTeX code,
 | 
						||
Org mode allows these symbols to be present without surrounding math
 | 
						||
delimiters, for example:
 | 
						||
 | 
						||
     Angles are written as Greek letters \alpha, \beta and \gamma.
 | 
						||
 | 
						||
   During export, these symbols will be transformed into the native
 | 
						||
format of the exporter back-end.  Strings like `\alpha' will be
 | 
						||
exported as `α' in the HTML output, and as `\(\alpha\)' in the
 | 
						||
LaTeX output.  Similarly, `\nbsp' will become ` ' in HTML and `~'
 | 
						||
in LaTeX.  If you need such a symbol inside a word, terminate it like
 | 
						||
this: `\Aacute{}stor'.
 | 
						||
 | 
						||
   A large number of entities is provided, with names taken from both
 | 
						||
HTML and LaTeX; see the variable `org-entities' for the complete list.
 | 
						||
`\-' is treated as a shy hyphen, and `--', `---', and `...' are all
 | 
						||
converted into special commands creating hyphens of different lengths
 | 
						||
or a compact set of dots.
 | 
						||
 | 
						||
   If you would like to see entities displayed as UTF-8 characters, use
 | 
						||
the following command(1):
 | 
						||
 | 
						||
`C-c C-x \'
 | 
						||
     Toggle display of entities as UTF-8 characters.  This does not
 | 
						||
     change the buffer content which remains plain ASCII, but it
 | 
						||
     overlays the UTF-8 character for display purposes only.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) You can turn this on by default by setting the variable
 | 
						||
`org-pretty-entities', or on a per-file base with the `#+STARTUP'
 | 
						||
option `entitiespretty'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Subscripts and superscripts,  Next: LaTeX fragments,  Prev: Special symbols,  Up: Embedded LaTeX
 | 
						||
 | 
						||
11.7.2 Subscripts and superscripts
 | 
						||
----------------------------------
 | 
						||
 | 
						||
Just like in LaTeX, `^' and `_' are used to indicate super- and
 | 
						||
subscripts.  Again, these can be used without embedding them in
 | 
						||
math-mode delimiters.  To increase the readability of ASCII text, it is
 | 
						||
not necessary (but OK) to surround multi-character sub- and
 | 
						||
superscripts with curly braces.  For example
 | 
						||
 | 
						||
     The mass of the sun is M_sun = 1.989 x 10^30 kg.  The radius of
 | 
						||
     the sun is R_{sun} = 6.96 x 10^8 m.
 | 
						||
 | 
						||
   If you write a text where the underscore is often used in a different
 | 
						||
context, Org's convention to always interpret these as subscripts can
 | 
						||
get in your way.  Configure the variable `org-use-sub-superscripts' to
 | 
						||
change this convention.  For example, when setting this variable to
 | 
						||
`{}', `a_b' will not be interpreted as a subscript, but `a_{b}' will.
 | 
						||
 | 
						||
`C-c C-x \'
 | 
						||
     In addition to showing entities as UTF-8 characters, this command
 | 
						||
     will also format sub- and superscripts in a WYSIWYM way.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: LaTeX fragments,  Next: Previewing LaTeX fragments,  Prev: Subscripts and superscripts,  Up: Embedded LaTeX
 | 
						||
 | 
						||
11.7.3 LaTeX fragments
 | 
						||
----------------------
 | 
						||
 | 
						||
Going beyond symbols and sub- and superscripts, a full formula language
 | 
						||
is needed.  Org mode can contain LaTeX math fragments, and it supports
 | 
						||
ways to process these for several export back-ends.  When exporting to
 | 
						||
LaTeX, the code is left as it is.  When exporting to HTML, Org can use
 | 
						||
either MathJax (http://www.mathjax.org) (*note Math formatting in HTML
 | 
						||
export::) or transcode the math into images (see *note Previewing LaTeX
 | 
						||
fragments::).
 | 
						||
 | 
						||
   LaTeX fragments don't need any special marking at all.  The following
 | 
						||
snippets will be identified as LaTeX source code:
 | 
						||
   * Environments of any kind(1).  The only requirement is that the
 | 
						||
     `\begin' statement appears on a new line, at the beginning of the
 | 
						||
     line or after whitespaces only.
 | 
						||
 | 
						||
   * Text within the usual LaTeX math delimiters.  To avoid conflicts
 | 
						||
     with currency specifications, single `$' characters are only
 | 
						||
     recognized as math delimiters if the enclosed text contains at
 | 
						||
     most two line breaks, is directly attached to the `$' characters
 | 
						||
     with no whitespace in between, and if the closing `$' is followed
 | 
						||
     by whitespace or punctuation (parentheses and quotes are
 | 
						||
     considered to be punctuation in this context).  For the other
 | 
						||
     delimiters, there is no such restriction, so when in doubt, use
 | 
						||
     `\(...\)' as inline math delimiters.
 | 
						||
 | 
						||
For example:
 | 
						||
 | 
						||
     \begin{equation}
 | 
						||
     x=\sqrt{b}
 | 
						||
     \end{equation}
 | 
						||
 | 
						||
     If $a^2=b$ and \( b=2 \), then the solution must be
 | 
						||
     either $$ a=+\sqrt{2} $$ or \[ a=-\sqrt{2} \].
 | 
						||
 | 
						||
   LaTeX processing can be configured with the variable
 | 
						||
`org-export-with-latex'.  The default setting is `t' which means
 | 
						||
MathJax for HTML, and no processing for ASCII and LaTeX back-ends.  You
 | 
						||
can also set this variable on a per-file basis using one of these lines:
 | 
						||
 | 
						||
     #+OPTIONS: tex:t          Do the right thing automatically (MathJax)
 | 
						||
     #+OPTIONS: tex:nil        Do not process LaTeX fragments at all
 | 
						||
     #+OPTIONS: tex:verbatim   Verbatim export, for jsMath or so
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) When MathJax is used, only the environments recognized by
 | 
						||
MathJax will be processed.  When `dvipng' program or `imagemagick'
 | 
						||
suite is used to create images, any LaTeX environment will be handled.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Previewing LaTeX fragments,  Next: CDLaTeX mode,  Prev: LaTeX fragments,  Up: Embedded LaTeX
 | 
						||
 | 
						||
11.7.4 Previewing LaTeX fragments
 | 
						||
---------------------------------
 | 
						||
 | 
						||
If you have a working LaTeX installation and either `dvipng' or
 | 
						||
`convert' installed(1), LaTeX fragments can be processed to produce
 | 
						||
images of the typeset expressions to be used for inclusion while
 | 
						||
exporting to HTML (see *note LaTeX fragments::), or for inline
 | 
						||
previewing within Org mode.
 | 
						||
 | 
						||
   You can customize the variables `org-format-latex-options' and
 | 
						||
`org-format-latex-header' to influence some aspects of the preview.  In
 | 
						||
particular, the `:scale' (and for HTML export, `:html-scale') property
 | 
						||
of the former can be used to adjust the size of the preview images.
 | 
						||
 | 
						||
`C-c C-x C-l'
 | 
						||
     Produce a preview image of the LaTeX fragment at point and overlay
 | 
						||
     it over the source code.  If there is no fragment at point,
 | 
						||
     process all fragments in the current entry (between two
 | 
						||
     headlines).  When called with a prefix argument, process the
 | 
						||
     entire subtree.  When called with two prefix arguments, or when
 | 
						||
     the cursor is before the first headline, process the entire buffer.  
 | 
						||
 | 
						||
`C-c C-c'
 | 
						||
     Remove the overlay preview images.
 | 
						||
 | 
						||
   You can turn on the previewing of all LaTeX fragments in a file with
 | 
						||
 | 
						||
     #+STARTUP: latexpreview
 | 
						||
 | 
						||
   To disable it, simply use
 | 
						||
 | 
						||
     #+STARTUP: nolatexpreview
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) These are respectively available at
 | 
						||
`http://sourceforge.net/projects/dvipng/' and from the `imagemagick'
 | 
						||
suite. Choose the converter by setting the variable
 | 
						||
`org-latex-create-formula-image-program' accordingly.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: CDLaTeX mode,  Prev: Previewing LaTeX fragments,  Up: Embedded LaTeX
 | 
						||
 | 
						||
11.7.5 Using CDLaTeX to enter math
 | 
						||
----------------------------------
 | 
						||
 | 
						||
CDLaTeX mode is a minor mode that is normally used in combination with a
 | 
						||
major LaTeX mode like AUCTeX in order to speed-up insertion of
 | 
						||
environments and math templates.  Inside Org mode, you can make use of
 | 
						||
some of the features of CDLaTeX mode.  You need to install `cdlatex.el'
 | 
						||
and `texmathp.el' (the latter comes also with AUCTeX) from
 | 
						||
`http://www.astro.uva.nl/~dominik/Tools/cdlatex'.  Don't use CDLaTeX
 | 
						||
mode itself under Org mode, but use the light version
 | 
						||
`org-cdlatex-mode' that comes as part of Org mode.  Turn it on for the
 | 
						||
current buffer with `M-x org-cdlatex-mode RET', or for all Org files
 | 
						||
with
 | 
						||
 | 
						||
     (add-hook 'org-mode-hook 'turn-on-org-cdlatex)
 | 
						||
 | 
						||
   When this mode is enabled, the following features are present (for
 | 
						||
more details see the documentation of CDLaTeX mode):
 | 
						||
   * Environment templates can be inserted with `C-c {'.
 | 
						||
 | 
						||
   * The <TAB> key will do template expansion if the cursor is inside a
 | 
						||
     LaTeX fragment(1).  For example, <TAB> will expand `fr' to
 | 
						||
     `\frac{}{}' and position the cursor correctly inside the first
 | 
						||
     brace.  Another <TAB> will get you into the second brace.  Even
 | 
						||
     outside fragments, <TAB> will expand environment abbreviations at
 | 
						||
     the beginning of a line.  For example, if you write `equ' at the
 | 
						||
     beginning of a line and press <TAB>, this abbreviation will be
 | 
						||
     expanded to an `equation' environment.  To get a list of all
 | 
						||
     abbreviations, type `M-x cdlatex-command-help RET'.
 | 
						||
 | 
						||
   * Pressing `_' and `^' inside a LaTeX fragment will insert these
 | 
						||
     characters together with a pair of braces.  If you use <TAB> to
 | 
						||
     move out of the braces, and if the braces surround only a single
 | 
						||
     character or macro, they are removed again (depending on the
 | 
						||
     variable `cdlatex-simplify-sub-super-scripts').
 | 
						||
 | 
						||
   * Pressing the grave accent ``' followed by a character inserts math
 | 
						||
     macros, also outside LaTeX fragments.  If you wait more than 1.5
 | 
						||
     seconds after the grave accent, a help window will pop up.
 | 
						||
 | 
						||
   * Pressing the apostrophe `'' followed by another character modifies
 | 
						||
     the symbol before point with an accent or a font.  If you wait
 | 
						||
     more than 1.5 seconds after the apostrophe, a help window will pop
 | 
						||
     up.  Character modification will work only inside LaTeX fragments;
 | 
						||
     outside the quote is normal.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Org mode has a method to test if the cursor is inside such a
 | 
						||
fragment, see the documentation of the function
 | 
						||
`org-inside-LaTeX-fragment-p'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Special blocks,  Prev: Embedded LaTeX,  Up: Markup
 | 
						||
 | 
						||
11.8 Special blocks
 | 
						||
===================
 | 
						||
 | 
						||
Org syntax includes pre-defined blocks (*note Paragraphs:: and *note
 | 
						||
Literal examples::).  It is also possible to create blocks containing
 | 
						||
raw code targeted at a specific back-end (e.g., `#+BEGIN_LATEX').
 | 
						||
 | 
						||
   Any other block is a _special block_.  Its name is case-sensitive.
 | 
						||
 | 
						||
   For example, `#+BEGIN_abstract' and `#+BEGIN_video' are special
 | 
						||
blocks.  The first one is useful when exporting to LaTeX, the second one
 | 
						||
when exporting to HTML5.
 | 
						||
 | 
						||
   Each export back-end decides if they should be exported, and how.
 | 
						||
When the block is ignored, its contents are still exported, as if the
 | 
						||
opening and closing block lines were not there.  For example, when
 | 
						||
exporting a `#+BEGIN_test' block, HTML back-end wraps its contents
 | 
						||
within a `<div name="test">' tag.
 | 
						||
 | 
						||
   Refer to back-end specific documentation for more information.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Exporting,  Next: Publishing,  Prev: Markup,  Up: Top
 | 
						||
 | 
						||
12 Exporting
 | 
						||
************
 | 
						||
 | 
						||
The Org mode export facilities can be used to export Org documents or
 | 
						||
parts of Org documents to a variety of other formats.  In addition,
 | 
						||
these facilities can be used with `orgtbl-mode' and/or `orgstruct-mode'
 | 
						||
in foreign buffers so you can author tables and lists in Org syntax and
 | 
						||
convert them in place to the target language.
 | 
						||
 | 
						||
   ASCII export produces a readable and simple version of an Org file
 | 
						||
for printing and sharing notes.  HTML export allows you to easily
 | 
						||
publish notes on the web, or to build full-fledged websites.  LaTeX
 | 
						||
export lets you use Org mode and its structured editing functions to
 | 
						||
create arbitrarily complex LaTeX files for any kind of document.
 | 
						||
OpenDocument Text (ODT) export allows seamless collaboration across
 | 
						||
organizational boundaries.  Markdown export lets you seamlessly
 | 
						||
collaborate with other developers.  Finally, iCal export can extract
 | 
						||
entries with deadlines or appointments to produce a file in the
 | 
						||
iCalendar format.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* The export dispatcher::       The main exporter interface
 | 
						||
* Export back-ends::            Built-in export formats
 | 
						||
* Export settings::             Generic export settings
 | 
						||
* ASCII/Latin-1/UTF-8 export::  Exporting to flat files with encoding
 | 
						||
* Beamer export::               Exporting as a Beamer presentation
 | 
						||
* HTML export::                 Exporting to HTML
 | 
						||
* LaTeX and PDF export::     Exporting to LaTeX, and processing to PDF
 | 
						||
* Markdown export::             Exporting to Markdown
 | 
						||
* OpenDocument Text export::    Exporting to OpenDocument Text
 | 
						||
* Org export::                  Exporting to Org
 | 
						||
* Texinfo export::              Exporting to Texinfo
 | 
						||
* iCalendar export::            Exporting to iCalendar
 | 
						||
* Other built-in back-ends::    Exporting to a man page
 | 
						||
* Export in foreign buffers::   Author tables and lists in Org syntax
 | 
						||
* Advanced configuration::      Fine-tuning the export output
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: The export dispatcher,  Next: Export back-ends,  Up: Exporting
 | 
						||
 | 
						||
12.1 The export dispatcher
 | 
						||
==========================
 | 
						||
 | 
						||
The main entry point for export related tasks is the dispatcher, a
 | 
						||
hierarchical menu from which it is possible to select an export format
 | 
						||
and toggle export options(1).
 | 
						||
 | 
						||
`C-c C-e'     (`org-export-dispatch')
 | 
						||
     Dispatch for export and publishing commands.  When called with a
 | 
						||
     `C-u' prefix argument, repeat the last export command on the
 | 
						||
     current buffer while preserving toggled options.  If the current
 | 
						||
     buffer hasn't changed and subtree export was activated, the
 | 
						||
     command will affect that same subtree.
 | 
						||
 | 
						||
   Normally the entire buffer is exported, but if there is an active
 | 
						||
region only that part of the buffer will be exported.
 | 
						||
 | 
						||
   Several export options (*note Export settings::) can be toggled from
 | 
						||
the export dispatcher with the following key combinations:
 | 
						||
 | 
						||
`C-a'
 | 
						||
     Toggle asynchronous export.  Asynchronous export uses an external
 | 
						||
     Emacs process that is configured with a specified initialization
 | 
						||
     file.
 | 
						||
 | 
						||
     While exporting asynchronously, the output is not displayed, but
 | 
						||
     stored in a place called "the export stack".  This stack can be
 | 
						||
     displayed by calling the dispatcher with a double `C-u' prefix
 | 
						||
     argument, or with `&' key from the dispatcher menu.
 | 
						||
 | 
						||
     To make this behavior the default, customize the variable
 | 
						||
     `org-export-in-background'.
 | 
						||
 | 
						||
`C-b'
 | 
						||
     Toggle body-only export.  Its effect depends on the back-end used.
 | 
						||
     Typically, if the back-end has a header section (like
 | 
						||
     `<head>...</head>' in the HTML back-end), a body-only export will
 | 
						||
     not include this header.
 | 
						||
 | 
						||
`C-s'
 | 
						||
     Toggle subtree export.  The top heading becomes the document title.
 | 
						||
 | 
						||
     You can change the default state of this option by setting
 | 
						||
     `org-export-initial-scope'.
 | 
						||
 | 
						||
`C-v'
 | 
						||
     Toggle visible-only export.  Only export the text that is currently
 | 
						||
     visible, i.e., not hidden by outline visibility in the buffer.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) It is also possible to use a less intrusive interface by setting
 | 
						||
`org-export-dispatch-use-expert-ui' to a non-`nil' value.  In that
 | 
						||
case, only a prompt is visible from the minibuffer.  From there one can
 | 
						||
still switch back to regular menu by pressing <?>.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Export back-ends,  Next: Export settings,  Prev: The export dispatcher,  Up: Exporting
 | 
						||
 | 
						||
12.2 Export back-ends
 | 
						||
=====================
 | 
						||
 | 
						||
An export back-end is a library that translates Org syntax into a
 | 
						||
foreign format.  An export format is not available until the proper
 | 
						||
back-end has been loaded.
 | 
						||
 | 
						||
   By default, the following four back-ends are loaded: `ascii',
 | 
						||
`html', `icalendar' and `latex'.  It is possible to add more (or remove
 | 
						||
some) by customizing `org-export-backends'.
 | 
						||
 | 
						||
   Built-in back-ends include:
 | 
						||
 | 
						||
   * ascii (ASCII format)
 | 
						||
 | 
						||
   * beamer (LaTeX Beamer format)
 | 
						||
 | 
						||
   * html (HTML format)
 | 
						||
 | 
						||
   * icalendar (iCalendar format)
 | 
						||
 | 
						||
   * latex (LaTeX format)
 | 
						||
 | 
						||
   * man (Man page format)
 | 
						||
 | 
						||
   * md (Markdown format)
 | 
						||
 | 
						||
   * odt (OpenDocument Text format)
 | 
						||
 | 
						||
   * org (Org format)
 | 
						||
 | 
						||
   * texinfo (Texinfo format)
 | 
						||
 | 
						||
   Other back-ends might be found in the `contrib/' directory (*note
 | 
						||
Installation::).
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Export settings,  Next: ASCII/Latin-1/UTF-8 export,  Prev: Export back-ends,  Up: Exporting
 | 
						||
 | 
						||
12.3 Export settings
 | 
						||
====================
 | 
						||
 | 
						||
Export options can be set: globally with variables; for an individual
 | 
						||
file by making variables buffer-local with in-buffer settings (*note
 | 
						||
In-buffer settings::), by setting individual keywords, or by specifying
 | 
						||
them in a compact form with the `#+OPTIONS' keyword; or for a tree by
 | 
						||
setting properties (*note Properties and columns::).  Options set at a
 | 
						||
specific level override options set at a more general level.
 | 
						||
 | 
						||
   In-buffer settings may appear anywhere in the file, either directly
 | 
						||
or indirectly through a file included using `#+SETUPFILE: filename'
 | 
						||
syntax.  Option keyword sets tailored to a particular back-end can be
 | 
						||
inserted from the export dispatcher (*note The export dispatcher::)
 | 
						||
using the `Insert template' command by pressing <#>.  To insert
 | 
						||
keywords individually, a good way to make sure the keyword is correct
 | 
						||
is to type `#+' and then to use `M-<TAB>' for completion.
 | 
						||
 | 
						||
   The export keywords available for every back-end, and their
 | 
						||
equivalent global variables, include:
 | 
						||
 | 
						||
`AUTHOR'
 | 
						||
     The document author (`user-full-name').
 | 
						||
 | 
						||
`CREATOR'
 | 
						||
     Entity responsible for output generation
 | 
						||
     (`org-export-creator-string').
 | 
						||
 | 
						||
`DATE'
 | 
						||
     A date or a time-stamp(1).
 | 
						||
 | 
						||
`EMAIL'
 | 
						||
     The email address (`user-mail-address').
 | 
						||
 | 
						||
`LANGUAGE'
 | 
						||
     The language used for translating some strings
 | 
						||
     (`org-export-default-language').  E.g., `#+LANGUAGE: fr' will tell
 | 
						||
     Org to translate _File_ (english) into _Fichier_ (french) in the
 | 
						||
     clocktable.
 | 
						||
 | 
						||
`SELECT_TAGS'
 | 
						||
     The tags that select a tree for export (`org-export-select-tags').
 | 
						||
     The default value is `:export:'.  Within a subtree tagged with
 | 
						||
     `:export:', you can still exclude entries with `:noexport:' (see
 | 
						||
     below).  When headlines are selectively exported with `:export:'
 | 
						||
     anywhere in a file, text before the first headline is ignored.
 | 
						||
 | 
						||
`EXCLUDE_TAGS'
 | 
						||
     The tags that exclude a tree from export
 | 
						||
     (`org-export-exclude-tags').  The default value is `:noexport:'.
 | 
						||
     Entries with the `:noexport:' tag will be unconditionally excluded
 | 
						||
     from the export, even if they have an `:export:' tag.  Code blocks
 | 
						||
     contained in excluded subtrees will still be executed during
 | 
						||
     export even though the subtree is not exported.
 | 
						||
 | 
						||
`TITLE'
 | 
						||
     The title to be shown.  You can use several such keywords for long
 | 
						||
     titles.
 | 
						||
 | 
						||
   The `#+OPTIONS' keyword is a compact(2) form that recognizes the
 | 
						||
following arguments:
 | 
						||
 | 
						||
`':'
 | 
						||
     Toggle smart quotes (`org-export-with-smart-quotes').
 | 
						||
 | 
						||
`*:'
 | 
						||
     Toggle emphasized text (`org-export-with-emphasize').
 | 
						||
 | 
						||
`-:'
 | 
						||
     Toggle conversion of special strings
 | 
						||
     (`org-export-with-special-strings').
 | 
						||
 | 
						||
`::'
 | 
						||
     Toggle fixed-width sections (`org-export-with-fixed-width').
 | 
						||
 | 
						||
`<:'
 | 
						||
     Toggle inclusion of any time/date active/inactive stamps
 | 
						||
     (`org-export-with-timestamps').
 | 
						||
 | 
						||
`\n:'
 | 
						||
     Toggle line-break-preservation (`org-export-preserve-breaks').
 | 
						||
 | 
						||
`^:'
 | 
						||
     Toggle TeX-like syntax for sub- and superscripts.  If you write
 | 
						||
     "^:{}", `a_{b}' will be interpreted, but the simple `a_b' will be
 | 
						||
     left as it is (`org-export-with-sub-superscripts').
 | 
						||
 | 
						||
`arch:'
 | 
						||
     Configure export of archived trees.  Can be set to `headline' to
 | 
						||
     only process the headline, skipping its contents
 | 
						||
     (`org-export-with-archived-trees').
 | 
						||
 | 
						||
`author:'
 | 
						||
     Toggle inclusion of author name into exported file
 | 
						||
     (`org-export-with-author').
 | 
						||
 | 
						||
`c:'
 | 
						||
     Toggle inclusion of CLOCK keywords (`org-export-with-clocks').
 | 
						||
 | 
						||
`creator:'
 | 
						||
     Toggle inclusion of creator info into exported file
 | 
						||
     (`org-export-with-creator').
 | 
						||
 | 
						||
`d:'
 | 
						||
     Toggle inclusion of drawers, or list drawers to include
 | 
						||
     (`org-export-with-drawers').
 | 
						||
 | 
						||
`date:'
 | 
						||
     Toggle inclusion of a date into exported file
 | 
						||
     (`org-export-with-date').
 | 
						||
 | 
						||
`e:'
 | 
						||
     Toggle inclusion of entities (`org-export-with-entities').
 | 
						||
 | 
						||
`email:'
 | 
						||
     Toggle inclusion of the author's e-mail into exported file
 | 
						||
     (`org-export-with-email').
 | 
						||
 | 
						||
`f:'
 | 
						||
     Toggle the inclusion of footnotes (`org-export-with-footnotes').
 | 
						||
 | 
						||
`H:'
 | 
						||
     Set the number of headline levels for export
 | 
						||
     (`org-export-headline-levels').  Below that level, headlines are
 | 
						||
     treated differently.  In most back-ends, they become list items.
 | 
						||
 | 
						||
`inline:'
 | 
						||
     Toggle inclusion of inlinetasks (`org-export-with-inlinetasks').
 | 
						||
 | 
						||
`num:'
 | 
						||
     Toggle section-numbers (`org-export-with-section-numbers').  It
 | 
						||
     can also be set to a number `n', so only headlines at that level
 | 
						||
     or above will be numbered.  Finally, irrespective of the level of
 | 
						||
     a specific headline, the numbering of it can be disabled by
 | 
						||
     setting the `UNNUMBERED' property to non-`nil'.  This also affects
 | 
						||
     subheadings.
 | 
						||
 | 
						||
`p:'
 | 
						||
     Toggle export of planning information (`org-export-with-planning').
 | 
						||
     "Planning information" is the line containing the `SCHEDULED:', the
 | 
						||
     `DEADLINE:' or the `CLOSED:' cookies or a combination of them.
 | 
						||
 | 
						||
`pri:'
 | 
						||
     Toggle inclusion of priority cookies (`org-export-with-priority').
 | 
						||
 | 
						||
`prop:'
 | 
						||
     Toggle inclusion of property drawers, or list properties to include
 | 
						||
     (`org-export-with-properties').
 | 
						||
 | 
						||
`stat:'
 | 
						||
     Toggle inclusion of statistics cookies
 | 
						||
     (`org-export-with-statistics-cookies').
 | 
						||
 | 
						||
`tags:'
 | 
						||
     Toggle inclusion of tags, may also be `not-in-toc'
 | 
						||
     (`org-export-with-tags').
 | 
						||
 | 
						||
`tasks:'
 | 
						||
     Toggle inclusion of tasks (TODO items), can be `nil' to remove all
 | 
						||
     tasks, `todo' to remove DONE tasks, or a list of keywords to keep
 | 
						||
     (`org-export-with-tasks').
 | 
						||
 | 
						||
`tex:'
 | 
						||
     Configure export of LaTeX fragments and environments.  It may be
 | 
						||
     set to `verbatim' (`org-export-with-latex').
 | 
						||
 | 
						||
`timestamp:'
 | 
						||
     Toggle inclusion of the creation time into exported file
 | 
						||
     (`org-export-time-stamp-file').
 | 
						||
 | 
						||
`title:'
 | 
						||
     Toggle inclusion of title (`org-export-with-title').
 | 
						||
 | 
						||
`toc:'
 | 
						||
     Toggle inclusion of the table of contents, or set the level limit
 | 
						||
     (`org-export-with-toc').
 | 
						||
 | 
						||
`todo:'
 | 
						||
     Toggle inclusion of TODO keywords into exported text
 | 
						||
     (`org-export-with-todo-keywords').
 | 
						||
 | 
						||
`|:'
 | 
						||
     Toggle inclusion of tables (`org-export-with-tables').
 | 
						||
 | 
						||
 | 
						||
   When exporting only a subtree, each of the previous keywords(3) can
 | 
						||
be overridden locally by special node properties.  These begin with
 | 
						||
`EXPORT_', followed by the name of the keyword they supplant.  For
 | 
						||
example, `DATE' and `OPTIONS' keywords become, respectively,
 | 
						||
`EXPORT_DATE' and `EXPORT_OPTIONS' properties.
 | 
						||
 | 
						||
   If `org-export-allow-bind-keywords' is non-`nil', Emacs variables
 | 
						||
can become buffer-local during export by using the BIND keyword.  Its
 | 
						||
syntax is `#+BIND: variable value'.  This is particularly useful for
 | 
						||
in-buffer settings that cannot be changed using specific keywords.
 | 
						||
 | 
						||
   The name of the output file to be generated is taken from the file
 | 
						||
associated to the buffer, when possible, or asked to you otherwise.
 | 
						||
For subtree export, you can also set `EXPORT_FILE_NAME' property.  In
 | 
						||
all cases, only the base name of the file is retained, and a back-end
 | 
						||
specific extension is added.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) The variable `org-export-date-timestamp-format' defines how this
 | 
						||
time-stamp will be exported.
 | 
						||
 | 
						||
   (2) If you want to configure many options this way, you can use
 | 
						||
several `#+OPTIONS' lines.
 | 
						||
 | 
						||
   (3) With the exception of `SETUPFILE'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: ASCII/Latin-1/UTF-8 export,  Next: Beamer export,  Prev: Export settings,  Up: Exporting
 | 
						||
 | 
						||
12.4 ASCII/Latin-1/UTF-8 export
 | 
						||
===============================
 | 
						||
 | 
						||
ASCII export produces a simple and very readable version of an Org mode
 | 
						||
file, containing only plain ASCII.  Latin-1 and UTF-8 export augment
 | 
						||
the file with special characters and symbols available in these
 | 
						||
encodings.
 | 
						||
 | 
						||
   Upon exporting, text is filled and justified, when appropriate,
 | 
						||
according the text width set in `org-ascii-text-width'.
 | 
						||
 | 
						||
   Links are exported in a footnote-like style, with the descriptive
 | 
						||
part in the text and the link in a note before the next heading.  See
 | 
						||
the variable `org-ascii-links-to-notes' for details and other options.
 | 
						||
 | 
						||
ASCII export commands
 | 
						||
---------------------
 | 
						||
 | 
						||
`C-c C-e t a/l/u     (`org-ascii-export-to-ascii')'
 | 
						||
     Export as an ASCII file.  For an Org file, `myfile.org', the ASCII
 | 
						||
     file will be `myfile.txt'.  The file will be overwritten without
 | 
						||
     warning.  When the original file is `myfile.txt', the resulting
 | 
						||
     file becomes `myfile.txt.txt' in order to prevent data loss.  
 | 
						||
 | 
						||
`C-c C-e t A/L/U     (`org-ascii-export-as-ascii')'
 | 
						||
     Export to a temporary buffer.  Do not create a file.
 | 
						||
 | 
						||
ASCII specific export settings
 | 
						||
------------------------------
 | 
						||
 | 
						||
ASCII export introduces a single of keywords, similar to the general
 | 
						||
options settings described in *note Export settings::.
 | 
						||
 | 
						||
`SUBTITLE'
 | 
						||
     The document subtitle.
 | 
						||
 | 
						||
Header and sectioning structure
 | 
						||
-------------------------------
 | 
						||
 | 
						||
In the exported version, the first three outline levels become
 | 
						||
headlines, defining a general document structure.  Additional levels
 | 
						||
are exported as lists.  The transition can also occur at a different
 | 
						||
level (*note Export settings::).
 | 
						||
 | 
						||
Quoting ASCII text
 | 
						||
------------------
 | 
						||
 | 
						||
You can insert text that will only appear when using `ASCII' back-end
 | 
						||
with the following constructs:
 | 
						||
 | 
						||
     Text @@ascii:and additional text@@ within a paragraph.
 | 
						||
 | 
						||
     #+ASCII: Some text
 | 
						||
 | 
						||
     #+BEGIN_ASCII
 | 
						||
     All lines in this block will appear only when using this back-end.
 | 
						||
     #+END_ASCII
 | 
						||
 | 
						||
ASCII specific attributes
 | 
						||
-------------------------
 | 
						||
 | 
						||
`ASCII' back-end only understands one attribute, `:width', which
 | 
						||
specifies the length, in characters, of a given horizontal rule.  It
 | 
						||
must be specified using an `ATTR_ASCII' line, directly preceding the
 | 
						||
rule.
 | 
						||
 | 
						||
     #+ATTR_ASCII: :width 10
 | 
						||
     -----
 | 
						||
 | 
						||
ASCII special blocks
 | 
						||
--------------------
 | 
						||
 | 
						||
In addition to `#+BEGIN_CENTER' blocks (*note Paragraphs::), it is
 | 
						||
possible to justify contents to the left or the right of the page with
 | 
						||
the following dedicated blocks.
 | 
						||
 | 
						||
     #+BEGIN_JUSTIFYLEFT
 | 
						||
     It's just a jump to the left...
 | 
						||
     #+END_JUSTIFYLEFT
 | 
						||
 | 
						||
     #+BEGIN_JUSTIFYRIGHT
 | 
						||
     ...and then a step to the right.
 | 
						||
     #+END_JUSTIFYRIGHT
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Beamer export,  Next: HTML export,  Prev: ASCII/Latin-1/UTF-8 export,  Up: Exporting
 | 
						||
 | 
						||
12.5 Beamer export
 | 
						||
==================
 | 
						||
 | 
						||
The LaTeX class _Beamer_ allows production of high quality
 | 
						||
presentations using LaTeX and pdf processing.  Org mode has special
 | 
						||
support for turning an Org mode file or tree into a Beamer presentation.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Beamer export commands:: How to export Beamer documents.
 | 
						||
* Beamer specific export settings:: Export settings for Beamer export.
 | 
						||
* Sectioning Frames and Blocks in Beamer:: Blocks and sections in Beamer.
 | 
						||
* Beamer specific syntax:: Syntax specific to Beamer.
 | 
						||
* Editing support:: Helper functions for Org Beamer export.
 | 
						||
* A Beamer Example:: An complete Beamer example.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Beamer export commands,  Next: Beamer specific export settings,  Up: Beamer export
 | 
						||
 | 
						||
12.5.1 Beamer export commands
 | 
						||
-----------------------------
 | 
						||
 | 
						||
`C-c C-e l b     (`org-beamer-export-to-latex')'
 | 
						||
     Export as a LaTeX file.  For an Org file `myfile.org', the LaTeX
 | 
						||
     file will be `myfile.tex'.  The file will be overwritten without
 | 
						||
     warning.  
 | 
						||
 | 
						||
`C-c C-e l B     (`org-beamer-export-as-latex')'
 | 
						||
     Export to a temporary buffer.  Do not create a file.  
 | 
						||
 | 
						||
`C-c C-e l P     (`org-beamer-export-to-pdf')'
 | 
						||
     Export as LaTeX and then process to PDF.
 | 
						||
 | 
						||
`C-c C-e l O'
 | 
						||
     Export as LaTeX and then process to PDF, then open the resulting
 | 
						||
     PDF file.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Beamer specific export settings,  Next: Sectioning Frames and Blocks in Beamer,  Prev: Beamer export commands,  Up: Beamer export
 | 
						||
 | 
						||
12.5.2 Beamer specific export settings
 | 
						||
--------------------------------------
 | 
						||
 | 
						||
Beamer export introduces a number of keywords, similar to the general
 | 
						||
options settings described in *note Export settings::.
 | 
						||
 | 
						||
`BEAMER_THEME'
 | 
						||
     The Beamer theme (`org-beamer-theme').  Options can be specified
 | 
						||
     via brackets, for example:
 | 
						||
          #+BEAMER_THEME: Rochester [height=20pt]
 | 
						||
 | 
						||
`BEAMER_FONT_THEME'
 | 
						||
     The Beamer font theme.
 | 
						||
 | 
						||
`BEAMER_INNER_THEME'
 | 
						||
     The Beamer inner theme.
 | 
						||
 | 
						||
`BEAMER_OUTER_THEME'
 | 
						||
     The Beamer outer theme.
 | 
						||
 | 
						||
`BEAMER_HEADER'
 | 
						||
     Arbitrary lines inserted into the preamble, just before the
 | 
						||
     `hyperref' settings.
 | 
						||
 | 
						||
`DESCRIPTION'
 | 
						||
     The document description.  By default these are inserted as
 | 
						||
     metadata using `hyperref'.  Document metadata can be configured via
 | 
						||
     `org-latex-hyperref-template'.  Description can also be typeset as
 | 
						||
     part of the front matter via `org-latex-title-command'.  You can
 | 
						||
     use several `#+DESCRIPTION' keywords if the description is is long.
 | 
						||
 | 
						||
`KEYWORDS'
 | 
						||
     The keywords defining the contents of the document.  By default
 | 
						||
     these are inserted as metadata using `hyperref'.  Document
 | 
						||
     metadata can be configured via `org-latex-hyperref-template'.
 | 
						||
     Description can also be typeset as part of the front matter via
 | 
						||
     `org-latex-title-command'.  You can use several `#+KEYWORDS' if
 | 
						||
     the description is is long.
 | 
						||
 | 
						||
`SUBTITLE'
 | 
						||
     The document subtitle.  This is typeset using the format string
 | 
						||
     `org-beamer-subtitle-format'.  It can also access via
 | 
						||
     `org-latex-hyperref-template' or typeset as part of the front
 | 
						||
     matter via `org-latex-title-command'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Sectioning Frames and Blocks in Beamer,  Next: Beamer specific syntax,  Prev: Beamer specific export settings,  Up: Beamer export
 | 
						||
 | 
						||
12.5.3 Sectioning, Frames and Blocks in Beamer
 | 
						||
----------------------------------------------
 | 
						||
 | 
						||
Any tree with not-too-deep level nesting should in principle be
 | 
						||
exportable as a Beamer presentation.  Headlines fall into three
 | 
						||
categories: sectioning elements, frames and blocks.
 | 
						||
 | 
						||
   - Headlines become frames when their level is equal to
 | 
						||
     `org-beamer-frame-level' or `H' value in an `OPTIONS' line (*note
 | 
						||
     Export settings::).
 | 
						||
 | 
						||
     Though, if a headline in the current tree has a `BEAMER_ENV'
 | 
						||
     property set to either to `frame' or `fullframe', its level
 | 
						||
     overrides the variable.  A `fullframe' is a frame with an empty
 | 
						||
     (ignored) title.
 | 
						||
 | 
						||
   - All frame's children become `block' environments.  Special block
 | 
						||
     types can be enforced by setting headline's `BEAMER_ENV'
 | 
						||
     property(1) to an appropriate value (see
 | 
						||
     `org-beamer-environments-default' for supported values and
 | 
						||
     `org-beamer-environments-extra' for adding more).
 | 
						||
 | 
						||
   - As a special case, if the `BEAMER_ENV' property is set to either
 | 
						||
     `appendix', `note', `noteNH' or `againframe', the headline will
 | 
						||
     become, respectively, an appendix, a note (within frame or between
 | 
						||
     frame, depending on its level), a note with its title ignored or an
 | 
						||
     `\againframe' command.  In the latter case, a `BEAMER_REF' property
 | 
						||
     is mandatory in order to refer to the frame being resumed, and
 | 
						||
     contents are ignored.
 | 
						||
 | 
						||
     Also, a headline with an `ignoreheading' environment will have its
 | 
						||
     contents only inserted in the output.  This special value is
 | 
						||
     useful to have data between frames, or to properly close a
 | 
						||
     `column' environment.
 | 
						||
 | 
						||
   Headlines also support `BEAMER_ACT' and `BEAMER_OPT' properties.
 | 
						||
The former is translated as an overlay/action specification, or a
 | 
						||
default overlay specification when enclosed within square brackets.
 | 
						||
The latter specifies options(2) for the current frame or block.  The
 | 
						||
export back-end will automatically wrap properties within angular or
 | 
						||
square brackets when appropriate.
 | 
						||
 | 
						||
   Moreover, headlines handle the `BEAMER_COL' property.  Its value
 | 
						||
should be a decimal number representing the width of the column as a
 | 
						||
fraction of the total text width.  If the headline has no specific
 | 
						||
environment, its title will be ignored and its contents will fill the
 | 
						||
column created.  Otherwise, the block will fill the whole column and
 | 
						||
the title will be preserved.  Two contiguous headlines with a non-`nil'
 | 
						||
`BEAMER_COL' value share the same `columns' LaTeX environment.  It will
 | 
						||
end before the next headline without such a property.  This environment
 | 
						||
is generated automatically.  Although, it can also be explicitly
 | 
						||
created, with a special `columns' value for `BEAMER_ENV' property (if
 | 
						||
it needs to be set up with some specific options, for example).
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) If this property is set, the entry will also get a
 | 
						||
`:B_environment:' tag to make this visible.  This tag has no semantic
 | 
						||
meaning, it is only a visual aid.
 | 
						||
 | 
						||
   (2) The `fragile' option is added automatically if it contains code
 | 
						||
that requires a verbatim environment, though.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Beamer specific syntax,  Next: Editing support,  Prev: Sectioning Frames and Blocks in Beamer,  Up: Beamer export
 | 
						||
 | 
						||
12.5.4 Beamer specific syntax
 | 
						||
-----------------------------
 | 
						||
 | 
						||
The Beamer back-end is an extension of the LaTeX back-end.  As such,
 | 
						||
all LaTeX specific syntax (e.g., `#+LATEX:' or `#+ATTR_LATEX:') is
 | 
						||
recognized.  See *note LaTeX and PDF export:: for more information.
 | 
						||
 | 
						||
   Table of contents generated from `toc:t' `OPTION' keyword are
 | 
						||
wrapped within a `frame' environment.  Those generated from a `TOC'
 | 
						||
keyword (*note Table of contents::) are not.  In that case, it is also
 | 
						||
possible to specify options, enclosed within square brackets.
 | 
						||
 | 
						||
     #+TOC: headlines [currentsection]
 | 
						||
 | 
						||
   Beamer specific code can be inserted with the following constructs:
 | 
						||
 | 
						||
     #+BEAMER: \pause
 | 
						||
 | 
						||
     #+BEGIN_BEAMER
 | 
						||
     All lines in this block will appear only when using this back-end.
 | 
						||
     #+END_BEAMER
 | 
						||
 | 
						||
     Text @@beamer:some code@@ within a paragraph.
 | 
						||
 | 
						||
   In particular, this last example can be used to add overlay
 | 
						||
specifications to objects whose type is among `bold', `item', `link',
 | 
						||
`radio-target' and `target', when the value is enclosed within angular
 | 
						||
brackets and put at the beginning the object.
 | 
						||
 | 
						||
     A *@@beamer:<2->@@useful* feature
 | 
						||
 | 
						||
   Eventually, every plain list has support for `:environment',
 | 
						||
`:overlay' and `:options' attributes through `ATTR_BEAMER' affiliated
 | 
						||
keyword.  The first one allows the use of a different environment, the
 | 
						||
second sets overlay specifications and the last one inserts optional
 | 
						||
arguments in current list environment.
 | 
						||
 | 
						||
     #+ATTR_BEAMER: :overlay +-
 | 
						||
     - item 1
 | 
						||
     - item 2
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Editing support,  Next: A Beamer Example,  Prev: Beamer specific syntax,  Up: Beamer export
 | 
						||
 | 
						||
12.5.5 Editing support
 | 
						||
----------------------
 | 
						||
 | 
						||
You can turn on a special minor mode `org-beamer-mode' for faster
 | 
						||
editing with:
 | 
						||
 | 
						||
     #+STARTUP: beamer
 | 
						||
 | 
						||
`C-c C-b     (`org-beamer-select-environment')'
 | 
						||
     In `org-beamer-mode', this key offers fast selection of a Beamer
 | 
						||
     environment or the `BEAMER_COL' property.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: A Beamer Example,  Prev: Editing support,  Up: Beamer export
 | 
						||
 | 
						||
12.5.6 A Beamer example
 | 
						||
-----------------------
 | 
						||
 | 
						||
Here is a simple example Org document that is intended for Beamer
 | 
						||
export.
 | 
						||
 | 
						||
     #+TITLE: Example Presentation
 | 
						||
     #+AUTHOR: Carsten Dominik
 | 
						||
     #+OPTIONS: H:2 toc:t num:t
 | 
						||
     #+LATEX_CLASS: beamer
 | 
						||
     #+LATEX_CLASS_OPTIONS: [presentation]
 | 
						||
     #+BEAMER_THEME: Madrid
 | 
						||
     #+COLUMNS: %45ITEM %10BEAMER_ENV(Env) %10BEAMER_ACT(Act) %4BEAMER_COL(Col) %8BEAMER_OPT(Opt)
 | 
						||
 | 
						||
     * This is the first structural section
 | 
						||
 | 
						||
     ** Frame 1
 | 
						||
     *** Thanks to Eric Fraga                                           :B_block:
 | 
						||
         :PROPERTIES:
 | 
						||
         :BEAMER_COL: 0.48
 | 
						||
         :BEAMER_ENV: block
 | 
						||
         :END:
 | 
						||
         for the first viable Beamer setup in Org
 | 
						||
     *** Thanks to everyone else                                        :B_block:
 | 
						||
         :PROPERTIES:
 | 
						||
         :BEAMER_COL: 0.48
 | 
						||
         :BEAMER_ACT: <2->
 | 
						||
         :BEAMER_ENV: block
 | 
						||
         :END:
 | 
						||
         for contributing to the discussion
 | 
						||
     **** This will be formatted as a beamer note                       :B_note:
 | 
						||
          :PROPERTIES:
 | 
						||
          :BEAMER_env: note
 | 
						||
          :END:
 | 
						||
     ** Frame 2 (where we will not use columns)
 | 
						||
     *** Request
 | 
						||
         Please test this stuff!
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: HTML export,  Next: LaTeX and PDF export,  Prev: Beamer export,  Up: Exporting
 | 
						||
 | 
						||
12.6 HTML export
 | 
						||
================
 | 
						||
 | 
						||
Org mode contains an HTML (XHTML 1.0 strict) exporter with extensive
 | 
						||
HTML formatting, in ways similar to John Gruber's _markdown_ language,
 | 
						||
but with additional support for tables.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* HTML Export commands::        How to invoke HTML export
 | 
						||
* HTML Specific export settings:: Export settings for HTML export.
 | 
						||
* HTML doctypes::               Org can export to various (X)HTML flavors
 | 
						||
* HTML preamble and postamble::  How to insert a preamble and a postamble
 | 
						||
* Quoting HTML tags::           Using direct HTML in Org mode
 | 
						||
* Links in HTML export::        How links will be interpreted and formatted
 | 
						||
* Tables in HTML export::       How to modify the formatting of tables
 | 
						||
* Images in HTML export::       How to insert figures into HTML output
 | 
						||
* Math formatting in HTML export::  Beautiful math also on the web
 | 
						||
* Text areas in HTML export::   An alternative way to show an example
 | 
						||
* CSS support::                 Changing the appearance of the output
 | 
						||
* JavaScript support::          Info and Folding in a web browser
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: HTML Export commands,  Next: HTML Specific export settings,  Up: HTML export
 | 
						||
 | 
						||
12.6.1 HTML export commands
 | 
						||
---------------------------
 | 
						||
 | 
						||
`C-c C-e h h     (`org-html-export-to-html')'
 | 
						||
     Export as an HTML file.  For an Org file `myfile.org', the HTML
 | 
						||
     file will be `myfile.html'.  The file will be overwritten without
 | 
						||
     warning.  `C-c C-e h o' Export as an HTML file and immediately
 | 
						||
     open it with a browser.  
 | 
						||
 | 
						||
`C-c C-e h H     (`org-html-export-as-html')'
 | 
						||
     Export to a temporary buffer.  Do not create a file.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: HTML Specific export settings,  Next: HTML doctypes,  Prev: HTML Export commands,  Up: HTML export
 | 
						||
 | 
						||
12.6.2 HTML Specific export settings
 | 
						||
------------------------------------
 | 
						||
 | 
						||
HTML export introduces a number of keywords, similar to the general
 | 
						||
options settings described in *note Export settings::.
 | 
						||
 | 
						||
`DESCRIPTION'
 | 
						||
     The document description.  This description is inserted as a HTML
 | 
						||
     meta tag.  You can use several such keywords if the list is long.
 | 
						||
 | 
						||
`HTML_DOCTYPE'
 | 
						||
     The document type, e.g. HTML5, (`org-html-doctype').
 | 
						||
 | 
						||
`HTML_CONTAINER'
 | 
						||
     The container, e.g. `div', used to wrap sections and elements
 | 
						||
     (`org-html-container-element').
 | 
						||
 | 
						||
`HTML_LINK_HOME'
 | 
						||
     The home link URL (`org-html-link-home').
 | 
						||
 | 
						||
`HTML_LINK_UP'
 | 
						||
     The up link URL (`org-html-link-up').
 | 
						||
 | 
						||
`HTML_MATHJAX'
 | 
						||
     Options for the MathJax (`org-html-mathjax-options').  MathJax is
 | 
						||
     used to typeset LaTeX math in HTML documents.  *note Math
 | 
						||
     formatting in HTML export:: contains an example.
 | 
						||
 | 
						||
`HTML_HEAD'
 | 
						||
     Arbitrary lines appended to the end of the head of the document
 | 
						||
     (`org-html-head').
 | 
						||
 | 
						||
`HTML_HEAD_EXTRA'
 | 
						||
     Arbitrary lines appended to the end of the header of the document
 | 
						||
     (`org-html-head-extra').
 | 
						||
 | 
						||
`KEYWORDS'
 | 
						||
     The keywords defining the contents of the document.  This
 | 
						||
     description is inserted as a HTML meta tag.  You can use several
 | 
						||
     such keywords if the list is long.
 | 
						||
 | 
						||
`LATEX_HEADER'
 | 
						||
     Arbitrary lines appended to the preamble used when transcoding
 | 
						||
     LaTeX fragments to images.  See *note Math formatting in HTML
 | 
						||
     export:: for details.
 | 
						||
 | 
						||
`SUBTITLE'
 | 
						||
     The document subtitle.  The formatting depends on whether HTML5 in
 | 
						||
     used and on the `subtitle' CSS class.
 | 
						||
 | 
						||
   These keywords are treated in details in the following sections.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: HTML doctypes,  Next: HTML preamble and postamble,  Prev: HTML Specific export settings,  Up: HTML export
 | 
						||
 | 
						||
12.6.3 HTML doctypes
 | 
						||
--------------------
 | 
						||
 | 
						||
Org can export to various (X)HTML flavors.
 | 
						||
 | 
						||
   Setting the variable `org-html-doctype' allows you to export to
 | 
						||
different (X)HTML variants.  The exported HTML will be adjusted
 | 
						||
according to the syntax requirements of that variant.  You can either
 | 
						||
set this variable to a doctype string directly, in which case the
 | 
						||
exporter will try to adjust the syntax automatically, or you can use a
 | 
						||
ready-made doctype.  The ready-made options are:
 | 
						||
 | 
						||
   * "html4-strict"
 | 
						||
 | 
						||
   * "html4-transitional"
 | 
						||
 | 
						||
   * "html4-frameset"
 | 
						||
 | 
						||
   * "xhtml-strict"
 | 
						||
 | 
						||
   * "xhtml-transitional"
 | 
						||
 | 
						||
   * "xhtml-frameset"
 | 
						||
 | 
						||
   * "xhtml-11"
 | 
						||
 | 
						||
   * "html5"
 | 
						||
 | 
						||
   * "xhtml5"
 | 
						||
 | 
						||
   See the variable `org-html-doctype-alist' for details.  The default
 | 
						||
is "xhtml-strict".
 | 
						||
 | 
						||
Fancy HTML5 export
 | 
						||
..................
 | 
						||
 | 
						||
HTML5 introduces several new element types.  By default, Org will not
 | 
						||
make use of these element types, but you can set `org-html-html5-fancy'
 | 
						||
to `t' (or set `html5-fancy' item in an `OPTIONS' line), to enable a
 | 
						||
few new block-level elements.  These are created using arbitrary
 | 
						||
#+BEGIN and #+END blocks. For instance:
 | 
						||
 | 
						||
     #+BEGIN_aside
 | 
						||
     Lorem ipsum
 | 
						||
     #+END_aside
 | 
						||
 | 
						||
   Will export to:
 | 
						||
 | 
						||
     <aside>
 | 
						||
       <p>Lorem ipsum</p>
 | 
						||
     </aside>
 | 
						||
 | 
						||
   While this:
 | 
						||
 | 
						||
     #+ATTR_HTML: :controls controls :width 350
 | 
						||
     #+BEGIN_video
 | 
						||
     #+HTML: <source src="movie.mp4" type="video/mp4">
 | 
						||
     #+HTML: <source src="movie.ogg" type="video/ogg">
 | 
						||
     Your browser does not support the video tag.
 | 
						||
     #+END_video
 | 
						||
 | 
						||
   Becomes:
 | 
						||
 | 
						||
     <video controls="controls" width="350">
 | 
						||
       <source src="movie.mp4" type="video/mp4">
 | 
						||
       <source src="movie.ogg" type="video/ogg">
 | 
						||
       <p>Your browser does not support the video tag.</p>
 | 
						||
     </video>
 | 
						||
 | 
						||
   Special blocks that do not correspond to HTML5 elements (see
 | 
						||
`org-html-html5-elements') will revert to the usual behavior, i.e.,
 | 
						||
`#+BEGIN_lederhosen' will still export to `<div class="lederhosen">'.
 | 
						||
 | 
						||
   Headlines cannot appear within special blocks.  To wrap a headline
 | 
						||
and its contents in e.g., `<section>' or `<article>' tags, set the
 | 
						||
`HTML_CONTAINER' property on the headline itself.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: HTML preamble and postamble,  Next: Quoting HTML tags,  Prev: HTML doctypes,  Up: HTML export
 | 
						||
 | 
						||
12.6.4 HTML preamble and postamble
 | 
						||
----------------------------------
 | 
						||
 | 
						||
The HTML exporter lets you define a preamble and a postamble.
 | 
						||
 | 
						||
   The default value for `org-html-preamble' is `t', which means that
 | 
						||
the preamble is inserted depending on the relevant format string in
 | 
						||
`org-html-preamble-format'.
 | 
						||
 | 
						||
   Setting `org-html-preamble' to a string will override the default
 | 
						||
format string.  If you set it to a function, it will insert the output
 | 
						||
of the function, which must be a string.  Setting to `nil' will not
 | 
						||
insert any preamble.
 | 
						||
 | 
						||
   The default value for `org-html-postamble' is `'auto', which means
 | 
						||
that the HTML exporter will look for information about the author, the
 | 
						||
email, the creator and the date, and build the postamble from these
 | 
						||
values.  Setting `org-html-postamble' to `t' will insert the postamble
 | 
						||
from the relevant format string found in `org-html-postamble-format'.
 | 
						||
Setting it to `nil' will not insert any postamble.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Quoting HTML tags,  Next: Links in HTML export,  Prev: HTML preamble and postamble,  Up: HTML export
 | 
						||
 | 
						||
12.6.5 Quoting HTML tags
 | 
						||
------------------------
 | 
						||
 | 
						||
Plain `<' and `>' are always transformed to `<' and `>' in HTML
 | 
						||
export.  If you want to include raw HTML code, which should only appear
 | 
						||
in HTML export, mark it with `@@html:' as in `@@html:<b>@@bold
 | 
						||
text@@html:</b>@@'.  For more extensive HTML that should be copied
 | 
						||
verbatim to the exported file use either
 | 
						||
 | 
						||
     #+HTML: Literal HTML code for export
 | 
						||
 | 
						||
or 
 | 
						||
 | 
						||
     #+BEGIN_HTML
 | 
						||
     All lines between these markers are exported literally
 | 
						||
     #+END_HTML
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Links in HTML export,  Next: Tables in HTML export,  Prev: Quoting HTML tags,  Up: HTML export
 | 
						||
 | 
						||
12.6.6 Links in HTML export
 | 
						||
---------------------------
 | 
						||
 | 
						||
Internal links (*note Internal links::) will continue to work in HTML.
 | 
						||
This includes automatic links created by radio targets (*note Radio
 | 
						||
targets::).  Links to external files will still work if the target file
 | 
						||
is on the same relative path as the published Org file.  Links to other
 | 
						||
`.org' files will be translated into HTML links under the assumption
 | 
						||
that an HTML version also exists of the linked file, at the same
 | 
						||
relative path; setting `org-html-link-org-files-as-html' to `nil'
 | 
						||
disables this translation.  `id:' links can then be used to jump to
 | 
						||
specific entries across files.  For information related to linking
 | 
						||
files while publishing them to a publishing directory see *note
 | 
						||
Publishing links::.
 | 
						||
 | 
						||
   If you want to specify attributes for links, you can do so using a
 | 
						||
special `#+ATTR_HTML' line to define attributes that will be added to
 | 
						||
the `<a>' or `<img>' tags.  Here is an example that sets `title' and
 | 
						||
`style' attributes for a link:
 | 
						||
 | 
						||
     #+ATTR_HTML: :title The Org mode homepage :style color:red;
 | 
						||
     [[http://orgmode.org]]
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Tables in HTML export,  Next: Images in HTML export,  Prev: Links in HTML export,  Up: HTML export
 | 
						||
 | 
						||
12.6.7 Tables in HTML export
 | 
						||
----------------------------
 | 
						||
 | 
						||
Org mode tables are exported to HTML using the table attributes defined
 | 
						||
in `org-html-table-default-attributes'.  The default setting makes
 | 
						||
tables without cell borders and frame.  If you would like to change
 | 
						||
this for individual tables, place something like the following before
 | 
						||
the table:
 | 
						||
 | 
						||
     #+CAPTION: This is a table with lines around and between cells
 | 
						||
     #+ATTR_HTML: :border 2 :rules all :frame border
 | 
						||
 | 
						||
   You can also group columns in the HTML output (*note Column
 | 
						||
groups::).
 | 
						||
 | 
						||
   Below is a list of options for customizing tables HTML export.
 | 
						||
 | 
						||
`org-html-table-align-individual-fields'
 | 
						||
     Non-`nil' means attach style attributes for alignment to each
 | 
						||
     table field.
 | 
						||
 | 
						||
`org-html-table-caption-above'
 | 
						||
     When non-`nil', place caption string at the beginning of the table.
 | 
						||
 | 
						||
`org-html-table-data-tags'
 | 
						||
     The opening and ending tags for table data fields.
 | 
						||
 | 
						||
`org-html-table-default-attributes'
 | 
						||
     Default attributes and values which will be used in table tags.
 | 
						||
 | 
						||
`org-html-table-header-tags'
 | 
						||
     The opening and ending tags for table header fields.
 | 
						||
 | 
						||
`org-html-table-row-tags'
 | 
						||
     The opening and ending tags for table rows.
 | 
						||
 | 
						||
`org-html-table-use-header-tags-for-first-column'
 | 
						||
     Non-`nil' means format column one in tables with header tags.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Images in HTML export,  Next: Math formatting in HTML export,  Prev: Tables in HTML export,  Up: HTML export
 | 
						||
 | 
						||
12.6.8 Images in HTML export
 | 
						||
----------------------------
 | 
						||
 | 
						||
HTML export can inline images given as links in the Org file, and it
 | 
						||
can make an image the clickable part of a link.  By default(1), images
 | 
						||
are inlined if a link does not have a description.  So
 | 
						||
`[[file:myimg.jpg]]' will be inlined, while `[[file:myimg.jpg][the
 | 
						||
image]]' will just produce a link `the image' that points to the image.
 | 
						||
If the description part itself is a `file:' link or a `http:' URL
 | 
						||
pointing to an image, this image will be inlined and activated so that
 | 
						||
clicking on the image will activate the link.  For example, to include
 | 
						||
a thumbnail that will link to a high resolution version of the image,
 | 
						||
you could use:
 | 
						||
 | 
						||
     [[file:highres.jpg][file:thumb.jpg]]
 | 
						||
 | 
						||
   If you need to add attributes to an inlined image, use a
 | 
						||
`#+ATTR_HTML'.  In the example below we specify the `alt' and `title'
 | 
						||
attributes to support text viewers and accessibility, and align it to
 | 
						||
the right.
 | 
						||
 | 
						||
     #+CAPTION: A black cat stalking a spider
 | 
						||
     #+ATTR_HTML: :alt cat/spider image :title Action! :align right
 | 
						||
     [[./img/a.jpg]]
 | 
						||
 | 
						||
You could use `http' addresses just as well.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) But see the variable `org-html-inline-images'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Math formatting in HTML export,  Next: Text areas in HTML export,  Prev: Images in HTML export,  Up: HTML export
 | 
						||
 | 
						||
12.6.9 Math formatting in HTML export
 | 
						||
-------------------------------------
 | 
						||
 | 
						||
LaTeX math snippets (*note LaTeX fragments::) can be displayed in two
 | 
						||
different ways on HTML pages.  The default is to use MathJax
 | 
						||
(http://www.mathjax.org) which should work out of the box with Org(1).
 | 
						||
Some MathJax display options can be configured via
 | 
						||
`org-html-mathjax-options', or in the buffer.  For example, with the
 | 
						||
following settings,
 | 
						||
     #+HTML_MATHJAX: align: left indent: 5em tagside: left font: Neo-Euler
 | 
						||
   equation labels will be displayed on the left marign and equations
 | 
						||
will be five ems from the left margin.
 | 
						||
 | 
						||
See the docstring of `org-html-mathjax-options' for all supported
 | 
						||
variables.  The MathJax template can be configure via
 | 
						||
`org-html-mathjax-template'.
 | 
						||
 | 
						||
   If you prefer, you can also request that LaTeX fragments are
 | 
						||
processed into small images that will be inserted into the browser
 | 
						||
page.  Before the availability of MathJax, this was the default method
 | 
						||
for Org files.  This method requires that the `dvipng' program or
 | 
						||
`imagemagick' suite is available on your system.  You can still get
 | 
						||
this processing with
 | 
						||
 | 
						||
     #+OPTIONS: tex:dvipng
 | 
						||
 | 
						||
   or:
 | 
						||
 | 
						||
     #+OPTIONS: tex:imagemagick
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) By default Org loads MathJax from MathJax.org
 | 
						||
(http://docs.mathjax.org/en/latest/start.html#using-the-mathjax-content-delivery-network-cdn).
 | 
						||
A link to the terms of service of the MathJax CDN can be found in the
 | 
						||
docstring of `org-html-mathjax-options'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Text areas in HTML export,  Next: CSS support,  Prev: Math formatting in HTML export,  Up: HTML export
 | 
						||
 | 
						||
12.6.10 Text areas in HTML export
 | 
						||
---------------------------------
 | 
						||
 | 
						||
An alternative way to publish literal code examples in HTML is to use
 | 
						||
text areas, where the example can even be edited before pasting it into
 | 
						||
an application.  It is triggered by `:textarea' attribute at an
 | 
						||
`example' or `src' block.
 | 
						||
 | 
						||
   You may also use `:height' and `:width' attributes to specify the
 | 
						||
height and width of the text area, which default to the number of lines
 | 
						||
in the example, and 80, respectively.  For example
 | 
						||
 | 
						||
     #+ATTR_HTML: :textarea t :width 40
 | 
						||
     #+BEGIN_EXAMPLE
 | 
						||
       (defun org-xor (a b)
 | 
						||
          "Exclusive or."
 | 
						||
          (if a (not b) b))
 | 
						||
     #+END_EXAMPLE
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: CSS support,  Next: JavaScript support,  Prev: Text areas in HTML export,  Up: HTML export
 | 
						||
 | 
						||
12.6.11 CSS support
 | 
						||
-------------------
 | 
						||
 | 
						||
You can modify the CSS style definitions for the exported file.  The
 | 
						||
HTML exporter assigns the following special CSS classes(1) to
 | 
						||
appropriate parts of the document--your style specifications may change
 | 
						||
these, in addition to any of the standard classes like for headlines,
 | 
						||
tables, etc.
 | 
						||
     p.author            author information, including email
 | 
						||
     p.date              publishing date
 | 
						||
     p.creator           creator info, about org mode version
 | 
						||
     .title              document title
 | 
						||
     .subtitle           document subtitle
 | 
						||
     .todo               TODO keywords, all not-done states
 | 
						||
     .done               the DONE keywords, all states that count as done
 | 
						||
     .WAITING            each TODO keyword also uses a class named after itself
 | 
						||
     .timestamp          timestamp
 | 
						||
     .timestamp-kwd      keyword associated with a timestamp, like SCHEDULED
 | 
						||
     .timestamp-wrapper  span around keyword plus timestamp
 | 
						||
     .tag                tag in a headline
 | 
						||
     ._HOME              each tag uses itself as a class, "@" replaced by "_"
 | 
						||
     .target             target for links
 | 
						||
     .linenr             the line number in a code example
 | 
						||
     .code-highlighted   for highlighting referenced code lines
 | 
						||
     div.outline-N       div for outline level N (headline plus text))
 | 
						||
     div.outline-text-N  extra div for text at outline level N
 | 
						||
     .section-number-N   section number in headlines, different for each level
 | 
						||
     .figure-number      label like "Figure 1:"
 | 
						||
     .table-number       label like "Table 1:"
 | 
						||
     .listing-number     label like "Listing 1:"
 | 
						||
     div.figure          how to format an inlined image
 | 
						||
     pre.src             formatted source code
 | 
						||
     pre.example         normal example
 | 
						||
     p.verse             verse paragraph
 | 
						||
     div.footnotes       footnote section headline
 | 
						||
     p.footnote          footnote definition paragraph, containing a footnote
 | 
						||
     .footref            a footnote reference number (always a <sup>)
 | 
						||
     .footnum            footnote number in footnote definition (always <sup>)
 | 
						||
 | 
						||
   Each exported file contains a compact default style that defines
 | 
						||
these classes in a basic way(2).  You may overwrite these settings, or
 | 
						||
add to them by using the variables `org-html-head' and
 | 
						||
`org-html-head-extra'.  You can override the global values of these
 | 
						||
variables for each file by using these keywords:
 | 
						||
 | 
						||
     #+HTML_HEAD: <link rel="stylesheet" type="text/css" href="style1.css" />
 | 
						||
     #+HTML_HEAD_EXTRA: <link rel="alternate stylesheet" type="text/css" href="style2.css" />
 | 
						||
 | 
						||
For longer style definitions, you can use several such lines.  You
 | 
						||
could also directly write a `<style>' `</style>' section in this way,
 | 
						||
without referring to an external file.
 | 
						||
 | 
						||
   In order to add styles to a subtree, use the `:HTML_CONTAINER_CLASS:'
 | 
						||
property to assign a class to the tree.  In order to specify CSS styles
 | 
						||
for a particular headline, you can use the id specified in a
 | 
						||
`:CUSTOM_ID:' property.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) If the classes on TODO keywords and tags lead to conflicts, use
 | 
						||
the variables `org-html-todo-kwd-class-prefix' and
 | 
						||
`org-html-tag-class-prefix' to make them unique.
 | 
						||
 | 
						||
   (2) This style is defined in the constant `org-html-style-default',
 | 
						||
which you should not modify.  To turn inclusion of these defaults off,
 | 
						||
customize `org-html-head-include-default-style' or set `html-style' to
 | 
						||
`nil' in an `OPTIONS' line.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: JavaScript support,  Prev: CSS support,  Up: HTML export
 | 
						||
 | 
						||
12.6.12 JavaScript supported display of web pages
 | 
						||
-------------------------------------------------
 | 
						||
 | 
						||
Sebastian Rose has written a JavaScript program especially designed to
 | 
						||
enhance the web viewing experience of HTML files created with Org.  This
 | 
						||
program allows you to view large files in two different ways.  The
 | 
						||
first one is an _Info_-like mode where each section is displayed
 | 
						||
separately and navigation can be done with the `n' and `p' keys (and
 | 
						||
some other keys as well, press `?' for an overview of the available
 | 
						||
keys).  The second view type is a _folding_ view much like Org provides
 | 
						||
inside Emacs.  The script is available at
 | 
						||
`http://orgmode.org/org-info.js' and you can find the documentation for
 | 
						||
it at `http://orgmode.org/worg/code/org-info-js/'.  We host the script
 | 
						||
at our site, but if you use it a lot, you might not want to be
 | 
						||
dependent on `http://orgmode.org' and prefer to install a local copy on
 | 
						||
your own web server.
 | 
						||
 | 
						||
   All it then takes to use this program is adding a single line to the
 | 
						||
Org file:
 | 
						||
 | 
						||
     #+INFOJS_OPT: view:info toc:nil
 | 
						||
 | 
						||
If this line is found, the HTML header will automatically contain the
 | 
						||
code needed to invoke the script.  Using the line above, you can set
 | 
						||
the following viewing options:
 | 
						||
 | 
						||
     path:    The path to the script.  The default is to grab the script from
 | 
						||
              `http://orgmode.org/org-info.js', but you might want to have
 | 
						||
              a local copy and use a path like `../scripts/org-info.js'.
 | 
						||
     view:    Initial view when the website is first shown.  Possible values are:
 | 
						||
              info      Info-like interface with one section per page.
 | 
						||
              overview  Folding interface, initially showing only top-level.
 | 
						||
              content   Folding interface, starting with all headlines visible.
 | 
						||
              showall   Folding interface, all headlines and text visible.
 | 
						||
     sdepth:  Maximum headline level that will still become an independent
 | 
						||
              section for info and folding modes.  The default is taken from
 | 
						||
              `org-export-headline-levels' (= the `H' switch in `#+OPTIONS').
 | 
						||
              If this is smaller than in `org-export-headline-levels', each
 | 
						||
              info/folding section can still contain child headlines.
 | 
						||
     toc:     Should the table of contents _initially_ be visible?
 | 
						||
              Even when `nil', you can always get to the "toc" with `i'.
 | 
						||
     tdepth:  The depth of the table of contents.  The defaults are taken from
 | 
						||
              the variables `org-export-headline-levels' and `org-export-with-toc'.
 | 
						||
     ftoc:    Does the CSS of the page specify a fixed position for the "toc"?
 | 
						||
              If yes, the toc will never be displayed as a section.
 | 
						||
     ltoc:    Should there be short contents (children) in each section?
 | 
						||
              Make this `above' if the section should be above initial text.
 | 
						||
     mouse:   Headings are highlighted when the mouse is over them.  Should be
 | 
						||
              `underline' (default) or a background color like `#cccccc'.
 | 
						||
     buttons: Should view-toggle buttons be everywhere?  When `nil' (the
 | 
						||
              default), only one such button will be present.
 | 
						||
   You can choose default values for these options by customizing the
 | 
						||
variable `org-html-infojs-options'.  If you always want to apply the
 | 
						||
script to your pages, configure the variable `org-html-use-infojs'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: LaTeX and PDF export,  Next: Markdown export,  Prev: HTML export,  Up: Exporting
 | 
						||
 | 
						||
12.7 LaTeX and PDF export
 | 
						||
=========================
 | 
						||
 | 
						||
LaTeX export can produce an arbitrarily complex LaTeX document of any
 | 
						||
standard or custom document class.  With further processing(1), which
 | 
						||
the LaTeX exporter is able to control, this back-end is able to produce
 | 
						||
PDF output.  Because the LaTeX exporter can be configured to use the
 | 
						||
`hyperref' package, the default setup produces fully-linked PDF output.
 | 
						||
 | 
						||
   As in LaTeX, blank lines are meaningful for this back-end: a
 | 
						||
paragraph will not be started if two contiguous syntactical elements
 | 
						||
are not separated by an empty line.
 | 
						||
 | 
						||
   This back-end also offers enhanced support for footnotes.  Thus, it
 | 
						||
handles nested footnotes, footnotes in tables and footnotes in a list
 | 
						||
item's description.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* LaTeX export commands::    How to export to LaTeX and PDF
 | 
						||
* LaTeX specific export settings::  Export settings for LaTeX
 | 
						||
* Header and sectioning::       Setting up the export file structure
 | 
						||
* Quoting LaTeX code::       Incorporating literal LaTeX code
 | 
						||
* LaTeX specific attributes::  Controlling LaTeX output
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) The default LaTeX output is designed for processing with
 | 
						||
`pdftex' or `latex'.  The LaTeX exporter can be configured to support
 | 
						||
alternative TeX engines, see see `org-latex-pdf-process', and
 | 
						||
alternative packages, see `org-latex-default-packages-alist' and
 | 
						||
`org-latex-packages-alist'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: LaTeX export commands,  Next: LaTeX specific export settings,  Up: LaTeX and PDF export
 | 
						||
 | 
						||
12.7.1 LaTeX export commands
 | 
						||
----------------------------
 | 
						||
 | 
						||
`C-c C-e l l     (`org-latex-export-to-latex')'
 | 
						||
     Export as a LaTeX file.  For an Org file `myfile.org', the LaTeX
 | 
						||
     file will be `myfile.tex'.  The file will be overwritten without
 | 
						||
     warning.  
 | 
						||
 | 
						||
`C-c C-e l L     (`org-latex-export-as-latex')'
 | 
						||
     Export to a temporary buffer.  Do not create a file.  
 | 
						||
 | 
						||
`C-c C-e l p     (`org-latex-export-to-pdf')'
 | 
						||
     Export as LaTeX and then process to PDF.
 | 
						||
 | 
						||
`C-c C-e l o'
 | 
						||
     Export as LaTeX and then process to PDF, then open the resulting
 | 
						||
     PDF file.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: LaTeX specific export settings,  Next: Header and sectioning,  Prev: LaTeX export commands,  Up: LaTeX and PDF export
 | 
						||
 | 
						||
12.7.2 LaTeX specific export settings
 | 
						||
-------------------------------------
 | 
						||
 | 
						||
The LaTeX exporter introduces a number of keywords, similar to the
 | 
						||
general options settings described in *note Export settings::.
 | 
						||
 | 
						||
`DESCRIPTION'
 | 
						||
     The document description.  By default these are inserted as
 | 
						||
     metadata using `hyperref'.  Document metadata can be configured via
 | 
						||
     `org-latex-hyperref-template'.  Description can also be typeset as
 | 
						||
     part of the front matter via `org-latex-title-command'.  You can
 | 
						||
     use several `#+DESCRIPTION' keywords if the description is is long.
 | 
						||
 | 
						||
`LATEX_CLASS'
 | 
						||
     The predefined preamble and headline level mapping to use
 | 
						||
     (`org-latex-default-class').  Must be an element in
 | 
						||
     `org-latex-classes'.
 | 
						||
 | 
						||
`LATEX_CLASS_OPTIONS'
 | 
						||
     Options given to the LaTeX document class.
 | 
						||
 | 
						||
`LATEX_HEADER'
 | 
						||
     Arbitrary lines added to the preamble of the document, before the
 | 
						||
     `hyperref' settings.  The location can be controlled via
 | 
						||
     `org-latex-classes'.
 | 
						||
 | 
						||
`LATEX_HEADER_EXTRA'
 | 
						||
     Arbitrary lines added to the preamble of the document, before the
 | 
						||
     `hyperref' settings.  The location can be controlled via
 | 
						||
     `org-latex-classes'.
 | 
						||
 | 
						||
`KEYWORDS'
 | 
						||
     The keywords defining the contents of the document.  By default
 | 
						||
     these are inserted as metadata using `hyperref'.  Document
 | 
						||
     metadata can be configured via `org-latex-hyperref-template'.
 | 
						||
     Description can also be typeset as part of the front matter via
 | 
						||
     `org-latex-title-command'.  You can use several `#+KEYWORDS' if
 | 
						||
     the description is is long.
 | 
						||
 | 
						||
`SUBTITLE'
 | 
						||
     The document subtitle.  This is typeset according to
 | 
						||
     `org-latex-subtitle-format'.  If `org-latex-subtitle-separate' is
 | 
						||
     non-`nil' it is typed as part of the `\title'-macro.  It can also
 | 
						||
     access via `org-latex-hyperref-template' or typeset as part of the
 | 
						||
     front matter via `org-latex-title-command'.
 | 
						||
 | 
						||
   These keywords are treated in details in the following sections.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Header and sectioning,  Next: Quoting LaTeX code,  Prev: LaTeX specific export settings,  Up: LaTeX and PDF export
 | 
						||
 | 
						||
12.7.3 Header and sectioning structure
 | 
						||
--------------------------------------
 | 
						||
 | 
						||
By default, the first three outline levels become headlines, defining a
 | 
						||
general document structure.  Additional levels are exported as `itemize'
 | 
						||
or `enumerate' lists.  The transition can also occur at a different
 | 
						||
level (*note Export settings::).
 | 
						||
 | 
						||
   By default, the LaTeX output uses the class `article'.
 | 
						||
 | 
						||
   You can change this globally by setting a different value for
 | 
						||
`org-latex-default-class' or locally by adding an option like
 | 
						||
`#+LATEX_CLASS: myclass' in your file, or with a `EXPORT_LATEX_CLASS'
 | 
						||
property that applies when exporting a region containing only this
 | 
						||
(sub)tree.  The class must be listed in `org-latex-classes'.  This
 | 
						||
variable defines a header template for each class(1), and allows you to
 | 
						||
define the sectioning structure for each class.  You can also define
 | 
						||
your own classes there.
 | 
						||
 | 
						||
   The `LATEX_CLASS_OPTIONS' keyword or `EXPORT_LATEX_CLASS_OPTIONS'
 | 
						||
property can specify the options for the `\documentclass' macro.  These
 | 
						||
options have to be provided, as expected by LaTeX, within square
 | 
						||
brackets.
 | 
						||
 | 
						||
   You can also use the `LATEX_HEADER' and `LATEX_HEADER_EXTRA'(2)
 | 
						||
keywords in order to add lines to the header.  See the docstring of
 | 
						||
`org-latex-classes' for more information.
 | 
						||
 | 
						||
   An example is shown below.
 | 
						||
 | 
						||
     #+LATEX_CLASS: article
 | 
						||
     #+LATEX_CLASS_OPTIONS: [a4paper]
 | 
						||
     #+LATEX_HEADER: \usepackage{xyz}
 | 
						||
 | 
						||
     * Headline 1
 | 
						||
       some text
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Into which the values of `org-latex-default-packages-alist' and
 | 
						||
`org-latex-packages-alist' are spliced.
 | 
						||
 | 
						||
   (2) Unlike `LATEX_HEADER', contents from `LATEX_HEADER_EXTRA'
 | 
						||
keywords will not be loaded when previewing LaTeX snippets (*note
 | 
						||
Previewing LaTeX fragments::).
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Quoting LaTeX code,  Next: LaTeX specific attributes,  Prev: Header and sectioning,  Up: LaTeX and PDF export
 | 
						||
 | 
						||
12.7.4 Quoting LaTeX code
 | 
						||
-------------------------
 | 
						||
 | 
						||
Embedded LaTeX as described in *note Embedded LaTeX::, will be correctly
 | 
						||
inserted into the LaTeX file.  Furthermore, you can add special code
 | 
						||
that should only be present in LaTeX export with the following
 | 
						||
constructs:
 | 
						||
 | 
						||
     Code within @@latex:some code@@ a paragraph.
 | 
						||
 | 
						||
     #+LATEX: Literal LaTeX code for export
 | 
						||
 | 
						||
     #+BEGIN_LATEX
 | 
						||
     All lines between these markers are exported literally
 | 
						||
     #+END_LATEX
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: LaTeX specific attributes,  Prev: Quoting LaTeX code,  Up: LaTeX and PDF export
 | 
						||
 | 
						||
12.7.5 LaTeX specific attributes
 | 
						||
--------------------------------
 | 
						||
 | 
						||
LaTeX understands attributes specified in an `ATTR_LATEX' line.  They
 | 
						||
affect tables, images, plain lists, source blocks, example blocks and
 | 
						||
special blocks.
 | 
						||
 | 
						||
Tables in LaTeX export
 | 
						||
......................
 | 
						||
 | 
						||
For LaTeX export of a table, you can specify a label and a caption
 | 
						||
(*note Images and tables::).  You can also use attributes to control
 | 
						||
table layout and contents.  Valid LaTeX attributes include:
 | 
						||
 | 
						||
`:mode'
 | 
						||
     Nature of table's contents.  It can be set to `table', `math',
 | 
						||
     `inline-math' or `verbatim'.  In particular, when in `math' or
 | 
						||
     `inline-math' mode, every cell is exported as-is, horizontal rules
 | 
						||
     are ignored and the table will be wrapped in a math environment.
 | 
						||
     Also, contiguous tables sharing the same math mode will be wrapped
 | 
						||
     within the same environment.  Default mode is determined in
 | 
						||
     `org-latex-default-table-mode'.
 | 
						||
 | 
						||
`:environment'
 | 
						||
     Environment used for the table.  It can be set to any LaTeX table
 | 
						||
     environment, like `tabularx'(1), `longtable', `array', `tabu'(2),
 | 
						||
     `bmatrix'... It defaults to `org-latex-default-table-environment'
 | 
						||
     value.
 | 
						||
 | 
						||
`:caption'
 | 
						||
     `#+CAPTION' keyword is the simplest way to set a caption for a
 | 
						||
     table (*note Images and tables::).  If you need more advanced
 | 
						||
     commands for that task, you can use `:caption' attribute instead.
 | 
						||
     Its value should be raw LaTeX code.  It has precedence over
 | 
						||
     `#+CAPTION'.
 | 
						||
 | 
						||
`:float'
 | 
						||
`:placement'
 | 
						||
     The `:float' specifies the float environment for the table.
 | 
						||
     Possible values are `sideways'(3), `multicolumn', `t' and `nil'.
 | 
						||
     When unspecified, a table with a caption will have a `table'
 | 
						||
     environment.  Moreover, the `:placement' attribute can specify the
 | 
						||
     positioning of the float.  Note: `:placement' is ignored for
 | 
						||
     `:float sideways' tables.
 | 
						||
 | 
						||
`:align'
 | 
						||
`:font'
 | 
						||
`:width'
 | 
						||
     Set, respectively, the alignment string of the table, its font
 | 
						||
     size and its width.  They only apply on regular tables.
 | 
						||
 | 
						||
`:spread'
 | 
						||
     Boolean specific to the `tabu' and `longtabu' environments, and
 | 
						||
     only takes effect when used in conjunction with the `:width'
 | 
						||
     attribute.  When `:spread' is non-`nil', the table will be spread
 | 
						||
     or shrunk by the value of `:width'.
 | 
						||
 | 
						||
`:booktabs'
 | 
						||
`:center'
 | 
						||
`:rmlines'
 | 
						||
     They toggle, respectively, `booktabs' usage (assuming the package
 | 
						||
     is properly loaded), table centering and removal of every
 | 
						||
     horizontal rule but the first one (in a "table.el" table only).
 | 
						||
     In particular, `org-latex-tables-booktabs' (respectively
 | 
						||
     `org-latex-tables-centered') activates the first (respectively
 | 
						||
     second) attribute globally.
 | 
						||
 | 
						||
`:math-prefix'
 | 
						||
`:math-suffix'
 | 
						||
`:math-arguments'
 | 
						||
     A string that will be inserted, respectively, before the table
 | 
						||
     within the math environment, after the table within the math
 | 
						||
     environment, and between the macro name and the contents of the
 | 
						||
     table.  The `:math-arguments' attribute is used for matrix macros
 | 
						||
     that require more than one argument (e.g., `qbordermatrix').
 | 
						||
 | 
						||
   Thus, attributes can be used in a wide array of situations, like
 | 
						||
writing a table that will span over multiple pages, or a matrix product:
 | 
						||
 | 
						||
     #+ATTR_LATEX: :environment longtable :align l|lp{3cm}r|l
 | 
						||
     | ..... | ..... |
 | 
						||
     | ..... | ..... |
 | 
						||
 | 
						||
     #+ATTR_LATEX: :mode math :environment bmatrix :math-suffix \times
 | 
						||
     | a | b |
 | 
						||
     | c | d |
 | 
						||
     #+ATTR_LATEX: :mode math :environment bmatrix
 | 
						||
     | 1 | 2 |
 | 
						||
     | 3 | 4 |
 | 
						||
 | 
						||
   In the example below, LaTeX command `\bicaption{HeadingA}{HeadingB}'
 | 
						||
will set the caption.
 | 
						||
 | 
						||
     #+ATTR_LATEX: :caption \bicaption{HeadingA}{HeadingB}
 | 
						||
     | ..... | ..... |
 | 
						||
     | ..... | ..... |
 | 
						||
 | 
						||
Images in LaTeX export
 | 
						||
......................
 | 
						||
 | 
						||
Images that are linked to without a description part in the link, like
 | 
						||
`[[file:img.jpg]]' or `[[./img.jpg]]' will be inserted into the PDF
 | 
						||
output file resulting from LaTeX processing.  Org will use an
 | 
						||
`\includegraphics' macro to insert the image(4).
 | 
						||
 | 
						||
   You can specify image width or height with, respectively, `:width'
 | 
						||
and `:height' attributes.  It is also possible to add any other option
 | 
						||
with the `:options' attribute, as shown in the following example:
 | 
						||
 | 
						||
     #+ATTR_LATEX: :width 5cm :options angle=90
 | 
						||
     [[./img/sed-hr4049.pdf]]
 | 
						||
 | 
						||
   If you need a specific command for the caption, use `:caption'
 | 
						||
attribute.  It will override standard `#+CAPTION' value, if any.
 | 
						||
 | 
						||
     #+ATTR_LATEX: :caption \bicaption{HeadingA}{HeadingB}
 | 
						||
     [[./img/sed-hr4049.pdf]]
 | 
						||
 | 
						||
   If you have specified a caption as described in *note Images and
 | 
						||
tables::, the picture will be wrapped into a `figure' environment and
 | 
						||
thus become a floating element.  You can also ask Org to export an
 | 
						||
image as a float without specifying caption by setting the `:float'
 | 
						||
attribute.  You may also set it to:
 | 
						||
   - `t': if you want to use the standard `figure' environment.  It is
 | 
						||
     used by default if you provide a caption to the image.
 | 
						||
 | 
						||
   - `multicolumn': if you wish to include an image which spans multiple
 | 
						||
     columns in a page.  This will export the image wrapped in a
 | 
						||
     `figure*' environment.
 | 
						||
 | 
						||
   - `wrap': if you would like to let text flow around the image.  It
 | 
						||
     will make the figure occupy the left half of the page.
 | 
						||
 | 
						||
   - `sideways': if you would like the image to appear alone on a
 | 
						||
     separate page rotated ninety degrees using the `sidewaysfigure'
 | 
						||
     environment.  Setting this `:float' option will ignore the
 | 
						||
     `:placement' setting.
 | 
						||
 | 
						||
   - `nil': if you need to avoid any floating environment, even when a
 | 
						||
     caption is provided.
 | 
						||
   To modify the placement option of any floating environment, set the
 | 
						||
`placement' attribute.
 | 
						||
 | 
						||
     #+ATTR_LATEX: :float wrap :width 0.38\textwidth :placement {r}{0.4\textwidth}
 | 
						||
     [[./img/hst.png]]
 | 
						||
 | 
						||
   If the `:comment-include' attribute is set to a non-`nil' value, the
 | 
						||
LaTeX `\includegraphics' macro will be commented out.
 | 
						||
 | 
						||
Plain lists in LaTeX export
 | 
						||
...........................
 | 
						||
 | 
						||
Plain lists accept two optional attributes: `:environment' and
 | 
						||
`:options'.  The first one allows the use of a non-standard environment
 | 
						||
(e.g., `inparaenum').  The second one specifies additional arguments for
 | 
						||
that environment.
 | 
						||
 | 
						||
     #+ATTR_LATEX: :environment compactitem :options [$\circ$]
 | 
						||
     - you need ``paralist'' package to reproduce this example.
 | 
						||
 | 
						||
Source blocks in LaTeX export
 | 
						||
.............................
 | 
						||
 | 
						||
In addition to syntax defined in *note Literal examples::, names and
 | 
						||
captions (*note Images and tables::), source blocks also accept two
 | 
						||
additional attributes: `:float' and `:options'.
 | 
						||
 | 
						||
   You may set the former to
 | 
						||
   - `t': if you want to make the source block a float.  It is the
 | 
						||
     default value when a caption is provided.
 | 
						||
 | 
						||
   - `multicolumn': if you wish to include a source block which spans
 | 
						||
     multiple columns in a page.
 | 
						||
 | 
						||
   - `nil': if you need to avoid any floating environment, even when a
 | 
						||
     caption is provided.  It is useful for source code that may not
 | 
						||
     fit in a single page.
 | 
						||
 | 
						||
     #+ATTR_LATEX: :float nil
 | 
						||
     #+BEGIN_SRC emacs-lisp
 | 
						||
     Code that may not fit in a single page.
 | 
						||
     #+END_SRC
 | 
						||
 | 
						||
   The latter allows to specify options relative to the package used to
 | 
						||
highlight code in the output (e.g., `listings').  This is the local
 | 
						||
counterpart to `org-latex-listings-options' and
 | 
						||
`org-latex-minted-options' variables, which see.
 | 
						||
 | 
						||
     #+ATTR_LATEX: :options commentstyle=\bfseries
 | 
						||
     #+BEGIN_SRC emacs-lisp
 | 
						||
       (defun Fib (n)                          ; Count rabbits.
 | 
						||
         (if (< n 2) n (+ (Fib (- n 1)) (Fib (- n 2)))))
 | 
						||
     #+END_SRC
 | 
						||
 | 
						||
Example blocks in LaTeX export
 | 
						||
..............................
 | 
						||
 | 
						||
By default, when exporting to LaTeX, example blocks contents are wrapped
 | 
						||
in a `verbatim' environment.  It is possible to use a different
 | 
						||
environment globally using an appropriate export filter (*note Advanced
 | 
						||
configuration::).  You can also change this per block using
 | 
						||
`:environment' parameter.
 | 
						||
 | 
						||
     #+ATTR_LATEX: :environment myverbatim
 | 
						||
     #+BEGIN_EXAMPLE
 | 
						||
     This sentence is false.
 | 
						||
     #+END_EXAMPLE
 | 
						||
 | 
						||
Special blocks in LaTeX export
 | 
						||
..............................
 | 
						||
 | 
						||
In LaTeX back-end, special blocks become environments of the same name.
 | 
						||
Value of `:options' attribute will be appended as-is to that
 | 
						||
environment's opening string.  For example:
 | 
						||
 | 
						||
     #+BEGIN_abstract
 | 
						||
     We demonstrate how to solve the Syracuse problem.
 | 
						||
     #+END_abstract
 | 
						||
 | 
						||
     #+ATTR_LATEX: :options [Proof of important theorem]
 | 
						||
     #+BEGIN_proof
 | 
						||
     ...
 | 
						||
     Therefore, any even number greater than 2 is the sum of two primes.
 | 
						||
     #+END_proof
 | 
						||
 | 
						||
becomes
 | 
						||
 | 
						||
     \begin{abstract}
 | 
						||
     We demonstrate how to solve the Syracuse problem.
 | 
						||
     \end{abstract}
 | 
						||
 | 
						||
     \begin{proof}[Proof of important theorem]
 | 
						||
     ...
 | 
						||
     Therefore, any even number greater than 2 is the sum of two primes.
 | 
						||
     \end{proof}
 | 
						||
 | 
						||
   If you need to insert a specific caption command, use `:caption'
 | 
						||
attribute.  It will override standard `#+CAPTION' value, if any.  For
 | 
						||
example:
 | 
						||
 | 
						||
     #+ATTR_LATEX: :caption \MyCaption{HeadingA}
 | 
						||
     #+BEGIN_proof
 | 
						||
     ...
 | 
						||
     #+END_proof
 | 
						||
 | 
						||
Horizontal rules
 | 
						||
................
 | 
						||
 | 
						||
Width and thickness of a given horizontal rule can be controlled with,
 | 
						||
respectively, `:width' and `:thickness' attributes:
 | 
						||
 | 
						||
     #+ATTR_LATEX: :width .6\textwidth :thickness 0.8pt
 | 
						||
     -----
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Requires adding the `tabularx' package to
 | 
						||
`org-latex-packages-alist'.
 | 
						||
 | 
						||
   (2) Requires adding the `tabu' package to `org-latex-packages-alist'.
 | 
						||
 | 
						||
   (3) Formerly, the value was `sidewaystable'.  This is deprecated
 | 
						||
since Org 8.3.
 | 
						||
 | 
						||
   (4) In the case of TikZ (`http://sourceforge.net/projects/pgf/')
 | 
						||
images, it will become an `\input' macro wrapped within a `tikzpicture'
 | 
						||
environment.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Markdown export,  Next: OpenDocument Text export,  Prev: LaTeX and PDF export,  Up: Exporting
 | 
						||
 | 
						||
12.8 Markdown export
 | 
						||
====================
 | 
						||
 | 
						||
`md' export back-end generates Markdown syntax(1) for an Org mode
 | 
						||
buffer.
 | 
						||
 | 
						||
   It is built over HTML back-end: any construct not supported by
 | 
						||
Markdown syntax (e.g., tables) will be controlled and translated by
 | 
						||
`html' back-end (*note HTML export::).
 | 
						||
 | 
						||
Markdown export commands
 | 
						||
------------------------
 | 
						||
 | 
						||
`C-c C-e m m     (`org-md-export-to-markdown')'
 | 
						||
     Export as a text file written in Markdown syntax.  For an Org file,
 | 
						||
     `myfile.org', the resulting file will be `myfile.md'.  The file
 | 
						||
     will be overwritten without warning.  
 | 
						||
 | 
						||
`C-c C-e m M     (`org-md-export-as-markdown')'
 | 
						||
     Export to a temporary buffer.  Do not create a file.
 | 
						||
 | 
						||
`C-c C-e m o'
 | 
						||
     Export as a text file with Markdown syntax, then open it.
 | 
						||
 | 
						||
Header and sectioning structure
 | 
						||
-------------------------------
 | 
						||
 | 
						||
Markdown export can generate both `atx' and `setext' types for
 | 
						||
headlines, according to `org-md-headline-style'.  The former introduces
 | 
						||
a hard limit of two levels, whereas the latter pushes it to six.
 | 
						||
Headlines below that limit are exported as lists.  You can also set a
 | 
						||
soft limit before that one (*note Export settings::).
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Vanilla flavor, as defined at
 | 
						||
`http://daringfireball.net/projects/markdown/'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: OpenDocument Text export,  Next: Org export,  Prev: Markdown export,  Up: Exporting
 | 
						||
 | 
						||
12.9 OpenDocument Text export
 | 
						||
=============================
 | 
						||
 | 
						||
Org mode(1) supports export to OpenDocument Text (ODT) format.
 | 
						||
Documents created by this exporter use the `OpenDocument-v1.2
 | 
						||
specification'(2) and are compatible with LibreOffice 3.4.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Pre-requisites for ODT export::  What packages ODT exporter relies on
 | 
						||
* ODT export commands::         How to invoke ODT export
 | 
						||
* ODT specific export settings:: Export settings for ODT
 | 
						||
* Extending ODT export::        How to produce `doc', `pdf' files
 | 
						||
* Applying custom styles::      How to apply custom styles to the output
 | 
						||
* Links in ODT export::         How links will be interpreted and formatted
 | 
						||
* Tables in ODT export::        How Tables are exported
 | 
						||
* Images in ODT export::        How to insert images
 | 
						||
* Math formatting in ODT export::  How LaTeX fragments are formatted
 | 
						||
* Labels and captions in ODT export::  How captions are rendered
 | 
						||
* Literal examples in ODT export::  How source and example blocks are formatted
 | 
						||
* Advanced topics in ODT export::  Read this if you are a power user
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Versions 7.8 or later
 | 
						||
 | 
						||
   (2) Open Document Format for Office Applications (OpenDocument)
 | 
						||
Version 1.2
 | 
						||
(http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2.html)
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Pre-requisites for ODT export,  Next: ODT export commands,  Up: OpenDocument Text export
 | 
						||
 | 
						||
12.9.1 Pre-requisites for ODT export
 | 
						||
------------------------------------
 | 
						||
 | 
						||
The ODT exporter relies on the `zip' program to create the final
 | 
						||
output.  Check the availability of this program before proceeding
 | 
						||
further.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: ODT export commands,  Next: ODT specific export settings,  Prev: Pre-requisites for ODT export,  Up: OpenDocument Text export
 | 
						||
 | 
						||
12.9.2 ODT export commands
 | 
						||
--------------------------
 | 
						||
 | 
						||
`C-c C-e o o     (`org-odt-export-to-odt')'
 | 
						||
     Export as OpenDocument Text file.
 | 
						||
 | 
						||
     If `org-odt-preferred-output-format' is specified, automatically
 | 
						||
     convert the exported file to that format.  *Note Automatically
 | 
						||
     exporting to other formats: x-export-to-other-formats.
 | 
						||
 | 
						||
     For an Org file `myfile.org', the ODT file will be `myfile.odt'.
 | 
						||
     The file will be overwritten without warning.  If there is an
 | 
						||
     active region,(1) only the region will be exported.  If the
 | 
						||
     selected region is a single tree,(2) the tree head will become the
 | 
						||
     document title.  If the tree head entry has, or inherits, an
 | 
						||
     `EXPORT_FILE_NAME' property, that name will be used for the export.
 | 
						||
 | 
						||
     `C-c C-e o O' Export as an OpenDocument Text file and open the
 | 
						||
     resulting file.
 | 
						||
 | 
						||
     If `org-odt-preferred-output-format' is specified, open the
 | 
						||
     converted file instead.  *Note Automatically exporting to other
 | 
						||
     formats: x-export-to-other-formats.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) This requires `transient-mark-mode' to be turned on
 | 
						||
 | 
						||
   (2) To select the current subtree, use `C-c @'
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: ODT specific export settings,  Next: Extending ODT export,  Prev: ODT export commands,  Up: OpenDocument Text export
 | 
						||
 | 
						||
12.9.3 ODT specific export settings
 | 
						||
-----------------------------------
 | 
						||
 | 
						||
The ODT exporter introduces a number of keywords, similar to the general
 | 
						||
options settings described in *note Export settings::.
 | 
						||
 | 
						||
`DESCRIPTION'
 | 
						||
     The document description.  These are inserted as document
 | 
						||
     metadata.  You can use several such keywords if the list is long.
 | 
						||
 | 
						||
`KEYWORDS'
 | 
						||
     The keywords defining the contents of the document.  These are
 | 
						||
     inserted as document metadata.  You can use several such keywords
 | 
						||
     if the list is long.
 | 
						||
 | 
						||
`ODT_STYLES_FILE'
 | 
						||
     The style file of the document (`org-odt-styles-file').  See *note
 | 
						||
     Applying custom styles:: for details.
 | 
						||
 | 
						||
`SUBTITLE'
 | 
						||
     The document subtitle.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Extending ODT export,  Next: Applying custom styles,  Prev: ODT specific export settings,  Up: OpenDocument Text export
 | 
						||
 | 
						||
12.9.4 Extending ODT export
 | 
						||
---------------------------
 | 
						||
 | 
						||
The ODT exporter can interface with a variety of document converters
 | 
						||
and supports popular converters out of the box.  As a result, you can
 | 
						||
use it to export to formats like `doc' or convert a document from one
 | 
						||
format (say `csv') to another format (say `ods' or `xls').
 | 
						||
 | 
						||
   If you have a working installation of LibreOffice, a document
 | 
						||
converter is pre-configured for you and you can use it right away.  If
 | 
						||
you would like to use `unoconv' as your preferred converter, customize
 | 
						||
the variable `org-odt-convert-process' to point to `unoconv'.  You can
 | 
						||
also use your own favorite converter or tweak the default settings of
 | 
						||
the `LibreOffice' and `unoconv' converters.  *Note Configuring a
 | 
						||
document converter::.
 | 
						||
 | 
						||
Automatically exporting to other formats
 | 
						||
........................................
 | 
						||
 | 
						||
Very often, you will find yourself exporting to ODT format, only to
 | 
						||
immediately save the exported document to other formats like `doc',
 | 
						||
`docx', `rtf', `pdf' etc.  In such cases, you can specify your
 | 
						||
preferred output format by customizing the variable
 | 
						||
`org-odt-preferred-output-format'.  This way, the export commands
 | 
						||
(*note Exporting to ODT: x-export-to-odt.) can be extended to export to
 | 
						||
a format that is of immediate interest to you.
 | 
						||
 | 
						||
Converting between document formats
 | 
						||
...................................
 | 
						||
 | 
						||
There are many document converters in the wild which support conversion
 | 
						||
to and from various file formats, including, but not limited to the ODT
 | 
						||
format.  LibreOffice converter, mentioned above, is one such converter.
 | 
						||
Once a converter is configured, you can interact with it using the
 | 
						||
following command.
 | 
						||
 | 
						||
`M-x org-odt-convert RET'
 | 
						||
     Convert an existing document from one format to another.  With a
 | 
						||
     prefix argument, also open the newly produced file.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Applying custom styles,  Next: Links in ODT export,  Prev: Extending ODT export,  Up: OpenDocument Text export
 | 
						||
 | 
						||
12.9.5 Applying custom styles
 | 
						||
-----------------------------
 | 
						||
 | 
						||
The ODT exporter ships with a set of OpenDocument styles (*note Working
 | 
						||
with OpenDocument style files::) that ensure a well-formatted output.
 | 
						||
These factory styles, however, may not cater to your specific tastes.
 | 
						||
To customize the output, you can either modify the above styles files
 | 
						||
directly, or generate the required styles using an application like
 | 
						||
LibreOffice.  The latter method is suitable for expert and non-expert
 | 
						||
users alike, and is described here.
 | 
						||
 | 
						||
Applying custom styles: the easy way
 | 
						||
....................................
 | 
						||
 | 
						||
  1. Create a sample `example.org' file with the below settings and
 | 
						||
     export it to ODT format.
 | 
						||
 | 
						||
          #+OPTIONS: H:10 num:t
 | 
						||
 | 
						||
  2. Open the above `example.odt' using LibreOffice.  Use the `Stylist'
 | 
						||
     to locate the target styles--these typically have the `Org'
 | 
						||
     prefix--and modify those to your taste.  Save the modified file
 | 
						||
     either as an OpenDocument Text (`.odt') or OpenDocument Template
 | 
						||
     (`.ott') file.
 | 
						||
 | 
						||
  3. Customize the variable `org-odt-styles-file' and point it to the
 | 
						||
     newly created file.  For additional configuration options *note
 | 
						||
     Overriding factory styles: x-overriding-factory-styles.
 | 
						||
 | 
						||
     If you would like to choose a style on a per-file basis, you can
 | 
						||
     use the `#+ODT_STYLES_FILE' option.  A typical setting will look
 | 
						||
     like
 | 
						||
 | 
						||
          #+ODT_STYLES_FILE: "/path/to/example.ott"
 | 
						||
 | 
						||
     or
 | 
						||
 | 
						||
          #+ODT_STYLES_FILE: ("/path/to/file.ott" ("styles.xml" "image/hdr.png"))
 | 
						||
 | 
						||
 | 
						||
Using third-party styles and templates
 | 
						||
......................................
 | 
						||
 | 
						||
You can use third-party styles and templates for customizing your
 | 
						||
output.  This will produce the desired output only if the template
 | 
						||
provides all style names that the `ODT' exporter relies on.  Unless
 | 
						||
this condition is met, the output is going to be less than
 | 
						||
satisfactory.  So it is highly recommended that you only work with
 | 
						||
templates that are directly derived from the factory settings.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Links in ODT export,  Next: Tables in ODT export,  Prev: Applying custom styles,  Up: OpenDocument Text export
 | 
						||
 | 
						||
12.9.6 Links in ODT export
 | 
						||
--------------------------
 | 
						||
 | 
						||
ODT exporter creates native cross-references for internal links.  It
 | 
						||
creates Internet-style links for all other links.
 | 
						||
 | 
						||
   A link with no description and destined to a regular (un-itemized)
 | 
						||
outline heading is replaced with a cross-reference and section number
 | 
						||
of the heading.
 | 
						||
 | 
						||
   A `\ref{label}'-style reference to an image, table etc. is replaced
 | 
						||
with a cross-reference and sequence number of the labeled entity.
 | 
						||
*Note Labels and captions in ODT export::.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Tables in ODT export,  Next: Images in ODT export,  Prev: Links in ODT export,  Up: OpenDocument Text export
 | 
						||
 | 
						||
12.9.7 Tables in ODT export
 | 
						||
---------------------------
 | 
						||
 | 
						||
Export of native Org mode tables (*note Tables::) and simple `table.el'
 | 
						||
tables is supported.  However, export of complex `table.el'
 | 
						||
tables--tables that have column or row spans--is not supported.  Such
 | 
						||
tables are stripped from the exported document.
 | 
						||
 | 
						||
   By default, a table is exported with top and bottom frames and with
 | 
						||
rules separating row and column groups (*note Column groups::).
 | 
						||
Furthermore, all tables are typeset to occupy the same width.  If the
 | 
						||
table specifies alignment and relative width for its columns (*note
 | 
						||
Column width and alignment::) then these are honored on export.(1)
 | 
						||
 | 
						||
   You can control the width of the table by specifying `:rel-width'
 | 
						||
property using an `#+ATTR_ODT' line.
 | 
						||
 | 
						||
   For example, consider the following table which makes use of all the
 | 
						||
rules mentioned above.
 | 
						||
 | 
						||
     #+ATTR_ODT: :rel-width 50
 | 
						||
     | Area/Month    |   Jan |   Feb |   Mar |   Sum |
 | 
						||
     |---------------+-------+-------+-------+-------|
 | 
						||
     | /             |     < |       |       |     < |
 | 
						||
     | <l13>         |  <r5> |  <r5> |  <r5> |  <r6> |
 | 
						||
     | North America |     1 |    21 |   926 |   948 |
 | 
						||
     | Middle East   |     6 |    75 |   844 |   925 |
 | 
						||
     | Asia Pacific  |     9 |    27 |   790 |   826 |
 | 
						||
     |---------------+-------+-------+-------+-------|
 | 
						||
     | Sum           |    16 |   123 |  2560 |  2699 |
 | 
						||
 | 
						||
   On export, the table will occupy 50% of text area.  The columns will
 | 
						||
be sized (roughly) in the ratio of 13:5:5:5:6.  The first column will
 | 
						||
be left-aligned and rest of the columns will be right-aligned.  There
 | 
						||
will be vertical rules after separating the header and last columns
 | 
						||
from other columns.  There will be horizontal rules separating the
 | 
						||
header and last rows from other rows.
 | 
						||
 | 
						||
   If you are not satisfied with the above formatting options, you can
 | 
						||
create custom table styles and associate them with a table using the
 | 
						||
`#+ATTR_ODT' line.  *Note Customizing tables in ODT export::.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) The column widths are interpreted as weighted ratios with the
 | 
						||
default weight being 1
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Images in ODT export,  Next: Math formatting in ODT export,  Prev: Tables in ODT export,  Up: OpenDocument Text export
 | 
						||
 | 
						||
12.9.8 Images in ODT export
 | 
						||
---------------------------
 | 
						||
 | 
						||
Embedding images
 | 
						||
................
 | 
						||
 | 
						||
You can embed images within the exported document by providing a link
 | 
						||
to the desired image file with no link description.  For example, to
 | 
						||
embed `img.png' do either of the following:
 | 
						||
 | 
						||
     [[file:img.png]]
 | 
						||
 | 
						||
     [[./img.png]]
 | 
						||
 | 
						||
Embedding clickable images
 | 
						||
..........................
 | 
						||
 | 
						||
You can create clickable images by providing a link whose description
 | 
						||
is a link to an image file.  For example, to embed a image
 | 
						||
`org-mode-unicorn.png' which when clicked jumps to `http://Orgmode.org'
 | 
						||
website, do the following
 | 
						||
 | 
						||
     [[http://orgmode.org][./org-mode-unicorn.png]]
 | 
						||
 | 
						||
Sizing and scaling of embedded images
 | 
						||
.....................................
 | 
						||
 | 
						||
You can control the size and scale of the embedded images using the
 | 
						||
`#+ATTR_ODT' attribute.
 | 
						||
 | 
						||
   The exporter specifies the desired size of the image in the final
 | 
						||
document in units of centimeters.  In order to scale the embedded
 | 
						||
images, the exporter queries for pixel dimensions of the images using
 | 
						||
one of a) ImageMagick's `identify' program or b) Emacs `create-image'
 | 
						||
and `image-size' APIs(1). The pixel dimensions are subsequently
 | 
						||
converted in to units of centimeters using `org-odt-pixels-per-inch'.
 | 
						||
The default value of this variable is set to `display-pixels-per-inch'.
 | 
						||
You can tweak this variable to achieve the best results.
 | 
						||
 | 
						||
   The examples below illustrate the various possibilities.
 | 
						||
 | 
						||
Explicitly size the image
 | 
						||
     To embed `img.png' as a 10 cm x 10 cm image, do the following:
 | 
						||
 | 
						||
          #+ATTR_ODT: :width 10 :height 10
 | 
						||
          [[./img.png]]
 | 
						||
 | 
						||
Scale the image
 | 
						||
     To embed `img.png' at half its size, do the following:
 | 
						||
 | 
						||
          #+ATTR_ODT: :scale 0.5
 | 
						||
          [[./img.png]]
 | 
						||
 | 
						||
Scale the image to a specific width
 | 
						||
     To embed `img.png' with a width of 10 cm while retaining the
 | 
						||
     original height:width ratio, do the following:
 | 
						||
 | 
						||
          #+ATTR_ODT: :width 10
 | 
						||
          [[./img.png]]
 | 
						||
 | 
						||
Scale the image to a specific height
 | 
						||
     To embed `img.png' with a height of 10 cm while retaining the
 | 
						||
     original height:width ratio, do the following
 | 
						||
 | 
						||
          #+ATTR_ODT: :height 10
 | 
						||
          [[./img.png]]
 | 
						||
 | 
						||
Anchoring of images
 | 
						||
...................
 | 
						||
 | 
						||
You can control the manner in which an image is anchored by setting the
 | 
						||
`:anchor' property of its `#+ATTR_ODT' line.  You can specify one of
 | 
						||
the following three values for the `:anchor' property: `"as-char"',
 | 
						||
`"paragraph"' and `"page"'.
 | 
						||
 | 
						||
   To create an image that is anchored to a page, do the following:
 | 
						||
     #+ATTR_ODT: :anchor "page"
 | 
						||
     [[./img.png]]
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Use of `ImageMagick' is only desirable.  However, if you
 | 
						||
routinely produce documents that have large images or you export your
 | 
						||
Org files that has images using a Emacs batch script, then the use of
 | 
						||
`ImageMagick' is mandatory.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Math formatting in ODT export,  Next: Labels and captions in ODT export,  Prev: Images in ODT export,  Up: OpenDocument Text export
 | 
						||
 | 
						||
12.9.9 Math formatting in ODT export
 | 
						||
------------------------------------
 | 
						||
 | 
						||
The ODT exporter has special support for handling math.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Working with LaTeX math snippets::  How to embed LaTeX math fragments
 | 
						||
* Working with MathML or OpenDocument formula files::  How to embed equations in native format
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Working with LaTeX math snippets,  Next: Working with MathML or OpenDocument formula files,  Up: Math formatting in ODT export
 | 
						||
 | 
						||
Working with LaTeX math snippets
 | 
						||
................................
 | 
						||
 | 
						||
LaTeX math snippets (*note LaTeX fragments::) can be embedded in the ODT
 | 
						||
document in one of the following ways:
 | 
						||
 | 
						||
  1. MathML
 | 
						||
 | 
						||
     This option is activated on a per-file basis with
 | 
						||
 | 
						||
          #+OPTIONS: LaTeX:t
 | 
						||
 | 
						||
     With this option, LaTeX fragments are first converted into MathML
 | 
						||
     fragments using an external LaTeX-to-MathML converter program.  The
 | 
						||
     resulting MathML fragments are then embedded as an OpenDocument
 | 
						||
     Formula in the exported document.
 | 
						||
 | 
						||
     You can specify the LaTeX-to-MathML converter by customizing the
 | 
						||
     variables `org-latex-to-mathml-convert-command' and
 | 
						||
     `org-latex-to-mathml-jar-file'.
 | 
						||
 | 
						||
     To use MathToWeb(1) as your converter, you can configure the above
 | 
						||
     variables as
 | 
						||
 | 
						||
          (setq org-latex-to-mathml-convert-command
 | 
						||
                "java -jar %j -unicode -force -df %o %I"
 | 
						||
                org-latex-to-mathml-jar-file
 | 
						||
                "/path/to/mathtoweb.jar")
 | 
						||
     To use LaTeXML(2) use
 | 
						||
          (setq org-latex-to-mathml-convert-command
 | 
						||
                "latexmlmath \"%i\" --presentationmathml=%o")
 | 
						||
 | 
						||
     You can use the following commands to quickly verify the
 | 
						||
     reliability of the LaTeX-to-MathML converter.
 | 
						||
 | 
						||
    `M-x org-odt-export-as-odf RET'
 | 
						||
          Convert a LaTeX math snippet to an OpenDocument formula
 | 
						||
          (`.odf') file.
 | 
						||
 | 
						||
    `M-x org-odt-export-as-odf-and-open RET'
 | 
						||
          Convert a LaTeX math snippet to an OpenDocument formula
 | 
						||
          (`.odf') file and open the formula file with the
 | 
						||
          system-registered application.
 | 
						||
 | 
						||
  2. PNG images
 | 
						||
 | 
						||
     This option is activated on a per-file basis with
 | 
						||
 | 
						||
          #+OPTIONS: tex:dvipng
 | 
						||
 | 
						||
     or:
 | 
						||
 | 
						||
          #+OPTIONS: tex:imagemagick
 | 
						||
 | 
						||
     With this option, LaTeX fragments are processed into PNG images
 | 
						||
     and the resulting images are embedded in the exported document.
 | 
						||
     This method requires that the `dvipng' program or `imagemagick'
 | 
						||
     suite be available on your system.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) See MathToWeb
 | 
						||
(http://www.mathtoweb.com/cgi-bin/mathtoweb_home.pl).
 | 
						||
 | 
						||
   (2) See `http://dlmf.nist.gov/LaTeXML/'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Working with MathML or OpenDocument formula files,  Prev: Working with LaTeX math snippets,  Up: Math formatting in ODT export
 | 
						||
 | 
						||
Working with MathML or OpenDocument formula files
 | 
						||
.................................................
 | 
						||
 | 
						||
For various reasons, you may find embedding LaTeX math snippets in an
 | 
						||
ODT document less than reliable.  In that case, you can embed a math
 | 
						||
equation by linking to its MathML (`.mml') source or its OpenDocument
 | 
						||
formula (`.odf') file as shown below:
 | 
						||
 | 
						||
     [[./equation.mml]]
 | 
						||
 | 
						||
   or
 | 
						||
 | 
						||
     [[./equation.odf]]
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Labels and captions in ODT export,  Next: Literal examples in ODT export,  Prev: Math formatting in ODT export,  Up: OpenDocument Text export
 | 
						||
 | 
						||
12.9.10 Labels and captions in ODT export
 | 
						||
-----------------------------------------
 | 
						||
 | 
						||
You can label and caption various category of objects--an inline image,
 | 
						||
a table, a LaTeX fragment or a Math formula--using `#+LABEL' and
 | 
						||
`#+CAPTION' lines.  *Note Images and tables::.  ODT exporter enumerates
 | 
						||
each labeled or captioned object of a given category separately.  As a
 | 
						||
result, each such object is assigned a sequence number based on order
 | 
						||
of its appearance in the Org file.
 | 
						||
 | 
						||
   In the exported document, a user-provided caption is augmented with
 | 
						||
the category and sequence number.  Consider the following inline image
 | 
						||
in an Org file.
 | 
						||
 | 
						||
     #+CAPTION: Bell curve
 | 
						||
     #+LABEL:   fig:SED-HR4049
 | 
						||
     [[./img/a.png]]
 | 
						||
 | 
						||
   It could be rendered as shown below in the exported document.
 | 
						||
 | 
						||
     Figure 2: Bell curve
 | 
						||
 | 
						||
   You can modify the category component of the caption by customizing
 | 
						||
the option `org-odt-category-map-alist'.  For example, to tag all
 | 
						||
embedded images with the string `Illustration' (instead of the default
 | 
						||
`Figure') use the following setting:
 | 
						||
 | 
						||
     (setq org-odt-category-map-alist
 | 
						||
           (("__Figure__" "Illustration" "value" "Figure" org-odt--enumerable-image-p)))
 | 
						||
 | 
						||
   With this, previous image will be captioned as below in the exported
 | 
						||
document.
 | 
						||
 | 
						||
     Illustration 2: Bell curve
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Literal examples in ODT export,  Next: Advanced topics in ODT export,  Prev: Labels and captions in ODT export,  Up: OpenDocument Text export
 | 
						||
 | 
						||
12.9.11 Literal examples in ODT export
 | 
						||
--------------------------------------
 | 
						||
 | 
						||
Export of literal examples (*note Literal examples::) with full
 | 
						||
fontification is supported.  Internally, the exporter relies on
 | 
						||
`htmlfontify.el' to generate all style definitions needed for a fancy
 | 
						||
listing.(1)  The auto-generated styles have `OrgSrc' as prefix and
 | 
						||
inherit their color from the faces used by Emacs `font-lock' library
 | 
						||
for the source language.
 | 
						||
 | 
						||
   If you prefer to use your own custom styles for fontification, you
 | 
						||
can do so by customizing the option
 | 
						||
`org-odt-create-custom-styles-for-srcblocks'.
 | 
						||
 | 
						||
   You can turn off fontification of literal examples by customizing the
 | 
						||
option `org-odt-fontify-srcblocks'.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Your `htmlfontify.el' library must at least be at Emacs 24.1
 | 
						||
levels for fontification to be turned on.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Advanced topics in ODT export,  Prev: Literal examples in ODT export,  Up: OpenDocument Text export
 | 
						||
 | 
						||
12.9.12 Advanced topics in ODT export
 | 
						||
-------------------------------------
 | 
						||
 | 
						||
If you rely heavily on ODT export, you may want to exploit the full set
 | 
						||
of features that the exporter offers.  This section describes features
 | 
						||
that would be of interest to power users.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Configuring a document converter::  How to register a document converter
 | 
						||
* Working with OpenDocument style files::  Explore the internals
 | 
						||
* Creating one-off styles::     How to produce custom highlighting etc
 | 
						||
* Customizing tables in ODT export::  How to define and use Table templates
 | 
						||
* Validating OpenDocument XML::  How to debug corrupt OpenDocument files
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Configuring a document converter,  Next: Working with OpenDocument style files,  Up: Advanced topics in ODT export
 | 
						||
 | 
						||
Configuring a document converter
 | 
						||
................................
 | 
						||
 | 
						||
The ODT exporter can work with popular converters with little or no
 | 
						||
extra configuration from your side. *Note Extending ODT export::.  If
 | 
						||
you are using a converter that is not supported by default or if you
 | 
						||
would like to tweak the default converter settings, proceed as below.
 | 
						||
 | 
						||
  1. Register the converter
 | 
						||
 | 
						||
     Name your converter and add it to the list of known converters by
 | 
						||
     customizing the option `org-odt-convert-processes'.  Also specify
 | 
						||
     how the converter can be invoked via command-line to effect the
 | 
						||
     conversion.
 | 
						||
 | 
						||
  2. Configure its capabilities
 | 
						||
 | 
						||
     Specify the set of formats the converter can handle by customizing
 | 
						||
     the variable `org-odt-convert-capabilities'.  Use the default
 | 
						||
     value for this variable as a guide for configuring your converter.
 | 
						||
     As suggested by the default setting, you can specify the full set
 | 
						||
     of formats supported by the converter and not limit yourself to
 | 
						||
     specifying formats that are related to just the OpenDocument Text
 | 
						||
     format.
 | 
						||
 | 
						||
  3. Choose the converter
 | 
						||
 | 
						||
     Select the newly added converter as the preferred one by
 | 
						||
     customizing the option `org-odt-convert-process'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Working with OpenDocument style files,  Next: Creating one-off styles,  Prev: Configuring a document converter,  Up: Advanced topics in ODT export
 | 
						||
 | 
						||
Working with OpenDocument style files
 | 
						||
.....................................
 | 
						||
 | 
						||
This section explores the internals of the ODT exporter and the means
 | 
						||
by which it produces styled documents.  Read this section if you are
 | 
						||
interested in exploring the automatic and custom OpenDocument styles
 | 
						||
used by the exporter.
 | 
						||
 | 
						||
a) Factory styles
 | 
						||
.................
 | 
						||
 | 
						||
The ODT exporter relies on two files for generating its output.  These
 | 
						||
files are bundled with the distribution under the directory pointed to
 | 
						||
by the variable `org-odt-styles-dir'.  The two files are:
 | 
						||
 | 
						||
   * `OrgOdtStyles.xml'
 | 
						||
 | 
						||
     This file contributes to the `styles.xml' file of the final `ODT'
 | 
						||
     document.  This file gets modified for the following purposes:
 | 
						||
       1. To control outline numbering based on user settings.
 | 
						||
 | 
						||
       2. To add styles generated by `htmlfontify.el' for fontification
 | 
						||
          of code blocks.
 | 
						||
 | 
						||
   * `OrgOdtContentTemplate.xml'
 | 
						||
 | 
						||
     This file contributes to the `content.xml' file of the final `ODT'
 | 
						||
     document.  The contents of the Org outline are inserted between the
 | 
						||
     `<office:text>'...`</office:text>' elements of this file.
 | 
						||
 | 
						||
     Apart from serving as a template file for the final `content.xml',
 | 
						||
     the file serves the following purposes:
 | 
						||
       1. It contains automatic styles for formatting of tables which
 | 
						||
          are referenced by the exporter.
 | 
						||
 | 
						||
       2. It contains `<text:sequence-decl>'...`</text:sequence-decl>'
 | 
						||
          elements that control how various entities--tables, images,
 | 
						||
          equations, etc.--are numbered.
 | 
						||
 | 
						||
b) Overriding factory styles
 | 
						||
............................
 | 
						||
 | 
						||
The following two variables control the location from which the ODT
 | 
						||
exporter picks up the custom styles and content template files.  You can
 | 
						||
customize these variables to override the factory styles used by the
 | 
						||
exporter.
 | 
						||
 | 
						||
   * `org-odt-styles-file'
 | 
						||
 | 
						||
     Use this variable to specify the `styles.xml' that will be used in
 | 
						||
     the final output.  You can specify one of the following values:
 | 
						||
 | 
						||
       1. A `styles.xml' file
 | 
						||
 | 
						||
          Use this file instead of the default `styles.xml'
 | 
						||
 | 
						||
       2. A `.odt' or `.ott' file
 | 
						||
 | 
						||
          Use the `styles.xml' contained in the specified OpenDocument
 | 
						||
          Text or Template file
 | 
						||
 | 
						||
       3. A `.odt' or `.ott' file and a subset of files contained
 | 
						||
          within them
 | 
						||
 | 
						||
          Use the `styles.xml' contained in the specified OpenDocument
 | 
						||
          Text or Template file.  Additionally extract the specified
 | 
						||
          member files and embed those within the final `ODT' document.
 | 
						||
 | 
						||
          Use this option if the `styles.xml' file references
 | 
						||
          additional files like header and footer images.
 | 
						||
 | 
						||
       4. `nil'
 | 
						||
 | 
						||
          Use the default `styles.xml'
 | 
						||
 | 
						||
   * `org-odt-content-template-file'
 | 
						||
 | 
						||
     Use this variable to specify the blank `content.xml' that will be
 | 
						||
     used in the final output.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Creating one-off styles,  Next: Customizing tables in ODT export,  Prev: Working with OpenDocument style files,  Up: Advanced topics in ODT export
 | 
						||
 | 
						||
Creating one-off styles
 | 
						||
.......................
 | 
						||
 | 
						||
There are times when you would want one-off formatting in the exported
 | 
						||
document.  You can achieve this by embedding raw OpenDocument XML in
 | 
						||
the Org file.  The use of this feature is better illustrated with
 | 
						||
couple of examples.
 | 
						||
 | 
						||
  1. Embedding ODT tags as part of regular text
 | 
						||
 | 
						||
     You can inline OpenDocument syntax by enclosing it within
 | 
						||
     `@@odt:...@@' markup.  For example, to highlight a region of text
 | 
						||
     do the following:
 | 
						||
 | 
						||
          @@odt:<text:span text:style-name="Highlight">This is a highlighted
 | 
						||
          text</text:span>@@.  But this is a regular text.
 | 
						||
 | 
						||
     *Hint:* To see the above example in action, edit your `styles.xml'
 | 
						||
     (*note Factory styles: x-orgodtstyles-xml.) and add a custom
 | 
						||
     `Highlight' style as shown below.
 | 
						||
 | 
						||
          <style:style style:name="Highlight" style:family="text">
 | 
						||
            <style:text-properties fo:background-color="#ff0000"/>
 | 
						||
          </style:style>
 | 
						||
 | 
						||
  2. Embedding a one-line OpenDocument XML
 | 
						||
 | 
						||
     You can add a simple OpenDocument one-liner using the `#+ODT:'
 | 
						||
     directive.  For example, to force a page break do the following:
 | 
						||
 | 
						||
          #+ODT: <text:p text:style-name="PageBreak"/>
 | 
						||
 | 
						||
     *Hint:* To see the above example in action, edit your `styles.xml'
 | 
						||
     (*note Factory styles: x-orgodtstyles-xml.) and add a custom
 | 
						||
     `PageBreak' style as shown below.
 | 
						||
 | 
						||
          <style:style style:name="PageBreak" style:family="paragraph"
 | 
						||
                       style:parent-style-name="Text_20_body">
 | 
						||
            <style:paragraph-properties fo:break-before="page"/>
 | 
						||
          </style:style>
 | 
						||
 | 
						||
  3. Embedding a block of OpenDocument XML
 | 
						||
 | 
						||
     You can add a large block of OpenDocument XML using the
 | 
						||
     `#+BEGIN_ODT'...`#+END_ODT' construct.
 | 
						||
 | 
						||
     For example, to create a one-off paragraph that uses bold text, do
 | 
						||
     the following:
 | 
						||
 | 
						||
          #+BEGIN_ODT
 | 
						||
          <text:p text:style-name="Text_20_body_20_bold">
 | 
						||
          This paragraph is specially formatted and uses bold text.
 | 
						||
          </text:p>
 | 
						||
          #+END_ODT
 | 
						||
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Customizing tables in ODT export,  Next: Validating OpenDocument XML,  Prev: Creating one-off styles,  Up: Advanced topics in ODT export
 | 
						||
 | 
						||
Customizing tables in ODT export
 | 
						||
................................
 | 
						||
 | 
						||
You can override the default formatting of the table by specifying a
 | 
						||
custom table style with the `#+ATTR_ODT' line.  For a discussion on
 | 
						||
default formatting of tables *note Tables in ODT export::.
 | 
						||
 | 
						||
   This feature closely mimics the way table templates are defined in
 | 
						||
the OpenDocument-v1.2 specification.(1)
 | 
						||
 | 
						||
   To have a quick preview of this feature, install the below setting
 | 
						||
and export the table that follows:
 | 
						||
 | 
						||
     (setq org-odt-table-styles
 | 
						||
           (append org-odt-table-styles
 | 
						||
                 '(("TableWithHeaderRowAndColumn" "Custom"
 | 
						||
                     ((use-first-row-styles . t)
 | 
						||
                      (use-first-column-styles . t)))
 | 
						||
                     ("TableWithFirstRowandLastRow" "Custom"
 | 
						||
                      ((use-first-row-styles . t)
 | 
						||
                      (use-last-row-styles . t))))))
 | 
						||
 | 
						||
     #+ATTR_ODT: :style TableWithHeaderRowAndColumn
 | 
						||
     | Name  | Phone | Age |
 | 
						||
     | Peter |  1234 |  17 |
 | 
						||
     | Anna  |  4321 |  25 |
 | 
						||
 | 
						||
   In the above example, you used a template named `Custom' and
 | 
						||
installed two table styles with the names `TableWithHeaderRowAndColumn'
 | 
						||
and `TableWithFirstRowandLastRow'.  (*Important:* The OpenDocument
 | 
						||
styles needed for producing the above template have been pre-defined for
 | 
						||
you.  These styles are available under the section marked `Custom Table
 | 
						||
Template' in `OrgOdtContentTemplate.xml' (*note Factory styles:
 | 
						||
x-orgodtcontenttemplate-xml.).  If you need additional templates you
 | 
						||
have to define these styles yourselves.
 | 
						||
 | 
						||
   To use this feature proceed as follows:
 | 
						||
 | 
						||
  1. Create a table template(2)
 | 
						||
 | 
						||
     A table template is nothing but a set of `table-cell' and
 | 
						||
     `paragraph' styles for each of the following table cell categories:
 | 
						||
 | 
						||
        - Body
 | 
						||
 | 
						||
        - First column
 | 
						||
 | 
						||
        - Last column
 | 
						||
 | 
						||
        - First row
 | 
						||
 | 
						||
        - Last row
 | 
						||
 | 
						||
        - Even row
 | 
						||
 | 
						||
        - Odd row
 | 
						||
 | 
						||
        - Even column
 | 
						||
 | 
						||
        - Odd Column
 | 
						||
 | 
						||
     The names for the above styles must be chosen based on the name of
 | 
						||
     the table template using a well-defined convention.
 | 
						||
 | 
						||
     The naming convention is better illustrated with an example.  For
 | 
						||
     a table template with the name `Custom', the needed style names
 | 
						||
     are listed in the following table.
 | 
						||
 | 
						||
     Table cell type   `table-cell' style          `paragraph' style
 | 
						||
     ------------------------------------------------------------------------------- 
 | 
						||
 | 
						||
     Body              `CustomTableCell'           `CustomTableParagraph'
 | 
						||
     First column      `CustomFirstColumnTableCell'`CustomFirstColumnTableParagraph'
 | 
						||
     Last column       `CustomLastColumnTableCell' `CustomLastColumnTableParagraph'
 | 
						||
     First row         `CustomFirstRowTableCell'   `CustomFirstRowTableParagraph'
 | 
						||
     Last row          `CustomLastRowTableCell'    `CustomLastRowTableParagraph'
 | 
						||
     Even row          `CustomEvenRowTableCell'    `CustomEvenRowTableParagraph'
 | 
						||
     Odd row           `CustomOddRowTableCell'     `CustomOddRowTableParagraph'
 | 
						||
     Even column       `CustomEvenColumnTableCell' `CustomEvenColumnTableParagraph'
 | 
						||
     Odd column        `CustomOddColumnTableCell'  `CustomOddColumnTableParagraph'
 | 
						||
 | 
						||
     To create a table template with the name `Custom', define the above
 | 
						||
     styles in the
 | 
						||
     `<office:automatic-styles>'...`</office:automatic-styles>' element
 | 
						||
     of the content template file (*note Factory styles:
 | 
						||
     x-orgodtcontenttemplate-xml.).
 | 
						||
 | 
						||
  2. Define a table style(3)
 | 
						||
 | 
						||
     To define a table style, create an entry for the style in the
 | 
						||
     variable `org-odt-table-styles' and specify the following:
 | 
						||
 | 
						||
        - the name of the table template created in step (1)
 | 
						||
 | 
						||
        - the set of cell styles in that template that are to be
 | 
						||
          activated
 | 
						||
 | 
						||
     For example, the entry below defines two different table styles
 | 
						||
     `TableWithHeaderRowAndColumn' and `TableWithFirstRowandLastRow'
 | 
						||
     based on the same template `Custom'.  The styles achieve their
 | 
						||
     intended effect by selectively activating the individual cell
 | 
						||
     styles in that template.
 | 
						||
 | 
						||
          (setq org-odt-table-styles
 | 
						||
                (append org-odt-table-styles
 | 
						||
                        '(("TableWithHeaderRowAndColumn" "Custom"
 | 
						||
                           ((use-first-row-styles . t)
 | 
						||
                            (use-first-column-styles . t)))
 | 
						||
                          ("TableWithFirstRowandLastRow" "Custom"
 | 
						||
                           ((use-first-row-styles . t)
 | 
						||
                            (use-last-row-styles . t))))))
 | 
						||
 | 
						||
  3. Associate a table with the table style
 | 
						||
 | 
						||
     To do this, specify the table style created in step (2) as part of
 | 
						||
     the `ATTR_ODT' line as shown below.
 | 
						||
 | 
						||
          #+ATTR_ODT: :style "TableWithHeaderRowAndColumn"
 | 
						||
          | Name  | Phone | Age |
 | 
						||
          | Peter |  1234 |  17 |
 | 
						||
          | Anna  |  4321 |  25 |
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) OpenDocument-v1.2 Specification
 | 
						||
(http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2.html)
 | 
						||
 | 
						||
   (2) See the `<table:table-template>' element of the
 | 
						||
OpenDocument-v1.2 specification
 | 
						||
 | 
						||
   (3) See the attributes `table:template-name',
 | 
						||
`table:use-first-row-styles', `table:use-last-row-styles',
 | 
						||
`table:use-first-column-styles', `table:use-last-column-styles',
 | 
						||
`table:use-banding-rows-styles', and `table:use-banding-column-styles'
 | 
						||
of the `<table:table>' element in the OpenDocument-v1.2 specification
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Validating OpenDocument XML,  Prev: Customizing tables in ODT export,  Up: Advanced topics in ODT export
 | 
						||
 | 
						||
Validating OpenDocument XML
 | 
						||
...........................
 | 
						||
 | 
						||
Occasionally, you will discover that the document created by the ODT
 | 
						||
exporter cannot be opened by your favorite application.  One of the
 | 
						||
common reasons for this is that the `.odt' file is corrupt.  In such
 | 
						||
cases, you may want to validate the document against the OpenDocument
 | 
						||
RELAX NG Compact Syntax (RNC) schema.
 | 
						||
 | 
						||
   For de-compressing the `.odt' file(1): *note (emacs)File Archives::.
 | 
						||
For general help with validation (and schema-sensitive editing) of XML
 | 
						||
files: *note (nxml-mode)Introduction::.
 | 
						||
 | 
						||
   If you have ready access to OpenDocument `.rnc' files and the needed
 | 
						||
schema-locating rules in a single folder, you can customize the variable
 | 
						||
`org-odt-schema-dir' to point to that directory.  The ODT exporter will
 | 
						||
take care of updating the `rng-schema-locating-files' for you.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) `.odt' files are nothing but `zip' archives
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Org export,  Next: Texinfo export,  Prev: OpenDocument Text export,  Up: Exporting
 | 
						||
 | 
						||
12.10 Org export
 | 
						||
================
 | 
						||
 | 
						||
`org' export back-end creates a normalized version of the Org document
 | 
						||
in current buffer.  In particular, it evaluates Babel code (*note
 | 
						||
Evaluating code blocks::) and removes other back-ends specific contents.
 | 
						||
 | 
						||
Org export commands
 | 
						||
-------------------
 | 
						||
 | 
						||
`C-c C-e O o     (`org-org-export-to-org')'
 | 
						||
     Export as an Org document.  For an Org file, `myfile.org', the
 | 
						||
     resulting file will be `myfile.org.org'.  The file will be
 | 
						||
     overwritten without warning.  
 | 
						||
 | 
						||
`C-c C-e O O     (`org-org-export-as-org')'
 | 
						||
     Export to a temporary buffer.  Do not create a file.
 | 
						||
 | 
						||
`C-c C-e O v'
 | 
						||
     Export to an Org file, then open it.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Texinfo export,  Next: iCalendar export,  Prev: Org export,  Up: Exporting
 | 
						||
 | 
						||
12.11 Texinfo export
 | 
						||
====================
 | 
						||
 | 
						||
`texinfo' export back-end generates Texinfo code and can compile it into
 | 
						||
an Info file.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Texinfo export commands::     How to invoke Texinfo export
 | 
						||
* Texinfo specific export settings:: Export settings for Texinfo
 | 
						||
* Document preamble::           File header, title and copyright page
 | 
						||
* Headings and sectioning structure:: Building document structure
 | 
						||
* Indices::                     Creating indices
 | 
						||
* Quoting Texinfo code::        Incorporating literal Texinfo code
 | 
						||
* Texinfo specific attributes:: Controlling Texinfo output
 | 
						||
* An example::
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Texinfo export commands,  Next: Texinfo specific export settings,  Up: Texinfo export
 | 
						||
 | 
						||
12.11.1 Texinfo export commands
 | 
						||
-------------------------------
 | 
						||
 | 
						||
`C-c C-e i t     (`org-texinfo-export-to-texinfo')'
 | 
						||
     Export as a Texinfo file.  For an Org file, `myfile.org', the
 | 
						||
     resulting file will be `myfile.texi'.  The file will be
 | 
						||
     overwritten without warning.  
 | 
						||
 | 
						||
`C-c C-e i i     (`org-texinfo-export-to-info')'
 | 
						||
     Export to Texinfo and then process to an Info file(1).
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) By setting `org-texinfo-info-process', it is possible to
 | 
						||
generate other formats, including DocBook.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Texinfo specific export settings,  Next: Document preamble,  Prev: Texinfo export commands,  Up: Texinfo export
 | 
						||
 | 
						||
12.11.2 Texinfo specific export settings
 | 
						||
----------------------------------------
 | 
						||
 | 
						||
The Texinfo exporter introduces a number of keywords, similar to the
 | 
						||
general options settings described in *note Export settings::.
 | 
						||
 | 
						||
`SUBTITLE'
 | 
						||
     The document subtitle.
 | 
						||
 | 
						||
`SUBAUTHOR'
 | 
						||
     The document subauthor.
 | 
						||
 | 
						||
`TEXINFO_FILENAME'
 | 
						||
     The Texinfo filename.
 | 
						||
 | 
						||
`TEXINFO_CLASS'
 | 
						||
     The class of the document (`org-texinfo-default-class').  This
 | 
						||
     must be a member of `org-texinfo-classes'.
 | 
						||
 | 
						||
`TEXINFO_HEADER'
 | 
						||
     Arbitrary lines inserted at the end of the preamble.
 | 
						||
 | 
						||
`TEXINFO_POST_HEADER'
 | 
						||
     Arbitrary lines inserted at the end of the preamble.
 | 
						||
 | 
						||
`TEXINFO_DIR_CATEGORY'
 | 
						||
     The directory category of the document.
 | 
						||
 | 
						||
`TEXINFO_DIR_TITLE'
 | 
						||
     The directory title of the document.
 | 
						||
 | 
						||
`TEXINFO_DIR_DESC'
 | 
						||
     The directory description of the document.
 | 
						||
 | 
						||
`TEXINFO_PRINTED_TITLE'
 | 
						||
     The printed title of the document.
 | 
						||
 | 
						||
   These keywords are treated in details in the following sections.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Document preamble,  Next: Headings and sectioning structure,  Prev: Texinfo specific export settings,  Up: Texinfo export
 | 
						||
 | 
						||
12.11.3 Document preamble
 | 
						||
-------------------------
 | 
						||
 | 
						||
When processing a document, `texinfo' back-end generates a minimal file
 | 
						||
header along with a title page, a copyright page, and a menu.  You
 | 
						||
control the latter through the structure of the document (*note
 | 
						||
Headings and sectioning structure::).  Various keywords allow you to
 | 
						||
tweak the other parts.  It is also possible to give directions to
 | 
						||
install the document in the `Top' node.
 | 
						||
 | 
						||
File header
 | 
						||
...........
 | 
						||
 | 
						||
Upon creating the header of a Texinfo file, the back-end guesses a name
 | 
						||
for the Info file to be compiled.  This may not be a sensible choice,
 | 
						||
e.g., if you want to produce the final document in a different
 | 
						||
directory.  Specify an alternate path with `#+TEXINFO_FILENAME' keyword
 | 
						||
to override the default destination.
 | 
						||
 | 
						||
   Along with the output file name, the header contains information
 | 
						||
about the language (*note Export settings::) and current encoding
 | 
						||
used(1).  Insert a `#+TEXINFO_HEADER' keyword for each additional
 | 
						||
command needed, e.g., @code{@synindex}.
 | 
						||
 | 
						||
   If you happen to regularly install the same set of commands, it may
 | 
						||
be easier to define your own class in `org-texinfo-classes', which see.
 | 
						||
Set `#+TEXINFO_CLASS' keyword accordingly in your document to activate
 | 
						||
it.
 | 
						||
 | 
						||
Title and copyright page
 | 
						||
........................
 | 
						||
 | 
						||
The default template includes a title page for hard copy output.  The
 | 
						||
title and author displayed on this page are extracted from,
 | 
						||
respectively, `#+TITLE' and `#+AUTHOR' keywords (*note Export
 | 
						||
settings::).  It is also possible to print a different, more specific,
 | 
						||
title with `#+TEXINFO_PRINTED_TITLE' keyword, and add subtitles with
 | 
						||
`#+SUBTITLE' keyword.  Both expect raw Texinfo code in their value.
 | 
						||
 | 
						||
   Likewise, information brought by `#+AUTHOR' may not be enough.  You
 | 
						||
can include other authors with several `#+SUBAUTHOR' keywords.  Values
 | 
						||
are also expected to be written in Texinfo code.
 | 
						||
 | 
						||
     #+AUTHOR: Jane Smith
 | 
						||
     #+SUBAUTHOR: John Doe
 | 
						||
     #+TEXINFO_PRINTED_TITLE: This Long Title@inlinefmt{tex,@*} Is Broken in @TeX{}
 | 
						||
 | 
						||
   Copying material is defined in a dedicated headline with a non-`nil'
 | 
						||
`:COPYING:' property.  The contents are inserted within a `@copying'
 | 
						||
command at the beginning of the document whereas the heading itself
 | 
						||
does not appear in the structure of the document.
 | 
						||
 | 
						||
   Copyright information is printed on the back of the title page.
 | 
						||
 | 
						||
     * Copying
 | 
						||
       :PROPERTIES:
 | 
						||
       :COPYING: t
 | 
						||
       :END:
 | 
						||
 | 
						||
       This is a short example of a complete Texinfo file, version 1.0.
 | 
						||
 | 
						||
       Copyright \copy 2016 Free Software Foundation, Inc.
 | 
						||
 | 
						||
The Top node
 | 
						||
............
 | 
						||
 | 
						||
You may ultimately want to install your new Info file in your system.
 | 
						||
You can write an appropriate entry in the top level directory
 | 
						||
specifying its category and title with, respectively,
 | 
						||
`#+TEXINFO_DIR_CATEGORY' and `#+TEXINFO_DIR_TITLE'.  Optionally, you
 | 
						||
can add a short description using `#+TEXINFO_DIR_DESC'.  The following
 | 
						||
example would write an entry similar to Org's in the `Top' node.
 | 
						||
 | 
						||
     #+TEXINFO_DIR_CATEGORY: Emacs
 | 
						||
     #+TEXINFO_DIR_TITLE: Org Mode: (org)
 | 
						||
     #+TEXINFO_DIR_DESC: Outline-based notes management and organizer
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) See `org-texinfo-coding-system' for more information.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Headings and sectioning structure,  Next: Indices,  Prev: Document preamble,  Up: Texinfo export
 | 
						||
 | 
						||
12.11.4 Headings and sectioning structure
 | 
						||
-----------------------------------------
 | 
						||
 | 
						||
`texinfo' uses a pre-defined scheme, or class, to convert headlines into
 | 
						||
Texinfo structuring commands.  For example, a top level headline
 | 
						||
appears as `@chapter' if it should be numbered or as `@unnumbered'
 | 
						||
otherwise.  If you need to use a different set of commands, e.g., to
 | 
						||
start with `@part' instead of `@chapter', install a new class in
 | 
						||
`org-texinfo-classes', then activate it with `#+TEXINFO_CLASS' keyword.
 | 
						||
Export process defaults to `org-texinfo-default-class' when there is no
 | 
						||
such keyword in the document.
 | 
						||
 | 
						||
   If a headline's level has no associated structuring command, or is
 | 
						||
below a certain threshold (*note Export settings::), that headline
 | 
						||
becomes a list in Texinfo output.
 | 
						||
 | 
						||
   As an exception, a headline with a non-`nil' `:APPENDIX:' property
 | 
						||
becomes an appendix, independently on its level and the class used.
 | 
						||
 | 
						||
   Each regular sectioning structure creates a menu entry, named after
 | 
						||
the heading.  You can provide a different, e.g., shorter, title in
 | 
						||
`:ALT_TITLE:' property (*note Table of contents::).  Optionally, you can
 | 
						||
specify a description for the item in `:DESCRIPTION:' property.  E.g.,
 | 
						||
 | 
						||
     * Controlling Screen Display
 | 
						||
       :PROPERTIES:
 | 
						||
       :ALT_TITLE: Display
 | 
						||
       :DESCRIPTION: Controlling Screen Display
 | 
						||
       :END:
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Indices,  Next: Quoting Texinfo code,  Prev: Headings and sectioning structure,  Up: Texinfo export
 | 
						||
 | 
						||
12.11.5 Indices
 | 
						||
---------------
 | 
						||
 | 
						||
Index entries are created using dedicated keywords.  `texinfo' back-end
 | 
						||
provides one for each predefined type: `#+CINDEX', `#+FINDEX',
 | 
						||
`#+KINDEX', `#+PINDEX', `#+TINDEX' and `#+VINDEX'.  For custom indices,
 | 
						||
you can write raw Texinfo code (*note Quoting Texinfo code::).
 | 
						||
 | 
						||
     #+CINDEX: Defining indexing entries
 | 
						||
 | 
						||
   To generate an index, you need to set the `:INDEX:' property of a
 | 
						||
headline to an appropriate abbreviation (e.g., `cp' or `vr').  The
 | 
						||
headline is then exported as an unnumbered chapter or section command
 | 
						||
and the index is inserted after its contents.
 | 
						||
 | 
						||
     * Concept Index
 | 
						||
       :PROPERTIES:
 | 
						||
       :INDEX: cp
 | 
						||
       :END:
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Quoting Texinfo code,  Next: Texinfo specific attributes,  Prev: Indices,  Up: Texinfo export
 | 
						||
 | 
						||
12.11.6 Quoting Texinfo code
 | 
						||
----------------------------
 | 
						||
 | 
						||
It is possible to insert raw Texinfo code using any of the following
 | 
						||
constructs
 | 
						||
 | 
						||
     Richard @@texinfo:@sc{@@Stallman@@texinfo:}@@ commence' GNU.
 | 
						||
 | 
						||
     #+TEXINFO: @need800
 | 
						||
     This paragraph is preceded by...
 | 
						||
 | 
						||
     #+BEGIN_TEXINFO
 | 
						||
     @auindex Johnson, Mark
 | 
						||
     @auindex Lakoff, George
 | 
						||
     #+END_TEXINFO
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Texinfo specific attributes,  Next: An example,  Prev: Quoting Texinfo code,  Up: Texinfo export
 | 
						||
 | 
						||
12.11.7 Texinfo specific attributes
 | 
						||
-----------------------------------
 | 
						||
 | 
						||
`texinfo' back-end understands several attributes in plain lists, tables
 | 
						||
and images.  They must be specified using an `#+ATTR_TEXINFO' keyword,
 | 
						||
written just above the list, table or image.
 | 
						||
 | 
						||
Plain lists
 | 
						||
...........
 | 
						||
 | 
						||
In Texinfo output, description lists appear as two-column tables, using
 | 
						||
the default command `@table'.  You can use `@ftable' or `@vtable'(1)
 | 
						||
instead with `:table-type' attribute.
 | 
						||
 | 
						||
   In any case, these constructs require a highlighting command for
 | 
						||
entries in the list.  You can provide one with `:indic' attribute.  If
 | 
						||
you do not, it defaults to the value stored in
 | 
						||
`org-texinfo-def-table-markup', which see.
 | 
						||
 | 
						||
     #+ATTR_TEXINFO: :indic @asis
 | 
						||
     - foo :: This is the text for /foo/, with no highlighting.
 | 
						||
 | 
						||
Tables
 | 
						||
......
 | 
						||
 | 
						||
When exporting a table, column widths are deduced from the longest cell
 | 
						||
in each column.  You can also define them explicitly as fractions of
 | 
						||
the line length, using `:columns' attribute.
 | 
						||
 | 
						||
     #+ATTR_TEXINFO: :columns .5 .5
 | 
						||
     | a cell | another cell |
 | 
						||
 | 
						||
Images
 | 
						||
......
 | 
						||
 | 
						||
Images are links to files with a supported image extension and no
 | 
						||
description.  Image scaling is set with `:width' and `:height'
 | 
						||
attributes.  You can also use `:alt' to specify alternate text, as
 | 
						||
Texinfo code.
 | 
						||
 | 
						||
     #+ATTR_TEXINFO: :width 1in :alt Alternate @i{text}
 | 
						||
     [[ridt.pdf]]
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) For more information, *note (texinfo)Two-column Tables::.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: An example,  Prev: Texinfo specific attributes,  Up: Texinfo export
 | 
						||
 | 
						||
12.11.8 An example
 | 
						||
------------------
 | 
						||
 | 
						||
Here is a thorough example.  *note (texinfo)GNU Sample Texts:: for an
 | 
						||
equivalent Texinfo code.
 | 
						||
 | 
						||
     #+MACRO: version 2.0
 | 
						||
     #+MACRO: updated last updated 4 March 2014
 | 
						||
 | 
						||
     #+OPTIONS: ':t toc:t author:t email:t
 | 
						||
     #+TITLE: GNU Sample {{{version}}}
 | 
						||
     #+AUTHOR: A.U. Thor
 | 
						||
     #+EMAIL: bug-sample@gnu.org
 | 
						||
     #+LANGUAGE: en
 | 
						||
 | 
						||
     #+TEXINFO_FILENAME: sample.info
 | 
						||
     #+TEXINFO_HEADER: @syncodeindex pg cp
 | 
						||
 | 
						||
     #+TEXINFO_DIR_CATEGORY: Texinfo documentation system
 | 
						||
     #+TEXINFO_DIR_TITLE: sample: (sample)
 | 
						||
     #+TEXINFO_DIR_DESC: Invoking sample
 | 
						||
 | 
						||
     #+TEXINFO_PRINTED_TITLE: GNU Sample
 | 
						||
     #+SUBTITLE: for version {{{version}}}, {{{updated}}}
 | 
						||
 | 
						||
     * Copying
 | 
						||
       :PROPERTIES:
 | 
						||
       :COPYING:  t
 | 
						||
       :END:
 | 
						||
 | 
						||
       This manual is for GNU Sample (version {{{version}}},
 | 
						||
       {{{updated}}}), which is an example in the Texinfo documentation.
 | 
						||
 | 
						||
       Copyright @@texinfo:@copyright{}@@ 2013 Free Software Foundation,
 | 
						||
       Inc.
 | 
						||
 | 
						||
       #+BEGIN_QUOTE
 | 
						||
       Permission is granted to copy, distribute and/or modify this
 | 
						||
       document under the terms of the GNU Free Documentation License,
 | 
						||
       Version 1.3 or any later version published by the Free Software
 | 
						||
       Foundation; with no Invariant Sections, with no Front-Cover Texts,
 | 
						||
       and with no Back-Cover Texts.  A copy of the license is included in
 | 
						||
       the section entitled "GNU Free Documentation License".
 | 
						||
       #+END_QUOTE
 | 
						||
 | 
						||
     * Invoking sample
 | 
						||
 | 
						||
       #+PINDEX: sample
 | 
						||
       #+CINDEX: invoking @command{sample}
 | 
						||
 | 
						||
       This is a sample manual.  There is no sample program to invoke, but
 | 
						||
       if there were, you could see its basic usage and command line
 | 
						||
       options here.
 | 
						||
 | 
						||
     * GNU Free Documentation License
 | 
						||
       :PROPERTIES:
 | 
						||
       :APPENDIX: t
 | 
						||
       :END:
 | 
						||
 | 
						||
       #+TEXINFO: @include fdl.texi
 | 
						||
 | 
						||
     * Index
 | 
						||
       :PROPERTIES:
 | 
						||
       :INDEX:    cp
 | 
						||
       :END:
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: iCalendar export,  Next: Other built-in back-ends,  Prev: Texinfo export,  Up: Exporting
 | 
						||
 | 
						||
12.12 iCalendar export
 | 
						||
======================
 | 
						||
 | 
						||
Some people use Org mode for keeping track of projects, but still
 | 
						||
prefer a standard calendar application for anniversaries and
 | 
						||
appointments.  In this case it can be useful to show deadlines and
 | 
						||
other time-stamped items in Org files in the calendar application.  Org
 | 
						||
mode can export calendar information in the standard iCalendar format.
 | 
						||
If you also want to have TODO entries included in the export, configure
 | 
						||
the variable `org-icalendar-include-todo'.  Plain timestamps are
 | 
						||
exported as VEVENT, and TODO items as VTODO.  It will also create
 | 
						||
events from deadlines that are in non-TODO items.  Deadlines and
 | 
						||
scheduling dates in TODO items will be used to set the start and due
 | 
						||
dates for the TODO entry(1).  As categories, it will use the tags
 | 
						||
locally defined in the heading, and the file/tree category(2).  See the
 | 
						||
variable `org-icalendar-alarm-time' for a way to assign alarms to
 | 
						||
entries with a time.
 | 
						||
 | 
						||
   The iCalendar standard requires each entry to have a globally unique
 | 
						||
identifier (UID).  Org creates these identifiers during export.  If you
 | 
						||
set the variable `org-icalendar-store-UID', the UID will be stored in
 | 
						||
the `:ID:' property of the entry and re-used next time you report this
 | 
						||
entry.  Since a single entry can give rise to multiple iCalendar
 | 
						||
entries (as a timestamp, a deadline, a scheduled item, and as a TODO
 | 
						||
item), Org adds prefixes to the UID, depending on what triggered the
 | 
						||
inclusion of the entry.  In this way the UID remains unique, but a
 | 
						||
synchronization program can still figure out from which entry all the
 | 
						||
different instances originate.
 | 
						||
 | 
						||
`C-c C-e c f     (`org-icalendar-export-to-ics')'
 | 
						||
     Create iCalendar entries for the current buffer and store them in
 | 
						||
     the same directory, using a file extension `.ics'.  
 | 
						||
 | 
						||
`C-c C-e c a     (`org-icalendar-export-agenda-files')'
 | 
						||
     Like `C-c C-e c f', but do this for all files in
 | 
						||
     `org-agenda-files'.  For each of these files, a separate iCalendar
 | 
						||
     file will be written.  
 | 
						||
 | 
						||
`C-c C-e c c     (`org-icalendar-combine-agenda-files')'
 | 
						||
     Create a single large iCalendar file from all files in
 | 
						||
     `org-agenda-files' and write it to the file given by
 | 
						||
     `org-icalendar-combined-agenda-file'.
 | 
						||
 | 
						||
   The export will honor SUMMARY, DESCRIPTION and LOCATION(3)
 | 
						||
properties if the selected entries have them.  If not, the summary will
 | 
						||
be derived from the headline, and the description from the body
 | 
						||
(limited to `org-icalendar-include-body' characters).
 | 
						||
 | 
						||
   How this calendar is best read and updated, depends on the
 | 
						||
application you are using.  The FAQ covers this issue.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) See the variables `org-icalendar-use-deadline' and
 | 
						||
`org-icalendar-use-scheduled'.
 | 
						||
 | 
						||
   (2) To add inherited tags or the TODO state, configure the variable
 | 
						||
`org-icalendar-categories'.
 | 
						||
 | 
						||
   (3) The LOCATION property can be inherited from higher in the
 | 
						||
hierarchy if you configure `org-use-property-inheritance' accordingly.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Other built-in back-ends,  Next: Export in foreign buffers,  Prev: iCalendar export,  Up: Exporting
 | 
						||
 | 
						||
12.13 Other built-in back-ends
 | 
						||
==============================
 | 
						||
 | 
						||
On top of the aforementioned back-ends, Org comes with other built-in
 | 
						||
ones:
 | 
						||
 | 
						||
   * `ox-man.el': export to a man page.
 | 
						||
 | 
						||
   To activate these export back-end, customize `org-export-backends' or
 | 
						||
load them directly with e.g., `(require 'ox-man)'.  This will add new
 | 
						||
keys in the export dispatcher (*note The export dispatcher::).
 | 
						||
 | 
						||
   See the comment section of these files for more information on how
 | 
						||
to use them.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Export in foreign buffers,  Next: Advanced configuration,  Prev: Other built-in back-ends,  Up: Exporting
 | 
						||
 | 
						||
12.14 Export in foreign buffers
 | 
						||
===============================
 | 
						||
 | 
						||
Most built-in back-ends come with a command to convert the selected
 | 
						||
region into a selected format and replace this region by the exported
 | 
						||
output.  Here is a list of such conversion commands:
 | 
						||
 | 
						||
`org-html-convert-region-to-html'
 | 
						||
     Convert the selected region into HTML.
 | 
						||
 | 
						||
`org-latex-convert-region-to-latex'
 | 
						||
     Convert the selected region into LaTeX.
 | 
						||
 | 
						||
`org-texinfo-convert-region-to-texinfo'
 | 
						||
     Convert the selected region into `Texinfo'.
 | 
						||
 | 
						||
`org-md-convert-region-to-md'
 | 
						||
     Convert the selected region into `MarkDown'.
 | 
						||
 | 
						||
   This is particularly useful for converting tables and lists in
 | 
						||
foreign buffers.  E.g., in an HTML buffer, you can turn on
 | 
						||
`orgstruct-mode', then use Org commands for editing a list, and finally
 | 
						||
select and convert the list with `M-x org-html-convert-region-to-html
 | 
						||
RET'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Advanced configuration,  Prev: Export in foreign buffers,  Up: Exporting
 | 
						||
 | 
						||
12.15 Advanced configuration
 | 
						||
============================
 | 
						||
 | 
						||
Hooks
 | 
						||
-----
 | 
						||
 | 
						||
Two hooks are run during the first steps of the export process.  The
 | 
						||
first one, `org-export-before-processing-hook' is called before
 | 
						||
expanding macros, Babel code and include keywords in the buffer.  The
 | 
						||
second one, `org-export-before-parsing-hook', as its name suggests,
 | 
						||
happens just before parsing the buffer.  Their main use is for heavy
 | 
						||
duties, that is duties involving structural modifications of the
 | 
						||
document.  For example, one may want to remove every headline in the
 | 
						||
buffer during export.  The following code can achieve this:
 | 
						||
 | 
						||
     (defun my-headline-removal (backend)
 | 
						||
       "Remove all headlines in the current buffer.
 | 
						||
     BACKEND is the export back-end being used, as a symbol."
 | 
						||
       (org-map-entries
 | 
						||
        (lambda () (delete-region (point) (progn (forward-line) (point))))))
 | 
						||
 | 
						||
     (add-hook 'org-export-before-parsing-hook 'my-headline-removal)
 | 
						||
 | 
						||
   Note that functions used in these hooks require a mandatory argument,
 | 
						||
a symbol representing the back-end used.
 | 
						||
 | 
						||
Filters
 | 
						||
-------
 | 
						||
 | 
						||
Filters are lists of functions applied on a specific part of the output
 | 
						||
from a given back-end.  More explicitly, each time a back-end
 | 
						||
transforms an Org object or element into another language, all
 | 
						||
functions within a given filter type are called in turn on the string
 | 
						||
produced.  The string returned by the last function will be the one
 | 
						||
used in the final output.
 | 
						||
 | 
						||
   There are filter sets for each type of element or object, for plain
 | 
						||
text, for the parse tree, for the export options and for the final
 | 
						||
output.  They are all named after the same scheme:
 | 
						||
`org-export-filter-TYPE-functions', where `TYPE' is the type targeted
 | 
						||
by the filter.  Valid types are:
 | 
						||
 | 
						||
body                     bold                     babel-call
 | 
						||
center-block             clock                    code
 | 
						||
diary-sexp               drawer                   dynamic-block
 | 
						||
entity                   example-block            export-block
 | 
						||
export-snippet           final-output             fixed-width
 | 
						||
footnote-definition      footnote-reference       headline
 | 
						||
horizontal-rule          inline-babel-call        inline-src-block
 | 
						||
inlinetask               italic                   item
 | 
						||
keyword                  latex-environment        latex-fragment
 | 
						||
line-break               link                     node-property
 | 
						||
options                  paragraph                parse-tree
 | 
						||
plain-list               plain-text               planning
 | 
						||
property-drawer          quote-block              radio-target
 | 
						||
section                  special-block            src-block
 | 
						||
statistics-cookie        strike-through           subscript
 | 
						||
superscript              table                    table-cell
 | 
						||
table-row                target                   timestamp
 | 
						||
underline                verbatim                 verse-block
 | 
						||
 | 
						||
   For example, the following snippet allows me to use non-breaking
 | 
						||
spaces in the Org buffer and get them translated into LaTeX without
 | 
						||
using the `\nbsp' macro (where `_' stands for the non-breaking space):
 | 
						||
 | 
						||
     (defun my-latex-filter-nobreaks (text backend info)
 | 
						||
       "Ensure \"_\" are properly handled in LaTeX export."
 | 
						||
       (when (org-export-derived-backend-p backend 'latex)
 | 
						||
             (replace-regexp-in-string "_" "~" text)))
 | 
						||
 | 
						||
     (add-to-list 'org-export-filter-plain-text-functions
 | 
						||
                  'my-latex-filter-nobreaks)
 | 
						||
 | 
						||
   Three arguments must be provided to a filter: the code being
 | 
						||
changed, the back-end used, and some information about the export
 | 
						||
process.  You can safely ignore the third argument for most purposes.
 | 
						||
Note the use of `org-export-derived-backend-p', which ensures that the
 | 
						||
filter will only be applied when using `latex' back-end or any other
 | 
						||
back-end derived from it (e.g., `beamer').
 | 
						||
 | 
						||
Defining filters for individual files
 | 
						||
-------------------------------------
 | 
						||
 | 
						||
You can customize the export for just a specific file by binding export
 | 
						||
filter variables using `#+BIND'.  Here is an example where we introduce
 | 
						||
two filters, one to remove brackets from time stamps, and one to
 | 
						||
entirely remove any strike-through text.  The functions doing the
 | 
						||
filtering are defined in an src block that allows the filter function
 | 
						||
definitions to exist in the file itself and ensures that the functions
 | 
						||
will be there when needed.
 | 
						||
 | 
						||
     #+BIND: org-export-filter-timestamp-functions (tmp-f-timestamp)
 | 
						||
     #+BIND: org-export-filter-strike-through-functions (tmp-f-strike-through)
 | 
						||
     #+begin_src emacs-lisp :exports results :results none
 | 
						||
       (defun tmp-f-timestamp (s backend info)
 | 
						||
         (replace-regexp-in-string "&[lg]t;\\|[][]" "" s))
 | 
						||
       (defun tmp-f-strike-through (s backend info) "")
 | 
						||
     #+end_src
 | 
						||
 | 
						||
Extending an existing back-end
 | 
						||
------------------------------
 | 
						||
 | 
						||
This is obviously the most powerful customization, since the changes
 | 
						||
happen at the parser level.  Indeed, some export back-ends are built as
 | 
						||
extensions of other ones (e.g., Markdown back-end an extension of HTML
 | 
						||
back-end).
 | 
						||
 | 
						||
   Extending a back-end means that if an element type is not transcoded
 | 
						||
by the new back-end, it will be handled by the original one.  Hence you
 | 
						||
can extend specific parts of a back-end without too much work.
 | 
						||
 | 
						||
   As an example, imagine we want the `ascii' back-end to display the
 | 
						||
language used in a source block, when it is available, but only when
 | 
						||
some attribute is non-`nil', like the following:
 | 
						||
 | 
						||
     #+ATTR_ASCII: :language t
 | 
						||
 | 
						||
   Because that back-end is lacking in that area, we are going to
 | 
						||
create a new back-end, `my-ascii' that will do the job.
 | 
						||
 | 
						||
     (defun my-ascii-src-block (src-block contents info)
 | 
						||
       "Transcode a SRC-BLOCK element from Org to ASCII.
 | 
						||
     CONTENTS is nil.  INFO is a plist used as a communication
 | 
						||
     channel."
 | 
						||
       (if (not (org-export-read-attribute :attr_ascii src-block :language))
 | 
						||
         (org-export-with-backend 'ascii src-block contents info)
 | 
						||
       (concat
 | 
						||
        (format ",--[ %s ]--\n%s`----"
 | 
						||
                (org-element-property :language src-block)
 | 
						||
                (replace-regexp-in-string
 | 
						||
                 "^" "| "
 | 
						||
                 (org-element-normalize-string
 | 
						||
                  (org-export-format-code-default src-block info)))))))
 | 
						||
 | 
						||
     (org-export-define-derived-backend 'my-ascii 'ascii
 | 
						||
       :translate-alist '((src-block . my-ascii-src-block)))
 | 
						||
 | 
						||
   The `my-ascii-src-block' function looks at the attribute above the
 | 
						||
element.  If it isn't true, it gives hand to the `ascii' back-end.
 | 
						||
Otherwise, it creates a box around the code, leaving room for the
 | 
						||
language.  A new back-end is then created.  It only changes its
 | 
						||
behavior when translating `src-block' type element.  Now, all it takes
 | 
						||
to use the new back-end is calling the following from an Org buffer:
 | 
						||
 | 
						||
     (org-export-to-buffer 'my-ascii "*Org MY-ASCII Export*")
 | 
						||
 | 
						||
   It is obviously possible to write an interactive function for this,
 | 
						||
install it in the export dispatcher menu, and so on.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Publishing,  Next: Working with source code,  Prev: Exporting,  Up: Top
 | 
						||
 | 
						||
13 Publishing
 | 
						||
*************
 | 
						||
 | 
						||
Org includes a publishing management system that allows you to configure
 | 
						||
automatic HTML conversion of _projects_ composed of interlinked org
 | 
						||
files.  You can also configure Org to automatically upload your
 | 
						||
exported HTML pages and related attachments, such as images and source
 | 
						||
code files, to a web server.
 | 
						||
 | 
						||
   You can also use Org to convert files into PDF, or even combine HTML
 | 
						||
and PDF conversion so that files are available in both formats on the
 | 
						||
server.
 | 
						||
 | 
						||
   Publishing has been contributed to Org by David O'Toole.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Configuration::               Defining projects
 | 
						||
* Uploading files::             How to get files up on the server
 | 
						||
* Sample configuration::        Example projects
 | 
						||
* Triggering publication::      Publication commands
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Configuration,  Next: Uploading files,  Up: Publishing
 | 
						||
 | 
						||
13.1 Configuration
 | 
						||
==================
 | 
						||
 | 
						||
Publishing needs significant configuration to specify files, destination
 | 
						||
and many other properties of a project.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Project alist::               The central configuration variable
 | 
						||
* Sources and destinations::    From here to there
 | 
						||
* Selecting files::             What files are part of the project?
 | 
						||
* Publishing action::           Setting the function doing the publishing
 | 
						||
* Publishing options::          Tweaking HTML/LaTeX export
 | 
						||
* Publishing links::            Which links keep working after publishing?
 | 
						||
* Sitemap::                     Generating a list of all pages
 | 
						||
* Generating an index::         An index that reaches across pages
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Project alist,  Next: Sources and destinations,  Up: Configuration
 | 
						||
 | 
						||
13.1.1 The variable `org-publish-project-alist'
 | 
						||
-----------------------------------------------
 | 
						||
 | 
						||
Publishing is configured almost entirely through setting the value of
 | 
						||
one variable, called `org-publish-project-alist'.  Each element of the
 | 
						||
list configures one project, and may be in one of the two following
 | 
						||
forms:
 | 
						||
 | 
						||
        ("project-name" :property value :property value ...)
 | 
						||
          i.e., a well-formed property list with alternating keys and values
 | 
						||
     or
 | 
						||
        ("project-name" :components ("project-name" "project-name" ...))
 | 
						||
 | 
						||
   In both cases, projects are configured by specifying property
 | 
						||
values.  A project defines the set of files that will be published, as
 | 
						||
well as the publishing configuration to use when publishing those
 | 
						||
files.  When a project takes the second form listed above, the
 | 
						||
individual members of the `:components' property are taken to be
 | 
						||
sub-projects, which group together files requiring different publishing
 | 
						||
options.  When you publish such a "meta-project", all the components
 | 
						||
will also be published, in the sequence given.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Sources and destinations,  Next: Selecting files,  Prev: Project alist,  Up: Configuration
 | 
						||
 | 
						||
13.1.2 Sources and destinations for files
 | 
						||
-----------------------------------------
 | 
						||
 | 
						||
Most properties are optional, but some should always be set.  In
 | 
						||
particular, Org needs to know where to look for source files, and where
 | 
						||
to put published files.
 | 
						||
 | 
						||
`:base-directory'      Directory containing publishing source files
 | 
						||
`:publishing-directory'Directory where output files will be published.
 | 
						||
                       You can directly publish to a web server using a
 | 
						||
                       file name syntax appropriate for the Emacs
 | 
						||
                       `tramp' package.  Or you can publish to a local
 | 
						||
                       directory and use external tools to upload your
 | 
						||
                       website (*note Uploading files::).
 | 
						||
`:preparation-function'Function or list of functions to be called before
 | 
						||
                       starting the publishing process, for example, to
 | 
						||
                       run `make' for updating files to be published.
 | 
						||
                       The project property list is scoped into this
 | 
						||
                       call as the variable `project-plist'.
 | 
						||
`:completion-function' Function or list of functions called after
 | 
						||
                       finishing the publishing process, for example, to
 | 
						||
                       change permissions of the resulting files.  The
 | 
						||
                       project property list is scoped into this call as
 | 
						||
                       the variable `project-plist'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Selecting files,  Next: Publishing action,  Prev: Sources and destinations,  Up: Configuration
 | 
						||
 | 
						||
13.1.3 Selecting files
 | 
						||
----------------------
 | 
						||
 | 
						||
By default, all files with extension `.org' in the base directory are
 | 
						||
considered part of the project.  This can be modified by setting the
 | 
						||
properties
 | 
						||
`:base-extension'  Extension (without the dot!) of source files.  This
 | 
						||
                   actually is a regular expression.  Set this to the
 | 
						||
                   symbol `any' if you want to get all files in
 | 
						||
                   `:base-directory', even without extension.
 | 
						||
`:exclude'         Regular expression to match file names that should
 | 
						||
                   not be published, even though they have been selected
 | 
						||
                   on the basis of their extension.
 | 
						||
`:include'         List of files to be included regardless of
 | 
						||
                   `:base-extension' and `:exclude'.
 | 
						||
`:recursive'       non-`nil' means, check base-directory recursively for
 | 
						||
                   files to publish.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Publishing action,  Next: Publishing options,  Prev: Selecting files,  Up: Configuration
 | 
						||
 | 
						||
13.1.4 Publishing action
 | 
						||
------------------------
 | 
						||
 | 
						||
Publishing means that a file is copied to the destination directory and
 | 
						||
possibly transformed in the process.  The default transformation is to
 | 
						||
export Org files as HTML files, and this is done by the function
 | 
						||
`org-html-publish-to-html', which calls the HTML exporter (*note HTML
 | 
						||
export::).  But you also can publish your content as PDF files using
 | 
						||
`org-latex-publish-to-pdf' or as `ascii', `Texinfo', etc., using the
 | 
						||
corresponding functions.
 | 
						||
 | 
						||
   If you want to publish the Org file as an `.org' file but with the
 | 
						||
archived, commented and tag-excluded trees removed, use the function
 | 
						||
`org-org-publish-to-org'.  This will produce `file.org' and put it in
 | 
						||
the publishing directory.  If you want a htmlized version of this file,
 | 
						||
set the parameter `:htmlized-source' to `t', it will produce
 | 
						||
`file.org.html' in the publishing directory(1).
 | 
						||
 | 
						||
   Other files like images only need to be copied to the publishing
 | 
						||
destination.  For this you can use `org-publish-attachment'.  For
 | 
						||
non-org files, you always need to specify the publishing function:
 | 
						||
 | 
						||
`:publishing-function' Function executing the publication of a file.
 | 
						||
                       This may also be a list of functions, which will
 | 
						||
                       all be called in turn.
 | 
						||
`:htmlized-source'     non-`nil' means, publish htmlized source.
 | 
						||
 | 
						||
   The function must accept three arguments: a property list containing
 | 
						||
at least a `:publishing-directory' property, the name of the file to be
 | 
						||
published and the path to the publishing directory of the output file.
 | 
						||
It should take the specified file, make the necessary transformation
 | 
						||
(if any) and place the result into the destination folder.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) If the publishing directory is the same than the source
 | 
						||
directory, `file.org' will be exported as `file.org.org', so probably
 | 
						||
don't want to do this.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Publishing options,  Next: Publishing links,  Prev: Publishing action,  Up: Configuration
 | 
						||
 | 
						||
13.1.5 Options for the exporters
 | 
						||
--------------------------------
 | 
						||
 | 
						||
The property list can be used to set export options during the
 | 
						||
publishing process.  In most cases, these properties correspond to user
 | 
						||
variables in Org.  While some properties are available for all export
 | 
						||
back-ends, most of them are back-end specific.  The following sections
 | 
						||
list properties along with the variable they belong to.  See the
 | 
						||
documentation string of these options for details.
 | 
						||
 | 
						||
   When a property is given a value in `org-publish-project-alist', its
 | 
						||
setting overrides the value of the corresponding user variable (if any)
 | 
						||
during publishing.  Options set within a file (*note Export settings::),
 | 
						||
however, override everything.
 | 
						||
 | 
						||
Generic properties
 | 
						||
..................
 | 
						||
 | 
						||
`:archived-trees'         `org-export-with-archived-trees'
 | 
						||
`:exclude-tags'           `org-export-exclude-tags'
 | 
						||
`:headline-levels'        `org-export-headline-levels'
 | 
						||
`:language'               `org-export-default-language'
 | 
						||
`:preserve-breaks'        `org-export-preserve-breaks'
 | 
						||
`:section-numbers'        `org-export-with-section-numbers'
 | 
						||
`:select-tags'            `org-export-select-tags'
 | 
						||
`:with-author'            `org-export-with-author'
 | 
						||
`:with-creator'           `org-export-with-creator'
 | 
						||
`:with-date'              `org-export-with-date'
 | 
						||
`:with-drawers'           `org-export-with-drawers'
 | 
						||
`:with-email'             `org-export-with-email'
 | 
						||
`:with-emphasize'         `org-export-with-emphasize'
 | 
						||
`:with-fixed-width'       `org-export-with-fixed-width'
 | 
						||
`:with-footnotes'         `org-export-with-footnotes'
 | 
						||
`:with-latex'             `org-export-with-latex'
 | 
						||
`:with-planning'          `org-export-with-planning'
 | 
						||
`:with-priority'          `org-export-with-priority'
 | 
						||
`:with-properties'        `org-export-with-properties'
 | 
						||
`:with-special-strings'   `org-export-with-special-strings'
 | 
						||
`:with-sub-superscript'   `org-export-with-sub-superscripts'
 | 
						||
`:with-tables'            `org-export-with-tables'
 | 
						||
`:with-tags'              `org-export-with-tags'
 | 
						||
`:with-tasks'             `org-export-with-tasks'
 | 
						||
`:with-timestamps'        `org-export-with-timestamps'
 | 
						||
`:with-title'             `org-export-with-title'
 | 
						||
`:with-toc'               `org-export-with-toc'
 | 
						||
`:with-todo-keywords'     `org-export-with-todo-keywords'
 | 
						||
 | 
						||
ASCII specific properties
 | 
						||
.........................
 | 
						||
 | 
						||
`:ascii-bullets'                         `org-ascii-bullets'
 | 
						||
`:ascii-caption-above'                   `org-ascii-caption-above'
 | 
						||
`:ascii-charset'                         `org-ascii-charset'
 | 
						||
`:ascii-global-margin'                   `org-ascii-global-margin'
 | 
						||
`:ascii-format-drawer-function'          `org-ascii-format-drawer-function'
 | 
						||
`:ascii-format-inlinetask-function'      `org-ascii-format-inlinetask-function'
 | 
						||
`:ascii-headline-spacing'                `org-ascii-headline-spacing'
 | 
						||
`:ascii-indented-line-width'             `org-ascii-indented-line-width'
 | 
						||
`:ascii-inlinetask-width'                `org-ascii-inlinetask-width'
 | 
						||
`:ascii-inner-margin'                    `org-ascii-inner-margin'
 | 
						||
`:ascii-links-to-notes'                  `org-ascii-links-to-notes'
 | 
						||
`:ascii-list-margin'                     `org-ascii-list-margin'
 | 
						||
`:ascii-paragraph-spacing'               `org-ascii-paragraph-spacing'
 | 
						||
`:ascii-quote-margin'                    `org-ascii-quote-margin'
 | 
						||
`:ascii-table-keep-all-vertical-lines'   `org-ascii-table-keep-all-vertical-lines'
 | 
						||
`:ascii-table-use-ascii-art'             `org-ascii-table-use-ascii-art'
 | 
						||
`:ascii-table-widen-columns'             `org-ascii-table-widen-columns'
 | 
						||
`:ascii-text-width'                      `org-ascii-text-width'
 | 
						||
`:ascii-underline'                       `org-ascii-underline'
 | 
						||
`:ascii-verbatim-format'                 `org-ascii-verbatim-format'
 | 
						||
 | 
						||
Beamer specific properties
 | 
						||
..........................
 | 
						||
 | 
						||
`:beamer-theme'                   `org-beamer-theme'
 | 
						||
`:beamer-column-view-format'      `org-beamer-column-view-format'
 | 
						||
`:beamer-environments-extra'      `org-beamer-environments-extra'
 | 
						||
`:beamer-frame-default-options'   `org-beamer-frame-default-options'
 | 
						||
`:beamer-outline-frame-options'   `org-beamer-outline-frame-options'
 | 
						||
`:beamer-outline-frame-title'     `org-beamer-outline-frame-title'
 | 
						||
`:beamer-subtitle-format'         `org-beamer-subtitle-format'
 | 
						||
 | 
						||
HTML specific properties
 | 
						||
........................
 | 
						||
 | 
						||
`:html-allow-name-attribute-in-anchors'          `org-html-allow-name-attribute-in-anchors'
 | 
						||
`:html-checkbox-type'                            `org-html-checkbox-type'
 | 
						||
`:html-container'                                `org-html-container-element'
 | 
						||
`:html-divs'                                     `org-html-divs'
 | 
						||
`:html-doctype'                                  `org-html-doctype'
 | 
						||
`:html-extension'                                `org-html-extension'
 | 
						||
`:html-footnote-format'                          `org-html-footnote-format'
 | 
						||
`:html-footnote-separator'                       `org-html-footnote-separator'
 | 
						||
`:html-footnotes-section'                        `org-html-footnotes-section'
 | 
						||
`:html-format-drawer-function'                   `org-html-format-drawer-function'
 | 
						||
`:html-format-headline-function'                 `org-html-format-headline-function'
 | 
						||
`:html-format-inlinetask-function'               `org-html-format-inlinetask-function'
 | 
						||
`:html-head-extra'                               `org-html-head-extra'
 | 
						||
`:html-head-include-default-style'               `org-html-head-include-default-style'
 | 
						||
`:html-head-include-scripts'                     `org-html-head-include-scripts'
 | 
						||
`:html-head'                                     `org-html-head'
 | 
						||
`:html-home/up-format'                           `org-html-home/up-format'
 | 
						||
`:html-html5-fancy'                              `org-html-html5-fancy'
 | 
						||
`:html-indent'                                   `org-html-indent'
 | 
						||
`:html-infojs-options'                           `org-html-infojs-options'
 | 
						||
`:html-infojs-template'                          `org-html-infojs-template'
 | 
						||
`:html-inline-image-rules'                       `org-html-inline-image-rules'
 | 
						||
`:html-inline-images'                            `org-html-inline-images'
 | 
						||
`:html-link-home'                                `org-html-link-home'
 | 
						||
`:html-link-org-files-as-html'                   `org-html-link-org-files-as-html'
 | 
						||
`:html-link-up'                                  `org-html-link-up'
 | 
						||
`:html-link-use-abs-url'                         `org-html-link-use-abs-url'
 | 
						||
`:html-mathjax-options'                          `org-html-mathjax-options'
 | 
						||
`:html-mathjax-template'                         `org-html-mathjax-template'
 | 
						||
`:html-metadata-timestamp-format'                `org-html-metadata-timestamp-format'
 | 
						||
`:html-postamble-format'                         `org-html-postamble-format'
 | 
						||
`:html-postamble'                                `org-html-postamble'
 | 
						||
`:html-preamble-format'                          `org-html-preamble-format'
 | 
						||
`:html-preamble'                                 `org-html-preamble'
 | 
						||
`:html-table-align-individual-fields'            `org-html-table-align-individual-fields'
 | 
						||
`:html-table-attributes'                         `org-html-table-default-attributes'
 | 
						||
`:html-table-caption-above'                      `org-html-table-caption-above'
 | 
						||
`:html-table-data-tags'                          `org-html-table-data-tags'
 | 
						||
`:html-table-header-tags'                        `org-html-table-header-tags'
 | 
						||
`:html-table-row-tags'                           `org-html-table-row-tags'
 | 
						||
`:html-table-use-header-tags-for-first-column'   `org-html-table-use-header-tags-for-first-column'
 | 
						||
`:html-tag-class-prefix'                         `org-html-tag-class-prefix'
 | 
						||
`:html-text-markup-alist'                        `org-html-text-markup-alist'
 | 
						||
`:html-todo-kwd-class-prefix'                    `org-html-todo-kwd-class-prefix'
 | 
						||
`:html-toplevel-hlevel'                          `org-html-toplevel-hlevel'
 | 
						||
`:html-use-infojs'                               `org-html-use-infojs'
 | 
						||
`:html-validation-link'                          `org-html-validation-link'
 | 
						||
`:html-viewport'                                 `org-html-viewport'
 | 
						||
`:html-xml-declaration'                          `org-html-xml-declaration'
 | 
						||
 | 
						||
LaTeX specific properties
 | 
						||
.........................
 | 
						||
 | 
						||
`:latex-active-timestamp-format'         `org-latex-active-timestamp-format'
 | 
						||
`:latex-caption-above'                   `org-latex-caption-above'
 | 
						||
`:latex-classes'                         `org-latex-classes'
 | 
						||
`:latex-class'                           `org-latex-default-class'
 | 
						||
`:latex-default-figure-position'         `org-latex-default-figure-position'
 | 
						||
`:latex-default-table-environment'       `org-latex-default-table-environment'
 | 
						||
`:latex-default-table-mode'              `org-latex-default-table-mode'
 | 
						||
`:latex-diary-timestamp-format'          `org-latex-diary-timestamp-format'
 | 
						||
`:latex-footnote-separator'              `org-latex-footnote-separator'
 | 
						||
`:latex-format-drawer-function'          `org-latex-format-drawer-function'
 | 
						||
`:latex-format-headline-function'        `org-latex-format-headline-function'
 | 
						||
`:latex-format-inlinetask-function'      `org-latex-format-inlinetask-function'
 | 
						||
`:latex-hyperref-template'               `org-latex-hyperref-template'
 | 
						||
`:latex-image-default-height'            `org-latex-image-default-height'
 | 
						||
`:latex-image-default-option'            `org-latex-image-default-option'
 | 
						||
`:latex-image-default-width'             `org-latex-image-default-width'
 | 
						||
`:latex-inactive-timestamp-format'       `org-latex-inactive-timestamp-format'
 | 
						||
`:latex-inline-image-rules'              `org-latex-inline-image-rules'
 | 
						||
`:latex-link-with-unknown-path-format'   `org-latex-link-with-unknown-path-format'
 | 
						||
`:latex-listings-langs'                  `org-latex-listings-langs'
 | 
						||
`:latex-listings-options'                `org-latex-listings-options'
 | 
						||
`:latex-listings'                        `org-latex-listings'
 | 
						||
`:latex-minted-langs'                    `org-latex-minted-langs'
 | 
						||
`:latex-minted-options'                  `org-latex-minted-options'
 | 
						||
`:latex-prefer-user-labels'              `org-latex-prefer-user-labels'
 | 
						||
`:latex-subtitle-format'                 `org-latex-subtitle-format'
 | 
						||
`:latex-subtitle-separate'               `org-latex-subtitle-separate'
 | 
						||
`:latex-table-scientific-notation'       `org-latex-table-scientific-notation'
 | 
						||
`:latex-tables-booktabs'                 `org-latex-tables-booktabs'
 | 
						||
`:latex-tables-centered'                 `org-latex-tables-centered'
 | 
						||
`:latex-text-markup-alist'               `org-latex-text-markup-alist'
 | 
						||
`:latex-title-command'                   `org-latex-title-command'
 | 
						||
`:latex-toc-command'                     `org-latex-toc-command'
 | 
						||
 | 
						||
Markdown specific properties
 | 
						||
............................
 | 
						||
 | 
						||
`:md-headline-style'   `org-md-headline-style'
 | 
						||
 | 
						||
ODT specific properties
 | 
						||
.......................
 | 
						||
 | 
						||
`:odt-content-template-file'        `org-odt-content-template-file'
 | 
						||
`:odt-display-outline-level'        `org-odt-display-outline-level'
 | 
						||
`:odt-fontify-srcblocks'            `org-odt-fontify-srcblocks'
 | 
						||
`:odt-format-drawer-function'       `org-odt-format-drawer-function'
 | 
						||
`:odt-format-headline-function'     `org-odt-format-headline-function'
 | 
						||
`:odt-format-inlinetask-function'   `org-odt-format-inlinetask-function'
 | 
						||
`:odt-inline-formula-rules'         `org-odt-inline-formula-rules'
 | 
						||
`:odt-inline-image-rules'           `org-odt-inline-image-rules'
 | 
						||
`:odt-pixels-per-inch'              `org-odt-pixels-per-inch'
 | 
						||
`:odt-styles-file'                  `org-odt-styles-file'
 | 
						||
`:odt-table-styles'                 `org-odt-table-styles'
 | 
						||
`:odt-use-date-fields'              `org-odt-use-date-fields'
 | 
						||
 | 
						||
Texinfo specific properties
 | 
						||
...........................
 | 
						||
 | 
						||
`:texinfo-active-timestamp-format'         `org-texinfo-active-timestamp-format'
 | 
						||
`:texinfo-classes'                         `org-texinfo-classes'
 | 
						||
`:texinfo-class'                           `org-texinfo-default-class'
 | 
						||
`:texinfo-def-table-markup'                `org-texinfo-def-table-markup'
 | 
						||
`:texinfo-diary-timestamp-format'          `org-texinfo-diary-timestamp-format'
 | 
						||
`:texinfo-filename'                        `org-texinfo-filename'
 | 
						||
`:texinfo-format-drawer-function'          `org-texinfo-format-drawer-function'
 | 
						||
`:texinfo-format-headline-function'        `org-texinfo-format-headline-function'
 | 
						||
`:texinfo-format-inlinetask-function'      `org-texinfo-format-inlinetask-function'
 | 
						||
`:texinfo-inactive-timestamp-format'       `org-texinfo-inactive-timestamp-format'
 | 
						||
`:texinfo-link-with-unknown-path-format'   `org-texinfo-link-with-unknown-path-format'
 | 
						||
`:texinfo-node-description-column'         `org-texinfo-node-description-column'
 | 
						||
`:texinfo-table-scientific-notation'       `org-texinfo-table-scientific-notation'
 | 
						||
`:texinfo-tables-verbatim'                 `org-texinfo-tables-verbatim'
 | 
						||
`:texinfo-text-markup-alist'               `org-texinfo-text-markup-alist'
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Publishing links,  Next: Sitemap,  Prev: Publishing options,  Up: Configuration
 | 
						||
 | 
						||
13.1.6 Links between published files
 | 
						||
------------------------------------
 | 
						||
 | 
						||
To create a link from one Org file to another, you would use something
 | 
						||
like `[[file:foo.org][The foo]]' or simply `file:foo.org.' (*note
 | 
						||
Hyperlinks::).  When published, this link becomes a link to `foo.html'.
 | 
						||
You can thus interlink the pages of your "org web" project and the
 | 
						||
links will work as expected when you publish them to HTML.  If you also
 | 
						||
publish the Org source file and want to link to it, use an `http:' link
 | 
						||
instead of a `file:' link, because `file:' links are converted to link
 | 
						||
to the corresponding `html' file.
 | 
						||
 | 
						||
   You may also link to related files, such as images.  Provided you
 | 
						||
are careful with relative file names, and provided you have also
 | 
						||
configured Org to upload the related files, these links will work too.
 | 
						||
See *note Complex example::, for an example of this usage.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Sitemap,  Next: Generating an index,  Prev: Publishing links,  Up: Configuration
 | 
						||
 | 
						||
13.1.7 Generating a sitemap
 | 
						||
---------------------------
 | 
						||
 | 
						||
The following properties may be used to control publishing of a map of
 | 
						||
files for a given project.
 | 
						||
 | 
						||
`:auto-sitemap'           When non-`nil', publish a sitemap during
 | 
						||
                          `org-publish-current-project' or
 | 
						||
                          `org-publish-all'.
 | 
						||
`:sitemap-filename'       Filename for output of sitemap.  Defaults to
 | 
						||
                          `sitemap.org' (which becomes `sitemap.html').
 | 
						||
`:sitemap-title'          Title of sitemap page.  Defaults to name of
 | 
						||
                          file.
 | 
						||
`:sitemap-function'       Plug-in function to use for generation of the
 | 
						||
                          sitemap.  Defaults to
 | 
						||
                          `org-publish-org-sitemap', which generates a
 | 
						||
                          plain list of links to all files in the
 | 
						||
                          project.
 | 
						||
`:sitemap-sort-folders'   Where folders should appear in the sitemap.
 | 
						||
                          Set this to `first' (default) or `last' to
 | 
						||
                          display folders first or last, respectively.
 | 
						||
                          Any other value will mix files and folders.
 | 
						||
`:sitemap-sort-files'     How the files are sorted in the site map.  Set
 | 
						||
                          this to `alphabetically' (default),
 | 
						||
                          `chronologically' or `anti-chronologically'.
 | 
						||
                          `chronologically' sorts the files with older
 | 
						||
                          date first while `anti-chronologically' sorts
 | 
						||
                          the files with newer date first.
 | 
						||
                          `alphabetically' sorts the files
 | 
						||
                          alphabetically.  The date of a file is
 | 
						||
                          retrieved with `org-publish-find-date'.
 | 
						||
`:sitemap-ignore-case'    Should sorting be case-sensitive?  Default
 | 
						||
                          `nil'.
 | 
						||
`:sitemap-file-entry-format'With this option one can tell how a sitemap's
 | 
						||
                          entry is formatted in the sitemap.  This is a
 | 
						||
                          format string with some escape sequences: `%t'
 | 
						||
                          stands for the title of the file, `%a' stands
 | 
						||
                          for the author of the file and `%d' stands for
 | 
						||
                          the date of the file.  The date is retrieved
 | 
						||
                          with the `org-publish-find-date' function and
 | 
						||
                          formatted with
 | 
						||
                          `org-publish-sitemap-date-format'.  Default
 | 
						||
                          `%t'.
 | 
						||
`:sitemap-date-format'    Format string for the `format-time-string'
 | 
						||
                          function that tells how a sitemap entry's date
 | 
						||
                          is to be formatted.  This property bypasses
 | 
						||
                          `org-publish-sitemap-date-format' which
 | 
						||
                          defaults to `%Y-%m-%d'.
 | 
						||
`:sitemap-sans-extension' When non-`nil', remove filenames' extensions
 | 
						||
                          from the generated sitemap.  Useful to have
 | 
						||
                          cool URIs (see
 | 
						||
                          `http://www.w3.org/Provider/Style/URI').
 | 
						||
                          Defaults to `nil'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Generating an index,  Prev: Sitemap,  Up: Configuration
 | 
						||
 | 
						||
13.1.8 Generating an index
 | 
						||
--------------------------
 | 
						||
 | 
						||
Org mode can generate an index across the files of a publishing project.
 | 
						||
 | 
						||
`:makeindex'       When non-`nil', generate in index in the file
 | 
						||
                   `theindex.org' and publish it as `theindex.html'.
 | 
						||
 | 
						||
   The file will be created when first publishing a project with the
 | 
						||
`:makeindex' set.  The file only contains a statement `#+INCLUDE:
 | 
						||
"theindex.inc"'.  You can then build around this include statement by
 | 
						||
adding a title, style information, etc.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Uploading files,  Next: Sample configuration,  Prev: Configuration,  Up: Publishing
 | 
						||
 | 
						||
13.2 Uploading files
 | 
						||
====================
 | 
						||
 | 
						||
For those people already utilizing third party sync tools such as
 | 
						||
`rsync' or `unison', it might be preferable not to use the built in
 | 
						||
remote publishing facilities of Org mode which rely heavily on Tramp.
 | 
						||
Tramp, while very useful and powerful, tends not to be so efficient for
 | 
						||
multiple file transfer and has been known to cause problems under heavy
 | 
						||
usage.
 | 
						||
 | 
						||
   Specialized synchronization utilities offer several advantages.  In
 | 
						||
addition to timestamp comparison, they also do content and
 | 
						||
permissions/attribute checks.  For this reason you might prefer to
 | 
						||
publish your web to a local directory (possibly even in place with your
 | 
						||
Org files) and then use `unison' or `rsync' to do the synchronization
 | 
						||
with the remote host.
 | 
						||
 | 
						||
   Since Unison (for example) can be configured as to which files to
 | 
						||
transfer to a certain remote destination, it can greatly simplify the
 | 
						||
project publishing definition.  Simply keep all files in the correct
 | 
						||
location, process your Org files with `org-publish' and let the
 | 
						||
synchronization tool do the rest.  You do not need, in this scenario,
 | 
						||
to include attachments such as `jpg', `css' or `gif' files in the
 | 
						||
project definition since the 3rd party tool syncs them.
 | 
						||
 | 
						||
   Publishing to a local directory is also much faster than to a remote
 | 
						||
one, so that you can afford more easily to republish entire projects.
 | 
						||
If you set `org-publish-use-timestamps-flag' to `nil', you gain the main
 | 
						||
benefit of re-including any changed external files such as source
 | 
						||
example files you might include with `#+INCLUDE:'.  The timestamp
 | 
						||
mechanism in Org is not smart enough to detect if included files have
 | 
						||
been modified.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Sample configuration,  Next: Triggering publication,  Prev: Uploading files,  Up: Publishing
 | 
						||
 | 
						||
13.3 Sample configuration
 | 
						||
=========================
 | 
						||
 | 
						||
Below we provide two example configurations.  The first one is a simple
 | 
						||
project publishing only a set of Org files.  The second example is more
 | 
						||
complex, with a multi-component project.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Simple example::              One-component publishing
 | 
						||
* Complex example::             A multi-component publishing example
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Simple example,  Next: Complex example,  Up: Sample configuration
 | 
						||
 | 
						||
13.3.1 Example: simple publishing configuration
 | 
						||
-----------------------------------------------
 | 
						||
 | 
						||
This example publishes a set of Org files to the `public_html'
 | 
						||
directory on the local machine.
 | 
						||
 | 
						||
     (setq org-publish-project-alist
 | 
						||
           '(("org"
 | 
						||
              :base-directory "~/org/"
 | 
						||
              :publishing-directory "~/public_html"
 | 
						||
              :section-numbers nil
 | 
						||
              :with-toc nil
 | 
						||
              :html-head "<link rel=\"stylesheet\"
 | 
						||
                         href=\"../other/mystyle.css\"
 | 
						||
                         type=\"text/css\"/>")))
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Complex example,  Prev: Simple example,  Up: Sample configuration
 | 
						||
 | 
						||
13.3.2 Example: complex publishing configuration
 | 
						||
------------------------------------------------
 | 
						||
 | 
						||
This more complicated example publishes an entire website, including
 | 
						||
Org files converted to HTML, image files, Emacs Lisp source code, and
 | 
						||
style sheets.  The publishing directory is remote and private files are
 | 
						||
excluded.
 | 
						||
 | 
						||
   To ensure that links are preserved, care should be taken to replicate
 | 
						||
your directory structure on the web server, and to use relative file
 | 
						||
paths.  For example, if your Org files are kept in `~/org' and your
 | 
						||
publishable images in `~/images', you would link to an image with
 | 
						||
     file:../images/myimage.png
 | 
						||
   On the web server, the relative path to the image should be the
 | 
						||
same.  You can accomplish this by setting up an "images" folder in the
 | 
						||
right place on the web server, and publishing images to it.
 | 
						||
 | 
						||
     (setq org-publish-project-alist
 | 
						||
           '(("orgfiles"
 | 
						||
               :base-directory "~/org/"
 | 
						||
               :base-extension "org"
 | 
						||
               :publishing-directory "/ssh:user@host:~/html/notebook/"
 | 
						||
               :publishing-function org-html-publish-to-html
 | 
						||
               :exclude "PrivatePage.org"   ;; regexp
 | 
						||
               :headline-levels 3
 | 
						||
               :section-numbers nil
 | 
						||
               :with-toc nil
 | 
						||
               :html-head "<link rel=\"stylesheet\"
 | 
						||
                       href=\"../other/mystyle.css\" type=\"text/css\"/>"
 | 
						||
               :html-preamble t)
 | 
						||
 | 
						||
              ("images"
 | 
						||
               :base-directory "~/images/"
 | 
						||
               :base-extension "jpg\\|gif\\|png"
 | 
						||
               :publishing-directory "/ssh:user@host:~/html/images/"
 | 
						||
               :publishing-function org-publish-attachment)
 | 
						||
 | 
						||
              ("other"
 | 
						||
               :base-directory "~/other/"
 | 
						||
               :base-extension "css\\|el"
 | 
						||
               :publishing-directory "/ssh:user@host:~/html/other/"
 | 
						||
               :publishing-function org-publish-attachment)
 | 
						||
              ("website" :components ("orgfiles" "images" "other"))))
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Triggering publication,  Prev: Sample configuration,  Up: Publishing
 | 
						||
 | 
						||
13.4 Triggering publication
 | 
						||
===========================
 | 
						||
 | 
						||
Once properly configured, Org can publish with the following commands:
 | 
						||
 | 
						||
`C-c C-e P x     (`org-publish')'
 | 
						||
     Prompt for a specific project and publish all files that belong to
 | 
						||
     it.  
 | 
						||
 | 
						||
`C-c C-e P p     (`org-publish-current-project')'
 | 
						||
     Publish the project containing the current file.  
 | 
						||
 | 
						||
`C-c C-e P f     (`org-publish-current-file')'
 | 
						||
     Publish only the current file.  
 | 
						||
 | 
						||
`C-c C-e P a     (`org-publish-all')'
 | 
						||
     Publish every project.
 | 
						||
 | 
						||
   Org uses timestamps to track when a file has changed.  The above
 | 
						||
functions normally only publish changed files.  You can override this
 | 
						||
and force publishing of all files by giving a prefix argument to any of
 | 
						||
the commands above, or by customizing the variable
 | 
						||
`org-publish-use-timestamps-flag'.  This may be necessary in particular
 | 
						||
if files include other files via `#+SETUPFILE:' or `#+INCLUDE:'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Working with source code,  Next: Miscellaneous,  Prev: Publishing,  Up: Top
 | 
						||
 | 
						||
14 Working with source code
 | 
						||
***************************
 | 
						||
 | 
						||
Source code can be included in Org mode documents using a `src' block,
 | 
						||
e.g.:
 | 
						||
 | 
						||
     #+BEGIN_SRC emacs-lisp
 | 
						||
       (defun org-xor (a b)
 | 
						||
          "Exclusive or."
 | 
						||
          (if a (not b) b))
 | 
						||
     #+END_SRC
 | 
						||
 | 
						||
   Org mode provides a number of features for working with live source
 | 
						||
code, including editing of code blocks in their native major-mode,
 | 
						||
evaluation of code blocks, converting code blocks into source files
 | 
						||
(known as "tangling" in literate programming), and exporting code
 | 
						||
blocks and their results in several formats.  This functionality was
 | 
						||
contributed by Eric Schulte and Dan Davison, and was originally named
 | 
						||
Org-babel.
 | 
						||
 | 
						||
   The following sections describe Org mode's code block handling
 | 
						||
facilities.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Structure of code blocks::    Code block syntax described
 | 
						||
* Editing source code::         Language major-mode editing
 | 
						||
* Exporting code blocks::       Export contents and/or results
 | 
						||
* Extracting source code::      Create pure source code files
 | 
						||
* Evaluating code blocks::      Place results of evaluation in the Org mode buffer
 | 
						||
* Library of Babel::            Use and contribute to a library of useful code blocks
 | 
						||
* Languages::                   List of supported code block languages
 | 
						||
* Header arguments::            Configure code block functionality
 | 
						||
* Results of evaluation::       How evaluation results are handled
 | 
						||
* Noweb reference syntax::      Literate programming in Org mode
 | 
						||
* Key bindings and useful functions::  Work quickly with code blocks
 | 
						||
* Batch execution::             Call functions from the command line
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Structure of code blocks,  Next: Editing source code,  Up: Working with source code
 | 
						||
 | 
						||
14.1 Structure of code blocks
 | 
						||
=============================
 | 
						||
 | 
						||
Live code blocks can be specified with a `src' block or inline.(1)  The
 | 
						||
structure of a `src' block is
 | 
						||
 | 
						||
     #+NAME: <name>
 | 
						||
     #+BEGIN_SRC <language> <switches> <header arguments>
 | 
						||
       <body>
 | 
						||
     #+END_SRC
 | 
						||
 | 
						||
   The `#+NAME:' line is optional, and can be used to name the code
 | 
						||
block.  Live code blocks require that a language be specified on the
 | 
						||
`#+BEGIN_SRC' line.  Switches and header arguments are optional.  
 | 
						||
 | 
						||
   Live code blocks can also be specified inline using
 | 
						||
 | 
						||
     src_<language>{<body>}
 | 
						||
 | 
						||
   or
 | 
						||
 | 
						||
     src_<language>[<header arguments>]{<body>}
 | 
						||
 | 
						||
`<#+NAME: name>'
 | 
						||
     This line associates a name with the code block.  This is similar
 | 
						||
     to the `#+NAME: Name' lines that can be used to name tables in Org
 | 
						||
     mode files.  Referencing the name of a code block makes it
 | 
						||
     possible to evaluate the block from other places in the file, from
 | 
						||
     other files, or from Org mode table formulas (see *note The
 | 
						||
     spreadsheet::).  Names are assumed to be unique and the behavior
 | 
						||
     of Org mode when two or more blocks share the same name is
 | 
						||
     undefined.  
 | 
						||
 | 
						||
`<language>'
 | 
						||
     The language of the code in the block (see *note Languages::).  
 | 
						||
 | 
						||
`<switches>'
 | 
						||
     Optional switches control code block export (see the discussion of
 | 
						||
     switches in *note Literal examples::) 
 | 
						||
 | 
						||
`<header arguments>'
 | 
						||
     Optional header arguments control many aspects of evaluation,
 | 
						||
     export and tangling of code blocks (see *note Header arguments::).
 | 
						||
     Header arguments can also be set on a per-buffer or per-subtree
 | 
						||
     basis using properties.
 | 
						||
 | 
						||
`source code, header arguments'
 | 
						||
 | 
						||
`<body>'
 | 
						||
     Source code in the specified language.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Note that `src' blocks may be inserted using Org mode's *note
 | 
						||
Easy templates:: system
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Editing source code,  Next: Exporting code blocks,  Prev: Structure of code blocks,  Up: Working with source code
 | 
						||
 | 
						||
14.2 Editing source code
 | 
						||
========================
 | 
						||
 | 
						||
Use `C-c '' to edit the current code block.  This brings up a language
 | 
						||
major-mode edit buffer containing the body of the code block.  Manually
 | 
						||
saving this buffer with <C-x C-s> will write the contents back to the
 | 
						||
Org buffer.  You can also set `org-edit-src-auto-save-idle-delay' to
 | 
						||
save the base buffer after some idle delay, or
 | 
						||
`org-edit-src-turn-on-auto-save' to auto-save this buffer into a
 | 
						||
separate file using `auto-save-mode'.  Use `C-c '' again to exit.
 | 
						||
 | 
						||
   The `org-src-mode' minor mode will be active in the edit buffer.  The
 | 
						||
following variables can be used to configure the behavior of the edit
 | 
						||
buffer.  See also the customization group `org-edit-structure' for
 | 
						||
further configuration options.
 | 
						||
 | 
						||
`org-src-lang-modes'
 | 
						||
     If an Emacs major-mode named `<lang>-mode' exists, where `<lang>'
 | 
						||
     is the language named in the header line of the code block, then
 | 
						||
     the edit buffer will be placed in that major-mode.  This variable
 | 
						||
     can be used to map arbitrary language names to existing major
 | 
						||
     modes.
 | 
						||
 | 
						||
`org-src-window-setup'
 | 
						||
     Controls the way Emacs windows are rearranged when the edit buffer
 | 
						||
     is created.
 | 
						||
 | 
						||
`org-src-preserve-indentation'
 | 
						||
     By default, the value is `nil', which means that when code blocks
 | 
						||
     are evaluated during export or tangled, they are re-inserted into
 | 
						||
     the code block, which may replace sequences of spaces with tab
 | 
						||
     characters.  When non-`nil', whitespace in code blocks will be
 | 
						||
     preserved during export or tangling, exactly as it appears.  This
 | 
						||
     variable is especially useful for tangling languages such as
 | 
						||
     Python, in which whitespace indentation in the output is critical.
 | 
						||
 | 
						||
`org-src-ask-before-returning-to-edit-buffer'
 | 
						||
     By default, Org will ask before returning to an open edit buffer.
 | 
						||
     Set this variable to `nil' to switch without asking.
 | 
						||
 | 
						||
   To turn on native code fontification in the _Org_ buffer, configure
 | 
						||
the variable `org-src-fontify-natively'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Exporting code blocks,  Next: Extracting source code,  Prev: Editing source code,  Up: Working with source code
 | 
						||
 | 
						||
14.3 Exporting code blocks
 | 
						||
==========================
 | 
						||
 | 
						||
It is possible to export the _code_ of code blocks, the _results_ of
 | 
						||
code block evaluation, _both_ the code and the results of code block
 | 
						||
evaluation, or _none_.  For most languages, the default exports code.
 | 
						||
However, for some languages (e.g., `ditaa') the default exports the
 | 
						||
results of code block evaluation.  For information on exporting code
 | 
						||
block bodies, see *note Literal examples::.  For information on
 | 
						||
exporting parts of Org documents, see *note Exporting::.
 | 
						||
 | 
						||
   The `:exports' header argument can be used to specify export
 | 
						||
behavior (note that these arguments are only relevant for code blocks,
 | 
						||
not inline code):
 | 
						||
 | 
						||
Header arguments:
 | 
						||
.................
 | 
						||
 | 
						||
`:exports code'
 | 
						||
     The default in most languages.  The body of the code block is
 | 
						||
     exported, as described in *note Literal examples::.
 | 
						||
 | 
						||
`:exports results'
 | 
						||
     The code block will be evaluated each time to buffer is exported,
 | 
						||
     and the results will be placed in the Org mode buffer for export,
 | 
						||
     either updating previous results of the code block located
 | 
						||
     anywhere in the buffer or, if no previous results exist, placing
 | 
						||
     the results immediately after the code block.  The body of the
 | 
						||
     code block will not be exported.
 | 
						||
 | 
						||
`:exports both'
 | 
						||
     Both the code block and its results will be exported.
 | 
						||
 | 
						||
`:exports none'
 | 
						||
     Neither the code block nor its results will be exported.
 | 
						||
 | 
						||
   It is possible to inhibit the evaluation of code blocks during
 | 
						||
export.  Setting the `org-export-babel-evaluate' variable to `nil' will
 | 
						||
ensure that no code blocks are evaluated as part of the export process.
 | 
						||
This can be useful in situations where potentially untrusted Org mode
 | 
						||
files are exported in an automated fashion, for example when Org mode
 | 
						||
is used as the markup language for a wiki.  It is also possible to set
 | 
						||
this variable to `inline-only'.  In that case, only inline code blocks
 | 
						||
will be evaluated, in order to insert their results.  Non-inline code
 | 
						||
blocks are assumed to have their results already inserted in the buffer
 | 
						||
by manual evaluation.  This setting is useful to avoid expensive
 | 
						||
recalculations during export, not to provide security.
 | 
						||
 | 
						||
   Code blocks in commented subtrees (*note Comment lines::) are never
 | 
						||
evaluated on export.  However, code blocks in subtrees excluded from
 | 
						||
export (*note Export settings::) may be evaluated on export.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Extracting source code,  Next: Evaluating code blocks,  Prev: Exporting code blocks,  Up: Working with source code
 | 
						||
 | 
						||
14.4 Extracting source code
 | 
						||
===========================
 | 
						||
 | 
						||
Creating pure source code files by extracting code from source blocks is
 | 
						||
referred to as "tangling"--a term adopted from the literate programming
 | 
						||
community.  During "tangling" of code blocks their bodies are expanded
 | 
						||
using `org-babel-expand-src-block' which can expand both variable and
 | 
						||
"noweb" style references  (see *note Noweb reference syntax::).
 | 
						||
 | 
						||
Header arguments
 | 
						||
................
 | 
						||
 | 
						||
`:tangle no'
 | 
						||
     The default.  The code block is not included in the tangled output.
 | 
						||
 | 
						||
`:tangle yes'
 | 
						||
     Include the code block in the tangled output.  The output file
 | 
						||
     name is the name of the org file with the extension `.org'
 | 
						||
     replaced by the extension for the block language.
 | 
						||
 | 
						||
`:tangle filename'
 | 
						||
     Include the code block in the tangled output to file `filename'.
 | 
						||
 | 
						||
Functions
 | 
						||
.........
 | 
						||
 | 
						||
`org-babel-tangle'
 | 
						||
     Tangle the current file.  Bound to `C-c C-v t'.
 | 
						||
 | 
						||
     With prefix argument only tangle the current code block.
 | 
						||
 | 
						||
`org-babel-tangle-file'
 | 
						||
     Choose a file to tangle.  Bound to `C-c C-v f'.
 | 
						||
 | 
						||
Hooks
 | 
						||
.....
 | 
						||
 | 
						||
`org-babel-post-tangle-hook'
 | 
						||
     This hook is run from within code files tangled by
 | 
						||
     `org-babel-tangle'.  Example applications could include
 | 
						||
     post-processing, compilation or evaluation of tangled code files.
 | 
						||
 | 
						||
Jumping between code and Org
 | 
						||
............................
 | 
						||
 | 
						||
When tangling code from an Org-mode buffer to a source code file, you'll
 | 
						||
frequently find yourself viewing the file of tangled source code (e.g.,
 | 
						||
many debuggers point to lines of the source code file).  It is useful
 | 
						||
to be able to navigate from the tangled source to the Org-mode buffer
 | 
						||
from which the code originated.
 | 
						||
 | 
						||
   The `org-babel-tangle-jump-to-org' function provides this jumping
 | 
						||
from code to Org-mode functionality.  Two header arguments are required
 | 
						||
for jumping to work, first the `padline' (*note padline::) option must
 | 
						||
be set to true (the default setting), second the `comments' (*note
 | 
						||
comments::) header argument must be set to `link', which will insert
 | 
						||
comments into the source code buffer which point back to the original
 | 
						||
Org-mode file.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Evaluating code blocks,  Next: Library of Babel,  Prev: Extracting source code,  Up: Working with source code
 | 
						||
 | 
						||
14.5 Evaluating code blocks
 | 
						||
===========================
 | 
						||
 | 
						||
Code blocks can be evaluated(1) and the results of evaluation
 | 
						||
optionally placed in the Org mode buffer.  The results of evaluation
 | 
						||
are placed following a line that begins by default with `#+RESULTS' and
 | 
						||
optionally a cache identifier and/or the name of the evaluated code
 | 
						||
block.  The default value of `#+RESULTS' can be changed with the
 | 
						||
customizable variable `org-babel-results-keyword'.
 | 
						||
 | 
						||
   By default, the evaluation facility is only enabled for Lisp code
 | 
						||
blocks specified as `emacs-lisp'.  See *note Languages:: to enable other
 | 
						||
supported languages.  See *note Structure of code blocks:: for
 | 
						||
information on the syntax used to define a code block.
 | 
						||
 | 
						||
   There are a number of ways to evaluate code blocks.  The simplest is
 | 
						||
to press `C-c C-c' or `C-c C-v e' with the point on a code block(2).
 | 
						||
This will call the `org-babel-execute-src-block' function to evaluate
 | 
						||
the block and insert its results into the Org mode buffer.
 | 
						||
 | 
						||
   It is also possible to evaluate named code blocks from anywhere(3)
 | 
						||
in an Org mode buffer or an Org mode table.  These named code blocks
 | 
						||
can be located in the current Org mode buffer or in the "Library of
 | 
						||
Babel" (*note Library of Babel::).  Named code blocks can be evaluated
 | 
						||
with a separate `#+CALL:' line or inline within a block of text.  In
 | 
						||
both cases the result is wrapped according to the value of
 | 
						||
`org-babel-inline-result-wrap', which by default is `"=%s="' for markup
 | 
						||
that produces verbatim text.
 | 
						||
 | 
						||
   The syntax of the `#+CALL:' line is
 | 
						||
 | 
						||
     #+CALL: <name>(<arguments>)
 | 
						||
     #+CALL: <name>[<inside header arguments>](<arguments>) <end header arguments>
 | 
						||
 | 
						||
   The syntax for inline evaluation of named code blocks is
 | 
						||
 | 
						||
     ... call_<name>(<arguments>) ...
 | 
						||
     ... call_<name>[<inside header arguments>](<arguments>)[<end header arguments>] ...
 | 
						||
 | 
						||
`<name>'
 | 
						||
     The name of the code block to be evaluated (see *note Structure of
 | 
						||
     code blocks::).
 | 
						||
 | 
						||
`<arguments>'
 | 
						||
     Arguments specified in this section will be passed to the code
 | 
						||
     block.  These arguments use standard function call syntax, rather
 | 
						||
     than header argument syntax.  For example, a `#+CALL:' line that
 | 
						||
     passes the number four to a code block named `double', which
 | 
						||
     declares the header argument `:var n=2', would be written as
 | 
						||
     `#+CALL: double(n=4)'.
 | 
						||
 | 
						||
`<inside header arguments>'
 | 
						||
     Inside header arguments are passed through and applied to the
 | 
						||
     named code block.  These arguments use header argument syntax
 | 
						||
     rather than standard function call syntax.  Inside header
 | 
						||
     arguments affect how the code block is evaluated.  For example,
 | 
						||
     `[:results output]' will collect the results of everything printed
 | 
						||
     to `STDOUT' during execution of the code block.
 | 
						||
 | 
						||
`<end header arguments>'
 | 
						||
     End header arguments are applied to the calling instance and do
 | 
						||
     not affect evaluation of the named code block.  They affect how
 | 
						||
     the results are incorporated into the Org mode buffer and how the
 | 
						||
     call line is exported.  For example, `:results html' will insert
 | 
						||
     the results of the call line evaluation in the Org buffer, wrapped
 | 
						||
     in a `BEGIN_HTML:' block.
 | 
						||
 | 
						||
     For more examples of passing header arguments to `#+CALL:' lines
 | 
						||
     see *note Header arguments in function calls::.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Whenever code is evaluated there is a potential for that code to
 | 
						||
do harm.  Org mode provides safeguards to ensure that code is only
 | 
						||
evaluated after explicit confirmation from the user.  For information
 | 
						||
on these safeguards (and on how to disable them) see *note Code
 | 
						||
evaluation security::.
 | 
						||
 | 
						||
   (2) The option `org-babel-no-eval-on-ctrl-c-ctrl-c' can be used to
 | 
						||
remove code evaluation from the `C-c C-c' key binding.
 | 
						||
 | 
						||
   (3) Actually, the constructs call_<name>() and src_<lang>{} are not
 | 
						||
evaluated when they appear in a keyword line (i.e. lines starting with
 | 
						||
`#+KEYWORD:', *note In-buffer settings::).
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Library of Babel,  Next: Languages,  Prev: Evaluating code blocks,  Up: Working with source code
 | 
						||
 | 
						||
14.6 Library of Babel
 | 
						||
=====================
 | 
						||
 | 
						||
The "Library of Babel" consists of code blocks that can be called from
 | 
						||
any Org mode file.  Code blocks defined in the "Library of Babel" can
 | 
						||
be called remotely as if they were in the current Org mode buffer (see
 | 
						||
*note Evaluating code blocks:: for information on the syntax of remote
 | 
						||
code block evaluation).
 | 
						||
 | 
						||
   The central repository of code blocks in the "Library of Babel" is
 | 
						||
housed in an Org mode file located in the `doc' directory of Org mode.
 | 
						||
 | 
						||
   Users can add code blocks they believe to be generally useful to
 | 
						||
their "Library of Babel."  The code blocks can be stored in any Org
 | 
						||
mode file and then loaded into the library with `org-babel-lob-ingest'.
 | 
						||
 | 
						||
   Code blocks located in any Org mode file can be loaded into the
 | 
						||
"Library of Babel" with the `org-babel-lob-ingest' function, bound to
 | 
						||
`C-c C-v i'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Languages,  Next: Header arguments,  Prev: Library of Babel,  Up: Working with source code
 | 
						||
 | 
						||
14.7 Languages
 | 
						||
==============
 | 
						||
 | 
						||
Code blocks in the following languages are supported.
 | 
						||
 | 
						||
Language           Identifier         Language           Identifier
 | 
						||
---------------------------------------------------------------------------- 
 | 
						||
Asymptote          asymptote          Awk                awk
 | 
						||
C                  C                  C++                C++
 | 
						||
Clojure            clojure            CSS                css
 | 
						||
D                  d                  ditaa              ditaa
 | 
						||
Graphviz           dot                Emacs Calc         calc
 | 
						||
Emacs Lisp         emacs-lisp         Fortran            fortran
 | 
						||
gnuplot            gnuplot            Haskell            haskell
 | 
						||
Java               java               Javascript         js
 | 
						||
LaTeX              latex              Ledger             ledger
 | 
						||
Lisp               lisp               Lilypond           lilypond
 | 
						||
MATLAB             matlab             Mscgen             mscgen
 | 
						||
Objective Caml     ocaml              Octave             octave
 | 
						||
Org mode           org                Oz                 oz
 | 
						||
Perl               perl               Plantuml           plantuml
 | 
						||
Processing.js      processing         Python             python
 | 
						||
R                  R                  Ruby               ruby
 | 
						||
Sass               sass               Scheme             scheme
 | 
						||
GNU Screen         screen             Sed                sed
 | 
						||
shell              sh                 SQL                sql
 | 
						||
SQLite             sqlite                                
 | 
						||
 | 
						||
   Language-specific documentation is available for some languages.  If
 | 
						||
available, it can be found at
 | 
						||
`http://orgmode.org/worg/org-contrib/babel/languages.html'.
 | 
						||
 | 
						||
   The option `org-babel-load-languages' controls which languages are
 | 
						||
enabled for evaluation (by default only `emacs-lisp' is enabled).  This
 | 
						||
variable can be set using the customization interface or by adding code
 | 
						||
like the following to your emacs configuration.
 | 
						||
 | 
						||
   The following disables `emacs-lisp' evaluation and enables
 | 
						||
evaluation of `R' code blocks.
 | 
						||
 | 
						||
     (org-babel-do-load-languages
 | 
						||
      'org-babel-load-languages
 | 
						||
      '((emacs-lisp . nil)
 | 
						||
        (R . t)))
 | 
						||
 | 
						||
   It is also possible to enable support for a language by loading the
 | 
						||
related elisp file with `require'.
 | 
						||
 | 
						||
   The following adds support for evaluating `clojure' code blocks.
 | 
						||
 | 
						||
     (require 'ob-clojure)
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Header arguments,  Next: Results of evaluation,  Prev: Languages,  Up: Working with source code
 | 
						||
 | 
						||
14.8 Header arguments
 | 
						||
=====================
 | 
						||
 | 
						||
Code block functionality can be configured with header arguments.  This
 | 
						||
section provides an overview of the use of header arguments, and then
 | 
						||
describes each header argument in detail.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Using header arguments::      Different ways to set header arguments
 | 
						||
* Specific header arguments::   List of header arguments
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Using header arguments,  Next: Specific header arguments,  Up: Header arguments
 | 
						||
 | 
						||
14.8.1 Using header arguments
 | 
						||
-----------------------------
 | 
						||
 | 
						||
The values of header arguments can be set in several way.  When the
 | 
						||
header arguments in each layer have been determined, they are combined
 | 
						||
in order from the first, least specific (having the lowest priority) up
 | 
						||
to the last, most specific (having the highest priority).  A header
 | 
						||
argument with a higher priority replaces the same header argument
 | 
						||
specified at lower priority.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* System-wide header arguments::  Set global default values
 | 
						||
* Language-specific header arguments::  Set default values by language
 | 
						||
* Header arguments in Org mode properties::  Set default values for a buffer or heading
 | 
						||
* Language-specific header arguments in Org mode properties::  Set language-specific default values for a buffer or heading
 | 
						||
* Code block specific header arguments::  The most common way to set values
 | 
						||
* Header arguments in function calls::  The most specific level
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: System-wide header arguments,  Next: Language-specific header arguments,  Up: Using header arguments
 | 
						||
 | 
						||
System-wide header arguments
 | 
						||
............................
 | 
						||
 | 
						||
System-wide values of header arguments can be specified by adapting the
 | 
						||
`org-babel-default-header-args' variable:
 | 
						||
 | 
						||
     :session    => "none"
 | 
						||
     :results    => "replace"
 | 
						||
     :exports    => "code"
 | 
						||
     :cache      => "no"
 | 
						||
     :noweb      => "no"
 | 
						||
 | 
						||
   For example, the following example could be used to set the default
 | 
						||
value of `:noweb' header arguments to `yes'.  This would have the
 | 
						||
effect of expanding `:noweb' references by default when evaluating
 | 
						||
source code blocks.
 | 
						||
 | 
						||
     (setq org-babel-default-header-args
 | 
						||
           (cons '(:noweb . "yes")
 | 
						||
                 (assq-delete-all :noweb org-babel-default-header-args)))
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Language-specific header arguments,  Next: Header arguments in Org mode properties,  Prev: System-wide header arguments,  Up: Using header arguments
 | 
						||
 | 
						||
Language-specific header arguments
 | 
						||
..................................
 | 
						||
 | 
						||
Each language can define its own set of default header arguments in
 | 
						||
variable `org-babel-default-header-args:<lang>', where `<lang>' is the
 | 
						||
name of the language.  See the language-specific documentation
 | 
						||
available online at `http://orgmode.org/worg/org-contrib/babel'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Header arguments in Org mode properties,  Next: Language-specific header arguments in Org mode properties,  Prev: Language-specific header arguments,  Up: Using header arguments
 | 
						||
 | 
						||
Header arguments in Org mode properties
 | 
						||
.......................................
 | 
						||
 | 
						||
Buffer-wide header arguments may be specified as properties through the
 | 
						||
use of `#+PROPERTY:' lines placed anywhere in an Org mode file (see
 | 
						||
*note Property syntax::).
 | 
						||
 | 
						||
   For example the following would set `session' to `*R*' (only for R
 | 
						||
code blocks), and `results' to `silent' for every code block in the
 | 
						||
buffer, ensuring that all execution took place in the same session, and
 | 
						||
no results would be inserted into the buffer.
 | 
						||
 | 
						||
     #+PROPERTY: header-args:R  :session *R*
 | 
						||
     #+PROPERTY: header-args    :results silent
 | 
						||
 | 
						||
   Header arguments read from Org mode properties can also be set on a
 | 
						||
per-subtree basis using property drawers (see *note Property syntax::).  When
 | 
						||
properties are used to set default header arguments, they are always
 | 
						||
looked up with inheritance, regardless of the value of
 | 
						||
`org-use-property-inheritance'.  Properties are evaluated as seen by the
 | 
						||
outermost call or source block.(1)
 | 
						||
 | 
						||
   In the following example the value of the `:cache' header argument
 | 
						||
will default to `yes' in all code blocks in the subtree rooted at the
 | 
						||
following heading:
 | 
						||
 | 
						||
     * outline header
 | 
						||
       :PROPERTIES:
 | 
						||
       :header-args:    :cache yes
 | 
						||
       :END:
 | 
						||
 | 
						||
   Properties defined in this way override the properties set in
 | 
						||
`org-babel-default-header-args' and are applied for all activated
 | 
						||
languages.  It is convenient to use the `org-set-property' function
 | 
						||
bound to `C-c C-x p' to set properties in Org mode documents.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) The deprecated syntax for default header argument properties,
 | 
						||
using the name of the header argument as a property name directly,
 | 
						||
evaluates the property as seen by the corresponding source block
 | 
						||
definition.  This behavior has been kept for backwards compatibility.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Language-specific header arguments in Org mode properties,  Next: Code block specific header arguments,  Prev: Header arguments in Org mode properties,  Up: Using header arguments
 | 
						||
 | 
						||
Language-specific header arguments in Org mode properties
 | 
						||
.........................................................
 | 
						||
 | 
						||
Language-specific header arguments are also read from properties
 | 
						||
`header-args:<lang>' where `<lang>' is the name of the language
 | 
						||
targeted.  As an example
 | 
						||
 | 
						||
     * Heading
 | 
						||
       :PROPERTIES:
 | 
						||
       :header-args:clojure:    :session *clojure-1*
 | 
						||
       :header-args:R:          :session *R*
 | 
						||
       :END:
 | 
						||
     ** Subheading
 | 
						||
       :PROPERTIES:
 | 
						||
       :header-args:clojure:    :session *clojure-2*
 | 
						||
       :END:
 | 
						||
 | 
						||
   would independently set a default session header argument for R and
 | 
						||
clojure for calls and source blocks under subtree "Heading" and change
 | 
						||
to a different clojure setting for evaluations under subtree
 | 
						||
"Subheading", while the R session is inherited from "Heading" and
 | 
						||
therefore unchanged.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Code block specific header arguments,  Next: Header arguments in function calls,  Prev: Language-specific header arguments in Org mode properties,  Up: Using header arguments
 | 
						||
 | 
						||
Code block specific header arguments
 | 
						||
....................................
 | 
						||
 | 
						||
The most common way to assign values to header arguments is at the code
 | 
						||
block level.  This can be done by listing a sequence of header
 | 
						||
arguments and their values as part of the `#+BEGIN_SRC' line.
 | 
						||
Properties set in this way override both the values of
 | 
						||
`org-babel-default-header-args' and header arguments specified as
 | 
						||
properties.  In the following example, the `:results' header argument
 | 
						||
is set to `silent', meaning the results of execution will not be
 | 
						||
inserted in the buffer, and the `:exports' header argument is set to
 | 
						||
`code', meaning only the body of the code block will be preserved on
 | 
						||
export to HTML or LaTeX.
 | 
						||
 | 
						||
     #+NAME: factorial
 | 
						||
     #+BEGIN_SRC haskell :results silent :exports code :var n=0
 | 
						||
     fac 0 = 1
 | 
						||
     fac n = n * fac (n-1)
 | 
						||
     #+END_SRC
 | 
						||
   Similarly, it is possible to set header arguments for inline code
 | 
						||
blocks
 | 
						||
 | 
						||
     src_haskell[:exports both]{fac 5}
 | 
						||
 | 
						||
   Code block header arguments can span multiple lines using
 | 
						||
`#+HEADER:' or `#+HEADERS:' lines preceding a code block or nested
 | 
						||
between the `#+NAME:' line and the `#+BEGIN_SRC' line of a named code
 | 
						||
block.  
 | 
						||
 | 
						||
   Multi-line header arguments on an un-named code block:
 | 
						||
 | 
						||
      #+HEADERS: :var data1=1
 | 
						||
      #+BEGIN_SRC emacs-lisp :var data2=2
 | 
						||
        (message "data1:%S, data2:%S" data1 data2)
 | 
						||
      #+END_SRC
 | 
						||
 | 
						||
      #+RESULTS:
 | 
						||
      : data1:1, data2:2
 | 
						||
 | 
						||
   Multi-line header arguments on a named code block:
 | 
						||
 | 
						||
        #+NAME: named-block
 | 
						||
        #+HEADER: :var data=2
 | 
						||
        #+BEGIN_SRC emacs-lisp
 | 
						||
          (message "data:%S" data)
 | 
						||
        #+END_SRC
 | 
						||
 | 
						||
        #+RESULTS: named-block
 | 
						||
        : data:2
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Header arguments in function calls,  Prev: Code block specific header arguments,  Up: Using header arguments
 | 
						||
 | 
						||
Header arguments in function calls
 | 
						||
..................................
 | 
						||
 | 
						||
At the most specific level, header arguments for "Library of Babel" or
 | 
						||
`#+CALL:' lines can be set as shown in the two examples below.  For more
 | 
						||
information on the structure of `#+CALL:' lines see *note Evaluating
 | 
						||
code blocks::.
 | 
						||
 | 
						||
   The following will apply the `:exports results' header argument to
 | 
						||
the evaluation of the `#+CALL:' line.
 | 
						||
 | 
						||
     #+CALL: factorial(n=5) :exports results
 | 
						||
 | 
						||
   The following will apply the `:session special' header argument to
 | 
						||
the evaluation of the `factorial' code block.
 | 
						||
 | 
						||
     #+CALL: factorial[:session special](n=5)
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Specific header arguments,  Prev: Using header arguments,  Up: Header arguments
 | 
						||
 | 
						||
14.8.2 Specific header arguments
 | 
						||
--------------------------------
 | 
						||
 | 
						||
Header arguments consist of an initial colon followed by the name of the
 | 
						||
argument in lowercase letters.  The following header arguments are
 | 
						||
defined:
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* var::                         Pass arguments to code blocks
 | 
						||
* results::                     Specify the type of results and how they will
 | 
						||
                                be collected and handled
 | 
						||
* file::                        Specify a path for file output
 | 
						||
* file-desc::                   Specify a description for file results
 | 
						||
* file-ext::                    Specify an extension for file output
 | 
						||
* output-dir::                  Specify a directory to write file output to
 | 
						||
* dir::                         Specify the default (possibly remote)
 | 
						||
                                directory for code block execution
 | 
						||
* exports::                     Export code and/or results
 | 
						||
* tangle::                      Toggle tangling and specify file name
 | 
						||
* mkdirp::                      Toggle creation of parent directories of target
 | 
						||
                                files during tangling
 | 
						||
* comments::                    Toggle insertion of comments in tangled
 | 
						||
                                code files
 | 
						||
* padline::                     Control insertion of padding lines in tangled
 | 
						||
                                code files
 | 
						||
* no-expand::                   Turn off variable assignment and noweb
 | 
						||
                                expansion during tangling
 | 
						||
* session::                     Preserve the state of code evaluation
 | 
						||
* noweb::                       Toggle expansion of noweb references
 | 
						||
* noweb-ref::                   Specify block's noweb reference resolution target
 | 
						||
* noweb-sep::                   String used to separate noweb references
 | 
						||
* cache::                       Avoid re-evaluating unchanged code blocks
 | 
						||
* sep::                         Delimiter for writing tabular results outside Org
 | 
						||
* hlines::                      Handle horizontal lines in tables
 | 
						||
* colnames::                    Handle column names in tables
 | 
						||
* rownames::                    Handle row names in tables
 | 
						||
* shebang::                     Make tangled files executable
 | 
						||
* tangle-mode::                 Set permission of tangled files
 | 
						||
* eval::                        Limit evaluation of specific code blocks
 | 
						||
* wrap::                        Mark source block evaluation results
 | 
						||
* post::                        Post processing of code block results
 | 
						||
* prologue::                    Text to prepend to code block body
 | 
						||
* epilogue::                    Text to append to code block body
 | 
						||
 | 
						||
   Additional header arguments are defined on a language-specific
 | 
						||
basis, see *note Languages::.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: var,  Next: results,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.1 `:var'
 | 
						||
...............
 | 
						||
 | 
						||
The `:var' header argument is used to pass arguments to code blocks.
 | 
						||
The specifics of how arguments are included in a code block vary by
 | 
						||
language; these are addressed in the language-specific documentation.
 | 
						||
However, the syntax used to specify arguments is the same across all
 | 
						||
languages.  In every case, variables require a default value when they
 | 
						||
are declared.
 | 
						||
 | 
						||
   The values passed to arguments can either be literal values,
 | 
						||
references, or Emacs Lisp code (see *note Emacs Lisp evaluation of
 | 
						||
variables: var.).  References include anything in the Org mode file
 | 
						||
that takes a `#+NAME:' or `#+RESULTS:' line: tables, lists,
 | 
						||
`#+BEGIN_EXAMPLE' blocks, other code blocks and the results of other
 | 
						||
code blocks.
 | 
						||
 | 
						||
   Note: When a reference is made to another code block, the referenced
 | 
						||
block will be evaluated unless it has current cached results (see *note
 | 
						||
cache::).
 | 
						||
 | 
						||
   Argument values can be indexed in a manner similar to arrays (see
 | 
						||
*note Indexable variable values: var.).
 | 
						||
 | 
						||
   The following syntax is used to pass arguments to code blocks using
 | 
						||
the `:var' header argument.
 | 
						||
 | 
						||
     :var name=assign
 | 
						||
 | 
						||
   The argument, `assign', can either be a literal value, such as a
 | 
						||
string `"string"' or a number `9', or a reference to a table, a list, a
 | 
						||
literal example, another code block (with or without arguments), or the
 | 
						||
results of evaluating another code block.
 | 
						||
 | 
						||
   Here are examples of passing values by reference:
 | 
						||
 | 
						||
"table"
 | 
						||
     an Org mode table named with either a `#+NAME:' line
 | 
						||
 | 
						||
          #+NAME: example-table
 | 
						||
          | 1 |
 | 
						||
          | 2 |
 | 
						||
          | 3 |
 | 
						||
          | 4 |
 | 
						||
 | 
						||
          #+NAME: table-length
 | 
						||
          #+BEGIN_SRC emacs-lisp :var table=example-table
 | 
						||
          (length table)
 | 
						||
          #+END_SRC
 | 
						||
 | 
						||
          #+RESULTS: table-length
 | 
						||
          : 4
 | 
						||
 | 
						||
"list"
 | 
						||
     a simple list named with a `#+NAME:' line (note that nesting is not
 | 
						||
     carried through to the source code block)
 | 
						||
 | 
						||
          #+NAME: example-list
 | 
						||
            - simple
 | 
						||
              - not
 | 
						||
              - nested
 | 
						||
            - list
 | 
						||
 | 
						||
          #+BEGIN_SRC emacs-lisp :var x=example-list
 | 
						||
            (print x)
 | 
						||
          #+END_SRC
 | 
						||
 | 
						||
          #+RESULTS:
 | 
						||
          | simple | list |
 | 
						||
 | 
						||
"code block without arguments"
 | 
						||
     a code block name (from the example above), as assigned by
 | 
						||
     `#+NAME:', optionally followed by parentheses
 | 
						||
 | 
						||
          #+BEGIN_SRC emacs-lisp :var length=table-length()
 | 
						||
          (* 2 length)
 | 
						||
          #+END_SRC
 | 
						||
 | 
						||
          #+RESULTS:
 | 
						||
          : 8
 | 
						||
 | 
						||
"code block with arguments"
 | 
						||
     a code block name, as assigned by `#+NAME:', followed by
 | 
						||
     parentheses and optional arguments passed within the parentheses
 | 
						||
     following the code block name using standard function call syntax
 | 
						||
 | 
						||
          #+NAME: double
 | 
						||
          #+BEGIN_SRC emacs-lisp :var input=8
 | 
						||
          (* 2 input)
 | 
						||
          #+END_SRC
 | 
						||
 | 
						||
          #+RESULTS: double
 | 
						||
          : 16
 | 
						||
 | 
						||
          #+NAME: squared
 | 
						||
          #+BEGIN_SRC emacs-lisp :var input=double(input=1)
 | 
						||
          (* input input)
 | 
						||
          #+END_SRC
 | 
						||
 | 
						||
          #+RESULTS: squared
 | 
						||
          : 4
 | 
						||
 | 
						||
"literal example"
 | 
						||
     a literal example block named with a `#+NAME:' line
 | 
						||
 | 
						||
          #+NAME: literal-example
 | 
						||
          #+BEGIN_EXAMPLE
 | 
						||
          A literal example
 | 
						||
          on two lines
 | 
						||
          #+END_EXAMPLE
 | 
						||
 | 
						||
          #+NAME: read-literal-example
 | 
						||
          #+BEGIN_SRC emacs-lisp :var x=literal-example
 | 
						||
            (concatenate 'string x " for you.")
 | 
						||
          #+END_SRC
 | 
						||
 | 
						||
          #+RESULTS: read-literal-example
 | 
						||
          : A literal example
 | 
						||
          : on two lines for you.
 | 
						||
 | 
						||
 | 
						||
Indexable variable values
 | 
						||
.........................
 | 
						||
 | 
						||
It is possible to reference portions of variable values by "indexing"
 | 
						||
into the variables.  Indexes are 0 based with negative values counting
 | 
						||
back from the end.  If an index is separated by `,'s then each
 | 
						||
subsequent section will index into the next deepest nesting or
 | 
						||
dimension of the value.  Note that this indexing occurs _before_ other
 | 
						||
table related header arguments like `:hlines', `:colnames' and
 | 
						||
`:rownames' are applied.  The following example assigns the last cell
 | 
						||
of the first row the table `example-table' to the variable `data':
 | 
						||
 | 
						||
     #+NAME: example-table
 | 
						||
     | 1 | a |
 | 
						||
     | 2 | b |
 | 
						||
     | 3 | c |
 | 
						||
     | 4 | d |
 | 
						||
 | 
						||
     #+BEGIN_SRC emacs-lisp :var data=example-table[0,-1]
 | 
						||
       data
 | 
						||
     #+END_SRC
 | 
						||
 | 
						||
     #+RESULTS:
 | 
						||
     : a
 | 
						||
 | 
						||
   Ranges of variable values can be referenced using two integers
 | 
						||
separated by a `:', in which case the entire inclusive range is
 | 
						||
referenced.  For example the following assigns the middle three rows of
 | 
						||
`example-table' to `data'.
 | 
						||
 | 
						||
     #+NAME: example-table
 | 
						||
     | 1 | a |
 | 
						||
     | 2 | b |
 | 
						||
     | 3 | c |
 | 
						||
     | 4 | d |
 | 
						||
     | 5 | 3 |
 | 
						||
 | 
						||
     #+BEGIN_SRC emacs-lisp :var data=example-table[1:3]
 | 
						||
       data
 | 
						||
     #+END_SRC
 | 
						||
 | 
						||
     #+RESULTS:
 | 
						||
     | 2 | b |
 | 
						||
     | 3 | c |
 | 
						||
     | 4 | d |
 | 
						||
 | 
						||
   Additionally, an empty index, or the single character `*', are both
 | 
						||
interpreted to mean the entire range and as such are equivalent to
 | 
						||
`0:-1', as shown in the following example in which the entire first
 | 
						||
column is referenced.
 | 
						||
 | 
						||
     #+NAME: example-table
 | 
						||
     | 1 | a |
 | 
						||
     | 2 | b |
 | 
						||
     | 3 | c |
 | 
						||
     | 4 | d |
 | 
						||
 | 
						||
     #+BEGIN_SRC emacs-lisp :var data=example-table[,0]
 | 
						||
       data
 | 
						||
     #+END_SRC
 | 
						||
 | 
						||
     #+RESULTS:
 | 
						||
     | 1 | 2 | 3 | 4 |
 | 
						||
 | 
						||
   It is possible to index into the results of code blocks as well as
 | 
						||
tables.  Any number of dimensions can be indexed.  Dimensions are
 | 
						||
separated from one another by commas, as shown in the following example.
 | 
						||
 | 
						||
     #+NAME: 3D
 | 
						||
     #+BEGIN_SRC emacs-lisp
 | 
						||
       '(((1  2  3)  (4  5  6)  (7  8  9))
 | 
						||
         ((10 11 12) (13 14 15) (16 17 18))
 | 
						||
         ((19 20 21) (22 23 24) (25 26 27)))
 | 
						||
     #+END_SRC
 | 
						||
 | 
						||
     #+BEGIN_SRC emacs-lisp :var data=3D[1,,1]
 | 
						||
       data
 | 
						||
     #+END_SRC
 | 
						||
 | 
						||
     #+RESULTS:
 | 
						||
     | 11 | 14 | 17 |
 | 
						||
 | 
						||
Emacs Lisp evaluation of variables
 | 
						||
..................................
 | 
						||
 | 
						||
Emacs lisp code can be used to initialize variable values.  When a
 | 
						||
variable value starts with `(', `[', `'' or ``' it will be evaluated as
 | 
						||
Emacs Lisp and the result of the evaluation will be assigned as the
 | 
						||
variable value.  The following example demonstrates use of this
 | 
						||
evaluation to reliably pass the file-name of the Org mode buffer to a
 | 
						||
code block--note that evaluation of header arguments is guaranteed to
 | 
						||
take place in the original Org mode file, while there is no such
 | 
						||
guarantee for evaluation of the code block body.
 | 
						||
 | 
						||
     #+BEGIN_SRC sh :var filename=(buffer-file-name) :exports both
 | 
						||
       wc -w $filename
 | 
						||
     #+END_SRC
 | 
						||
 | 
						||
   Note that values read from tables and lists will not be evaluated as
 | 
						||
Emacs Lisp, as shown in the following example.
 | 
						||
 | 
						||
     #+NAME: table
 | 
						||
     | (a b c) |
 | 
						||
 | 
						||
     #+HEADERS: :var data=table[0,0]
 | 
						||
     #+BEGIN_SRC perl
 | 
						||
       $data
 | 
						||
     #+END_SRC
 | 
						||
 | 
						||
     #+RESULTS:
 | 
						||
     : (a b c)
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: results,  Next: file,  Prev: var,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.2 `:results'
 | 
						||
...................
 | 
						||
 | 
						||
There are four classes of `:results' header argument.  Only one option
 | 
						||
per class may be supplied per code block.
 | 
						||
 | 
						||
   * collection header arguments specify how the results should be
 | 
						||
     collected from the code block
 | 
						||
 | 
						||
   * type header arguments specify what type of result the code block
 | 
						||
     will return--which has implications for how they will be processed
 | 
						||
     before insertion into the Org mode buffer
 | 
						||
 | 
						||
   * format header arguments specify what type of result the code block
 | 
						||
     will return--which has implications for how they will be inserted
 | 
						||
     into the Org mode buffer
 | 
						||
 | 
						||
   * handling header arguments specify how the results of evaluating
 | 
						||
     the code block should be handled.
 | 
						||
 | 
						||
Collection
 | 
						||
..........
 | 
						||
 | 
						||
The following options are mutually exclusive, and specify how the
 | 
						||
results should be collected from the code block.
 | 
						||
 | 
						||
   * `value' This is the default.  The result is the value of the last
 | 
						||
     statement in the code block.  This header argument places the
 | 
						||
     evaluation in functional mode.  Note that in some languages, e.g.,
 | 
						||
     Python, use of this result type requires that a `return' statement
 | 
						||
     be included in the body of the source code block.  E.g., `:results
 | 
						||
     value'.
 | 
						||
 | 
						||
   * `output' The result is the collection of everything printed to
 | 
						||
     STDOUT during the execution of the code block.  This header
 | 
						||
     argument places the evaluation in scripting mode.  E.g., `:results
 | 
						||
     output'.
 | 
						||
 | 
						||
Type
 | 
						||
....
 | 
						||
 | 
						||
The following options are mutually exclusive and specify what type of
 | 
						||
results the code block will return.  By default, results are inserted
 | 
						||
as either a table or scalar depending on their value.
 | 
						||
 | 
						||
   * `table', `vector' The results should be interpreted as an Org mode
 | 
						||
     table.  If a single value is returned, it will be converted into a
 | 
						||
     table with one row and one column.  E.g., `:results value table'.
 | 
						||
 | 
						||
   * `list' The results should be interpreted as an Org mode list.  If
 | 
						||
     a single scalar value is returned it will be converted into a list
 | 
						||
     with only one element.
 | 
						||
 | 
						||
   * `scalar', `verbatim' The results should be interpreted
 | 
						||
     literally--they will not be converted into a table.  The results
 | 
						||
     will be inserted into the Org mode buffer as quoted text.  E.g.,
 | 
						||
     `:results value verbatim'.
 | 
						||
 | 
						||
   * `file' The results will be interpreted as the path to a file, and
 | 
						||
     will be inserted into the Org mode buffer as a file link.  E.g.,
 | 
						||
     `:results value file'.
 | 
						||
 | 
						||
Format
 | 
						||
......
 | 
						||
 | 
						||
The following options are mutually exclusive and specify what type of
 | 
						||
results the code block will return.  By default, results are inserted
 | 
						||
according to the type as specified above.
 | 
						||
 | 
						||
   * `raw' The results are interpreted as raw Org mode code and are
 | 
						||
     inserted directly into the buffer.  If the results look like a
 | 
						||
     table they will be aligned as such by Org mode.  E.g., `:results
 | 
						||
     value raw'.
 | 
						||
 | 
						||
   * `org' The results are will be enclosed in a `BEGIN_SRC org' block.
 | 
						||
     They are not comma-escaped by default but they will be if you hit
 | 
						||
     `TAB' in the block and/or if you export the file.  E.g., `:results
 | 
						||
     value org'.
 | 
						||
 | 
						||
   * `html' Results are assumed to be HTML and will be enclosed in a
 | 
						||
     `BEGIN_HTML' block.  E.g., `:results value html'.
 | 
						||
 | 
						||
   * `latex' Results assumed to be LaTeX and are enclosed in a
 | 
						||
     `BEGIN_LaTeX' block.  E.g., `:results value latex'.
 | 
						||
 | 
						||
   * `code' Result are assumed to be parsable code and are enclosed in
 | 
						||
     a code block.  E.g., `:results value code'.
 | 
						||
 | 
						||
   * `pp' The result is converted to pretty-printed code and is
 | 
						||
     enclosed in a code block.  This option currently supports Emacs
 | 
						||
     Lisp, Python, and Ruby.  E.g., `:results value pp'.
 | 
						||
 | 
						||
   * `drawer' The result is wrapped in a RESULTS drawer.  This can be
 | 
						||
     useful for inserting `raw' or `org' syntax results in such a way
 | 
						||
     that their extent is known and they can be automatically removed
 | 
						||
     or replaced.
 | 
						||
 | 
						||
Handling
 | 
						||
........
 | 
						||
 | 
						||
The following results options indicate what happens with the results
 | 
						||
once they are collected.
 | 
						||
 | 
						||
   * `silent' The results will be echoed in the minibuffer but will not
 | 
						||
     be inserted into the Org mode buffer.  E.g., `:results output
 | 
						||
     silent'.
 | 
						||
 | 
						||
   * `replace' The default value.  Any existing results will be
 | 
						||
     removed, and the new results will be inserted into the Org mode
 | 
						||
     buffer in their place.  E.g., `:results output replace'.
 | 
						||
 | 
						||
   * `append' If there are pre-existing results of the code block then
 | 
						||
     the new results will be appended to the existing results.
 | 
						||
     Otherwise the new results will be inserted as with `replace'.
 | 
						||
 | 
						||
   * `prepend' If there are pre-existing results of the code block then
 | 
						||
     the new results will be prepended to the existing results.
 | 
						||
     Otherwise the new results will be inserted as with `replace'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: file,  Next: file-desc,  Prev: results,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.3 `:file'
 | 
						||
................
 | 
						||
 | 
						||
The header argument `:file' is used to specify an external file in which
 | 
						||
to save code block results.  After code block evaluation an Org mode
 | 
						||
style `[[file:]]' link (see *note Link format::) to the file will be
 | 
						||
inserted into the Org mode buffer.  Some languages including R,
 | 
						||
gnuplot, dot, and ditaa provide special handling of the `:file' header
 | 
						||
argument automatically wrapping the code block body in the boilerplate
 | 
						||
code required to save output to the specified file.  This is often
 | 
						||
useful for saving graphical output of a code block to the specified
 | 
						||
file.
 | 
						||
 | 
						||
   The argument to `:file' should be either a string specifying the
 | 
						||
path to a file, or a list of two strings in which case the first
 | 
						||
element of the list should be the path to a file and the second a
 | 
						||
description for the link.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: file-desc,  Next: file-ext,  Prev: file,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.4 `:file-desc'
 | 
						||
.....................
 | 
						||
 | 
						||
The value of the `:file-desc' header argument is used to provide a
 | 
						||
description for file code block results which are inserted as Org mode
 | 
						||
links (see *note Link format::).  If the `:file-desc' header argument
 | 
						||
is given with no value the link path will be placed in both the "link"
 | 
						||
and the "description" portion of the Org mode link.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: file-ext,  Next: output-dir,  Prev: file-desc,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.5 `:file-ext'
 | 
						||
....................
 | 
						||
 | 
						||
The value of the `:file-ext' header argument is used to provide an
 | 
						||
extension to write the file output to.  It is combined with the
 | 
						||
`#+NAME:' of the source block and the value of the *note output-dir::
 | 
						||
header argument to generate a complete file name.
 | 
						||
 | 
						||
   This header arg will be overridden by `:file', and thus has no effect
 | 
						||
when the latter is specified.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: output-dir,  Next: dir,  Prev: file-ext,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.6 `:output-dir'
 | 
						||
......................
 | 
						||
 | 
						||
The value of the `:output-dir' header argument is used to provide a
 | 
						||
directory to write the file output to.  It may specify an absolute
 | 
						||
directory (beginning with `/') or a relative directory (without `/').
 | 
						||
It can be combined with the `#+NAME:' of the source block and the value
 | 
						||
of the *note file-ext:: header argument to generate a complete file
 | 
						||
name, or used along with a *note file:: header arg.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: dir,  Next: exports,  Prev: output-dir,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.7 `:dir' and remote execution
 | 
						||
....................................
 | 
						||
 | 
						||
While the `:file' header argument can be used to specify the path to the
 | 
						||
output file, `:dir' specifies the default directory during code block
 | 
						||
execution.  If it is absent, then the directory associated with the
 | 
						||
current buffer is used.  In other words, supplying `:dir path'
 | 
						||
temporarily has the same effect as changing the current directory with
 | 
						||
`M-x cd path RET', and then not supplying `:dir'.  Under the surface,
 | 
						||
`:dir' simply sets the value of the Emacs variable `default-directory'.
 | 
						||
 | 
						||
   When using `:dir', you should supply a relative path for file output
 | 
						||
(e.g., `:file myfile.jpg' or `:file results/myfile.jpg') in which case
 | 
						||
that path will be interpreted relative to the default directory.
 | 
						||
 | 
						||
   In other words, if you want your plot to go into a folder called
 | 
						||
`Work' in your home directory, you could use
 | 
						||
 | 
						||
     #+BEGIN_SRC R :file myplot.png :dir ~/Work
 | 
						||
     matplot(matrix(rnorm(100), 10), type="l")
 | 
						||
     #+END_SRC
 | 
						||
 | 
						||
Remote execution
 | 
						||
................
 | 
						||
 | 
						||
A directory on a remote machine can be specified using tramp file
 | 
						||
syntax, in which case the code will be evaluated on the remote machine.
 | 
						||
An example is
 | 
						||
 | 
						||
     #+BEGIN_SRC R :file plot.png :dir /dand@yakuba.princeton.edu:
 | 
						||
     plot(1:10, main=system("hostname", intern=TRUE))
 | 
						||
     #+END_SRC
 | 
						||
 | 
						||
   Text results will be returned to the local Org mode buffer as usual,
 | 
						||
and file output will be created on the remote machine with relative
 | 
						||
paths interpreted relative to the remote directory.  An Org mode link
 | 
						||
to the remote file will be created.
 | 
						||
 | 
						||
   So, in the above example a plot will be created on the remote
 | 
						||
machine, and a link of the following form will be inserted in the org
 | 
						||
buffer:
 | 
						||
 | 
						||
     [[file:/scp:dand@yakuba.princeton.edu:/home/dand/plot.png][plot.png]]
 | 
						||
 | 
						||
   Most of this functionality follows immediately from the fact that
 | 
						||
`:dir' sets the value of the Emacs variable `default-directory', thanks
 | 
						||
to tramp.  Those using XEmacs, or GNU Emacs prior to version 23 may
 | 
						||
need to install tramp separately in order for these features to work
 | 
						||
correctly.
 | 
						||
 | 
						||
Further points
 | 
						||
..............
 | 
						||
 | 
						||
   * If `:dir' is used in conjunction with `:session', although it will
 | 
						||
     determine the starting directory for a new session as expected, no
 | 
						||
     attempt is currently made to alter the directory associated with
 | 
						||
     an existing session.
 | 
						||
 | 
						||
   * `:dir' should typically not be used to create files during export
 | 
						||
     with `:exports results' or `:exports both'.  The reason is that,
 | 
						||
     in order to retain portability of exported material between
 | 
						||
     machines, during export links inserted into the buffer will _not_
 | 
						||
     be expanded against `default directory'.  Therefore, if
 | 
						||
     `default-directory' is altered using `:dir', it is probable that
 | 
						||
     the file will be created in a location to which the link does not
 | 
						||
     point.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: exports,  Next: tangle,  Prev: dir,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.8 `:exports'
 | 
						||
...................
 | 
						||
 | 
						||
The `:exports' header argument specifies what should be included in HTML
 | 
						||
or LaTeX exports of the Org mode file.  Note that the `:exports' option
 | 
						||
is only relevant for code blocks, not inline code.
 | 
						||
 | 
						||
   * `code' The default.  The body of code is included into the
 | 
						||
     exported file.  E.g., `:exports code'.
 | 
						||
 | 
						||
   * `results' The result of evaluating the code is included in the
 | 
						||
     exported file.  E.g., `:exports results'.
 | 
						||
 | 
						||
   * `both' Both the code and results are included in the exported
 | 
						||
     file.  E.g., `:exports both'.
 | 
						||
 | 
						||
   * `none' Nothing is included in the exported file.  E.g., `:exports
 | 
						||
     none'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: tangle,  Next: mkdirp,  Prev: exports,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.9 `:tangle'
 | 
						||
..................
 | 
						||
 | 
						||
The `:tangle' header argument specifies whether or not the code block
 | 
						||
should be included in tangled extraction of source code files.
 | 
						||
 | 
						||
   * `tangle' The code block is exported to a source code file named
 | 
						||
     after the full path (including the directory) and file name (w/o
 | 
						||
     extension) of the Org mode file.  E.g., `:tangle yes'.
 | 
						||
 | 
						||
   * `no' The default.  The code block is not exported to a source code
 | 
						||
     file.  E.g., `:tangle no'.
 | 
						||
 | 
						||
   * other Any other string passed to the `:tangle' header argument is
 | 
						||
     interpreted as a path (directory and file name relative to the
 | 
						||
     directory of the Org mode file) to which the block will be
 | 
						||
     exported.  E.g., `:tangle path'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: mkdirp,  Next: comments,  Prev: tangle,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.10 `:mkdirp'
 | 
						||
...................
 | 
						||
 | 
						||
The `:mkdirp' header argument can be used to create parent directories
 | 
						||
of tangled files when missing.  This can be set to `yes' to enable
 | 
						||
directory creation or to `no' to inhibit directory creation.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: comments,  Next: padline,  Prev: mkdirp,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.11 `:comments'
 | 
						||
.....................
 | 
						||
 | 
						||
By default code blocks are tangled to source-code files without any
 | 
						||
insertion of comments beyond those which may already exist in the body
 | 
						||
of the code block.  The `:comments' header argument can be set as
 | 
						||
follows to control the insertion of extra comments into the tangled
 | 
						||
code file.
 | 
						||
 | 
						||
   * `no' The default.  No extra comments are inserted during tangling.
 | 
						||
 | 
						||
   * `link' The code block is wrapped in comments which contain
 | 
						||
     pointers back to the original Org file from which the code was
 | 
						||
     tangled.
 | 
						||
 | 
						||
   * `yes' A synonym for "link" to maintain backwards compatibility.
 | 
						||
 | 
						||
   * `org' Include text from the Org mode file as a comment.  The text
 | 
						||
     is picked from the leading context of the tangled code and is
 | 
						||
     limited by the nearest headline or source block as the case may be.
 | 
						||
 | 
						||
   * `both' Turns on both the "link" and "org" comment options.
 | 
						||
 | 
						||
   * `noweb' Turns on the "link" comment option, and additionally wraps
 | 
						||
     expanded noweb references in the code block body in link comments.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: padline,  Next: no-expand,  Prev: comments,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.12 `:padline'
 | 
						||
....................
 | 
						||
 | 
						||
Control in insertion of padding lines around code block bodies in
 | 
						||
tangled code files.  The default value is `yes' which results in
 | 
						||
insertion of newlines before and after each tangled code block.  The
 | 
						||
following arguments are accepted.
 | 
						||
 | 
						||
   * `yes' Insert newlines before and after each code block body in
 | 
						||
     tangled code files.
 | 
						||
 | 
						||
   * `no' Do not insert any newline padding in tangled output.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: no-expand,  Next: session,  Prev: padline,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.13 `:no-expand'
 | 
						||
......................
 | 
						||
 | 
						||
By default, code blocks are expanded with `org-babel-expand-src-block'
 | 
						||
during tangling.  This has the effect of assigning values to variables
 | 
						||
specified with `:var' (see *note var::), and of replacing "noweb"
 | 
						||
references (see *note Noweb reference syntax::) with their targets.  The
 | 
						||
`:no-expand' header argument can be used to turn off this behavior.
 | 
						||
Note: The `:no-expand' header argument has no impact on export, i.e.
 | 
						||
code blocks will irrespective of this header argument expanded for
 | 
						||
execution.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: session,  Next: noweb,  Prev: no-expand,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.14 `:session'
 | 
						||
....................
 | 
						||
 | 
						||
The `:session' header argument starts a (possibly named) session for an
 | 
						||
interpreted language where the interpreter’s state is preserved.  All
 | 
						||
code blocks sharing the same name are exectuted by the same interpreter
 | 
						||
process.  By default, a session is not started.
 | 
						||
 | 
						||
   * `none' The default.  Each block is evaluated in its own
 | 
						||
     interpreter process, which is terminated after the evaluation.
 | 
						||
 | 
						||
   * `other' Any other string passed to the `:session' header argument
 | 
						||
     will give the session a name.  For example, `:session mysession'.
 | 
						||
     If `:session' is given but no name string is specified, the
 | 
						||
     session is named according to the language used in the block.  All
 | 
						||
     blocks with the same session name share the same session.  Using
 | 
						||
     different session names enables concurrent sessions (even for the
 | 
						||
     same interpreted language, if the language supports multiple
 | 
						||
     sessions).
 | 
						||
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: noweb,  Next: noweb-ref,  Prev: session,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.15 `:noweb'
 | 
						||
..................
 | 
						||
 | 
						||
The `:noweb' header argument controls expansion of "noweb" syntax
 | 
						||
references (see *note Noweb reference syntax::) when the code block is
 | 
						||
evaluated, tangled, or exported.  The `:noweb' header argument can have
 | 
						||
one of the five values: `no', `yes', `tangle', or `no-export'
 | 
						||
`strip-export'.
 | 
						||
 | 
						||
   * `no' The default.  "Noweb" syntax references in the body of the
 | 
						||
     code block will not be expanded before the code block is
 | 
						||
     evaluated, tangled or exported.
 | 
						||
 | 
						||
   * `yes' "Noweb" syntax references in the body of the code block will
 | 
						||
     be expanded before the code block is evaluated, tangled or
 | 
						||
     exported.
 | 
						||
 | 
						||
   * `tangle' "Noweb" syntax references in the body of the code block
 | 
						||
     will be expanded before the code block is tangled.  However,
 | 
						||
     "noweb" syntax references will not be expanded when the code block
 | 
						||
     is evaluated or exported.
 | 
						||
 | 
						||
   * `no-export' "Noweb" syntax references in the body of the code
 | 
						||
     block will be expanded before the block is evaluated or tangled.
 | 
						||
     However, "noweb" syntax references will not be expanded when the
 | 
						||
     code block is exported.
 | 
						||
 | 
						||
   * `strip-export' "Noweb" syntax references in the body of the code
 | 
						||
     block will be expanded before the block is evaluated or tangled.
 | 
						||
     However, "noweb" syntax references will be removed when the code
 | 
						||
     block is exported.
 | 
						||
 | 
						||
   * `eval' "Noweb" syntax references in the body of the code block
 | 
						||
     will only be expanded before the block is evaluated.
 | 
						||
 | 
						||
Noweb prefix lines
 | 
						||
..................
 | 
						||
 | 
						||
Noweb insertions are now placed behind the line prefix of the
 | 
						||
`<<reference>>'.  This behavior is illustrated in the following
 | 
						||
example.  Because the `<<example>>' noweb reference appears behind the
 | 
						||
SQL comment syntax, each line of the expanded noweb reference will be
 | 
						||
commented.
 | 
						||
 | 
						||
   This code block:
 | 
						||
 | 
						||
     -- <<example>>
 | 
						||
 | 
						||
   expands to:
 | 
						||
 | 
						||
     -- this is the
 | 
						||
     -- multi-line body of example
 | 
						||
 | 
						||
   Note that noweb replacement text that does not contain any newlines
 | 
						||
will not be affected by this change, so it is still possible to use
 | 
						||
inline noweb references.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: noweb-ref,  Next: noweb-sep,  Prev: noweb,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.16 `:noweb-ref'
 | 
						||
......................
 | 
						||
 | 
						||
When expanding "noweb" style references, the bodies of all code block
 | 
						||
with _either_ a block name matching the reference name _or_ a
 | 
						||
`:noweb-ref' header argument matching the reference name will be
 | 
						||
concatenated together to form the replacement text.
 | 
						||
 | 
						||
   By setting this header argument at the subtree or file level, simple
 | 
						||
code block concatenation may be achieved.  For example, when tangling
 | 
						||
the following Org mode file, the bodies of code blocks will be
 | 
						||
concatenated into the resulting pure code file(1).
 | 
						||
 | 
						||
      #+BEGIN_SRC sh :tangle yes :noweb yes :shebang #!/bin/sh
 | 
						||
        <<fullest-disk>>
 | 
						||
      #+END_SRC
 | 
						||
      * the mount point of the fullest disk
 | 
						||
        :PROPERTIES:
 | 
						||
        :noweb-ref: fullest-disk
 | 
						||
        :END:
 | 
						||
 | 
						||
      ** query all mounted disks
 | 
						||
      #+BEGIN_SRC sh
 | 
						||
        df \
 | 
						||
      #+END_SRC
 | 
						||
 | 
						||
      ** strip the header row
 | 
						||
      #+BEGIN_SRC sh
 | 
						||
        |sed '1d' \
 | 
						||
      #+END_SRC
 | 
						||
 | 
						||
      ** sort by the percent full
 | 
						||
      #+BEGIN_SRC sh
 | 
						||
        |awk '{print $5 " " $6}'|sort -n |tail -1 \
 | 
						||
      #+END_SRC
 | 
						||
 | 
						||
      ** extract the mount point
 | 
						||
      #+BEGIN_SRC sh
 | 
						||
        |awk '{print $2}'
 | 
						||
      #+END_SRC
 | 
						||
 | 
						||
   The `:noweb-sep' (see *note noweb-sep::) header argument holds the
 | 
						||
string used to separate accumulate noweb references like those above.
 | 
						||
By default a newline is used.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) (The example needs property inheritance to be turned on for the
 | 
						||
`noweb-ref' property, see *note Property inheritance::).
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: noweb-sep,  Next: cache,  Prev: noweb-ref,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.17 `:noweb-sep'
 | 
						||
......................
 | 
						||
 | 
						||
The `:noweb-sep' header argument holds the string used to separate
 | 
						||
accumulate noweb references (see *note noweb-ref::).  By default a
 | 
						||
newline is used.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: cache,  Next: sep,  Prev: noweb-sep,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.18 `:cache'
 | 
						||
..................
 | 
						||
 | 
						||
The `:cache' header argument controls the use of in-buffer caching of
 | 
						||
the results of evaluating code blocks.  It can be used to avoid
 | 
						||
re-evaluating unchanged code blocks.  Note that the `:cache' header
 | 
						||
argument will not attempt to cache results when the `:session' header
 | 
						||
argument is used, because the results of the code block execution may
 | 
						||
be stored in the session outside of the Org mode buffer.  The `:cache'
 | 
						||
header argument can have one of two values: `yes' or `no'.
 | 
						||
 | 
						||
   * `no' The default.  No caching takes place, and the code block will
 | 
						||
     be evaluated every time it is called.
 | 
						||
 | 
						||
   * `yes' Every time the code block is run a SHA1 hash of the code and
 | 
						||
     arguments passed to the block will be generated.  This hash is
 | 
						||
     packed into the `#+RESULTS:' line and will be checked on subsequent
 | 
						||
     executions of the code block.  If the code block has not changed
 | 
						||
     since the last time it was evaluated, it will not be re-evaluated.
 | 
						||
 | 
						||
   Code block caches notice if the value of a variable argument to the
 | 
						||
code block has changed.  If this is the case, the cache is invalidated
 | 
						||
and the code block is re-run.  In the following example, `caller' will
 | 
						||
not be re-run unless the results of `random' have changed since it was
 | 
						||
last run.
 | 
						||
 | 
						||
      #+NAME: random
 | 
						||
      #+BEGIN_SRC R :cache yes
 | 
						||
      runif(1)
 | 
						||
      #+END_SRC
 | 
						||
 | 
						||
      #+RESULTS[a2a72cd647ad44515fab62e144796432793d68e1]: random
 | 
						||
      0.4659510825295
 | 
						||
 | 
						||
      #+NAME: caller
 | 
						||
      #+BEGIN_SRC emacs-lisp :var x=random :cache yes
 | 
						||
      x
 | 
						||
      #+END_SRC
 | 
						||
 | 
						||
      #+RESULTS[bec9c8724e397d5df3b696502df3ed7892fc4f5f]: caller
 | 
						||
      0.254227238707244
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: sep,  Next: hlines,  Prev: cache,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.19 `:sep'
 | 
						||
................
 | 
						||
 | 
						||
The `:sep' header argument can be used to control the delimiter used
 | 
						||
when writing tabular results out to files external to Org mode.  This
 | 
						||
is used either when opening tabular results of a code block by calling
 | 
						||
the `org-open-at-point' function bound to `C-c C-o' on the code block,
 | 
						||
or when writing code block results to an external file (see *note
 | 
						||
file::) header argument.
 | 
						||
 | 
						||
   By default, when `:sep' is not specified output tables are tab
 | 
						||
delimited.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: hlines,  Next: colnames,  Prev: sep,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.20 `:hlines'
 | 
						||
...................
 | 
						||
 | 
						||
Tables are frequently represented with one or more horizontal lines, or
 | 
						||
hlines.  The `:hlines' argument to a code block accepts the values
 | 
						||
`yes' or `no', with a default value of `no'.
 | 
						||
 | 
						||
   * `no' Strips horizontal lines from the input table.  In most
 | 
						||
     languages this is the desired effect because an `hline' symbol is
 | 
						||
     interpreted as an unbound variable and raises an error.  Setting
 | 
						||
     `:hlines no' or relying on the default value yields the following
 | 
						||
     results.
 | 
						||
 | 
						||
          #+NAME: many-cols
 | 
						||
          | a | b | c |
 | 
						||
          |---+---+---|
 | 
						||
          | d | e | f |
 | 
						||
          |---+---+---|
 | 
						||
          | g | h | i |
 | 
						||
 | 
						||
          #+NAME: echo-table
 | 
						||
          #+BEGIN_SRC python :var tab=many-cols
 | 
						||
            return tab
 | 
						||
          #+END_SRC
 | 
						||
 | 
						||
          #+RESULTS: echo-table
 | 
						||
          | a | b | c |
 | 
						||
          | d | e | f |
 | 
						||
          | g | h | i |
 | 
						||
 | 
						||
   * `yes' Leaves hlines in the table.  Setting `:hlines yes' has this
 | 
						||
     effect.
 | 
						||
 | 
						||
          #+NAME: many-cols
 | 
						||
          | a | b | c |
 | 
						||
          |---+---+---|
 | 
						||
          | d | e | f |
 | 
						||
          |---+---+---|
 | 
						||
          | g | h | i |
 | 
						||
 | 
						||
          #+NAME: echo-table
 | 
						||
          #+BEGIN_SRC python :var tab=many-cols :hlines yes
 | 
						||
            return tab
 | 
						||
          #+END_SRC
 | 
						||
 | 
						||
          #+RESULTS: echo-table
 | 
						||
          | a | b | c |
 | 
						||
          |---+---+---|
 | 
						||
          | d | e | f |
 | 
						||
          |---+---+---|
 | 
						||
          | g | h | i |
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: colnames,  Next: rownames,  Prev: hlines,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.21 `:colnames'
 | 
						||
.....................
 | 
						||
 | 
						||
The `:colnames' header argument accepts the values `yes', `no', or
 | 
						||
`nil' for unassigned.  The default value is `nil'.  Note that the
 | 
						||
behavior of the `:colnames' header argument may differ across languages.
 | 
						||
 | 
						||
   * `nil' If an input table looks like it has column names (because
 | 
						||
     its second row is an hline), then the column names will be removed
 | 
						||
     from the table before processing, then reapplied to the results.
 | 
						||
 | 
						||
          #+NAME: less-cols
 | 
						||
          | a |
 | 
						||
          |---|
 | 
						||
          | b |
 | 
						||
          | c |
 | 
						||
 | 
						||
          #+NAME: echo-table-again
 | 
						||
          #+BEGIN_SRC python :var tab=less-cols
 | 
						||
            return [[val + '*' for val in row] for row in tab]
 | 
						||
          #+END_SRC
 | 
						||
 | 
						||
          #+RESULTS: echo-table-again
 | 
						||
          | a  |
 | 
						||
          |----|
 | 
						||
          | b* |
 | 
						||
          | c* |
 | 
						||
 | 
						||
     Please note that column names are not removed before the table is
 | 
						||
     indexed using variable indexing *Note Indexable variable values:
 | 
						||
     var.
 | 
						||
 | 
						||
   * `no' No column name pre-processing takes place
 | 
						||
 | 
						||
   * `yes' Column names are removed and reapplied as with `nil' even if
 | 
						||
     the table does not "look like" it has column names (i.e., the
 | 
						||
     second row is not an hline)
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: rownames,  Next: shebang,  Prev: colnames,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.22 `:rownames'
 | 
						||
.....................
 | 
						||
 | 
						||
The `:rownames' header argument can take on the values `yes' or `no',
 | 
						||
with a default value of `no'.  Note that Emacs Lisp code blocks ignore
 | 
						||
the `:rownames' header argument entirely given the ease with which
 | 
						||
tables with row names may be handled directly in Emacs Lisp.
 | 
						||
 | 
						||
   * `no' No row name pre-processing will take place.
 | 
						||
 | 
						||
   * `yes' The first column of the table is removed from the table
 | 
						||
     before processing, and is then reapplied to the results.
 | 
						||
 | 
						||
          #+NAME: with-rownames
 | 
						||
          | one | 1 | 2 | 3 | 4 |  5 |
 | 
						||
          | two | 6 | 7 | 8 | 9 | 10 |
 | 
						||
 | 
						||
          #+NAME: echo-table-once-again
 | 
						||
          #+BEGIN_SRC python :var tab=with-rownames :rownames yes
 | 
						||
            return [[val + 10 for val in row] for row in tab]
 | 
						||
          #+END_SRC
 | 
						||
 | 
						||
          #+RESULTS: echo-table-once-again
 | 
						||
          | one | 11 | 12 | 13 | 14 | 15 |
 | 
						||
          | two | 16 | 17 | 18 | 19 | 20 |
 | 
						||
 | 
						||
     Please note that row names are not removed before the table is
 | 
						||
     indexed using variable indexing *Note Indexable variable values:
 | 
						||
     var.
 | 
						||
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: shebang,  Next: tangle-mode,  Prev: rownames,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.23 `:shebang'
 | 
						||
....................
 | 
						||
 | 
						||
Setting the `:shebang' header argument to a string value (e.g.,
 | 
						||
`:shebang "#!/bin/bash"') causes the string to be inserted as the first
 | 
						||
line of any tangled file holding the code block, and the file
 | 
						||
permissions of the tangled file are set to make it executable.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: tangle-mode,  Next: eval,  Prev: shebang,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.24 `:tangle-mode'
 | 
						||
........................
 | 
						||
 | 
						||
The `tangle-mode' header argument controls the permission set on tangled
 | 
						||
files.  The value of this header argument will be passed to
 | 
						||
`set-file-modes'.  For example, to set a tangled file as read only use
 | 
						||
`:tangle-mode (identity #o444)', or to set a tangled file as executable
 | 
						||
use `:tangle-mode (identity #o755)'.  Blocks with `shebang' (*note
 | 
						||
shebang::) header arguments will automatically be made executable unless
 | 
						||
the `tangle-mode' header argument is also used.  The behavior is
 | 
						||
undefined if multiple code blocks with different values for the
 | 
						||
`tangle-mode' header argument are tangled to the same file.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: eval,  Next: wrap,  Prev: tangle-mode,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.25 `:eval'
 | 
						||
.................
 | 
						||
 | 
						||
The `:eval' header argument can be used to limit the evaluation of
 | 
						||
specific code blocks.  The `:eval' header argument can be useful for
 | 
						||
protecting against the evaluation of dangerous code blocks or to ensure
 | 
						||
that evaluation will require a query regardless of the value of the
 | 
						||
`org-confirm-babel-evaluate' variable.  The possible values of `:eval'
 | 
						||
and their effects are shown below.
 | 
						||
 | 
						||
`never or no'
 | 
						||
     The code block will not be evaluated under any circumstances.
 | 
						||
 | 
						||
`query'
 | 
						||
     Evaluation of the code block will require a query.
 | 
						||
 | 
						||
`never-export or no-export'
 | 
						||
     The code block will not be evaluated during export but may still
 | 
						||
     be called interactively.
 | 
						||
 | 
						||
`query-export'
 | 
						||
     Evaluation of the code block during export will require a query.
 | 
						||
 | 
						||
   If this header argument is not set then evaluation is determined by
 | 
						||
the value of the `org-confirm-babel-evaluate' variable see *note Code
 | 
						||
evaluation security::.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: wrap,  Next: post,  Prev: eval,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.26 `:wrap'
 | 
						||
.................
 | 
						||
 | 
						||
The `:wrap' header argument is used to mark the results of source block
 | 
						||
evaluation.  The header argument can be passed a string that will be
 | 
						||
appended to `#+BEGIN_' and `#+END_', which will then be used to wrap the
 | 
						||
results.  If not string is specified then the results will be wrapped
 | 
						||
in a `#+BEGIN/END_RESULTS' block.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: post,  Next: prologue,  Prev: wrap,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.27 `:post'
 | 
						||
.................
 | 
						||
 | 
						||
The `:post' header argument is used to post-process the results of a
 | 
						||
code block execution.  When a post argument is given, the results of
 | 
						||
the code block will temporarily be bound to the `*this*' variable.
 | 
						||
This variable may then be included in header argument forms such as
 | 
						||
those used in *note var:: header argument specifications allowing
 | 
						||
passing of results to other code blocks, or direct execution via Emacs
 | 
						||
Lisp.  Additional header arguments may be passed to the
 | 
						||
`:post'-function.
 | 
						||
 | 
						||
   The following two examples illustrate the usage of the `:post' header
 | 
						||
argument.  The first example shows how to attach a attribute-line via
 | 
						||
`:post'.
 | 
						||
 | 
						||
     #+name: attr_wrap
 | 
						||
     #+begin_src sh :var data="" :var width="\\textwidth" :results output
 | 
						||
       echo "#+ATTR_LATEX: :width $width"
 | 
						||
       echo "$data"
 | 
						||
     #+end_src
 | 
						||
 | 
						||
     #+header: :file /tmp/it.png
 | 
						||
     #+begin_src dot :post attr_wrap(width="5cm", data=*this*) :results drawer
 | 
						||
       digraph{
 | 
						||
               a -> b;
 | 
						||
               b -> c;
 | 
						||
               c -> a;
 | 
						||
       }
 | 
						||
     #+end_src
 | 
						||
 | 
						||
     #+RESULTS:
 | 
						||
     :RESULTS:
 | 
						||
     #+ATTR_LATEX :width 5cm
 | 
						||
     [[file:/tmp/it.png]]
 | 
						||
     :END:
 | 
						||
 | 
						||
   The second examples shows how to use `:post' together with the
 | 
						||
`:colnames' header argument.
 | 
						||
     #+name: round-tbl
 | 
						||
     #+begin_src emacs-lisp :var tbl="" fmt="%.3f"
 | 
						||
       (mapcar (lambda (row)
 | 
						||
                 (mapcar (lambda (cell)
 | 
						||
                           (if (numberp cell)
 | 
						||
                               (format fmt cell)
 | 
						||
                             cell))
 | 
						||
                         row))
 | 
						||
               tbl)
 | 
						||
     #+end_src
 | 
						||
 | 
						||
     #+begin_src R :colnames yes :post round-tbl[:colnames yes](*this*)
 | 
						||
     set.seed(42)
 | 
						||
     data.frame(foo=rnorm(1))
 | 
						||
     #+end_src
 | 
						||
 | 
						||
     #+RESULTS:
 | 
						||
     |   foo |
 | 
						||
     |-------|
 | 
						||
     | 1.371 |
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: prologue,  Next: epilogue,  Prev: post,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.28 `:prologue'
 | 
						||
.....................
 | 
						||
 | 
						||
The value of the `prologue' header argument will be prepended to the
 | 
						||
code block body before execution.  For example, `:prologue "reset"' may
 | 
						||
be used to reset a gnuplot session before execution of a particular code
 | 
						||
block, or the following configuration may be used to do this for all
 | 
						||
gnuplot code blocks.  Also see *note epilogue::.
 | 
						||
 | 
						||
     (add-to-list 'org-babel-default-header-args:gnuplot
 | 
						||
                  '((:prologue . "reset")))
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: epilogue,  Prev: prologue,  Up: Specific header arguments
 | 
						||
 | 
						||
14.8.2.29 `:epilogue'
 | 
						||
.....................
 | 
						||
 | 
						||
The value of the `epilogue' header argument will be appended to the code
 | 
						||
block body before execution.  Also see *note prologue::.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Results of evaluation,  Next: Noweb reference syntax,  Prev: Header arguments,  Up: Working with source code
 | 
						||
 | 
						||
14.9 Results of evaluation
 | 
						||
==========================
 | 
						||
 | 
						||
The way in which results are handled depends on whether a session is
 | 
						||
invoked, as well as on whether `:results value' or `:results output' is
 | 
						||
used.  The following table shows the table possibilities.  For a full
 | 
						||
listing of the possible results header arguments see *note results::.
 | 
						||
 | 
						||
                    Non-session              Session
 | 
						||
`:results value'    value of last            value of last expression
 | 
						||
                    expression               
 | 
						||
`:results output'   contents of STDOUT       concatenation of interpreter
 | 
						||
                                             output
 | 
						||
 | 
						||
   Note: With `:results value', the result in both `:session' and
 | 
						||
non-session is returned to Org mode as a table (a one- or
 | 
						||
two-dimensional vector of strings or numbers) when appropriate.
 | 
						||
 | 
						||
14.9.1 Non-session
 | 
						||
------------------
 | 
						||
 | 
						||
14.9.1.1 `:results value'
 | 
						||
.........................
 | 
						||
 | 
						||
This is the default.  Internally, the value is obtained by wrapping the
 | 
						||
code in a function definition in the external language, and evaluating
 | 
						||
that function.  Therefore, code should be written as if it were the
 | 
						||
body of such a function.  In particular, note that Python does not
 | 
						||
automatically return a value from a function unless a `return'
 | 
						||
statement is present, and so a `return' statement will usually be
 | 
						||
required in Python.
 | 
						||
 | 
						||
   This is the only one of the four evaluation contexts in which the
 | 
						||
code is automatically wrapped in a function definition.
 | 
						||
 | 
						||
14.9.1.2 `:results output'
 | 
						||
..........................
 | 
						||
 | 
						||
The code is passed to the interpreter as an external process, and the
 | 
						||
contents of the standard output stream are returned as text.  (In
 | 
						||
certain languages this also contains the error output stream; this is
 | 
						||
an area for future work.)
 | 
						||
 | 
						||
14.9.2 Session
 | 
						||
--------------
 | 
						||
 | 
						||
14.9.2.1 `:results value'
 | 
						||
.........................
 | 
						||
 | 
						||
The code is passed to an interpreter running as an interactive Emacs
 | 
						||
inferior process.  Only languages which provide tools for interactive
 | 
						||
evaluation of code have session support, so some language (e.g., C and
 | 
						||
ditaa) do not support the `:session' header argument, and in other
 | 
						||
languages (e.g., Python and Haskell) which have limitations on the code
 | 
						||
which may be entered into interactive sessions, those limitations apply
 | 
						||
to the code in code blocks using the `:session' header argument as well.
 | 
						||
 | 
						||
   Unless the `:results output' option is supplied (see below) the
 | 
						||
result returned is the result of the last evaluation performed by the
 | 
						||
interpreter.  (This is obtained in a language-specific manner: the
 | 
						||
value of the variable `_' in Python and Ruby, and the value of
 | 
						||
`.Last.value' in R).
 | 
						||
 | 
						||
14.9.2.2 `:results output'
 | 
						||
..........................
 | 
						||
 | 
						||
The code is passed to the interpreter running as an interactive Emacs
 | 
						||
inferior process.  The result returned is the concatenation of the
 | 
						||
sequence of (text) output from the interactive interpreter.  Notice
 | 
						||
that this is not necessarily the same as what would be sent to `STDOUT'
 | 
						||
if the same code were passed to a non-interactive interpreter running
 | 
						||
as an external process.  For example, compare the following two blocks:
 | 
						||
 | 
						||
     #+BEGIN_SRC python :results output
 | 
						||
      print "hello"
 | 
						||
      2
 | 
						||
      print "bye"
 | 
						||
     #+END_SRC
 | 
						||
 | 
						||
     #+RESULTS:
 | 
						||
     : hello
 | 
						||
     : bye
 | 
						||
 | 
						||
   In non-session mode, the "2" is not printed and does not appear.
 | 
						||
 | 
						||
     #+BEGIN_SRC python :results output :session
 | 
						||
      print "hello"
 | 
						||
      2
 | 
						||
      print "bye"
 | 
						||
     #+END_SRC
 | 
						||
 | 
						||
     #+RESULTS:
 | 
						||
     : hello
 | 
						||
     : 2
 | 
						||
     : bye
 | 
						||
 | 
						||
   But in `:session' mode, the interactive interpreter receives input
 | 
						||
"2" and prints out its value, "2".  (Indeed, the other print statements
 | 
						||
are unnecessary here).
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Noweb reference syntax,  Next: Key bindings and useful functions,  Prev: Results of evaluation,  Up: Working with source code
 | 
						||
 | 
						||
14.10 Noweb reference syntax
 | 
						||
============================
 | 
						||
 | 
						||
The "noweb" (see `http://www.cs.tufts.edu/~nr/noweb/') Literate
 | 
						||
Programming system allows named blocks of code to be referenced by
 | 
						||
using the familiar Noweb syntax:
 | 
						||
 | 
						||
     <<code-block-name>>
 | 
						||
 | 
						||
   When a code block is tangled or evaluated, whether or not "noweb"
 | 
						||
references are expanded depends upon the value of the `:noweb' header
 | 
						||
argument.  If `:noweb yes', then a Noweb reference is expanded before
 | 
						||
evaluation.  If `:noweb no', the default, then the reference is not
 | 
						||
expanded before evaluation.  See the *note noweb-ref:: header argument
 | 
						||
for a more flexible way to resolve noweb references.
 | 
						||
 | 
						||
   It is possible to include the _results_ of a code block rather than
 | 
						||
the body.  This is done by appending parenthesis to the code block name
 | 
						||
which may optionally contain arguments to the code block as shown below.
 | 
						||
 | 
						||
     <<code-block-name(optional arguments)>>
 | 
						||
 | 
						||
   Note: the default value, `:noweb no', was chosen to ensure that
 | 
						||
correct code is not broken in a language, such as Ruby, where `<<arg>>'
 | 
						||
is a syntactically valid construct.  If `<<arg>>' is not syntactically
 | 
						||
valid in languages that you use, then please consider setting the
 | 
						||
default value.
 | 
						||
 | 
						||
   Note: if noweb tangling is slow in large Org mode files consider
 | 
						||
setting the `org-babel-use-quick-and-dirty-noweb-expansion' variable to
 | 
						||
`t'.  This will result in faster noweb reference resolution at the
 | 
						||
expense of not correctly resolving inherited values of the `:noweb-ref'
 | 
						||
header argument.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Key bindings and useful functions,  Next: Batch execution,  Prev: Noweb reference syntax,  Up: Working with source code
 | 
						||
 | 
						||
14.11 Key bindings and useful functions
 | 
						||
=======================================
 | 
						||
 | 
						||
Many common Org mode key sequences are re-bound depending on the
 | 
						||
context.
 | 
						||
 | 
						||
   Within a code block, the following key bindings are active:
 | 
						||
 | 
						||
`C-c C-c'          `org-babel-execute-src-block'
 | 
						||
`C-c C-o'          `org-babel-open-src-block-result'
 | 
						||
`M-<up>'           `org-babel-load-in-session'
 | 
						||
`M-<down>'         `org-babel-switch-to-session'
 | 
						||
 | 
						||
   In an Org mode buffer, the following key bindings are active:
 | 
						||
 | 
						||
`C-c C-v p'   or   `C-c C-v      `org-babel-previous-src-block'
 | 
						||
C-p'                             
 | 
						||
`C-c C-v n'   or   `C-c C-v      `org-babel-next-src-block'
 | 
						||
C-n'                             
 | 
						||
`C-c C-v e'   or   `C-c C-v      `org-babel-execute-maybe'
 | 
						||
C-e'                             
 | 
						||
`C-c C-v o'   or   `C-c C-v      `org-babel-open-src-block-result'
 | 
						||
C-o'                             
 | 
						||
`C-c C-v v'   or   `C-c C-v      `org-babel-expand-src-block'
 | 
						||
C-v'                             
 | 
						||
`C-c C-v u'   or   `C-c C-v      `org-babel-goto-src-block-head'
 | 
						||
C-u'                             
 | 
						||
`C-c C-v g'   or   `C-c C-v      `org-babel-goto-named-src-block'
 | 
						||
C-g'                             
 | 
						||
`C-c C-v r'   or   `C-c C-v      `org-babel-goto-named-result'
 | 
						||
C-r'                             
 | 
						||
`C-c C-v b'   or   `C-c C-v      `org-babel-execute-buffer'
 | 
						||
C-b'                             
 | 
						||
`C-c C-v s'   or   `C-c C-v      `org-babel-execute-subtree'
 | 
						||
C-s'                             
 | 
						||
`C-c C-v d'   or   `C-c C-v      `org-babel-demarcate-block'
 | 
						||
C-d'                             
 | 
						||
`C-c C-v t'   or   `C-c C-v      `org-babel-tangle'
 | 
						||
C-t'                             
 | 
						||
`C-c C-v f'   or   `C-c C-v      `org-babel-tangle-file'
 | 
						||
C-f'                             
 | 
						||
`C-c C-v c'   or   `C-c C-v      `org-babel-check-src-block'
 | 
						||
C-c'                             
 | 
						||
`C-c C-v j'   or   `C-c C-v      `org-babel-insert-header-arg'
 | 
						||
C-j'                             
 | 
						||
`C-c C-v l'   or   `C-c C-v      `org-babel-load-in-session'
 | 
						||
C-l'                             
 | 
						||
`C-c C-v i'   or   `C-c C-v      `org-babel-lob-ingest'
 | 
						||
C-i'                             
 | 
						||
`C-c C-v I'   or   `C-c C-v      `org-babel-view-src-block-info'
 | 
						||
C-I'                             
 | 
						||
`C-c C-v z'   or   `C-c C-v      `org-babel-switch-to-session-with-code'
 | 
						||
C-z'                             
 | 
						||
`C-c C-v a'   or   `C-c C-v      `org-babel-sha1-hash'
 | 
						||
C-a'                             
 | 
						||
`C-c C-v h'   or   `C-c C-v      `org-babel-describe-bindings'
 | 
						||
C-h'                             
 | 
						||
`C-c C-v x'   or   `C-c C-v      `org-babel-do-key-sequence-in-edit-buffer'
 | 
						||
C-x'                             
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Batch execution,  Prev: Key bindings and useful functions,  Up: Working with source code
 | 
						||
 | 
						||
14.12 Batch execution
 | 
						||
=====================
 | 
						||
 | 
						||
It is possible to call functions from the command line.  This shell
 | 
						||
script calls `org-babel-tangle' on every one of its arguments.
 | 
						||
 | 
						||
   Be sure to adjust the paths to fit your system.
 | 
						||
 | 
						||
     #!/bin/sh
 | 
						||
     # -*- mode: shell-script -*-
 | 
						||
     #
 | 
						||
     # tangle files with org-mode
 | 
						||
     #
 | 
						||
     DIR=`pwd`
 | 
						||
     FILES=""
 | 
						||
 | 
						||
     # wrap each argument in the code required to call tangle on it
 | 
						||
     for i in $@; do
 | 
						||
         FILES="$FILES \"$i\""
 | 
						||
     done
 | 
						||
 | 
						||
     emacs -Q --batch \
 | 
						||
     --eval "(progn
 | 
						||
     (add-to-list 'load-path (expand-file-name \"~/src/org/lisp/\"))
 | 
						||
     (add-to-list 'load-path (expand-file-name \"~/src/org/contrib/lisp/\" t))
 | 
						||
     (require 'org)(require 'org-exp)(require 'ob)(require 'ob-tangle)
 | 
						||
     (mapc (lambda (file)
 | 
						||
            (find-file (expand-file-name file \"$DIR\"))
 | 
						||
            (org-babel-tangle)
 | 
						||
            (kill-buffer)) '($FILES)))" 2>&1 |grep tangled
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Miscellaneous,  Next: Hacking,  Prev: Working with source code,  Up: Top
 | 
						||
 | 
						||
15 Miscellaneous
 | 
						||
****************
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Completion::                  M-TAB knows what you need
 | 
						||
* Easy templates::              Quick insertion of structural elements
 | 
						||
* Speed keys::                  Electric commands at the beginning of a headline
 | 
						||
* Code evaluation security::    Org mode files evaluate inline code
 | 
						||
* Customization::               Adapting Org to your taste
 | 
						||
* In-buffer settings::          Overview of the #+KEYWORDS
 | 
						||
* The very busy C-c C-c key::   When in doubt, press C-c C-c
 | 
						||
* Clean view::                  Getting rid of leading stars in the outline
 | 
						||
* TTY keys::                    Using Org on a tty
 | 
						||
* Interaction::                 Other Emacs packages
 | 
						||
* org-crypt::                   Encrypting Org files
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Completion,  Next: Easy templates,  Up: Miscellaneous
 | 
						||
 | 
						||
15.1 Completion
 | 
						||
===============
 | 
						||
 | 
						||
Emacs would not be Emacs without completion, and Org mode uses it
 | 
						||
whenever it makes sense.  If you prefer an iswitchb- or ido-like
 | 
						||
interface for some of the completion prompts, you can specify your
 | 
						||
preference by setting at most one of the variables
 | 
						||
`org-completion-use-iswitchb' `org-completion-use-ido'.
 | 
						||
 | 
						||
   Org supports in-buffer completion.  This type of completion does not
 | 
						||
make use of the minibuffer.  You simply type a few letters into the
 | 
						||
buffer and use the key to complete text right there.
 | 
						||
 | 
						||
`M-<TAB>'
 | 
						||
     Complete word at point
 | 
						||
        * At the beginning of a headline, complete TODO keywords.
 | 
						||
 | 
						||
        * After `\', complete TeX symbols supported by the exporter.
 | 
						||
 | 
						||
        * After `*', complete headlines in the current buffer so that
 | 
						||
          they can be used in search links like `[[*find this
 | 
						||
          headline]]'.
 | 
						||
 | 
						||
        * After `:' in a headline, complete tags.  The list of tags is
 | 
						||
          taken from the variable `org-tag-alist' (possibly set through
 | 
						||
          the `#+TAGS' in-buffer option, *note Setting tags::), or it
 | 
						||
          is created dynamically from all tags used in the current
 | 
						||
          buffer.
 | 
						||
 | 
						||
        * After `:' and not in a headline, complete property keys.  The
 | 
						||
          list of keys is constructed dynamically from all keys used in
 | 
						||
          the current buffer.
 | 
						||
 | 
						||
        * After `[', complete link abbreviations (*note Link
 | 
						||
          abbreviations::).
 | 
						||
 | 
						||
        * After `#+', complete the special keywords like `TYP_TODO' or
 | 
						||
          `OPTIONS' which set file-specific options for Org mode.  When
 | 
						||
          the option keyword is already complete, pressing `M-<TAB>'
 | 
						||
          again will insert example settings for this keyword.
 | 
						||
 | 
						||
        * In the line after `#+STARTUP: ', complete startup keywords,
 | 
						||
          i.e., valid keys for this line.
 | 
						||
 | 
						||
        * Elsewhere, complete dictionary words using Ispell.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Easy templates,  Next: Speed keys,  Prev: Completion,  Up: Miscellaneous
 | 
						||
 | 
						||
15.2 Easy templates
 | 
						||
===================
 | 
						||
 | 
						||
Org mode supports insertion of empty structural elements (like
 | 
						||
`#+BEGIN_SRC' and `#+END_SRC' pairs) with just a few key strokes.  This
 | 
						||
is achieved through a native template expansion mechanism.  Note that
 | 
						||
Emacs has several other template mechanisms which could be used in a
 | 
						||
similar way, for example `yasnippet'.
 | 
						||
 | 
						||
   To insert a structural element, type a `<', followed by a template
 | 
						||
selector and `<TAB>'.  Completion takes effect only when the above
 | 
						||
keystrokes are typed on a line by itself.
 | 
						||
 | 
						||
   The following template selectors are currently supported.
 | 
						||
 | 
						||
`s'     `#+BEGIN_SRC     ... #+END_SRC'
 | 
						||
`e'     `#+BEGIN_EXAMPLE ... #+END_EXAMPLE'
 | 
						||
`q'     `#+BEGIN_QUOTE   ... #+END_QUOTE'
 | 
						||
`v'     `#+BEGIN_VERSE   ... #+END_VERSE'
 | 
						||
`c'     `#+BEGIN_CENTER  ... #+END_CENTER'
 | 
						||
`l'     `#+BEGIN_LaTeX   ... #+END_LaTeX'
 | 
						||
`L'     `#+LaTeX:'
 | 
						||
`h'     `#+BEGIN_HTML    ... #+END_HTML'
 | 
						||
`H'     `#+HTML:'
 | 
						||
`a'     `#+BEGIN_ASCII   ... #+END_ASCII'
 | 
						||
`A'     `#+ASCII:'
 | 
						||
`i'     `#+INDEX:' line
 | 
						||
`I'     `#+INCLUDE:' line
 | 
						||
 | 
						||
   For example, on an empty line, typing "<e" and then pressing TAB,
 | 
						||
will expand into a complete EXAMPLE template.
 | 
						||
 | 
						||
   You can install additional templates by customizing the variable
 | 
						||
`org-structure-template-alist'.  See the docstring of the variable for
 | 
						||
additional details.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Speed keys,  Next: Code evaluation security,  Prev: Easy templates,  Up: Miscellaneous
 | 
						||
 | 
						||
15.3 Speed keys
 | 
						||
===============
 | 
						||
 | 
						||
Single keys can be made to execute commands when the cursor is at the
 | 
						||
beginning of a headline, i.e., before the first star.  Configure the
 | 
						||
variable `org-use-speed-commands' to activate this feature.  There is a
 | 
						||
pre-defined list of commands, and you can add more such commands using
 | 
						||
the variable `org-speed-commands-user'.  Speed keys not only speed up
 | 
						||
navigation and other commands, but they also provide an alternative way
 | 
						||
to execute commands bound to keys that are not or not easily available
 | 
						||
on a TTY, or on a small mobile device with a limited keyboard.
 | 
						||
 | 
						||
   To see which commands are available, activate the feature and press
 | 
						||
`?' with the cursor at the beginning of a headline.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Code evaluation security,  Next: Customization,  Prev: Speed keys,  Up: Miscellaneous
 | 
						||
 | 
						||
15.4 Code evaluation and security issues
 | 
						||
========================================
 | 
						||
 | 
						||
Org provides tools to work with code snippets, including evaluating
 | 
						||
them.
 | 
						||
 | 
						||
   Running code on your machine always comes with a security risk.
 | 
						||
Badly written or malicious code can be executed on purpose or by
 | 
						||
accident.  Org has default settings which will only evaluate such code
 | 
						||
if you give explicit permission to do so, and as a casual user of these
 | 
						||
features you should leave these precautions intact.
 | 
						||
 | 
						||
   For people who regularly work with such code, the confirmation
 | 
						||
prompts can become annoying, and you might want to turn them off.  This
 | 
						||
can be done, but you must be aware of the risks that are involved.
 | 
						||
 | 
						||
   Code evaluation can happen under the following circumstances:
 | 
						||
 | 
						||
Source code blocks
 | 
						||
     Source code blocks can be evaluated during export, or when
 | 
						||
     pressing `C-c C-c' in the block.  The most important thing to
 | 
						||
     realize here is that Org mode files which contain code snippets
 | 
						||
     are, in a certain sense, like executable files.  So you should
 | 
						||
     accept them and load them into Emacs only from trusted
 | 
						||
     sources--just like you would do with a program you install on your
 | 
						||
     computer.
 | 
						||
 | 
						||
     Make sure you know what you are doing before customizing the
 | 
						||
     variables which take off the default security brakes.
 | 
						||
 | 
						||
      -- User Option: org-confirm-babel-evaluate
 | 
						||
          When t (the default), the user is asked before every code
 | 
						||
          block evaluation.  When `nil', the user is not asked.  When
 | 
						||
          set to a function, it is called with two arguments (language
 | 
						||
          and body of the code block) and should return t to ask and
 | 
						||
          `nil' not to ask.
 | 
						||
 | 
						||
     For example, here is how to execute "ditaa" code (which is
 | 
						||
     considered safe) without asking:
 | 
						||
 | 
						||
          (defun my-org-confirm-babel-evaluate (lang body)
 | 
						||
            (not (string= lang "ditaa")))  ; don't ask for ditaa
 | 
						||
          (setq org-confirm-babel-evaluate 'my-org-confirm-babel-evaluate)
 | 
						||
 | 
						||
Following `shell' and `elisp' links
 | 
						||
     Org has two link types that can directly evaluate code (*note
 | 
						||
     External links::).  These links can be problematic because the
 | 
						||
     code to be evaluated is not visible.
 | 
						||
 | 
						||
      -- User Option: org-confirm-shell-link-function
 | 
						||
          Function to queries user about shell link execution.
 | 
						||
 | 
						||
      -- User Option: org-confirm-elisp-link-function
 | 
						||
          Functions to query user for Emacs Lisp link execution.
 | 
						||
 | 
						||
Formulas in tables
 | 
						||
     Formulas in tables (*note The spreadsheet::) are code that is
 | 
						||
     evaluated either by the calc interpreter, or by the Emacs Lisp
 | 
						||
     interpreter.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Customization,  Next: In-buffer settings,  Prev: Code evaluation security,  Up: Miscellaneous
 | 
						||
 | 
						||
15.5 Customization
 | 
						||
==================
 | 
						||
 | 
						||
There are more than 500 variables that can be used to customize Org.
 | 
						||
For the sake of compactness of the manual, I am not describing the
 | 
						||
variables here.  A structured overview of customization variables is
 | 
						||
available with `M-x org-customize RET'.  Or select `Browse Org Group'
 | 
						||
from the `Org->Customization' menu.  Many settings can also be
 | 
						||
activated on a per-file basis, by putting special lines into the buffer
 | 
						||
(*note In-buffer settings::).
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: In-buffer settings,  Next: The very busy C-c C-c key,  Prev: Customization,  Up: Miscellaneous
 | 
						||
 | 
						||
15.6 Summary of in-buffer settings
 | 
						||
==================================
 | 
						||
 | 
						||
Org mode uses special lines in the buffer to define settings on a
 | 
						||
per-file basis.  These lines start with a `#+' followed by a keyword, a
 | 
						||
colon, and then individual words defining a setting.  Several setting
 | 
						||
words can be in the same line, but you can also have multiple lines for
 | 
						||
the keyword.  While these settings are described throughout the manual,
 | 
						||
here is a summary.  After changing any of these lines in the buffer,
 | 
						||
press `C-c C-c' with the cursor still in the line to activate the
 | 
						||
changes immediately.  Otherwise they become effective only when the
 | 
						||
file is visited again in a new Emacs session.
 | 
						||
 | 
						||
`#+ARCHIVE: %s_done::'
 | 
						||
     This line sets the archive location for the agenda file.  It
 | 
						||
     applies for all subsequent lines until the next `#+ARCHIVE' line,
 | 
						||
     or the end of the file.  The first such line also applies to any
 | 
						||
     entries before it.  The corresponding variable is
 | 
						||
     `org-archive-location'.
 | 
						||
 | 
						||
`#+CATEGORY:'
 | 
						||
     This line sets the category for the agenda file.  The category
 | 
						||
     applies to the whole document.
 | 
						||
 | 
						||
`#+COLUMNS: %25ITEM ...'
 | 
						||
     Set the default format for columns view.  This format applies when
 | 
						||
     columns view is invoked in locations where no `COLUMNS' property
 | 
						||
     applies.
 | 
						||
 | 
						||
`#+CONSTANTS: name1=value1 ...'
 | 
						||
     Set file-local values for constants to be used in table formulas.
 | 
						||
     This line sets the local variable
 | 
						||
     `org-table-formula-constants-local'.  The global version of this
 | 
						||
     variable is `org-table-formula-constants'.
 | 
						||
 | 
						||
`#+FILETAGS: :tag1:tag2:tag3:'
 | 
						||
     Set tags that can be inherited by any entry in the file, including
 | 
						||
     the top-level entries.
 | 
						||
 | 
						||
`#+LINK: linkword replace'
 | 
						||
     These lines (several are allowed) specify link abbreviations.
 | 
						||
     *Note Link abbreviations::.  The corresponding variable is
 | 
						||
     `org-link-abbrev-alist'.
 | 
						||
 | 
						||
`#+PRIORITIES: highest lowest default'
 | 
						||
     This line sets the limits and the default for the priorities.  All
 | 
						||
     three must be either letters A-Z or numbers 0-9.  The highest
 | 
						||
     priority must have a lower ASCII number than the lowest priority.
 | 
						||
 | 
						||
`#+PROPERTY: Property_Name Value'
 | 
						||
     This line sets a default inheritance value for entries in the
 | 
						||
     current buffer, most useful for specifying the allowed values of a
 | 
						||
     property.  
 | 
						||
 | 
						||
`#+SETUPFILE: file'
 | 
						||
     This line defines a file that holds more in-buffer setup.
 | 
						||
     Normally this is entirely ignored.  Only when the buffer is parsed
 | 
						||
     for option-setting lines (i.e., when starting Org mode for a file,
 | 
						||
     when pressing `C-c C-c' in a settings line, or when exporting),
 | 
						||
     then the contents of this file are parsed as if they had been
 | 
						||
     included in the buffer.  In particular, the file can be any other
 | 
						||
     Org mode file with internal setup.  You can visit the file the
 | 
						||
     cursor is in the line with `C-c ''.
 | 
						||
 | 
						||
`#+STARTUP:'
 | 
						||
     This line sets options to be used at startup of Org mode, when an
 | 
						||
     Org file is being visited.
 | 
						||
 | 
						||
     The first set of options deals with the initial visibility of the
 | 
						||
     outline tree.  The corresponding variable for global default
 | 
						||
     settings is `org-startup-folded', with a default value `t', which
 | 
						||
     means `overview'.  
 | 
						||
          overview         top-level headlines only
 | 
						||
          content          all headlines
 | 
						||
          showall          no folding of any entries
 | 
						||
          showeverything   show even drawer contents
 | 
						||
 | 
						||
     Dynamic virtual indentation is controlled by the variable
 | 
						||
     `org-startup-indented'(1)
 | 
						||
          indent     start with `org-indent-mode' turned on
 | 
						||
          noindent   start with `org-indent-mode' turned off
 | 
						||
 | 
						||
     Then there are options for aligning tables upon visiting a file.
 | 
						||
     This is useful in files containing narrowed table columns.  The
 | 
						||
     corresponding variable is `org-startup-align-all-tables', with a
 | 
						||
     default value `nil'.  
 | 
						||
          align      align all tables
 | 
						||
          noalign    don't align tables on startup
 | 
						||
 | 
						||
     When visiting a file, inline images can be automatically
 | 
						||
     displayed.  The corresponding variable is
 | 
						||
     `org-startup-with-inline-images', with a default value `nil' to
 | 
						||
     avoid delays when visiting a file.  
 | 
						||
          inlineimages   show inline images
 | 
						||
          noinlineimages don't show inline images on startup
 | 
						||
 | 
						||
     When visiting a file, LaTeX fragments can be converted to images
 | 
						||
     automatically.  The variable `org-startup-with-latex-preview' which
 | 
						||
     controls this behavior, is set to `nil' by default to avoid delays
 | 
						||
     on startup.  
 | 
						||
          latexpreview   preview LaTeX fragments
 | 
						||
          nolatexpreview don't preview LaTeX fragments
 | 
						||
 | 
						||
     Logging the closing and reopening of TODO items and clock
 | 
						||
     intervals can be configured using these options (see variables
 | 
						||
     `org-log-done', `org-log-note-clock-out' and `org-log-repeat') 
 | 
						||
          logdone             record a timestamp when an item is marked DONE
 | 
						||
          lognotedone         record timestamp and a note when DONE
 | 
						||
          nologdone           don't record when items are marked DONE
 | 
						||
          logrepeat           record a time when reinstating a repeating item
 | 
						||
          lognoterepeat       record a note when reinstating a repeating item
 | 
						||
          nologrepeat         do not record when reinstating repeating item
 | 
						||
          lognoteclock-out    record a note when clocking out
 | 
						||
          nolognoteclock-out  don't record a note when clocking out
 | 
						||
          logreschedule       record a timestamp when scheduling time changes
 | 
						||
          lognotereschedule   record a note when scheduling time changes
 | 
						||
          nologreschedule     do not record when a scheduling date changes
 | 
						||
          logredeadline       record a timestamp when deadline changes
 | 
						||
          lognoteredeadline   record a note when deadline changes
 | 
						||
          nologredeadline     do not record when a deadline date changes
 | 
						||
          logrefile           record a timestamp when refiling
 | 
						||
          lognoterefile       record a note when refiling
 | 
						||
          nologrefile         do not record when refiling
 | 
						||
          logdrawer           store log into drawer
 | 
						||
          nologdrawer         store log outside of drawer
 | 
						||
          logstatesreversed   reverse the order of states notes
 | 
						||
          nologstatesreversed do not reverse the order of states notes
 | 
						||
 | 
						||
     Here are the options for hiding leading stars in outline headings,
 | 
						||
     and for indenting outlines.  The corresponding variables are
 | 
						||
     `org-hide-leading-stars' and `org-odd-levels-only', both with a
 | 
						||
     default setting `nil' (meaning `showstars' and `oddeven').  
 | 
						||
          hidestars  make all but one of the stars starting a headline invisible.
 | 
						||
          showstars  show all stars starting a headline
 | 
						||
          indent     virtual indentation according to outline level
 | 
						||
          noindent   no virtual indentation according to outline level
 | 
						||
          odd        allow only odd outline levels (1,3,...)
 | 
						||
          oddeven    allow all outline levels
 | 
						||
 | 
						||
     To turn on custom format overlays over timestamps (variables
 | 
						||
     `org-put-time-stamp-overlays' and
 | 
						||
     `org-time-stamp-overlay-formats'), use 
 | 
						||
          customtime overlay custom time format
 | 
						||
 | 
						||
     The following options influence the table spreadsheet (variable
 | 
						||
     `constants-unit-system').  
 | 
						||
          constcgs   `constants.el' should use the c-g-s unit system
 | 
						||
          constSI    `constants.el' should use the SI unit system
 | 
						||
 | 
						||
     To influence footnote settings, use the following keywords.  The
 | 
						||
     corresponding variables are `org-footnote-define-inline',
 | 
						||
     `org-footnote-auto-label', and `org-footnote-auto-adjust'.  
 | 
						||
          fninline    define footnotes inline
 | 
						||
          fnnoinline  define footnotes in separate section
 | 
						||
          fnlocal     define footnotes near first reference, but not inline
 | 
						||
          fnprompt    prompt for footnote labels
 | 
						||
          fnauto      create `[fn:1]'-like labels automatically (default)
 | 
						||
          fnconfirm   offer automatic label for editing or confirmation
 | 
						||
          fnplain     create `[1]'-like labels automatically
 | 
						||
          fnadjust    automatically renumber and sort footnotes
 | 
						||
          nofnadjust  do not renumber and sort automatically
 | 
						||
 | 
						||
     To hide blocks on startup, use these keywords.  The corresponding
 | 
						||
     variable is `org-hide-block-startup'.  
 | 
						||
          hideblocks   Hide all begin/end blocks on startup
 | 
						||
          nohideblocks Do not hide blocks on startup
 | 
						||
 | 
						||
     The display of entities as UTF-8 characters is governed by the
 | 
						||
     variable `org-pretty-entities' and the keywords 
 | 
						||
          entitiespretty  Show entities as UTF-8 characters where possible
 | 
						||
          entitiesplain   Leave entities plain
 | 
						||
 | 
						||
`#+TAGS:  TAG1(c1) TAG2(c2)'
 | 
						||
     These lines (several such lines are allowed) specify the valid
 | 
						||
     tags in this file, and (potentially) the corresponding _fast tag
 | 
						||
     selection_ keys.  The corresponding variable is `org-tag-alist'.  
 | 
						||
 | 
						||
`#+TBLFM:'
 | 
						||
     This line contains the formulas for the table directly above the
 | 
						||
     line.
 | 
						||
 | 
						||
     Table can have multiple lines containing `#+TBLFM:'.  Note that
 | 
						||
     only the first line of `#+TBLFM:' will be applied when you
 | 
						||
     recalculate the table.  For more details see *note Using multiple
 | 
						||
     #+TBLFM lines:: in *note Editing and debugging formulas::.
 | 
						||
 | 
						||
`#+TITLE:, #+AUTHOR:, #+EMAIL:, #+LANGUAGE:, #+DATE:,'
 | 
						||
`#+OPTIONS:, #+BIND:,'
 | 
						||
`#+SELECT_TAGS:, #+EXCLUDE_TAGS:'
 | 
						||
     These lines provide settings for exporting files.  For more
 | 
						||
     details see *note Export settings::.
 | 
						||
 | 
						||
`#+TODO:    #+SEQ_TODO:   #+TYP_TODO:'
 | 
						||
     These lines set the TODO keywords and their interpretation in the
 | 
						||
     current file.  The corresponding variable is `org-todo-keywords'.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Emacs 23 and Org mode 6.29 are required
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: The very busy C-c C-c key,  Next: Clean view,  Prev: In-buffer settings,  Up: Miscellaneous
 | 
						||
 | 
						||
15.7 The very busy C-c C-c key
 | 
						||
==============================
 | 
						||
 | 
						||
The key `C-c C-c' has many purposes in Org, which are all mentioned
 | 
						||
scattered throughout this manual.  One specific function of this key is
 | 
						||
to add _tags_ to a headline (*note Tags::).  In many other
 | 
						||
circumstances it means something like _"Hey Org, look here and update
 | 
						||
according to what you see here"_.  Here is a summary of what this means
 | 
						||
in different contexts.
 | 
						||
 | 
						||
   - If there are highlights in the buffer from the creation of a sparse
 | 
						||
     tree, or from clock display, remove these highlights.
 | 
						||
 | 
						||
   - If the cursor is in one of the special `#+KEYWORD' lines, this
 | 
						||
     triggers scanning the buffer for these lines and updating the
 | 
						||
     information.
 | 
						||
 | 
						||
   - If the cursor is inside a table, realign the table.  This command
 | 
						||
     works even if the automatic table editor has been turned off.
 | 
						||
 | 
						||
   - If the cursor is on a `#+TBLFM' line, re-apply the formulas to the
 | 
						||
     entire table.
 | 
						||
 | 
						||
   - If the current buffer is a capture buffer, close the note and file
 | 
						||
     it.  With a prefix argument, file it, without further interaction,
 | 
						||
     to the default location.
 | 
						||
 | 
						||
   - If the cursor is on a `<<<target>>>', update radio targets and
 | 
						||
     corresponding links in this buffer.
 | 
						||
 | 
						||
   - If the cursor is in a property line or at the start or end of a
 | 
						||
     property drawer, offer property commands.
 | 
						||
 | 
						||
   - If the cursor is at a footnote reference, go to the corresponding
 | 
						||
     definition, and _vice versa_.
 | 
						||
 | 
						||
   - If the cursor is on a statistics cookie, update it.
 | 
						||
 | 
						||
   - If the cursor is in a plain list item with a checkbox, toggle the
 | 
						||
     status of the checkbox.
 | 
						||
 | 
						||
   - If the cursor is on a numbered item in a plain list, renumber the
 | 
						||
     ordered list.
 | 
						||
 | 
						||
   - If the cursor is on the `#+BEGIN' line of a dynamic block, the
 | 
						||
     block is updated.
 | 
						||
 | 
						||
   - If the cursor is at a timestamp, fix the day name in the timestamp.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Clean view,  Next: TTY keys,  Prev: The very busy C-c C-c key,  Up: Miscellaneous
 | 
						||
 | 
						||
15.8 A cleaner outline view
 | 
						||
===========================
 | 
						||
 | 
						||
Some people find it noisy and distracting that the Org headlines start
 | 
						||
with a potentially large number of stars, and that text below the
 | 
						||
headlines is not indented.  While this is no problem when writing a
 | 
						||
_book-like_ document where the outline headings are really section
 | 
						||
headings, in a more _list-oriented_ outline, indented structure is a
 | 
						||
lot cleaner:
 | 
						||
 | 
						||
     * Top level headline             |    * Top level headline
 | 
						||
     ** Second level                  |      * Second level
 | 
						||
     *** 3rd level                    |        * 3rd level
 | 
						||
     some text                        |          some text
 | 
						||
     *** 3rd level                    |        * 3rd level
 | 
						||
     more text                        |          more text
 | 
						||
     * Another top level headline     |    * Another top level headline
 | 
						||
 | 
						||
If you are using at least Emacs 23.2(1) and version 6.29 of Org, this
 | 
						||
kind of view can be achieved dynamically at display time using
 | 
						||
`org-indent-mode'.  In this minor mode, all lines are prefixed for
 | 
						||
display with the necessary amount of space(2).  Also headlines are
 | 
						||
prefixed with additional stars, so that the amount of indentation
 | 
						||
shifts by two(3)  spaces per level.  All headline stars but the last
 | 
						||
one are made invisible using the `org-hide' face(4); see below under
 | 
						||
`2.' for more information on how this works.  You can turn on
 | 
						||
`org-indent-mode' for all files by customizing the variable
 | 
						||
`org-startup-indented', or you can turn it on for individual files using
 | 
						||
 | 
						||
     #+STARTUP: indent
 | 
						||
 | 
						||
   If you want a similar effect in an earlier version of Emacs and/or
 | 
						||
Org, or if you want the indentation to be hard space characters so that
 | 
						||
the plain text file looks as similar as possible to the Emacs display,
 | 
						||
Org supports you in the following way:
 | 
						||
 | 
						||
  1. _Indentation of text below headlines_
 | 
						||
     You may indent text below each headline to make the left boundary
 | 
						||
     line up with the headline, like
 | 
						||
 | 
						||
          *** 3rd level
 | 
						||
              more text, now indented
 | 
						||
 | 
						||
     Org supports this with paragraph filling, line wrapping, and
 | 
						||
     structure editing(5), preserving or adapting the indentation as
 | 
						||
     appropriate.
 | 
						||
 | 
						||
  2. _Hiding leading stars_
 | 
						||
     You can modify the display in such a way that all leading stars
 | 
						||
     become invisible.  To do this in a global way, configure the
 | 
						||
     variable `org-hide-leading-stars' or change this on a per-file
 | 
						||
     basis with
 | 
						||
 | 
						||
          #+STARTUP: hidestars
 | 
						||
          #+STARTUP: showstars
 | 
						||
 | 
						||
     With hidden stars, the tree becomes:
 | 
						||
 | 
						||
          * Top level headline
 | 
						||
           * Second level
 | 
						||
            * 3rd level
 | 
						||
            ...
 | 
						||
 | 
						||
     The leading stars are not truly replaced by whitespace, they are
 | 
						||
     only fontified with the face `org-hide' that uses the background
 | 
						||
     color as font color.  If you are not using either white or black
 | 
						||
     background, you may have to customize this face to get the wanted
 | 
						||
     effect.  Another possibility is to set this font such that the
 | 
						||
     extra stars are almost invisible, for example using the color
 | 
						||
     `grey90' on a white background.
 | 
						||
 | 
						||
  3. Things become cleaner still if you skip all the even levels and
 | 
						||
     use only odd levels 1, 3, 5..., effectively adding two stars to go
 | 
						||
     from one outline level to the next(6).  In this way we get the
 | 
						||
     outline view shown at the beginning of this section.  In order to
 | 
						||
     make the structure editing and export commands handle this
 | 
						||
     convention correctly, configure the variable
 | 
						||
     `org-odd-levels-only', or set this on a per-file basis with one of
 | 
						||
     the following lines:
 | 
						||
 | 
						||
          #+STARTUP: odd
 | 
						||
          #+STARTUP: oddeven
 | 
						||
 | 
						||
     You can convert an Org file from single-star-per-level to the
 | 
						||
     double-star-per-level convention with `M-x
 | 
						||
     org-convert-to-odd-levels RET' in that file.  The reverse
 | 
						||
     operation is `M-x org-convert-to-oddeven-levels'.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Emacs 23.1 can actually crash with `org-indent-mode'
 | 
						||
 | 
						||
   (2) `org-indent-mode' also sets the `wrap-prefix' property, such
 | 
						||
that `visual-line-mode' (or purely setting `word-wrap') wraps long
 | 
						||
lines (including headlines) correctly indented.
 | 
						||
 | 
						||
   (3) See the variable `org-indent-indentation-per-level'.
 | 
						||
 | 
						||
   (4) Turning on `org-indent-mode' sets `org-hide-leading-stars' to
 | 
						||
`t' and `org-adapt-indentation' to `nil'.
 | 
						||
 | 
						||
   (5) See also the variable `org-adapt-indentation'.
 | 
						||
 | 
						||
   (6) When you need to specify a level for a property search or refile
 | 
						||
targets, `LEVEL=2' will correspond to 3 stars, etc.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: TTY keys,  Next: Interaction,  Prev: Clean view,  Up: Miscellaneous
 | 
						||
 | 
						||
15.9 Using Org on a tty
 | 
						||
=======================
 | 
						||
 | 
						||
Because Org contains a large number of commands, by default many of
 | 
						||
Org's core commands are bound to keys that are generally not accessible
 | 
						||
on a tty, such as the cursor keys (<left>, <right>, <up>, <down>),
 | 
						||
<TAB> and <RET>, in particular when used together with modifiers like
 | 
						||
<Meta> and/or <Shift>.  To access these commands on a tty when special
 | 
						||
keys are unavailable, the following alternative bindings can be used.
 | 
						||
The tty bindings below will likely be more cumbersome; you may find for
 | 
						||
some of the bindings below that a customized workaround suits you
 | 
						||
better.  For example, changing a timestamp is really only fun with
 | 
						||
`S-<cursor>' keys, whereas on a tty you would rather use `C-c .' to
 | 
						||
re-insert the timestamp.
 | 
						||
 | 
						||
Default     Alternative 1  Speed   Alternative 2
 | 
						||
                           key     
 | 
						||
`S-<TAB>'   `C-u <TAB>'    `C'     
 | 
						||
`M-<left>'  `C-c C-x l'    `l'     `<Esc> <left>'
 | 
						||
`M-S-<left>'`C-c C-x L'    `L'     
 | 
						||
`M-<right>' `C-c C-x r'    `r'     `<Esc>
 | 
						||
                                   <right>'
 | 
						||
`M-S-<right>'`C-c C-x R'    `R'     
 | 
						||
`M-<up>'    `C-c C-x u'    ` '     `<Esc> <up>'
 | 
						||
`M-S-<up>'  `C-c C-x U'    `U'     
 | 
						||
`M-<down>'  `C-c C-x d'    ` '     `<Esc> <down>'
 | 
						||
`M-S-<down>'`C-c C-x D'    `D'     
 | 
						||
`S-<RET>'   `C-c C-x c'    ` '     
 | 
						||
`M-<RET>'   `C-c C-x m'    ` '     `<Esc> <RET>'
 | 
						||
`M-S-<RET>' `C-c C-x M'    ` '     
 | 
						||
`S-<left>'  `C-c <left>'   ` '     
 | 
						||
`S-<right>' `C-c <right>'  ` '     
 | 
						||
`S-<up>'    `C-c <up>'     ` '     
 | 
						||
`S-<down>'  `C-c <down>'   ` '     
 | 
						||
`C-S-<left>'`C-c C-x       ` '     
 | 
						||
            <left>'                
 | 
						||
`C-S-<right>'`C-c C-x       ` '     
 | 
						||
            <right>'               
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Interaction,  Next: org-crypt,  Prev: TTY keys,  Up: Miscellaneous
 | 
						||
 | 
						||
15.10 Interaction with other packages
 | 
						||
=====================================
 | 
						||
 | 
						||
Org lives in the world of GNU Emacs and interacts in various ways with
 | 
						||
other code out there.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Cooperation::                 Packages Org cooperates with
 | 
						||
* Conflicts::                   Packages that lead to conflicts
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Cooperation,  Next: Conflicts,  Up: Interaction
 | 
						||
 | 
						||
15.10.1 Packages that Org cooperates with
 | 
						||
-----------------------------------------
 | 
						||
 | 
						||
`calc.el' by Dave Gillespie
 | 
						||
     Org uses the Calc package for implementing spreadsheet
 | 
						||
     functionality in its tables (*note The spreadsheet::).  Org checks
 | 
						||
     for the availability of Calc by looking for the function
 | 
						||
     `calc-eval' which will have been autoloaded during setup if Calc
 | 
						||
     has been installed properly.  As of Emacs 22, Calc is part of the
 | 
						||
     Emacs distribution.  Another possibility for interaction between
 | 
						||
     the two packages is using Calc for embedded calculations.  *Note
 | 
						||
     Embedded Mode: (calc)Embedded Mode.
 | 
						||
 | 
						||
`constants.el' by Carsten Dominik
 | 
						||
     In a table formula (*note The spreadsheet::), it is possible to use
 | 
						||
     names for natural constants or units.  Instead of defining your own
 | 
						||
     constants in the variable `org-table-formula-constants', install
 | 
						||
     the `constants' package which defines a large number of constants
 | 
						||
     and units, and lets you use unit prefixes like `M' for `Mega',
 | 
						||
     etc.  You will need version 2.0 of this package, available at
 | 
						||
     `http://www.astro.uva.nl/~dominik/Tools'.  Org checks for the
 | 
						||
     function `constants-get', which has to be autoloaded in your
 | 
						||
     setup.  See the installation instructions in the file
 | 
						||
     `constants.el'.
 | 
						||
 | 
						||
`cdlatex.el' by Carsten Dominik
 | 
						||
     Org mode can make use of the CDLaTeX package to efficiently enter
 | 
						||
     LaTeX fragments into Org files.  See *note CDLaTeX mode::.
 | 
						||
 | 
						||
`imenu.el' by Ake Stenhoff and Lars Lindberg
 | 
						||
     Imenu allows menu access to an index of items in a file.  Org mode
 | 
						||
     supports Imenu--all you need to do to get the index is the
 | 
						||
     following:
 | 
						||
          (add-hook 'org-mode-hook
 | 
						||
                    (lambda () (imenu-add-to-menubar "Imenu")))
 | 
						||
     By default the index is two levels deep--you can modify the depth
 | 
						||
     using the option `org-imenu-depth'.
 | 
						||
 | 
						||
`remember.el' by John Wiegley
 | 
						||
     Org used to use this package for capture, but no longer does.
 | 
						||
 | 
						||
`speedbar.el' by Eric M. Ludlam
 | 
						||
     Speedbar is a package that creates a special frame displaying
 | 
						||
     files and index items in files.  Org mode supports Speedbar and
 | 
						||
     allows you to drill into Org files directly from the Speedbar.  It
 | 
						||
     also allows you to restrict the scope of agenda commands to a file
 | 
						||
     or a subtree by using the command `<' in the Speedbar frame.  
 | 
						||
 | 
						||
`table.el' by Takaaki Ota
 | 
						||
     Complex ASCII tables with automatic line wrapping, column- and
 | 
						||
     row-spanning, and alignment can be created using the Emacs table
 | 
						||
     package by Takaaki Ota (`http://sourceforge.net/projects/table',
 | 
						||
     and also part of Emacs 22).  Org mode will recognize these tables
 | 
						||
     and export them properly.  Because of interference with other Org
 | 
						||
     mode functionality, you unfortunately cannot edit these tables
 | 
						||
     directly in the buffer.  Instead, you need to use the command `C-c
 | 
						||
     '' to edit them, similar to source code snippets.
 | 
						||
 | 
						||
    `C-c '     (`org-edit-special')'
 | 
						||
          Edit a `table.el' table.  Works when the cursor is in a
 | 
						||
          table.el table.  
 | 
						||
 | 
						||
    `C-c ~     (`org-table-create-with-table.el')'
 | 
						||
          Insert a `table.el' table.  If there is already a table at
 | 
						||
          point, this command converts it between the `table.el' format
 | 
						||
          and the Org mode format.  See the documentation string of the
 | 
						||
          command `org-convert-table' for the restrictions under which
 | 
						||
          this is possible.
 | 
						||
     `table.el' is part of Emacs since Emacs 22.
 | 
						||
 | 
						||
`footnote.el' by Steven L. Baur
 | 
						||
     Org mode recognizes numerical footnotes as provided by this
 | 
						||
     package.  However, Org mode also has its own footnote support
 | 
						||
     (*note Footnotes::), which makes using `footnote.el' unnecessary.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Conflicts,  Prev: Cooperation,  Up: Interaction
 | 
						||
 | 
						||
15.10.2 Packages that lead to conflicts with Org mode
 | 
						||
-----------------------------------------------------
 | 
						||
 | 
						||
     In Emacs 23, `shift-selection-mode' is on by default, meaning that
 | 
						||
     cursor motions combined with the shift key should start or enlarge
 | 
						||
     regions.  This conflicts with the use of `S-<cursor>' commands in
 | 
						||
     Org to change timestamps, TODO keywords, priorities, and item
 | 
						||
     bullet types if the cursor is at such a location.  By default,
 | 
						||
     `S-<cursor>' commands outside special contexts don't do anything,
 | 
						||
     but you can customize the variable `org-support-shift-select'.
 | 
						||
     Org mode then tries to accommodate shift selection by (i) using it
 | 
						||
     outside of the special contexts where special commands apply, and
 | 
						||
     by (ii) extending an existing active region even if the cursor
 | 
						||
     moves across a special context.
 | 
						||
 | 
						||
`CUA.el' by Kim. F. Storm
 | 
						||
     Key bindings in Org conflict with the `S-<cursor>' keys used by
 | 
						||
     CUA mode (as well as `pc-select-mode' and `s-region-mode') to
 | 
						||
     select and extend the region.  In fact, Emacs 23 has this built-in
 | 
						||
     in the form of `shift-selection-mode', see previous paragraph.  If
 | 
						||
     you are using Emacs 23, you probably don't want to use another
 | 
						||
     package for this purpose.  However, if you prefer to leave these
 | 
						||
     keys to a different package while working in Org mode, configure
 | 
						||
     the variable `org-replace-disputed-keys'.  When set, Org will move
 | 
						||
     the following key bindings in Org files, and in the agenda buffer
 | 
						||
     (but not during date selection).
 | 
						||
 | 
						||
          S-UP      =>  M-p             S-DOWN     =>  M-n
 | 
						||
          S-LEFT    =>  M--             S-RIGHT    =>  M-+
 | 
						||
          C-S-LEFT  =>  M-S--           C-S-RIGHT  =>  M-S-+
 | 
						||
 | 
						||
     Yes, these are unfortunately more difficult to remember.  If you
 | 
						||
     want to have other replacement keys, look at the variable
 | 
						||
     `org-disputed-keys'.
 | 
						||
 | 
						||
`ecomplete.el' by Lars Magne Ingebrigtsen <larsi@gnus.org>
 | 
						||
     Ecomplete provides "electric" address completion in address header
 | 
						||
     lines in message buffers.  Sadly Orgtbl mode cuts ecompletes power
 | 
						||
     supply: No completion happens when Orgtbl mode is enabled in
 | 
						||
     message buffers while entering text in address header lines.  If
 | 
						||
     one wants to use ecomplete one should _not_ follow the advice to
 | 
						||
     automagically turn on Orgtbl mode in message buffers (see *note
 | 
						||
     Orgtbl mode::), but instead--after filling in the message
 | 
						||
     headers--turn on Orgtbl mode manually when needed in the messages
 | 
						||
     body.
 | 
						||
 | 
						||
`filladapt.el' by Kyle Jones
 | 
						||
     Org mode tries to do the right thing when filling paragraphs, list
 | 
						||
     items and other elements.  Many users reported they had problems
 | 
						||
     using both `filladapt.el' and Org mode, so a safe thing to do is
 | 
						||
     to disable it like this:
 | 
						||
 | 
						||
          (add-hook 'org-mode-hook 'turn-off-filladapt-mode)
 | 
						||
 | 
						||
`yasnippet.el'
 | 
						||
     The way Org mode binds the <TAB> key (binding to `[tab]' instead of
 | 
						||
     `"\t"') overrules YASnippet's access to this key.  The following
 | 
						||
     code fixed this problem:
 | 
						||
 | 
						||
          (add-hook 'org-mode-hook
 | 
						||
                    (lambda ()
 | 
						||
                      (org-set-local 'yas/trigger-key [tab])
 | 
						||
                      (define-key yas/keymap [tab] 'yas/next-field-or-maybe-expand)))
 | 
						||
 | 
						||
     The latest version of yasnippet doesn't play well with Org mode.
 | 
						||
     If the above code does not fix the conflict, start by defining the
 | 
						||
     following function:
 | 
						||
 | 
						||
          (defun yas/org-very-safe-expand ()
 | 
						||
            (let ((yas/fallback-behavior 'return-nil)) (yas/expand)))
 | 
						||
 | 
						||
     Then, tell Org mode what to do with the new function:
 | 
						||
 | 
						||
          (add-hook 'org-mode-hook
 | 
						||
                    (lambda ()
 | 
						||
                      (make-variable-buffer-local 'yas/trigger-key)
 | 
						||
                      (setq yas/trigger-key [tab])
 | 
						||
                      (add-to-list 'org-tab-first-hook 'yas/org-very-safe-expand)
 | 
						||
                      (define-key yas/keymap [tab] 'yas/next-field)))
 | 
						||
 | 
						||
`windmove.el' by Hovav Shacham
 | 
						||
     This package also uses the `S-<cursor>' keys, so everything written
 | 
						||
     in the paragraph above about CUA mode also applies here.  If you
 | 
						||
     want make the windmove function active in locations where Org mode
 | 
						||
     does not have special functionality on `S-<cursor>', add this to
 | 
						||
     your configuration:
 | 
						||
 | 
						||
          ;; Make windmove work in org-mode:
 | 
						||
          (add-hook 'org-shiftup-final-hook 'windmove-up)
 | 
						||
          (add-hook 'org-shiftleft-final-hook 'windmove-left)
 | 
						||
          (add-hook 'org-shiftdown-final-hook 'windmove-down)
 | 
						||
          (add-hook 'org-shiftright-final-hook 'windmove-right)
 | 
						||
 | 
						||
`viper.el' by Michael Kifer
 | 
						||
     Viper uses `C-c /' and therefore makes this key not access the
 | 
						||
     corresponding Org mode command `org-sparse-tree'.  You need to find
 | 
						||
     another key for this command, or override the key in
 | 
						||
     `viper-vi-global-user-map' with
 | 
						||
 | 
						||
          (define-key viper-vi-global-user-map "C-c /" 'org-sparse-tree)
 | 
						||
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: org-crypt,  Prev: Interaction,  Up: Miscellaneous
 | 
						||
 | 
						||
15.11 org-crypt.el
 | 
						||
==================
 | 
						||
 | 
						||
Org-crypt will encrypt the text of an entry, but not the headline, or
 | 
						||
properties.  Org-crypt uses the Emacs EasyPG library to encrypt and
 | 
						||
decrypt files.
 | 
						||
 | 
						||
   Any text below a headline that has a `:crypt:' tag will be
 | 
						||
automatically be encrypted when the file is saved.  If you want to use
 | 
						||
a different tag just customize the `org-crypt-tag-matcher' setting.
 | 
						||
 | 
						||
   To use org-crypt it is suggested that you have the following in your
 | 
						||
`.emacs':
 | 
						||
 | 
						||
     (require 'org-crypt)
 | 
						||
     (org-crypt-use-before-save-magic)
 | 
						||
     (setq org-tags-exclude-from-inheritance (quote ("crypt")))
 | 
						||
 | 
						||
     (setq org-crypt-key nil)
 | 
						||
       ;; GPG key to use for encryption
 | 
						||
       ;; Either the Key ID or set to nil to use symmetric encryption.
 | 
						||
 | 
						||
     (setq auto-save-default nil)
 | 
						||
       ;; Auto-saving does not cooperate with org-crypt.el: so you need
 | 
						||
       ;; to turn it off if you plan to use org-crypt.el quite often.
 | 
						||
       ;; Otherwise, you'll get an (annoying) message each time you
 | 
						||
       ;; start Org.
 | 
						||
 | 
						||
       ;; To turn it off only locally, you can insert this:
 | 
						||
       ;;
 | 
						||
       ;; # -*- buffer-auto-save-file-name: nil; -*-
 | 
						||
 | 
						||
   Excluding the crypt tag from inheritance prevents already encrypted
 | 
						||
text being encrypted again.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Hacking,  Next: MobileOrg,  Prev: Miscellaneous,  Up: Top
 | 
						||
 | 
						||
Appendix A Hacking
 | 
						||
******************
 | 
						||
 | 
						||
This appendix covers some areas where users can extend the
 | 
						||
functionality of Org.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Hooks::                       How to reach into Org's internals
 | 
						||
* Add-on packages::             Available extensions
 | 
						||
* Adding hyperlink types::      New custom link types
 | 
						||
* Adding export back-ends::     How to write new export back-ends
 | 
						||
* Context-sensitive commands::  How to add functionality to such commands
 | 
						||
* Tables in arbitrary syntax::  Orgtbl for LaTeX and other programs
 | 
						||
* Dynamic blocks::              Automatically filled blocks
 | 
						||
* Special agenda views::        Customized views
 | 
						||
* Speeding up your agendas::    Tips on how to speed up your agendas
 | 
						||
* Extracting agenda information::  Post-processing of agenda information
 | 
						||
* Using the property API::      Writing programs that use entry properties
 | 
						||
* Using the mapping API::       Mapping over all or selected entries
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Hooks,  Next: Add-on packages,  Up: Hacking
 | 
						||
 | 
						||
A.1 Hooks
 | 
						||
=========
 | 
						||
 | 
						||
Org has a large number of hook variables that can be used to add
 | 
						||
functionality.  This appendix about hacking is going to illustrate the
 | 
						||
use of some of them.  A complete list of all hooks with documentation is
 | 
						||
maintained by the Worg project and can be found at
 | 
						||
`http://orgmode.org/worg/org-configs/org-hooks.php'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Add-on packages,  Next: Adding hyperlink types,  Prev: Hooks,  Up: Hacking
 | 
						||
 | 
						||
A.2 Add-on packages
 | 
						||
===================
 | 
						||
 | 
						||
A large number of add-on packages have been written by various authors.
 | 
						||
 | 
						||
   These packages are not part of Emacs, but they are distributed as
 | 
						||
contributed packages with the separate release available at
 | 
						||
`http://orgmode.org'.  See the `contrib/README' file in the source code
 | 
						||
directory for a list of contributed files.  You may also find some more
 | 
						||
information on the Worg page: `http://orgmode.org/worg/org-contrib/'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Adding hyperlink types,  Next: Adding export back-ends,  Prev: Add-on packages,  Up: Hacking
 | 
						||
 | 
						||
A.3 Adding hyperlink types
 | 
						||
==========================
 | 
						||
 | 
						||
Org has a large number of hyperlink types built-in (*note
 | 
						||
Hyperlinks::).  If you would like to add new link types, Org provides
 | 
						||
an interface for doing so.  Let's look at an example file,
 | 
						||
`org-man.el', that will add support for creating links like
 | 
						||
`[[man:printf][The printf manpage]]' to show Unix manual pages inside
 | 
						||
Emacs:
 | 
						||
 | 
						||
     ;;; org-man.el - Support for links to manpages in Org
 | 
						||
 | 
						||
     (require 'org)
 | 
						||
 | 
						||
     (org-add-link-type "man" 'org-man-open)
 | 
						||
     (add-hook 'org-store-link-functions 'org-man-store-link)
 | 
						||
 | 
						||
     (defcustom org-man-command 'man
 | 
						||
       "The Emacs command to be used to display a man page."
 | 
						||
       :group 'org-link
 | 
						||
       :type '(choice (const man) (const woman)))
 | 
						||
 | 
						||
     (defun org-man-open (path)
 | 
						||
       "Visit the manpage on PATH.
 | 
						||
     PATH should be a topic that can be thrown at the man command."
 | 
						||
       (funcall org-man-command path))
 | 
						||
 | 
						||
     (defun org-man-store-link ()
 | 
						||
       "Store a link to a manpage."
 | 
						||
       (when (memq major-mode '(Man-mode woman-mode))
 | 
						||
         ;; This is a man page, we do make this link
 | 
						||
         (let* ((page (org-man-get-page-name))
 | 
						||
                (link (concat "man:" page))
 | 
						||
                (description (format "Manpage for %s" page)))
 | 
						||
           (org-store-link-props
 | 
						||
            :type "man"
 | 
						||
            :link link
 | 
						||
            :description description))))
 | 
						||
 | 
						||
     (defun org-man-get-page-name ()
 | 
						||
       "Extract the page name from the buffer name."
 | 
						||
       ;; This works for both `Man-mode' and `woman-mode'.
 | 
						||
       (if (string-match " \\(\\S-+\\)\\*" (buffer-name))
 | 
						||
           (match-string 1 (buffer-name))
 | 
						||
         (error "Cannot create link to this man page")))
 | 
						||
 | 
						||
     (provide 'org-man)
 | 
						||
 | 
						||
     ;;; org-man.el ends here
 | 
						||
 | 
						||
You would activate this new link type in `.emacs' with
 | 
						||
 | 
						||
     (require 'org-man)
 | 
						||
 | 
						||
Let's go through the file and see what it does.
 | 
						||
  1. It does `(require 'org)' to make sure that `org.el' has been
 | 
						||
     loaded.
 | 
						||
 | 
						||
  2. The next line calls `org-add-link-type' to define a new link type
 | 
						||
     with prefix `man'.  The call also contains the name of a function
 | 
						||
     that will be called to follow such a link.
 | 
						||
 | 
						||
  3. The next line adds a function to `org-store-link-functions', in
 | 
						||
     order to allow the command `C-c l' to record a useful link in a
 | 
						||
     buffer displaying a man page.
 | 
						||
 | 
						||
   The rest of the file defines the necessary variables and functions.
 | 
						||
First there is a customization variable that determines which Emacs
 | 
						||
command should be used to display man pages.  There are two options,
 | 
						||
`man' and `woman'.  Then the function to follow a link is defined.  It
 | 
						||
gets the link path as an argument--in this case the link path is just a
 | 
						||
topic for the manual command.  The function calls the value of
 | 
						||
`org-man-command' to display the man page.
 | 
						||
 | 
						||
   Finally the function `org-man-store-link' is defined.  When you try
 | 
						||
to store a link with `C-c l', this function will be called to try to
 | 
						||
make a link.  The function must first decide if it is supposed to
 | 
						||
create the link for this buffer type; we do this by checking the value
 | 
						||
of the variable `major-mode'.  If not, the function must exit and
 | 
						||
return the value `nil'.  If yes, the link is created by getting the
 | 
						||
manual topic from the buffer name and prefixing it with the string
 | 
						||
`man:'.  Then it must call the command `org-store-link-props' and set
 | 
						||
the `:type' and `:link' properties.  Optionally you can also set the
 | 
						||
`:description' property to provide a default for the link description
 | 
						||
when the link is later inserted into an Org buffer with `C-c C-l'.
 | 
						||
 | 
						||
   When it makes sense for your new link type, you may also define a
 | 
						||
function `org-PREFIX-complete-link' that implements special (e.g.,
 | 
						||
completion) support for inserting such a link with `C-c C-l'.  Such a
 | 
						||
function should not accept any arguments, and return the full link with
 | 
						||
prefix.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Adding export back-ends,  Next: Context-sensitive commands,  Prev: Adding hyperlink types,  Up: Hacking
 | 
						||
 | 
						||
A.4 Adding export back-ends
 | 
						||
===========================
 | 
						||
 | 
						||
Org 8.0 comes with a completely rewritten export engine which makes it
 | 
						||
easy to write new export back-ends, either from scratch, or by deriving
 | 
						||
them from existing ones.
 | 
						||
 | 
						||
   Your two entry points are respectively `org-export-define-backend'
 | 
						||
and `org-export-define-derived-backend'.  To grok these functions, you
 | 
						||
should first have a look at `ox-latex.el' (for how to define a new
 | 
						||
back-end from scratch) and `ox-beamer.el' (for how to derive a new
 | 
						||
back-end from an existing one.
 | 
						||
 | 
						||
   When creating a new back-end from scratch, the basic idea is to set
 | 
						||
the name of the back-end (as a symbol) and an alist of elements and
 | 
						||
export functions.  On top of this, you will need to set additional
 | 
						||
keywords like `:menu-entry' (to display the back-end in the export
 | 
						||
dispatcher), `:export-block' (to specify what blocks should not be
 | 
						||
exported by this back-end), and `:options-alist' (to let the user set
 | 
						||
export options that are specific to this back-end.)
 | 
						||
 | 
						||
   Deriving a new back-end is similar, except that you need to set
 | 
						||
`:translate-alist' to an alist of export functions that should be used
 | 
						||
instead of the parent back-end functions.
 | 
						||
 | 
						||
   For a complete reference documentation, see the Org Export Reference
 | 
						||
on Worg (http://orgmode.org/worg/dev/org-export-reference.html).
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Context-sensitive commands,  Next: Tables in arbitrary syntax,  Prev: Adding export back-ends,  Up: Hacking
 | 
						||
 | 
						||
A.5 Context-sensitive commands
 | 
						||
==============================
 | 
						||
 | 
						||
Org has several commands that act differently depending on context.
 | 
						||
The most important example is the `C-c C-c' (*note The very busy C-c
 | 
						||
C-c key::).  Also the `M-cursor' and `M-S-cursor' keys have this
 | 
						||
property.
 | 
						||
 | 
						||
   Add-ons can tap into this functionality by providing a function that
 | 
						||
detects special context for that add-on and executes functionality
 | 
						||
appropriate for the context.  Here is an example from Dan Davison's
 | 
						||
`org-R.el' which allows you to evaluate commands based on the `R'
 | 
						||
programming language (1).  For this package, special contexts are lines
 | 
						||
that start with `#+R:' or `#+RR:'.
 | 
						||
 | 
						||
     (defun org-R-apply-maybe ()
 | 
						||
       "Detect if this is context for org-R and execute R commands."
 | 
						||
       (if (save-excursion
 | 
						||
             (beginning-of-line 1)
 | 
						||
             (looking-at "#\\+RR?:"))
 | 
						||
           (progn (call-interactively 'org-R-apply)
 | 
						||
                  t) ;; to signal that we took action
 | 
						||
         nil)) ;; to signal that we did not
 | 
						||
 | 
						||
     (add-hook 'org-ctrl-c-ctrl-c-hook 'org-R-apply-maybe)
 | 
						||
 | 
						||
   The function first checks if the cursor is in such a line.  If that
 | 
						||
is the case, `org-R-apply' is called and the function returns `t' to
 | 
						||
signal that action was taken, and `C-c C-c' will stop looking for other
 | 
						||
contexts.  If the function finds it should do nothing locally, it
 | 
						||
returns `nil' so that other, similar functions can have a try.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) `org-R.el' has been replaced by the Org mode functionality
 | 
						||
described in *note Working with source code:: and is now obsolete.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Tables in arbitrary syntax,  Next: Dynamic blocks,  Prev: Context-sensitive commands,  Up: Hacking
 | 
						||
 | 
						||
A.6 Tables and lists in arbitrary syntax
 | 
						||
========================================
 | 
						||
 | 
						||
Since Orgtbl mode can be used as a minor mode in arbitrary buffers, a
 | 
						||
frequent feature request has been to make it work with native tables in
 | 
						||
specific languages, for example LaTeX.  However, this is extremely hard
 | 
						||
to do in a general way, would lead to a customization nightmare, and
 | 
						||
would take away much of the simplicity of the Orgtbl mode table editor.
 | 
						||
 | 
						||
   This appendix describes a different approach.  We keep the Orgtbl
 | 
						||
mode table in its native format (the source table), and use a custom
 | 
						||
function to translate the table to the correct syntax, and to install
 | 
						||
it in the right location (the target table).  This puts the burden of
 | 
						||
writing conversion functions on the user, but it allows for a very
 | 
						||
flexible system.
 | 
						||
 | 
						||
   Bastien added the ability to do the same with lists, in Orgstruct
 | 
						||
mode.  You can use Org's facilities to edit and structure lists by
 | 
						||
turning `orgstruct-mode' on, then locally exporting such lists in
 | 
						||
another format (HTML, LaTeX or Texinfo.)
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Radio tables::                Sending and receiving radio tables
 | 
						||
* A LaTeX example::          Step by step, almost a tutorial
 | 
						||
* Translator functions::        Copy and modify
 | 
						||
* Radio lists::                 Sending and receiving lists
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Radio tables,  Next: A LaTeX example,  Up: Tables in arbitrary syntax
 | 
						||
 | 
						||
A.6.1 Radio tables
 | 
						||
------------------
 | 
						||
 | 
						||
To define the location of the target table, you first need to create two
 | 
						||
lines that are comments in the current mode, but contain magic words
 | 
						||
`BEGIN/END RECEIVE ORGTBL' for Orgtbl mode to find.  Orgtbl mode will
 | 
						||
insert the translated table between these lines, replacing whatever was
 | 
						||
there before.  For example in C mode where comments are between `/* ...
 | 
						||
*/':
 | 
						||
 | 
						||
     /* BEGIN RECEIVE ORGTBL table_name */
 | 
						||
     /* END RECEIVE ORGTBL table_name */
 | 
						||
 | 
						||
Just above the source table, we put a special line that tells Orgtbl
 | 
						||
mode how to translate this table and where to install it.  For example: 
 | 
						||
     #+ORGTBL: SEND table_name translation_function arguments...
 | 
						||
 | 
						||
`table_name' is the reference name for the table that is also used in
 | 
						||
the receiver lines.  `translation_function' is the Lisp function that
 | 
						||
does the translation.  Furthermore, the line can contain a list of
 | 
						||
arguments (alternating key and value) at the end.  The arguments will be
 | 
						||
passed as a property list to the translation function for
 | 
						||
interpretation.  A few standard parameters are already recognized and
 | 
						||
acted upon before the translation function is called:
 | 
						||
 | 
						||
`:skip N'
 | 
						||
     Skip the first N lines of the table.  Hlines do count as separate
 | 
						||
     lines for this parameter!
 | 
						||
 | 
						||
`:skipcols (n1 n2 ...)'
 | 
						||
     List of columns that should be skipped.  If the table has a column
 | 
						||
     with calculation marks, that column is automatically discarded as
 | 
						||
     well.  Please note that the translator function sees the table
 | 
						||
     _after_ the removal of these columns, the function never knows
 | 
						||
     that there have been additional columns.
 | 
						||
 | 
						||
The one problem remaining is how to keep the source table in the buffer
 | 
						||
without disturbing the normal workings of the file, for example during
 | 
						||
compilation of a C file or processing of a LaTeX file.  There are a
 | 
						||
number of different solutions:
 | 
						||
 | 
						||
   * The table could be placed in a block comment if that is supported
 | 
						||
     by the language.  For example, in C mode you could wrap the table
 | 
						||
     between `/*' and `*/' lines.
 | 
						||
 | 
						||
   * Sometimes it is possible to put the table after some kind of END
 | 
						||
     statement, for example `\bye' in TeX and `\end{document}' in LaTeX.
 | 
						||
 | 
						||
   * You can just comment the table line-by-line whenever you want to
 | 
						||
     process the file, and uncomment it whenever you need to edit the
 | 
						||
     table.  This only sounds tedious--the command `M-x
 | 
						||
     orgtbl-toggle-comment RET' makes this comment-toggling very easy,
 | 
						||
     in particular if you bind it to a key.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: A LaTeX example,  Next: Translator functions,  Prev: Radio tables,  Up: Tables in arbitrary syntax
 | 
						||
 | 
						||
A.6.2 A LaTeX example of radio tables
 | 
						||
-------------------------------------
 | 
						||
 | 
						||
The best way to wrap the source table in LaTeX is to use the `comment'
 | 
						||
environment provided by `comment.sty'.  It has to be activated by
 | 
						||
placing `\usepackage{comment}' into the document header.  Orgtbl mode
 | 
						||
can insert a radio table skeleton(1)  with the command `M-x
 | 
						||
orgtbl-insert-radio-table RET'.  You will be prompted for a table name,
 | 
						||
let's say we use `salesfigures'.  You will then get the following
 | 
						||
template:
 | 
						||
 | 
						||
     % BEGIN RECEIVE ORGTBL salesfigures
 | 
						||
     % END RECEIVE ORGTBL salesfigures
 | 
						||
     \begin{comment}
 | 
						||
     #+ORGTBL: SEND salesfigures orgtbl-to-latex
 | 
						||
     | | |
 | 
						||
     \end{comment}
 | 
						||
 | 
						||
The `#+ORGTBL: SEND' line tells Orgtbl mode to use the function
 | 
						||
`orgtbl-to-latex' to convert the table into LaTeX and to put it into
 | 
						||
the receiver location with name `salesfigures'.  You may now fill in
 | 
						||
the table--feel free to use the spreadsheet features(2):
 | 
						||
 | 
						||
     % BEGIN RECEIVE ORGTBL salesfigures
 | 
						||
     % END RECEIVE ORGTBL salesfigures
 | 
						||
     \begin{comment}
 | 
						||
     #+ORGTBL: SEND salesfigures orgtbl-to-latex
 | 
						||
     | Month | Days | Nr sold | per day |
 | 
						||
     |-------+------+---------+---------|
 | 
						||
     | Jan   |   23 |      55 |     2.4 |
 | 
						||
     | Feb   |   21 |      16 |     0.8 |
 | 
						||
     | March |   22 |     278 |    12.6 |
 | 
						||
     #+TBLFM: $4=$3/$2;%.1f
 | 
						||
     % $ (optional extra dollar to keep font-lock happy, see footnote)
 | 
						||
     \end{comment}
 | 
						||
 | 
						||
When you are done, press `C-c C-c' in the table to get the converted
 | 
						||
table inserted between the two marker lines.
 | 
						||
 | 
						||
   Now let's assume you want to make the table header by hand, because
 | 
						||
you want to control how columns are aligned, etc.  In this case we make
 | 
						||
sure that the table translator skips the first 2 lines of the source
 | 
						||
table, and tell the command to work as a splice, i.e., to not produce
 | 
						||
header and footer commands of the target table:
 | 
						||
 | 
						||
     \begin{tabular}{lrrr}
 | 
						||
     Month & \multicolumn{1}{c}{Days} & Nr.\ sold & per day\\
 | 
						||
     % BEGIN RECEIVE ORGTBL salesfigures
 | 
						||
     % END RECEIVE ORGTBL salesfigures
 | 
						||
     \end{tabular}
 | 
						||
     %
 | 
						||
     \begin{comment}
 | 
						||
     #+ORGTBL: SEND salesfigures orgtbl-to-latex :splice t :skip 2
 | 
						||
     | Month | Days | Nr sold | per day |
 | 
						||
     |-------+------+---------+---------|
 | 
						||
     | Jan   |   23 |      55 |     2.4 |
 | 
						||
     | Feb   |   21 |      16 |     0.8 |
 | 
						||
     | March |   22 |     278 |    12.6 |
 | 
						||
     #+TBLFM: $4=$3/$2;%.1f
 | 
						||
     \end{comment}
 | 
						||
 | 
						||
   The LaTeX translator function `orgtbl-to-latex' is already part of
 | 
						||
Orgtbl mode.  By default, it uses a `tabular' environment to typeset the
 | 
						||
table and marks horizontal lines with `\hline'.  You can control the
 | 
						||
output through several parameters (see also *note Translator
 | 
						||
functions::), including the following ones :
 | 
						||
 | 
						||
`:splice nil/t'
 | 
						||
     When non-`nil', return only table body lines, don't wrap them into
 | 
						||
     a tabular environment.  Default is `nil'.
 | 
						||
 | 
						||
`:fmt fmt'
 | 
						||
     A format to be used to wrap each field, it should contain `%s' for
 | 
						||
     the original field value.  For example, to wrap each field value
 | 
						||
     in dollars, you could use `:fmt "$%s$"'.  This may also be a
 | 
						||
     property list with column numbers and formats, for example `:fmt
 | 
						||
     (2 "$%s$" 4 "%s\\%%")'.  A function of one argument can be used in
 | 
						||
     place of the strings; the function must return a formatted string.
 | 
						||
 | 
						||
`:efmt efmt'
 | 
						||
     Use this format to print numbers with exponentials.  The format
 | 
						||
     should have `%s' twice for inserting mantissa and exponent, for
 | 
						||
     example `"%s\\times10^{%s}"'.  This may also be a property list
 | 
						||
     with column numbers and formats, for example `:efmt (2
 | 
						||
     "$%s\\times10^{%s}$" 4 "$%s\\cdot10^{%s}$")'.  After `efmt' has
 | 
						||
     been applied to a value, `fmt' will also be applied.  Similar to
 | 
						||
     `fmt', functions of two arguments can be supplied instead of
 | 
						||
     strings.  By default, no special formatting is applied.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) By default this works only for LaTeX, HTML, and Texinfo.
 | 
						||
Configure the variable `orgtbl-radio-table-templates' to install
 | 
						||
templates for other modes.
 | 
						||
 | 
						||
   (2) If the `#+TBLFM' line contains an odd number of dollar
 | 
						||
characters, this may cause problems with font-lock in LaTeX mode.  As
 | 
						||
shown in the example you can fix this by adding an extra line inside the
 | 
						||
`comment' environment that is used to balance the dollar expressions.
 | 
						||
If you are using AUCTeX with the font-latex library, a much better
 | 
						||
solution is to add the `comment' environment to the variable
 | 
						||
`LaTeX-verbatim-environments'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Translator functions,  Next: Radio lists,  Prev: A LaTeX example,  Up: Tables in arbitrary syntax
 | 
						||
 | 
						||
A.6.3 Translator functions
 | 
						||
--------------------------
 | 
						||
 | 
						||
Orgtbl mode has several translator functions built-in: `orgtbl-to-csv'
 | 
						||
(comma-separated values), `orgtbl-to-tsv' (TAB-separated values)
 | 
						||
`orgtbl-to-latex', `orgtbl-to-html', `orgtbl-to-texinfo',
 | 
						||
`orgtbl-to-unicode' and `orgtbl-to-orgtbl'.  These all use a generic
 | 
						||
translator, `orgtbl-to-generic', which, in turn, can delegate
 | 
						||
translations to various export back-ends (*note Export back-ends::).
 | 
						||
 | 
						||
   In particular, properties passed into the function (i.e., the ones
 | 
						||
set by the `ORGTBL SEND' line) take precedence over translations
 | 
						||
defined in the function.  So if you would like to use the LaTeX
 | 
						||
translator, but wanted the line endings to be `\\[2mm]' instead of the
 | 
						||
default `\\', you could just overrule the default with
 | 
						||
 | 
						||
     #+ORGTBL: SEND test orgtbl-to-latex :lend " \\\\[2mm]"
 | 
						||
 | 
						||
   For a new language, you can use the generic function to write your
 | 
						||
own converter function.  For example, if you have a language where a
 | 
						||
table is started with `!BTBL!', ended with `!ETBL!', and where table
 | 
						||
lines are started with `!BL!', ended with `!EL!', and where the field
 | 
						||
separator is a TAB, you could define your generic translator like this:
 | 
						||
 | 
						||
     (defun orgtbl-to-language (table params)
 | 
						||
       "Convert the orgtbl-mode TABLE to language."
 | 
						||
       (orgtbl-to-generic
 | 
						||
        table
 | 
						||
        (org-combine-plists
 | 
						||
         '(:tstart "!BTBL!" :tend "!ETBL!" :lstart "!BL!" :lend "!EL!" :sep "\t")
 | 
						||
         params)))
 | 
						||
 | 
						||
Please check the documentation string of the function
 | 
						||
`orgtbl-to-generic' for a full list of parameters understood by that
 | 
						||
function, and remember that you can pass each of them into
 | 
						||
`orgtbl-to-latex', `orgtbl-to-texinfo', and any other function using
 | 
						||
the generic function.
 | 
						||
 | 
						||
   Of course you can also write a completely new function doing
 | 
						||
complicated things the generic translator cannot do.  A translator
 | 
						||
function takes two arguments.  The first argument is the table, a list
 | 
						||
of lines, each line either the symbol `hline' or a list of fields.  The
 | 
						||
second argument is the property list containing all parameters
 | 
						||
specified in the `#+ORGTBL: SEND' line.  The function must return a
 | 
						||
single string containing the formatted table.  If you write a generally
 | 
						||
useful translator, please post it on <emacs-orgmode@gnu.org> so that
 | 
						||
others can benefit from your work.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Radio lists,  Prev: Translator functions,  Up: Tables in arbitrary syntax
 | 
						||
 | 
						||
A.6.4 Radio lists
 | 
						||
-----------------
 | 
						||
 | 
						||
Sending and receiving radio lists works exactly the same way as sending
 | 
						||
and receiving radio tables (*note Radio tables::).  As for radio
 | 
						||
tables, you can insert radio list templates in HTML, LaTeX and Texinfo
 | 
						||
modes by calling `org-list-insert-radio-list'.
 | 
						||
 | 
						||
   Here are the differences with radio tables:
 | 
						||
 | 
						||
   - Orgstruct mode must be active.
 | 
						||
 | 
						||
   - Use the `ORGLST' keyword instead of `ORGTBL'.
 | 
						||
 | 
						||
   - The available translation functions for radio lists don't take
 | 
						||
     parameters.
 | 
						||
 | 
						||
   - `C-c C-c' will work when pressed on the first item of the list.
 | 
						||
 | 
						||
   Here is a LaTeX example.  Let's say that you have this in your LaTeX
 | 
						||
file:
 | 
						||
 | 
						||
     % BEGIN RECEIVE ORGLST to-buy
 | 
						||
     % END RECEIVE ORGLST to-buy
 | 
						||
     \begin{comment}
 | 
						||
     #+ORGLST: SEND to-buy org-list-to-latex
 | 
						||
     - a new house
 | 
						||
     - a new computer
 | 
						||
       + a new keyboard
 | 
						||
       + a new mouse
 | 
						||
     - a new life
 | 
						||
     \end{comment}
 | 
						||
 | 
						||
   Pressing `C-c C-c' on `a new house' and will insert the converted
 | 
						||
LaTeX list between the two marker lines.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Dynamic blocks,  Next: Special agenda views,  Prev: Tables in arbitrary syntax,  Up: Hacking
 | 
						||
 | 
						||
A.7 Dynamic blocks
 | 
						||
==================
 | 
						||
 | 
						||
Org documents can contain _dynamic blocks_.  These are specially marked
 | 
						||
regions that are updated by some user-written function.  A good example
 | 
						||
for such a block is the clock table inserted by the command `C-c C-x
 | 
						||
C-r' (*note Clocking work time::).
 | 
						||
 | 
						||
   Dynamic blocks are enclosed by a BEGIN-END structure that assigns a
 | 
						||
name to the block and can also specify parameters for the function
 | 
						||
producing the content of the block.
 | 
						||
 | 
						||
     #+BEGIN: myblock :parameter1 value1 :parameter2 value2 ...
 | 
						||
 | 
						||
     #+END:
 | 
						||
 | 
						||
   Dynamic blocks are updated with the following commands
 | 
						||
 | 
						||
`C-c C-x C-u     (`org-dblock-update')'
 | 
						||
     Update dynamic block at point.  
 | 
						||
 | 
						||
`C-u C-c C-x C-u'
 | 
						||
     Update all dynamic blocks in the current file.
 | 
						||
 | 
						||
   Updating a dynamic block means to remove all the text between BEGIN
 | 
						||
and END, parse the BEGIN line for parameters and then call the specific
 | 
						||
writer function for this block to insert the new content.  If you want
 | 
						||
to use the original content in the writer function, you can use the
 | 
						||
extra parameter `:content'.
 | 
						||
 | 
						||
   For a block with name `myblock', the writer function is
 | 
						||
`org-dblock-write:myblock' with as only parameter a property list with
 | 
						||
the parameters given in the begin line.  Here is a trivial example of a
 | 
						||
block that keeps track of when the block update function was last run:
 | 
						||
 | 
						||
     #+BEGIN: block-update-time :format "on %m/%d/%Y at %H:%M"
 | 
						||
 | 
						||
     #+END:
 | 
						||
 | 
						||
The corresponding block writer function could look like this:
 | 
						||
 | 
						||
     (defun org-dblock-write:block-update-time (params)
 | 
						||
       (let ((fmt (or (plist-get params :format) "%d. %m. %Y")))
 | 
						||
         (insert "Last block update at: "
 | 
						||
                 (format-time-string fmt))))
 | 
						||
 | 
						||
   If you want to make sure that all dynamic blocks are always
 | 
						||
up-to-date, you could add the function `org-update-all-dblocks' to a
 | 
						||
hook, for example `before-save-hook'.  `org-update-all-dblocks' is
 | 
						||
written in a way such that it does nothing in buffers that are not in
 | 
						||
`org-mode'.
 | 
						||
 | 
						||
   You can narrow the current buffer to the current dynamic block (like
 | 
						||
any other block) with `org-narrow-to-block'.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Special agenda views,  Next: Speeding up your agendas,  Prev: Dynamic blocks,  Up: Hacking
 | 
						||
 | 
						||
A.8 Special agenda views
 | 
						||
========================
 | 
						||
 | 
						||
Org provides a special hook that can be used to narrow down the
 | 
						||
selection made by these agenda views: `agenda', `agenda*'(1), `todo',
 | 
						||
`alltodo', `tags', `tags-todo', `tags-tree'.  You may specify a
 | 
						||
function that is used at each match to verify if the match should
 | 
						||
indeed be part of the agenda view, and if not, how much should be
 | 
						||
skipped.  You can specify a global condition that will be applied to
 | 
						||
all agenda views, this condition would be stored in the variable
 | 
						||
`org-agenda-skip-function-global'.  More commonly, such a definition is
 | 
						||
applied only to specific custom searches, using
 | 
						||
`org-agenda-skip-function'.
 | 
						||
 | 
						||
   Let's say you want to produce a list of projects that contain a
 | 
						||
WAITING tag anywhere in the project tree.  Let's further assume that
 | 
						||
you have marked all tree headings that define a project with the TODO
 | 
						||
keyword PROJECT.  In this case you would run a TODO search for the
 | 
						||
keyword PROJECT, but skip the match unless there is a WAITING tag
 | 
						||
anywhere in the subtree belonging to the project line.
 | 
						||
 | 
						||
   To achieve this, you must write a function that searches the subtree
 | 
						||
for the tag.  If the tag is found, the function must return `nil' to
 | 
						||
indicate that this match should not be skipped.  If there is no such
 | 
						||
tag, return the location of the end of the subtree, to indicate that
 | 
						||
search should continue from there.
 | 
						||
 | 
						||
     (defun my-skip-unless-waiting ()
 | 
						||
       "Skip trees that are not waiting"
 | 
						||
       (let ((subtree-end (save-excursion (org-end-of-subtree t))))
 | 
						||
         (if (re-search-forward ":waiting:" subtree-end t)
 | 
						||
             nil          ; tag found, do not skip
 | 
						||
           subtree-end))) ; tag not found, continue after end of subtree
 | 
						||
 | 
						||
   Now you may use this function in an agenda custom command, for
 | 
						||
example like this:
 | 
						||
 | 
						||
     (org-add-agenda-custom-command
 | 
						||
      '("b" todo "PROJECT"
 | 
						||
        ((org-agenda-skip-function 'my-skip-unless-waiting)
 | 
						||
         (org-agenda-overriding-header "Projects waiting for something: "))))
 | 
						||
 | 
						||
   Note that this also binds `org-agenda-overriding-header' to get a
 | 
						||
meaningful header in the agenda view.
 | 
						||
 | 
						||
   A general way to create custom searches is to base them on a search
 | 
						||
for entries with a certain level limit.  If you want to study all
 | 
						||
entries with your custom search function, simply do a search for
 | 
						||
`LEVEL>0'(2), and then use `org-agenda-skip-function' to select the
 | 
						||
entries you really want to have.
 | 
						||
 | 
						||
   You may also put a Lisp form into `org-agenda-skip-function'.  In
 | 
						||
particular, you may use the functions `org-agenda-skip-entry-if' and
 | 
						||
`org-agenda-skip-subtree-if' in this form, for example:
 | 
						||
 | 
						||
`(org-agenda-skip-entry-if 'scheduled)'
 | 
						||
     Skip current entry if it has been scheduled.
 | 
						||
 | 
						||
`(org-agenda-skip-entry-if 'notscheduled)'
 | 
						||
     Skip current entry if it has not been scheduled.
 | 
						||
 | 
						||
`(org-agenda-skip-entry-if 'deadline)'
 | 
						||
     Skip current entry if it has a deadline.
 | 
						||
 | 
						||
`(org-agenda-skip-entry-if 'scheduled 'deadline)'
 | 
						||
     Skip current entry if it has a deadline, or if it is scheduled.
 | 
						||
 | 
						||
`(org-agenda-skip-entry-if 'todo '("TODO" "WAITING"))'
 | 
						||
     Skip current entry if the TODO keyword is TODO or WAITING.
 | 
						||
 | 
						||
`(org-agenda-skip-entry-if 'todo 'done)'
 | 
						||
     Skip current entry if the TODO keyword marks a DONE state.
 | 
						||
 | 
						||
`(org-agenda-skip-entry-if 'timestamp)'
 | 
						||
     Skip current entry if it has any timestamp, may also be deadline
 | 
						||
     or scheduled.
 | 
						||
 | 
						||
`(org-agenda-skip-entry-if 'regexp "regular expression")'
 | 
						||
     Skip current entry if the regular expression matches in the entry.
 | 
						||
 | 
						||
`(org-agenda-skip-entry-if 'notregexp "regular expression")'
 | 
						||
     Skip current entry unless the regular expression matches.
 | 
						||
 | 
						||
`(org-agenda-skip-subtree-if 'regexp "regular expression")'
 | 
						||
     Same as above, but check and skip the entire subtree.
 | 
						||
 | 
						||
   Therefore we could also have written the search for WAITING projects
 | 
						||
like this, even without defining a special function:
 | 
						||
 | 
						||
     (org-add-agenda-custom-command
 | 
						||
      '("b" todo "PROJECT"
 | 
						||
        ((org-agenda-skip-function '(org-agenda-skip-subtree-if
 | 
						||
                                     'regexp ":waiting:"))
 | 
						||
         (org-agenda-overriding-header "Projects waiting for something: "))))
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) The `agenda*' view is the same as `agenda' except that it only
 | 
						||
considers _appointments_, i.e., scheduled and deadline items that have a
 | 
						||
time specification `[h]h:mm' in their time-stamps.
 | 
						||
 | 
						||
   (2) Note that, when using `org-odd-levels-only', a level number
 | 
						||
corresponds to order in the hierarchy, not to the number of stars.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Speeding up your agendas,  Next: Extracting agenda information,  Prev: Special agenda views,  Up: Hacking
 | 
						||
 | 
						||
A.9 Speeding up your agendas
 | 
						||
============================
 | 
						||
 | 
						||
When your Org files grow in both number and size, agenda commands may
 | 
						||
start to become slow.  Below are some tips on how to speed up the
 | 
						||
agenda commands.
 | 
						||
 | 
						||
  1. Reduce the number of Org agenda files: this will reduce the
 | 
						||
     slowdown caused by accessing a hard drive.
 | 
						||
 | 
						||
  2. Reduce the number of DONE and archived headlines: this way the
 | 
						||
     agenda does not need to skip them.
 | 
						||
 | 
						||
  3. Inhibit the dimming of blocked tasks:
 | 
						||
          (setq org-agenda-dim-blocked-tasks nil)
 | 
						||
 | 
						||
  4. Inhibit agenda files startup options:
 | 
						||
          (setq org-agenda-inhibit-startup nil)
 | 
						||
 | 
						||
  5. Disable tag inheritance in agenda:
 | 
						||
          (setq org-agenda-use-tag-inheritance nil)
 | 
						||
 | 
						||
   You can set these options for specific agenda views only.  See the
 | 
						||
docstrings of these variables for details on why they affect the agenda
 | 
						||
generation, and this dedicated Worg page
 | 
						||
(http://orgmode.org/worg/agenda-optimization.html) for further
 | 
						||
explanations.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Extracting agenda information,  Next: Using the property API,  Prev: Speeding up your agendas,  Up: Hacking
 | 
						||
 | 
						||
A.10 Extracting agenda information
 | 
						||
==================================
 | 
						||
 | 
						||
Org provides commands to access agenda information for the command line
 | 
						||
in Emacs batch mode.  This extracted information can be sent directly
 | 
						||
to a printer, or it can be read by a program that does further
 | 
						||
processing of the data.  The first of these commands is the function
 | 
						||
`org-batch-agenda', that produces an agenda view and sends it as ASCII
 | 
						||
text to STDOUT.  The command takes a single string as parameter.  If
 | 
						||
the string has length 1, it is used as a key to one of the commands you
 | 
						||
have configured in `org-agenda-custom-commands', basically any key you
 | 
						||
can use after `C-c a'.  For example, to directly print the current TODO
 | 
						||
list, you could use
 | 
						||
 | 
						||
     emacs -batch -l ~/.emacs -eval '(org-batch-agenda "t")' | lpr
 | 
						||
 | 
						||
   If the parameter is a string with 2 or more characters, it is used
 | 
						||
as a tags/TODO match string.  For example, to print your local shopping
 | 
						||
list (all items with the tag `shop', but excluding the tag `NewYork'),
 | 
						||
you could use
 | 
						||
 | 
						||
     emacs -batch -l ~/.emacs                                      \
 | 
						||
           -eval '(org-batch-agenda "+shop-NewYork")' | lpr
 | 
						||
 | 
						||
You may also modify parameters on the fly like this:
 | 
						||
 | 
						||
     emacs -batch -l ~/.emacs                                      \
 | 
						||
        -eval '(org-batch-agenda "a"                               \
 | 
						||
                 org-agenda-span (quote month)                     \
 | 
						||
                 org-agenda-include-diary nil                      \
 | 
						||
                 org-agenda-files (quote ("~/org/project.org")))'  \
 | 
						||
        | lpr
 | 
						||
 | 
						||
which will produce a 30-day agenda, fully restricted to the Org file
 | 
						||
`~/org/projects.org', not even including the diary.
 | 
						||
 | 
						||
   If you want to process the agenda data in more sophisticated ways,
 | 
						||
you can use the command `org-batch-agenda-csv' to get a comma-separated
 | 
						||
list of values for each agenda item.  Each line in the output will
 | 
						||
contain a number of fields separated by commas.  The fields in a line
 | 
						||
are:
 | 
						||
 | 
						||
     category     The category of the item
 | 
						||
     head         The headline, without TODO keyword, TAGS and PRIORITY
 | 
						||
     type         The type of the agenda entry, can be
 | 
						||
                     todo               selected in TODO match
 | 
						||
                     tagsmatch          selected in tags match
 | 
						||
                     diary              imported from diary
 | 
						||
                     deadline           a deadline
 | 
						||
                     scheduled          scheduled
 | 
						||
                     timestamp          appointment, selected by timestamp
 | 
						||
                     closed             entry was closed on date
 | 
						||
                     upcoming-deadline  warning about nearing deadline
 | 
						||
                     past-scheduled     forwarded scheduled item
 | 
						||
                     block              entry has date block including date
 | 
						||
     todo         The TODO keyword, if any
 | 
						||
     tags         All tags including inherited ones, separated by colons
 | 
						||
     date         The relevant date, like 2007-2-14
 | 
						||
     time         The time, like 15:00-16:50
 | 
						||
     extra        String with extra planning info
 | 
						||
     priority-l   The priority letter if any was given
 | 
						||
     priority-n   The computed numerical priority
 | 
						||
 | 
						||
Time and date will only be given if a timestamp (or deadline/scheduled)
 | 
						||
led to the selection of the item.
 | 
						||
 | 
						||
   A CSV list like this is very easy to use in a post-processing script.
 | 
						||
For example, here is a Perl program that gets the TODO list from
 | 
						||
Emacs/Org and prints all the items, preceded by a checkbox:
 | 
						||
 | 
						||
     #!/usr/bin/perl
 | 
						||
 | 
						||
     # define the Emacs command to run
 | 
						||
     $cmd = "emacs -batch -l ~/.emacs -eval '(org-batch-agenda-csv \"t\")'";
 | 
						||
 | 
						||
     # run it and capture the output
 | 
						||
     $agenda = qx{$cmd 2>/dev/null};
 | 
						||
 | 
						||
     # loop over all lines
 | 
						||
     foreach $line (split(/\n/,$agenda)) {
 | 
						||
       # get the individual values
 | 
						||
       ($category,$head,$type,$todo,$tags,$date,$time,$extra,
 | 
						||
        $priority_l,$priority_n) = split(/,/,$line);
 | 
						||
       # process and print
 | 
						||
       print "[ ] $head\n";
 | 
						||
     }
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Using the property API,  Next: Using the mapping API,  Prev: Extracting agenda information,  Up: Hacking
 | 
						||
 | 
						||
A.11 Using the property API
 | 
						||
===========================
 | 
						||
 | 
						||
Here is a description of the functions that can be used to work with
 | 
						||
properties.
 | 
						||
 | 
						||
 -- Function: org-entry-properties &optional pom which
 | 
						||
     Get all properties of the entry at point-or-marker POM.
 | 
						||
     This includes the TODO keyword, the tags, time strings for
 | 
						||
     deadline, scheduled, and clocking, and any additional properties
 | 
						||
     defined in the entry.  The return value is an alist.  Keys may
 | 
						||
     occur multiple times if the property key was used several times.
 | 
						||
     POM may also be `nil', in which case the current entry is used.
 | 
						||
     If WHICH is `nil' or `all', get all properties.  If WHICH is
 | 
						||
     `special' or `standard', only get that subclass.
 | 
						||
   
 | 
						||
 -- Function: org-entry-get pom property &optional inherit
 | 
						||
     Get value of `PROPERTY' for entry at point-or-marker `POM'.  By
 | 
						||
     default, this only looks at properties defined locally in the
 | 
						||
     entry.  If `INHERIT' is non-`nil' and the entry does not have the
 | 
						||
     property, then also check higher levels of the hierarchy.  If
 | 
						||
     `INHERIT' is the symbol `selective', use inheritance if and only
 | 
						||
     if the setting of `org-use-property-inheritance' selects
 | 
						||
     `PROPERTY' for inheritance.
 | 
						||
 | 
						||
 -- Function: org-entry-delete pom property
 | 
						||
     Delete the property `PROPERTY' from entry at point-or-marker POM.
 | 
						||
 | 
						||
 -- Function: org-entry-put pom property value
 | 
						||
     Set `PROPERTY' to `VALUE' for entry at point-or-marker POM.
 | 
						||
 | 
						||
 -- Function: org-buffer-property-keys &optional include-specials
 | 
						||
     Get all property keys in the current buffer.
 | 
						||
 | 
						||
 -- Function: org-insert-property-drawer
 | 
						||
     Insert a property drawer for the current entry.
 | 
						||
 | 
						||
 -- Function: org-entry-put-multivalued-property pom property &rest
 | 
						||
          values
 | 
						||
     Set `PROPERTY' at point-or-marker `POM' to `VALUES'.  `VALUES'
 | 
						||
     should be a list of strings.  They will be concatenated, with
 | 
						||
     spaces as separators.
 | 
						||
 | 
						||
 -- Function: org-entry-get-multivalued-property pom property
 | 
						||
     Treat the value of the property `PROPERTY' as a
 | 
						||
     whitespace-separated list of values and return the values as a
 | 
						||
     list of strings.
 | 
						||
 | 
						||
 -- Function: org-entry-add-to-multivalued-property pom property value
 | 
						||
     Treat the value of the property `PROPERTY' as a
 | 
						||
     whitespace-separated list of values and make sure that `VALUE' is
 | 
						||
     in this list.
 | 
						||
 | 
						||
 -- Function: org-entry-remove-from-multivalued-property pom property
 | 
						||
          value
 | 
						||
     Treat the value of the property `PROPERTY' as a
 | 
						||
     whitespace-separated list of values and make sure that `VALUE' is
 | 
						||
     _not_ in this list.
 | 
						||
 | 
						||
 -- Function: org-entry-member-in-multivalued-property pom property
 | 
						||
          value
 | 
						||
     Treat the value of the property `PROPERTY' as a
 | 
						||
     whitespace-separated list of values and check if `VALUE' is in
 | 
						||
     this list.
 | 
						||
 | 
						||
 -- User Option: org-property-allowed-value-functions
 | 
						||
     Hook for functions supplying allowed values for a specific
 | 
						||
     property.  The functions must take a single argument, the name of
 | 
						||
     the property, and return a flat list of allowed values.  If `:ETC'
 | 
						||
     is one of the values, use the values as completion help, but allow
 | 
						||
     also other values to be entered.  The functions must return `nil'
 | 
						||
     if they are not responsible for this property.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Using the mapping API,  Prev: Using the property API,  Up: Hacking
 | 
						||
 | 
						||
A.12 Using the mapping API
 | 
						||
==========================
 | 
						||
 | 
						||
Org has sophisticated mapping capabilities to find all entries
 | 
						||
satisfying certain criteria.  Internally, this functionality is used to
 | 
						||
produce agenda views, but there is also an API that can be used to
 | 
						||
execute arbitrary functions for each or selected entries.  The main
 | 
						||
entry point for this API is:
 | 
						||
 | 
						||
 -- Function: org-map-entries func &optional match scope &rest skip
 | 
						||
     Call `FUNC' at each headline selected by `MATCH' in `SCOPE'.
 | 
						||
 | 
						||
     `FUNC' is a function or a Lisp form.  The function will be called
 | 
						||
     without arguments, with the cursor positioned at the beginning of
 | 
						||
     the headline.  The return values of all calls to the function will
 | 
						||
     be collected and returned as a list.
 | 
						||
 | 
						||
     The call to `FUNC' will be wrapped into a save-excursion form, so
 | 
						||
     `FUNC' does not need to preserve point.  After evaluation, the
 | 
						||
     cursor will be moved to the end of the line (presumably of the
 | 
						||
     headline of the processed entry) and search continues from there.
 | 
						||
     Under some circumstances, this may not produce the wanted results.
 | 
						||
     For example, if you have removed (e.g., archived) the current
 | 
						||
     (sub)tree it could mean that the next entry will be skipped
 | 
						||
     entirely.  In such cases, you can specify the position from where
 | 
						||
     search should continue by making `FUNC' set the variable
 | 
						||
     `org-map-continue-from' to the desired buffer position.
 | 
						||
 | 
						||
     `MATCH' is a tags/property/todo match as it is used in the agenda
 | 
						||
     match view.  Only headlines that are matched by this query will be
 | 
						||
     considered during the iteration.  When `MATCH' is `nil' or `t', all
 | 
						||
     headlines will be visited by the iteration.
 | 
						||
 | 
						||
     `SCOPE' determines the scope of this command.  It can be any of:
 | 
						||
 | 
						||
          nil     the current buffer, respecting the restriction if any
 | 
						||
          tree    the subtree started with the entry at point
 | 
						||
          region  The entries within the active region, if any
 | 
						||
          file    the current buffer, without restriction
 | 
						||
          file-with-archives
 | 
						||
                  the current buffer, and any archives associated with it
 | 
						||
          agenda  all agenda files
 | 
						||
          agenda-with-archives
 | 
						||
                  all agenda files with any archive files associated with them
 | 
						||
          (file1 file2 ...)
 | 
						||
                  if this is a list, all files in the list will be scanned
 | 
						||
     The remaining args are treated as settings for the skipping
 | 
						||
     facilities of the scanner.  The following items can be given here:
 | 
						||
 | 
						||
          archive   skip trees with the archive tag
 | 
						||
          comment   skip trees with the COMMENT keyword
 | 
						||
          function or Lisp form
 | 
						||
                    will be used as value for `org-agenda-skip-function',
 | 
						||
                    so whenever the function returns t, FUNC
 | 
						||
                    will not be called for that entry and search will
 | 
						||
                    continue from the point where the function leaves it
 | 
						||
 | 
						||
   The function given to that mapping routine can really do anything
 | 
						||
you like.  It can use the property API (*note Using the property API::)
 | 
						||
to gather more information about the entry, or in order to change
 | 
						||
metadata in the entry.  Here are a couple of functions that might be
 | 
						||
handy:
 | 
						||
 | 
						||
 -- Function: org-todo &optional arg
 | 
						||
     Change the TODO state of the entry.  See the docstring of the
 | 
						||
     functions for the many possible values for the argument `ARG'.
 | 
						||
 | 
						||
 -- Function: org-priority &optional action
 | 
						||
     Change the priority of the entry.  See the docstring of this
 | 
						||
     function for the possible values for `ACTION'.
 | 
						||
 | 
						||
 -- Function: org-toggle-tag tag &optional onoff
 | 
						||
     Toggle the tag `TAG' in the current entry.  Setting `ONOFF' to
 | 
						||
     either `on' or `off' will not toggle tag, but ensure that it is
 | 
						||
     either on or off.
 | 
						||
 | 
						||
 -- Function: org-promote
 | 
						||
     Promote the current entry.
 | 
						||
 | 
						||
 -- Function: org-demote
 | 
						||
     Demote the current entry.
 | 
						||
 | 
						||
   Here is a simple example that will turn all entries in the current
 | 
						||
file with a tag `TOMORROW' into TODO entries with the keyword
 | 
						||
`UPCOMING'.  Entries in comment trees and in archive trees will be
 | 
						||
ignored.
 | 
						||
 | 
						||
     (org-map-entries
 | 
						||
      '(org-todo "UPCOMING")
 | 
						||
      "+TOMORROW" 'file 'archive 'comment)
 | 
						||
 | 
						||
   The following example counts the number of entries with TODO keyword
 | 
						||
`WAITING', in all agenda files.
 | 
						||
 | 
						||
     (length (org-map-entries t "/+WAITING" 'agenda))
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: MobileOrg,  Next: History and acknowledgments,  Prev: Hacking,  Up: Top
 | 
						||
 | 
						||
Appendix B MobileOrg
 | 
						||
********************
 | 
						||
 | 
						||
MobileOrg is the name of the mobile companion app for Org mode,
 | 
						||
currently available for iOS and for Android.  MobileOrg offers offline
 | 
						||
viewing and capture support for an Org mode system rooted on a "real"
 | 
						||
computer.  It also allows you to record changes to existing entries.
 | 
						||
The iOS implementation (https://github.com/MobileOrg/) for the
 | 
						||
iPhone/iPod Touch/iPad series of devices, was started by Richard
 | 
						||
Moreland and is now in the hands Sean Escriva.  Android users should
 | 
						||
check out MobileOrg Android
 | 
						||
(http://wiki.github.com/matburt/mobileorg-android/) by Matt Jones.  The
 | 
						||
two implementations are not identical but offer similar features.
 | 
						||
 | 
						||
   This appendix describes the support Org has for creating agenda
 | 
						||
views in a format that can be displayed by MobileOrg, and for
 | 
						||
integrating notes captured and changes made by MobileOrg into the main
 | 
						||
system.
 | 
						||
 | 
						||
   For changing tags and TODO states in MobileOrg, you should have set
 | 
						||
up the customization variables `org-todo-keywords' and `org-tag-alist'
 | 
						||
to cover all important tags and TODO keywords, even if individual files
 | 
						||
use only part of these.  MobileOrg will also offer you states and tags
 | 
						||
set up with in-buffer settings, but it will understand the logistics of
 | 
						||
TODO state sets (*note Per-file keywords::) and mutually exclusive tags
 | 
						||
(*note Setting tags::) only for those set in these variables.
 | 
						||
 | 
						||
* Menu:
 | 
						||
 | 
						||
* Setting up the staging area::  Where to interact with the mobile device
 | 
						||
* Pushing to MobileOrg::        Uploading Org files and agendas
 | 
						||
* Pulling from MobileOrg::      Integrating captured and flagged items
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Setting up the staging area,  Next: Pushing to MobileOrg,  Up: MobileOrg
 | 
						||
 | 
						||
B.1 Setting up the staging area
 | 
						||
===============================
 | 
						||
 | 
						||
MobileOrg needs to interact with Emacs through a directory on a server.
 | 
						||
If you are using a public server, you should consider encrypting the
 | 
						||
files that are uploaded to the server.  This can be done with Org mode
 | 
						||
7.02 and with MobileOrg 1.5 (iPhone version), and you need an `openssl'
 | 
						||
installation on your system.  To turn on encryption, set a password in
 | 
						||
MobileOrg and, on the Emacs side, configure the variable
 | 
						||
`org-mobile-use-encryption'(1).
 | 
						||
 | 
						||
   The easiest way to create that directory is to use a free
 | 
						||
Dropbox.com (http://dropbox.com) account(2).  When MobileOrg first
 | 
						||
connects to your Dropbox, it will create a directory MobileOrg inside
 | 
						||
the Dropbox.  After the directory has been created, tell Emacs about it:
 | 
						||
 | 
						||
     (setq org-mobile-directory "~/Dropbox/MobileOrg")
 | 
						||
 | 
						||
   Org mode has commands to put files for MobileOrg into that directory,
 | 
						||
and to read captured notes from there.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) If you can safely store the password in your Emacs setup, you
 | 
						||
might also want to configure `org-mobile-encryption-password'.  Please
 | 
						||
read the docstring of that variable.  Note that encryption will apply
 | 
						||
only to the contents of the `.org' files.  The file names themselves
 | 
						||
will remain visible.
 | 
						||
 | 
						||
   (2) If you cannot use Dropbox, or if your version of MobileOrg does
 | 
						||
not support it, you can use a webdav server.  For more information,
 | 
						||
check out the documentation of MobileOrg and also this FAQ entry
 | 
						||
(http://orgmode.org/worg/org-faq.html#mobileorg_webdav).
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Pushing to MobileOrg,  Next: Pulling from MobileOrg,  Prev: Setting up the staging area,  Up: MobileOrg
 | 
						||
 | 
						||
B.2 Pushing to MobileOrg
 | 
						||
========================
 | 
						||
 | 
						||
This operation copies all files currently listed in `org-mobile-files'
 | 
						||
to the directory `org-mobile-directory'.  By default this list contains
 | 
						||
all agenda files (as listed in `org-agenda-files'), but additional files
 | 
						||
can be included by customizing `org-mobile-files'.  File names will be
 | 
						||
staged with paths relative to `org-directory', so all files should be
 | 
						||
inside this directory(1).
 | 
						||
 | 
						||
   The push operation also creates a special Org file `agendas.org' with
 | 
						||
all custom agenda view defined by the user(2).
 | 
						||
 | 
						||
   Finally, Org writes the file `index.org', containing links to all
 | 
						||
other files.  MobileOrg first reads this file from the server, and then
 | 
						||
downloads all agendas and Org files listed in it.  To speed up the
 | 
						||
download, MobileOrg will only read files whose checksums(3) have
 | 
						||
changed.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) Symbolic links in `org-directory' need to have the same name as
 | 
						||
their targets.
 | 
						||
 | 
						||
   (2) While creating the agendas, Org mode will force ID properties on
 | 
						||
all referenced entries, so that these entries can be uniquely
 | 
						||
identified if MobileOrg flags them for further action.  If you do not
 | 
						||
want to get these properties in so many entries, you can set the
 | 
						||
variable `org-mobile-force-id-on-agenda-items' to `nil'.  Org mode will
 | 
						||
then rely on outline paths, in the hope that these will be unique
 | 
						||
enough.
 | 
						||
 | 
						||
   (3) Checksums are stored automatically in the file `checksums.dat'
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Pulling from MobileOrg,  Prev: Pushing to MobileOrg,  Up: MobileOrg
 | 
						||
 | 
						||
B.3 Pulling from MobileOrg
 | 
						||
==========================
 | 
						||
 | 
						||
When MobileOrg synchronizes with the server, it not only pulls the Org
 | 
						||
files for viewing.  It also appends captured entries and pointers to
 | 
						||
flagged and changed entries to the file `mobileorg.org' on the server.
 | 
						||
Org has a _pull_ operation that integrates this information into an
 | 
						||
inbox file and operates on the pointers to flagged entries.  Here is
 | 
						||
how it works:
 | 
						||
 | 
						||
  1. Org moves all entries found in `mobileorg.org'(1) and appends them
 | 
						||
     to the file pointed to by the variable
 | 
						||
     `org-mobile-inbox-for-pull'.  Each captured entry and each editing
 | 
						||
     event will be a top-level entry in the inbox file.
 | 
						||
 | 
						||
  2. After moving the entries, Org will attempt to implement the
 | 
						||
     changes made in MobileOrg.  Some changes are applied directly and
 | 
						||
     without user interaction.  Examples are all changes to tags, TODO
 | 
						||
     state, headline and body text that can be cleanly applied.
 | 
						||
     Entries that have been flagged for further action will receive a
 | 
						||
     tag `:FLAGGED:', so that they can be easily found again.  When
 | 
						||
     there is a problem finding an entry or applying the change, the
 | 
						||
     pointer entry will remain in the inbox and will be marked with an
 | 
						||
     error message.  You need to later resolve these issues by hand.
 | 
						||
 | 
						||
  3. Org will then generate an agenda view with all flagged entries.
 | 
						||
     The user should then go through these entries and do whatever
 | 
						||
     actions are necessary.  If a note has been stored while flagging
 | 
						||
     an entry in MobileOrg, that note will be displayed in the echo
 | 
						||
     area when the cursor is on the corresponding agenda line.
 | 
						||
 | 
						||
    `?'
 | 
						||
          Pressing `?' in that special agenda will display the full
 | 
						||
          flagging note in another window and also push it onto the
 | 
						||
          kill ring.  So you could use `?  z C-y C-c C-c' to store that
 | 
						||
          flagging note as a normal note in the entry.  Pressing `?'
 | 
						||
          twice in succession will offer to remove the `:FLAGGED:' tag
 | 
						||
          along with the recorded flagging note (which is stored in a
 | 
						||
          property).  In this way you indicate that the intended
 | 
						||
          processing for this flagged entry is finished.
 | 
						||
 | 
						||
   If you are not able to process all flagged entries directly, you can
 | 
						||
always return to this agenda view(2) using `C-c a ?'.
 | 
						||
 | 
						||
   ---------- Footnotes ----------
 | 
						||
 | 
						||
   (1) `mobileorg.org' will be empty after this operation.
 | 
						||
 | 
						||
   (2) Note, however, that there is a subtle difference.  The view
 | 
						||
created automatically by `M-x org-mobile-pull RET' is guaranteed to
 | 
						||
search all files that have been addressed by the last pull.  This might
 | 
						||
include a file that is not currently in your list of agenda files.  If
 | 
						||
you later use `C-c a ?' to regenerate the view, only the current agenda
 | 
						||
files will be searched.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: History and acknowledgments,  Next: GNU Free Documentation License,  Prev: MobileOrg,  Up: Top
 | 
						||
 | 
						||
Appendix C History and acknowledgments
 | 
						||
**************************************
 | 
						||
 | 
						||
C.1 From Carsten
 | 
						||
================
 | 
						||
 | 
						||
Org was born in 2003, out of frustration over the user interface of the
 | 
						||
Emacs Outline mode.  I was trying to organize my notes and projects,
 | 
						||
and using Emacs seemed to be the natural way to go.  However, having to
 | 
						||
remember eleven different commands with two or three keys per command,
 | 
						||
only to hide and show parts of the outline tree, that seemed entirely
 | 
						||
unacceptable to me.  Also, when using outlines to take notes, I
 | 
						||
constantly wanted to restructure the tree, organizing it parallel to my
 | 
						||
thoughts and plans.  _Visibility cycling_ and _structure editing_ were
 | 
						||
originally implemented in the package `outline-magic.el', but quickly
 | 
						||
moved to the more general `org.el'.  As this environment became
 | 
						||
comfortable for project planning, the next step was adding _TODO
 | 
						||
entries_, basic _timestamps_, and _table support_.  These areas
 | 
						||
highlighted the two main goals that Org still has today: to be a new,
 | 
						||
outline-based, plain text mode with innovative and intuitive editing
 | 
						||
features, and to incorporate project planning functionality directly
 | 
						||
into a notes file.
 | 
						||
 | 
						||
   Since the first release, literally thousands of emails to me or to
 | 
						||
<emacs-orgmode@gnu.org> have provided a constant stream of bug reports,
 | 
						||
feedback, new ideas, and sometimes patches and add-on code.  Many
 | 
						||
thanks to everyone who has helped to improve this package.  I am trying
 | 
						||
to keep here a list of the people who had significant influence in
 | 
						||
shaping one or more aspects of Org.  The list may not be complete, if I
 | 
						||
have forgotten someone, please accept my apologies and let me know.
 | 
						||
 | 
						||
   Before I get to this list, a few special mentions are in order:
 | 
						||
 | 
						||
Bastien Guerry
 | 
						||
     Bastien has written a large number of extensions to Org (most of
 | 
						||
     them integrated into the core by now), including the LaTeX
 | 
						||
     exporter and the plain list parser.  His support during the early
 | 
						||
     days was central to the success of this project.  Bastien also
 | 
						||
     invented Worg, helped establishing the Web presence of Org, and
 | 
						||
     sponsored hosting costs for the orgmode.org website.  Bastien
 | 
						||
     stepped in as maintainer of Org between 2011 and 2013, at a time
 | 
						||
     when I desparately needed a break.
 | 
						||
 | 
						||
Eric Schulte and Dan Davison
 | 
						||
     Eric and Dan are jointly responsible for the Org-babel system,
 | 
						||
     which turns Org into a multi-language environment for evaluating
 | 
						||
     code and doing literate programming and reproducible research.
 | 
						||
     This has become one of Org's killer features that define what Org
 | 
						||
     is today.
 | 
						||
 | 
						||
John Wiegley
 | 
						||
     John has contributed a number of great ideas and patches directly
 | 
						||
     to Org, including the attachment system (`org-attach.el'),
 | 
						||
     integration with Apple Mail (`org-mac-message.el'), hierarchical
 | 
						||
     dependencies of TODO items, habit tracking (`org-habits.el'), and
 | 
						||
     encryption (`org-crypt.el').  Also, the capture system is really
 | 
						||
     an extended copy of his great `remember.el'.
 | 
						||
 | 
						||
Sebastian Rose
 | 
						||
     Without Sebastian, the HTML/XHTML publishing of Org would be the
 | 
						||
     pitiful work of an ignorant amateur.  Sebastian has pushed this
 | 
						||
     part of Org onto a much higher level.  He also wrote
 | 
						||
     `org-info.js', a Java script for displaying web pages derived from
 | 
						||
     Org using an Info-like or a folding interface with single-key
 | 
						||
     navigation.
 | 
						||
 | 
						||
See below for the full list of contributions!  Again, please let me
 | 
						||
know what I am missing here!
 | 
						||
 | 
						||
C.2 From Bastien
 | 
						||
================
 | 
						||
 | 
						||
I (Bastien) have been maintaining Org between 2011 and 2013.  This
 | 
						||
appendix would not be complete without adding a few more
 | 
						||
acknowledgements and thanks.
 | 
						||
 | 
						||
   I am first grateful to Carsten for his trust while handing me over
 | 
						||
the maintainership of Org.  His unremitting support is what really
 | 
						||
helped me getting more confident over time, with both the community and
 | 
						||
the code.
 | 
						||
 | 
						||
   When I took over maintainership, I knew I would have to make Org more
 | 
						||
collaborative than ever, as I would have to rely on people that are more
 | 
						||
knowledgeable than I am on many parts of the code.  Here is a list of
 | 
						||
the persons I could rely on, they should really be considered
 | 
						||
co-maintainers, either of the code or the community:
 | 
						||
 | 
						||
Eric Schulte
 | 
						||
     Eric is maintaining the Babel parts of Org.  His reactivity here
 | 
						||
     kept me away from worrying about possible bugs here and let me
 | 
						||
     focus on other parts.
 | 
						||
 | 
						||
Nicolas Goaziou
 | 
						||
     Nicolas is maintaining the consistency of the deepest parts of
 | 
						||
     Org.  His work on `org-element.el' and `ox.el' has been
 | 
						||
     outstanding, and it opened the doors for many new ideas and
 | 
						||
     features.  He rewrote many of the old exporters to use the new
 | 
						||
     export engine, and helped with documenting this major change.
 | 
						||
     More importantly (if that's possible), he has been more than
 | 
						||
     reliable during all the work done for Org 8.0, and always very
 | 
						||
     reactive on the mailing list.
 | 
						||
 | 
						||
Achim Gratz
 | 
						||
     Achim rewrote the building process of Org, turning some _ad hoc_
 | 
						||
     tools into a flexible and conceptually clean process.  He
 | 
						||
     patiently coped with the many hiccups that such a change can
 | 
						||
     create for users.
 | 
						||
 | 
						||
Nick Dokos
 | 
						||
     The Org mode mailing list would not be such a nice place without
 | 
						||
     Nick, who patiently helped users so many times.  It is impossible
 | 
						||
     to overestimate such a great help, and the list would not be so
 | 
						||
     active without him.
 | 
						||
 | 
						||
   I received support from so many users that it is clearly impossible
 | 
						||
to be fair when shortlisting a few of them, but Org's history would not
 | 
						||
be complete if the ones above were not mentioned in this manual.
 | 
						||
 | 
						||
C.3 List of contributions
 | 
						||
=========================
 | 
						||
 | 
						||
   * Russel Adams came up with the idea for drawers.
 | 
						||
 | 
						||
   * Suvayu Ali has steadily helped on the mailing list, providing
 | 
						||
     useful feedback on many features and several patches.
 | 
						||
 | 
						||
   * Luis Anaya wrote `ox-man.el'.
 | 
						||
 | 
						||
   * Thomas Baumann wrote `org-bbdb.el' and `org-mhe.el'.
 | 
						||
 | 
						||
   * Michael Brand helped by reporting many bugs and testing many
 | 
						||
     features.  He also implemented the distinction between empty
 | 
						||
     fields and 0-value fields in Org's spreadsheets.
 | 
						||
 | 
						||
   * Christophe Bataillon created the great unicorn logo that we use on
 | 
						||
     the Org mode website.
 | 
						||
 | 
						||
   * Alex Bochannek provided a patch for rounding timestamps.
 | 
						||
 | 
						||
   * Jan Böcker wrote `org-docview.el'.
 | 
						||
 | 
						||
   * Brad Bozarth showed how to pull RSS feed data into Org mode files.
 | 
						||
 | 
						||
   * Tom Breton wrote `org-choose.el'.
 | 
						||
 | 
						||
   * Charles Cave's suggestion sparked the implementation of templates
 | 
						||
     for Remember, which are now templates for capture.
 | 
						||
 | 
						||
   * Pavel Chalmoviansky influenced the agenda treatment of items with
 | 
						||
     specified time.
 | 
						||
 | 
						||
   * Gregory Chernov patched support for Lisp forms into table
 | 
						||
     calculations and improved XEmacs compatibility, in particular by
 | 
						||
     porting `nouline.el' to XEmacs.
 | 
						||
 | 
						||
   * Sacha Chua suggested copying some linking code from Planner, and
 | 
						||
     helped make Org pupular through her blog.
 | 
						||
 | 
						||
   * Toby S. Cubitt contributed to the code for clock formats.
 | 
						||
 | 
						||
   * Baoqiu Cui contributed the first DocBook exporter.  In Org 8.0, we
 | 
						||
     go a different route: you can now export to Texinfo and export the
 | 
						||
     `.texi' file to DocBook using `makeinfo'.
 | 
						||
 | 
						||
   * Eddward DeVilla proposed and tested checkbox statistics.  He also
 | 
						||
     came up with the idea of properties, and that there should be an
 | 
						||
     API for them.
 | 
						||
 | 
						||
   * Nick Dokos tracked down several nasty bugs.
 | 
						||
 | 
						||
   * Kees Dullemond used to edit projects lists directly in HTML and so
 | 
						||
     inspired some of the early development, including HTML export.  He
 | 
						||
     also asked for a way to narrow wide table columns.
 | 
						||
 | 
						||
   * Jason Dunsmore has been maintaining the Org-Mode server at
 | 
						||
     Rackspace for several years now.  He also sponsored the hosting
 | 
						||
     costs until Rackspace started to host us for free.
 | 
						||
 | 
						||
   * Thomas S. Dye contributed documentation on Worg and helped
 | 
						||
     integrating the Org-Babel documentation into the manual.
 | 
						||
 | 
						||
   * Christian Egli converted the documentation into Texinfo format,
 | 
						||
     inspired the agenda, patched CSS formatting into the HTML
 | 
						||
     exporter, and wrote `org-taskjuggler.el', which has been rewritten
 | 
						||
     by Nicolas Goaziou as `ox-taskjuggler.el' for Org 8.0.
 | 
						||
 | 
						||
   * David Emery provided a patch for custom CSS support in exported
 | 
						||
     HTML agendas.
 | 
						||
 | 
						||
   * Sean Escriva took over MobileOrg development on the iPhone
 | 
						||
     platform.
 | 
						||
 | 
						||
   * Nic Ferrier contributed mailcap and XOXO support.
 | 
						||
 | 
						||
   * Miguel A. Figueroa-Villanueva implemented hierarchical checkboxes.
 | 
						||
 | 
						||
   * John Foerch figured out how to make incremental search show context
 | 
						||
     around a match in a hidden outline tree.
 | 
						||
 | 
						||
   * Raimar Finken wrote `org-git-line.el'.
 | 
						||
 | 
						||
   * Mikael Fornius works as a mailing list moderator.
 | 
						||
 | 
						||
   * Austin Frank works as a mailing list moderator.
 | 
						||
 | 
						||
   * Eric Fraga drove the development of BEAMER export with ideas and
 | 
						||
     testing.
 | 
						||
 | 
						||
   * Barry Gidden did proofreading the manual in preparation for the
 | 
						||
     book publication through Network Theory Ltd.
 | 
						||
 | 
						||
   * Niels Giesen had the idea to automatically archive DONE trees.
 | 
						||
 | 
						||
   * Nicolas Goaziou rewrote much of the plain list code.  He also wrote
 | 
						||
     `org-element.el' and `org-export.el', which was a huge step forward
 | 
						||
     in implementing a clean framework for Org exporters.
 | 
						||
 | 
						||
   * Kai Grossjohann pointed out key-binding conflicts with other
 | 
						||
     packages.
 | 
						||
 | 
						||
   * Brian Gough of Network Theory Ltd publishes the Org mode manual as
 | 
						||
     a book.
 | 
						||
 | 
						||
   * Bernt Hansen has driven much of the support for auto-repeating
 | 
						||
     tasks, task state change logging, and the clocktable.  His clear
 | 
						||
     explanations have been critical when we started to adopt the Git
 | 
						||
     version control system.
 | 
						||
 | 
						||
   * Manuel Hermenegildo has contributed various ideas, small fixes and
 | 
						||
     patches.
 | 
						||
 | 
						||
   * Phil Jackson wrote `org-irc.el'.
 | 
						||
 | 
						||
   * Scott Jaderholm proposed footnotes, control over whitespace between
 | 
						||
     folded entries, and column view for properties.
 | 
						||
 | 
						||
   * Matt Jones wrote MobileOrg Android.
 | 
						||
 | 
						||
   * Tokuya Kameshima wrote `org-wl.el' and `org-mew.el'.
 | 
						||
 | 
						||
   * Jonathan Leech-Pepin wrote `ox-texinfo.el'.
 | 
						||
 | 
						||
   * Shidai Liu ("Leo") asked for embedded LaTeX and tested it.  He also
 | 
						||
     provided frequent feedback and some patches.
 | 
						||
 | 
						||
   * Matt Lundin has proposed last-row references for table formulas
 | 
						||
     and named invisible anchors.  He has also worked a lot on the FAQ.
 | 
						||
 | 
						||
   * David Maus wrote `org-atom.el', maintains the issues file for Org,
 | 
						||
     and is a prolific contributor on the mailing list with competent
 | 
						||
     replies, small fixes and patches.
 | 
						||
 | 
						||
   * Jason F. McBrayer suggested agenda export to CSV format.
 | 
						||
 | 
						||
   * Max Mikhanosha came up with the idea of refiling and sticky
 | 
						||
     agendas.
 | 
						||
 | 
						||
   * Dmitri Minaev sent a patch to set priority limits on a per-file
 | 
						||
     basis.
 | 
						||
 | 
						||
   * Stefan Monnier provided a patch to keep the Emacs-Lisp compiler
 | 
						||
     happy.
 | 
						||
 | 
						||
   * Richard Moreland wrote MobileOrg for the iPhone.
 | 
						||
 | 
						||
   * Rick Moynihan proposed allowing multiple TODO sequences in a file
 | 
						||
     and being able to quickly restrict the agenda to a subtree.
 | 
						||
 | 
						||
   * Todd Neal provided patches for links to Info files and Elisp forms.
 | 
						||
 | 
						||
   * Greg Newman refreshed the unicorn logo into its current form.
 | 
						||
 | 
						||
   * Tim O'Callaghan suggested in-file links, search options for general
 | 
						||
     file links, and TAGS.
 | 
						||
 | 
						||
   * Osamu Okano wrote `orgcard2ref.pl', a Perl program to create a text
 | 
						||
     version of the reference card.
 | 
						||
 | 
						||
   * Takeshi Okano translated the manual and David O'Toole's tutorial
 | 
						||
     into Japanese.
 | 
						||
 | 
						||
   * Oliver Oppitz suggested multi-state TODO items.
 | 
						||
 | 
						||
   * Scott Otterson sparked the introduction of descriptive text for
 | 
						||
     links, among other things.
 | 
						||
 | 
						||
   * Pete Phillips helped during the development of the TAGS feature,
 | 
						||
     and provided frequent feedback.
 | 
						||
 | 
						||
   * Francesco Pizzolante provided patches that helped speeding up the
 | 
						||
     agenda generation.
 | 
						||
 | 
						||
   * Martin Pohlack provided the code snippet to bundle character
 | 
						||
     insertion into bundles of 20 for undo.
 | 
						||
 | 
						||
   * Rackspace.com is hosting our website for free.  Thank you
 | 
						||
     Rackspace!
 | 
						||
 | 
						||
   * T.V. Raman reported bugs and suggested improvements.
 | 
						||
 | 
						||
   * Matthias Rempe (Oelde) provided ideas, Windows support, and quality
 | 
						||
     control.
 | 
						||
 | 
						||
   * Paul Rivier provided the basic implementation of named footnotes.
 | 
						||
     He also acted as mailing list moderator for some time.
 | 
						||
 | 
						||
   * Kevin Rogers contributed code to access VM files on remote hosts.
 | 
						||
 | 
						||
   * Frank Ruell solved the mystery of the `keymapp nil' bug, a
 | 
						||
     conflict with `allout.el'.
 | 
						||
 | 
						||
   * Jason Riedy generalized the send-receive mechanism for Orgtbl
 | 
						||
     tables with extensive patches.
 | 
						||
 | 
						||
   * Philip Rooke created the Org reference card, provided lots of
 | 
						||
     feedback, developed and applied standards to the Org documentation.
 | 
						||
 | 
						||
   * Christian Schlauer proposed angular brackets around links, among
 | 
						||
     other things.
 | 
						||
 | 
						||
   * Christopher Schmidt reworked `orgstruct-mode' so that users can
 | 
						||
     enjoy folding in non-org buffers by using Org headlines in
 | 
						||
     comments.
 | 
						||
 | 
						||
   * Paul Sexton wrote `org-ctags.el'.
 | 
						||
 | 
						||
   * Linking to VM/BBDB/Gnus was first inspired by Tom Shannon's
 | 
						||
     `organizer-mode.el'.
 | 
						||
 | 
						||
   * Ilya Shlyakhter proposed the Archive Sibling, line numbering in
 | 
						||
     literal examples, and remote highlighting for referenced code
 | 
						||
     lines.
 | 
						||
 | 
						||
   * Stathis Sideris wrote the `ditaa.jar' ASCII to PNG converter that
 | 
						||
     is now packaged into Org's `contrib' directory.
 | 
						||
 | 
						||
   * Daniel Sinder came up with the idea of internal archiving by
 | 
						||
     locking subtrees.
 | 
						||
 | 
						||
   * Dale Smith proposed link abbreviations.
 | 
						||
 | 
						||
   * James TD Smith has contributed a large number of patches for useful
 | 
						||
     tweaks and features.
 | 
						||
 | 
						||
   * Adam Spiers asked for global linking commands, inspired the link
 | 
						||
     extension system, added support for mairix, and proposed the
 | 
						||
     mapping API.
 | 
						||
 | 
						||
   * Ulf Stegemann created the table to translate special symbols to
 | 
						||
     HTML, LaTeX, UTF-8, Latin-1 and ASCII.
 | 
						||
 | 
						||
   * Andy Stewart contributed code to `org-w3m.el', to copy HTML content
 | 
						||
     with links transformation to Org syntax.
 | 
						||
 | 
						||
   * David O'Toole wrote `org-publish.el' and drafted the manual
 | 
						||
     chapter about publishing.
 | 
						||
 | 
						||
   * Jambunathan K contributed the ODT exporter and rewrote the HTML
 | 
						||
     exporter.
 | 
						||
 | 
						||
   * Sebastien Vauban reported many issues with LaTeX and BEAMER export
 | 
						||
     and enabled source code highlighting in Gnus.
 | 
						||
 | 
						||
   * Stefan Vollmar organized a video-recorded talk at the
 | 
						||
     Max-Planck-Institute for Neurology.  He also inspired the creation
 | 
						||
     of a concept index for HTML export.
 | 
						||
 | 
						||
   * Jürgen Vollmer contributed code generating the table of contents
 | 
						||
     in HTML output.
 | 
						||
 | 
						||
   * Samuel Wales has provided important feedback and bug reports.
 | 
						||
 | 
						||
   * Chris Wallace provided a patch implementing the `QUOTE' keyword.
 | 
						||
 | 
						||
   * David Wainberg suggested archiving, and improvements to the linking
 | 
						||
     system.
 | 
						||
 | 
						||
   * Carsten Wimmer suggested some changes and helped fix a bug in
 | 
						||
     linking to Gnus.
 | 
						||
 | 
						||
   * Roland Winkler requested additional key bindings to make Org work
 | 
						||
     on a tty.
 | 
						||
 | 
						||
   * Piotr Zielinski wrote `org-mouse.el', proposed agenda blocks and
 | 
						||
     contributed various ideas and code snippets.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: GNU Free Documentation License,  Next: Main Index,  Prev: History and acknowledgments,  Up: Top
 | 
						||
 | 
						||
Appendix D GNU Free Documentation License
 | 
						||
*****************************************
 | 
						||
 | 
						||
                     Version 1.3, 3 November 2008
 | 
						||
 | 
						||
     Copyright (C) 2000, 2001, 2002, 2007, 2008, 2013, 2014 Free Software Foundation, Inc.
 | 
						||
     `http://fsf.org/'
 | 
						||
 | 
						||
     Everyone is permitted to copy and distribute verbatim copies
 | 
						||
     of this license document, but changing it is not allowed.
 | 
						||
 | 
						||
  0. PREAMBLE
 | 
						||
 | 
						||
     The purpose of this License is to make a manual, textbook, or other
 | 
						||
     functional and useful document "free" in the sense of freedom: to
 | 
						||
     assure everyone the effective freedom to copy and redistribute it,
 | 
						||
     with or without modifying it, either commercially or
 | 
						||
     noncommercially.  Secondarily, this License preserves for the
 | 
						||
     author and publisher a way to get credit for their work, while not
 | 
						||
     being considered responsible for modifications made by others.
 | 
						||
 | 
						||
     This License is a kind of "copyleft", which means that derivative
 | 
						||
     works of the document must themselves be free in the same sense.
 | 
						||
     It complements the GNU General Public License, which is a copyleft
 | 
						||
     license designed for free software.
 | 
						||
 | 
						||
     We have designed this License in order to use it for manuals for
 | 
						||
     free software, because free software needs free documentation: a
 | 
						||
     free program should come with manuals providing the same freedoms
 | 
						||
     that the software does.  But this License is not limited to
 | 
						||
     software manuals; it can be used for any textual work, regardless
 | 
						||
     of subject matter or whether it is published as a printed book.
 | 
						||
     We recommend this License principally for works whose purpose is
 | 
						||
     instruction or reference.
 | 
						||
 | 
						||
  1. APPLICABILITY AND DEFINITIONS
 | 
						||
 | 
						||
     This License applies to any manual or other work, in any medium,
 | 
						||
     that contains a notice placed by the copyright holder saying it
 | 
						||
     can be distributed under the terms of this License.  Such a notice
 | 
						||
     grants a world-wide, royalty-free license, unlimited in duration,
 | 
						||
     to use that work under the conditions stated herein.  The
 | 
						||
     "Document", below, refers to any such manual or work.  Any member
 | 
						||
     of the public is a licensee, and is addressed as "you".  You
 | 
						||
     accept the license if you copy, modify or distribute the work in a
 | 
						||
     way requiring permission under copyright law.
 | 
						||
 | 
						||
     A "Modified Version" of the Document means any work containing the
 | 
						||
     Document or a portion of it, either copied verbatim, or with
 | 
						||
     modifications and/or translated into another language.
 | 
						||
 | 
						||
     A "Secondary Section" is a named appendix or a front-matter section
 | 
						||
     of the Document that deals exclusively with the relationship of the
 | 
						||
     publishers or authors of the Document to the Document's overall
 | 
						||
     subject (or to related matters) and contains nothing that could
 | 
						||
     fall directly within that overall subject.  (Thus, if the Document
 | 
						||
     is in part a textbook of mathematics, a Secondary Section may not
 | 
						||
     explain any mathematics.)  The relationship could be a matter of
 | 
						||
     historical connection with the subject or with related matters, or
 | 
						||
     of legal, commercial, philosophical, ethical or political position
 | 
						||
     regarding them.
 | 
						||
 | 
						||
     The "Invariant Sections" are certain Secondary Sections whose
 | 
						||
     titles are designated, as being those of Invariant Sections, in
 | 
						||
     the notice that says that the Document is released under this
 | 
						||
     License.  If a section does not fit the above definition of
 | 
						||
     Secondary then it is not allowed to be designated as Invariant.
 | 
						||
     The Document may contain zero Invariant Sections.  If the Document
 | 
						||
     does not identify any Invariant Sections then there are none.
 | 
						||
 | 
						||
     The "Cover Texts" are certain short passages of text that are
 | 
						||
     listed, as Front-Cover Texts or Back-Cover Texts, in the notice
 | 
						||
     that says that the Document is released under this License.  A
 | 
						||
     Front-Cover Text may be at most 5 words, and a Back-Cover Text may
 | 
						||
     be at most 25 words.
 | 
						||
 | 
						||
     A "Transparent" copy of the Document means a machine-readable copy,
 | 
						||
     represented in a format whose specification is available to the
 | 
						||
     general public, that is suitable for revising the document
 | 
						||
     straightforwardly with generic text editors or (for images
 | 
						||
     composed of pixels) generic paint programs or (for drawings) some
 | 
						||
     widely available drawing editor, and that is suitable for input to
 | 
						||
     text formatters or for automatic translation to a variety of
 | 
						||
     formats suitable for input to text formatters.  A copy made in an
 | 
						||
     otherwise Transparent file format whose markup, or absence of
 | 
						||
     markup, has been arranged to thwart or discourage subsequent
 | 
						||
     modification by readers is not Transparent.  An image format is
 | 
						||
     not Transparent if used for any substantial amount of text.  A
 | 
						||
     copy that is not "Transparent" is called "Opaque".
 | 
						||
 | 
						||
     Examples of suitable formats for Transparent copies include plain
 | 
						||
     ASCII without markup, Texinfo input format, LaTeX input format,
 | 
						||
     SGML or XML using a publicly available DTD, and
 | 
						||
     standard-conforming simple HTML, PostScript or PDF designed for
 | 
						||
     human modification.  Examples of transparent image formats include
 | 
						||
     PNG, XCF and JPG.  Opaque formats include proprietary formats that
 | 
						||
     can be read and edited only by proprietary word processors, SGML or
 | 
						||
     XML for which the DTD and/or processing tools are not generally
 | 
						||
     available, and the machine-generated HTML, PostScript or PDF
 | 
						||
     produced by some word processors for output purposes only.
 | 
						||
 | 
						||
     The "Title Page" means, for a printed book, the title page itself,
 | 
						||
     plus such following pages as are needed to hold, legibly, the
 | 
						||
     material this License requires to appear in the title page.  For
 | 
						||
     works in formats which do not have any title page as such, "Title
 | 
						||
     Page" means the text near the most prominent appearance of the
 | 
						||
     work's title, preceding the beginning of the body of the text.
 | 
						||
 | 
						||
     The "publisher" means any person or entity that distributes copies
 | 
						||
     of the Document to the public.
 | 
						||
 | 
						||
     A section "Entitled XYZ" means a named subunit of the Document
 | 
						||
     whose title either is precisely XYZ or contains XYZ in parentheses
 | 
						||
     following text that translates XYZ in another language.  (Here XYZ
 | 
						||
     stands for a specific section name mentioned below, such as
 | 
						||
     "Acknowledgements", "Dedications", "Endorsements", or "History".)
 | 
						||
     To "Preserve the Title" of such a section when you modify the
 | 
						||
     Document means that it remains a section "Entitled XYZ" according
 | 
						||
     to this definition.
 | 
						||
 | 
						||
     The Document may include Warranty Disclaimers next to the notice
 | 
						||
     which states that this License applies to the Document.  These
 | 
						||
     Warranty Disclaimers are considered to be included by reference in
 | 
						||
     this License, but only as regards disclaiming warranties: any other
 | 
						||
     implication that these Warranty Disclaimers may have is void and
 | 
						||
     has no effect on the meaning of this License.
 | 
						||
 | 
						||
  2. VERBATIM COPYING
 | 
						||
 | 
						||
     You may copy and distribute the Document in any medium, either
 | 
						||
     commercially or noncommercially, provided that this License, the
 | 
						||
     copyright notices, and the license notice saying this License
 | 
						||
     applies to the Document are reproduced in all copies, and that you
 | 
						||
     add no other conditions whatsoever to those of this License.  You
 | 
						||
     may not use technical measures to obstruct or control the reading
 | 
						||
     or further copying of the copies you make or distribute.  However,
 | 
						||
     you may accept compensation in exchange for copies.  If you
 | 
						||
     distribute a large enough number of copies you must also follow
 | 
						||
     the conditions in section 3.
 | 
						||
 | 
						||
     You may also lend copies, under the same conditions stated above,
 | 
						||
     and you may publicly display copies.
 | 
						||
 | 
						||
  3. COPYING IN QUANTITY
 | 
						||
 | 
						||
     If you publish printed copies (or copies in media that commonly
 | 
						||
     have printed covers) of the Document, numbering more than 100, and
 | 
						||
     the Document's license notice requires Cover Texts, you must
 | 
						||
     enclose the copies in covers that carry, clearly and legibly, all
 | 
						||
     these Cover Texts: Front-Cover Texts on the front cover, and
 | 
						||
     Back-Cover Texts on the back cover.  Both covers must also clearly
 | 
						||
     and legibly identify you as the publisher of these copies.  The
 | 
						||
     front cover must present the full title with all words of the
 | 
						||
     title equally prominent and visible.  You may add other material
 | 
						||
     on the covers in addition.  Copying with changes limited to the
 | 
						||
     covers, as long as they preserve the title of the Document and
 | 
						||
     satisfy these conditions, can be treated as verbatim copying in
 | 
						||
     other respects.
 | 
						||
 | 
						||
     If the required texts for either cover are too voluminous to fit
 | 
						||
     legibly, you should put the first ones listed (as many as fit
 | 
						||
     reasonably) on the actual cover, and continue the rest onto
 | 
						||
     adjacent pages.
 | 
						||
 | 
						||
     If you publish or distribute Opaque copies of the Document
 | 
						||
     numbering more than 100, you must either include a
 | 
						||
     machine-readable Transparent copy along with each Opaque copy, or
 | 
						||
     state in or with each Opaque copy a computer-network location from
 | 
						||
     which the general network-using public has access to download
 | 
						||
     using public-standard network protocols a complete Transparent
 | 
						||
     copy of the Document, free of added material.  If you use the
 | 
						||
     latter option, you must take reasonably prudent steps, when you
 | 
						||
     begin distribution of Opaque copies in quantity, to ensure that
 | 
						||
     this Transparent copy will remain thus accessible at the stated
 | 
						||
     location until at least one year after the last time you
 | 
						||
     distribute an Opaque copy (directly or through your agents or
 | 
						||
     retailers) of that edition to the public.
 | 
						||
 | 
						||
     It is requested, but not required, that you contact the authors of
 | 
						||
     the Document well before redistributing any large number of
 | 
						||
     copies, to give them a chance to provide you with an updated
 | 
						||
     version of the Document.
 | 
						||
 | 
						||
  4. MODIFICATIONS
 | 
						||
 | 
						||
     You may copy and distribute a Modified Version of the Document
 | 
						||
     under the conditions of sections 2 and 3 above, provided that you
 | 
						||
     release the Modified Version under precisely this License, with
 | 
						||
     the Modified Version filling the role of the Document, thus
 | 
						||
     licensing distribution and modification of the Modified Version to
 | 
						||
     whoever possesses a copy of it.  In addition, you must do these
 | 
						||
     things in the Modified Version:
 | 
						||
 | 
						||
       A. Use in the Title Page (and on the covers, if any) a title
 | 
						||
          distinct from that of the Document, and from those of
 | 
						||
          previous versions (which should, if there were any, be listed
 | 
						||
          in the History section of the Document).  You may use the
 | 
						||
          same title as a previous version if the original publisher of
 | 
						||
          that version gives permission.
 | 
						||
 | 
						||
       B. List on the Title Page, as authors, one or more persons or
 | 
						||
          entities responsible for authorship of the modifications in
 | 
						||
          the Modified Version, together with at least five of the
 | 
						||
          principal authors of the Document (all of its principal
 | 
						||
          authors, if it has fewer than five), unless they release you
 | 
						||
          from this requirement.
 | 
						||
 | 
						||
       C. State on the Title page the name of the publisher of the
 | 
						||
          Modified Version, as the publisher.
 | 
						||
 | 
						||
       D. Preserve all the copyright notices of the Document.
 | 
						||
 | 
						||
       E. Add an appropriate copyright notice for your modifications
 | 
						||
          adjacent to the other copyright notices.
 | 
						||
 | 
						||
       F. Include, immediately after the copyright notices, a license
 | 
						||
          notice giving the public permission to use the Modified
 | 
						||
          Version under the terms of this License, in the form shown in
 | 
						||
          the Addendum below.
 | 
						||
 | 
						||
       G. Preserve in that license notice the full lists of Invariant
 | 
						||
          Sections and required Cover Texts given in the Document's
 | 
						||
          license notice.
 | 
						||
 | 
						||
       H. Include an unaltered copy of this License.
 | 
						||
 | 
						||
       I. Preserve the section Entitled "History", Preserve its Title,
 | 
						||
          and add to it an item stating at least the title, year, new
 | 
						||
          authors, and publisher of the Modified Version as given on
 | 
						||
          the Title Page.  If there is no section Entitled "History" in
 | 
						||
          the Document, create one stating the title, year, authors,
 | 
						||
          and publisher of the Document as given on its Title Page,
 | 
						||
          then add an item describing the Modified Version as stated in
 | 
						||
          the previous sentence.
 | 
						||
 | 
						||
       J. Preserve the network location, if any, given in the Document
 | 
						||
          for public access to a Transparent copy of the Document, and
 | 
						||
          likewise the network locations given in the Document for
 | 
						||
          previous versions it was based on.  These may be placed in
 | 
						||
          the "History" section.  You may omit a network location for a
 | 
						||
          work that was published at least four years before the
 | 
						||
          Document itself, or if the original publisher of the version
 | 
						||
          it refers to gives permission.
 | 
						||
 | 
						||
       K. For any section Entitled "Acknowledgements" or "Dedications",
 | 
						||
          Preserve the Title of the section, and preserve in the
 | 
						||
          section all the substance and tone of each of the contributor
 | 
						||
          acknowledgements and/or dedications given therein.
 | 
						||
 | 
						||
       L. Preserve all the Invariant Sections of the Document,
 | 
						||
          unaltered in their text and in their titles.  Section numbers
 | 
						||
          or the equivalent are not considered part of the section
 | 
						||
          titles.
 | 
						||
 | 
						||
       M. Delete any section Entitled "Endorsements".  Such a section
 | 
						||
          may not be included in the Modified Version.
 | 
						||
 | 
						||
       N. Do not retitle any existing section to be Entitled
 | 
						||
          "Endorsements" or to conflict in title with any Invariant
 | 
						||
          Section.
 | 
						||
 | 
						||
       O. Preserve any Warranty Disclaimers.
 | 
						||
 | 
						||
     If the Modified Version includes new front-matter sections or
 | 
						||
     appendices that qualify as Secondary Sections and contain no
 | 
						||
     material copied from the Document, you may at your option
 | 
						||
     designate some or all of these sections as invariant.  To do this,
 | 
						||
     add their titles to the list of Invariant Sections in the Modified
 | 
						||
     Version's license notice.  These titles must be distinct from any
 | 
						||
     other section titles.
 | 
						||
 | 
						||
     You may add a section Entitled "Endorsements", provided it contains
 | 
						||
     nothing but endorsements of your Modified Version by various
 | 
						||
     parties--for example, statements of peer review or that the text
 | 
						||
     has been approved by an organization as the authoritative
 | 
						||
     definition of a standard.
 | 
						||
 | 
						||
     You may add a passage of up to five words as a Front-Cover Text,
 | 
						||
     and a passage of up to 25 words as a Back-Cover Text, to the end
 | 
						||
     of the list of Cover Texts in the Modified Version.  Only one
 | 
						||
     passage of Front-Cover Text and one of Back-Cover Text may be
 | 
						||
     added by (or through arrangements made by) any one entity.  If the
 | 
						||
     Document already includes a cover text for the same cover,
 | 
						||
     previously added by you or by arrangement made by the same entity
 | 
						||
     you are acting on behalf of, you may not add another; but you may
 | 
						||
     replace the old one, on explicit permission from the previous
 | 
						||
     publisher that added the old one.
 | 
						||
 | 
						||
     The author(s) and publisher(s) of the Document do not by this
 | 
						||
     License give permission to use their names for publicity for or to
 | 
						||
     assert or imply endorsement of any Modified Version.
 | 
						||
 | 
						||
  5. COMBINING DOCUMENTS
 | 
						||
 | 
						||
     You may combine the Document with other documents released under
 | 
						||
     this License, under the terms defined in section 4 above for
 | 
						||
     modified versions, provided that you include in the combination
 | 
						||
     all of the Invariant Sections of all of the original documents,
 | 
						||
     unmodified, and list them all as Invariant Sections of your
 | 
						||
     combined work in its license notice, and that you preserve all
 | 
						||
     their Warranty Disclaimers.
 | 
						||
 | 
						||
     The combined work need only contain one copy of this License, and
 | 
						||
     multiple identical Invariant Sections may be replaced with a single
 | 
						||
     copy.  If there are multiple Invariant Sections with the same name
 | 
						||
     but different contents, make the title of each such section unique
 | 
						||
     by adding at the end of it, in parentheses, the name of the
 | 
						||
     original author or publisher of that section if known, or else a
 | 
						||
     unique number.  Make the same adjustment to the section titles in
 | 
						||
     the list of Invariant Sections in the license notice of the
 | 
						||
     combined work.
 | 
						||
 | 
						||
     In the combination, you must combine any sections Entitled
 | 
						||
     "History" in the various original documents, forming one section
 | 
						||
     Entitled "History"; likewise combine any sections Entitled
 | 
						||
     "Acknowledgements", and any sections Entitled "Dedications".  You
 | 
						||
     must delete all sections Entitled "Endorsements."
 | 
						||
 | 
						||
  6. COLLECTIONS OF DOCUMENTS
 | 
						||
 | 
						||
     You may make a collection consisting of the Document and other
 | 
						||
     documents released under this License, and replace the individual
 | 
						||
     copies of this License in the various documents with a single copy
 | 
						||
     that is included in the collection, provided that you follow the
 | 
						||
     rules of this License for verbatim copying of each of the
 | 
						||
     documents in all other respects.
 | 
						||
 | 
						||
     You may extract a single document from such a collection, and
 | 
						||
     distribute it individually under this License, provided you insert
 | 
						||
     a copy of this License into the extracted document, and follow
 | 
						||
     this License in all other respects regarding verbatim copying of
 | 
						||
     that document.
 | 
						||
 | 
						||
  7. AGGREGATION WITH INDEPENDENT WORKS
 | 
						||
 | 
						||
     A compilation of the Document or its derivatives with other
 | 
						||
     separate and independent documents or works, in or on a volume of
 | 
						||
     a storage or distribution medium, is called an "aggregate" if the
 | 
						||
     copyright resulting from the compilation is not used to limit the
 | 
						||
     legal rights of the compilation's users beyond what the individual
 | 
						||
     works permit.  When the Document is included in an aggregate, this
 | 
						||
     License does not apply to the other works in the aggregate which
 | 
						||
     are not themselves derivative works of the Document.
 | 
						||
 | 
						||
     If the Cover Text requirement of section 3 is applicable to these
 | 
						||
     copies of the Document, then if the Document is less than one half
 | 
						||
     of the entire aggregate, the Document's Cover Texts may be placed
 | 
						||
     on covers that bracket the Document within the aggregate, or the
 | 
						||
     electronic equivalent of covers if the Document is in electronic
 | 
						||
     form.  Otherwise they must appear on printed covers that bracket
 | 
						||
     the whole aggregate.
 | 
						||
 | 
						||
  8. TRANSLATION
 | 
						||
 | 
						||
     Translation is considered a kind of modification, so you may
 | 
						||
     distribute translations of the Document under the terms of section
 | 
						||
     4.  Replacing Invariant Sections with translations requires special
 | 
						||
     permission from their copyright holders, but you may include
 | 
						||
     translations of some or all Invariant Sections in addition to the
 | 
						||
     original versions of these Invariant Sections.  You may include a
 | 
						||
     translation of this License, and all the license notices in the
 | 
						||
     Document, and any Warranty Disclaimers, provided that you also
 | 
						||
     include the original English version of this License and the
 | 
						||
     original versions of those notices and disclaimers.  In case of a
 | 
						||
     disagreement between the translation and the original version of
 | 
						||
     this License or a notice or disclaimer, the original version will
 | 
						||
     prevail.
 | 
						||
 | 
						||
     If a section in the Document is Entitled "Acknowledgements",
 | 
						||
     "Dedications", or "History", the requirement (section 4) to
 | 
						||
     Preserve its Title (section 1) will typically require changing the
 | 
						||
     actual title.
 | 
						||
 | 
						||
  9. TERMINATION
 | 
						||
 | 
						||
     You may not copy, modify, sublicense, or distribute the Document
 | 
						||
     except as expressly provided under this License.  Any attempt
 | 
						||
     otherwise to copy, modify, sublicense, or distribute it is void,
 | 
						||
     and will automatically terminate your rights under this License.
 | 
						||
 | 
						||
     However, if you cease all violation of this License, then your
 | 
						||
     license from a particular copyright holder is reinstated (a)
 | 
						||
     provisionally, unless and until the copyright holder explicitly
 | 
						||
     and finally terminates your license, and (b) permanently, if the
 | 
						||
     copyright holder fails to notify you of the violation by some
 | 
						||
     reasonable means prior to 60 days after the cessation.
 | 
						||
 | 
						||
     Moreover, your license from a particular copyright holder is
 | 
						||
     reinstated permanently if the copyright holder notifies you of the
 | 
						||
     violation by some reasonable means, this is the first time you have
 | 
						||
     received notice of violation of this License (for any work) from
 | 
						||
     that copyright holder, and you cure the violation prior to 30 days
 | 
						||
     after your receipt of the notice.
 | 
						||
 | 
						||
     Termination of your rights under this section does not terminate
 | 
						||
     the licenses of parties who have received copies or rights from
 | 
						||
     you under this License.  If your rights have been terminated and
 | 
						||
     not permanently reinstated, receipt of a copy of some or all of
 | 
						||
     the same material does not give you any rights to use it.
 | 
						||
 | 
						||
 10. FUTURE REVISIONS OF THIS LICENSE
 | 
						||
 | 
						||
     The Free Software Foundation may publish new, revised versions of
 | 
						||
     the GNU Free Documentation License from time to time.  Such new
 | 
						||
     versions will be similar in spirit to the present version, but may
 | 
						||
     differ in detail to address new problems or concerns.  See
 | 
						||
     `http://www.gnu.org/copyleft/'.
 | 
						||
 | 
						||
     Each version of the License is given a distinguishing version
 | 
						||
     number.  If the Document specifies that a particular numbered
 | 
						||
     version of this License "or any later version" applies to it, you
 | 
						||
     have the option of following the terms and conditions either of
 | 
						||
     that specified version or of any later version that has been
 | 
						||
     published (not as a draft) by the Free Software Foundation.  If
 | 
						||
     the Document does not specify a version number of this License,
 | 
						||
     you may choose any version ever published (not as a draft) by the
 | 
						||
     Free Software Foundation.  If the Document specifies that a proxy
 | 
						||
     can decide which future versions of this License can be used, that
 | 
						||
     proxy's public statement of acceptance of a version permanently
 | 
						||
     authorizes you to choose that version for the Document.
 | 
						||
 | 
						||
 11. RELICENSING
 | 
						||
 | 
						||
     "Massive Multiauthor Collaboration Site" (or "MMC Site") means any
 | 
						||
     World Wide Web server that publishes copyrightable works and also
 | 
						||
     provides prominent facilities for anybody to edit those works.  A
 | 
						||
     public wiki that anybody can edit is an example of such a server.
 | 
						||
     A "Massive Multiauthor Collaboration" (or "MMC") contained in the
 | 
						||
     site means any set of copyrightable works thus published on the MMC
 | 
						||
     site.
 | 
						||
 | 
						||
     "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0
 | 
						||
     license published by Creative Commons Corporation, a not-for-profit
 | 
						||
     corporation with a principal place of business in San Francisco,
 | 
						||
     California, as well as future copyleft versions of that license
 | 
						||
     published by that same organization.
 | 
						||
 | 
						||
     "Incorporate" means to publish or republish a Document, in whole or
 | 
						||
     in part, as part of another Document.
 | 
						||
 | 
						||
     An MMC is "eligible for relicensing" if it is licensed under this
 | 
						||
     License, and if all works that were first published under this
 | 
						||
     License somewhere other than this MMC, and subsequently
 | 
						||
     incorporated in whole or in part into the MMC, (1) had no cover
 | 
						||
     texts or invariant sections, and (2) were thus incorporated prior
 | 
						||
     to November 1, 2008.
 | 
						||
 | 
						||
     The operator of an MMC Site may republish an MMC contained in the
 | 
						||
     site under CC-BY-SA on the same site at any time before August 1,
 | 
						||
     2009, provided the MMC is eligible for relicensing.
 | 
						||
 | 
						||
 | 
						||
ADDENDUM: How to use this License for your documents
 | 
						||
====================================================
 | 
						||
 | 
						||
To use this License in a document you have written, include a copy of
 | 
						||
the License in the document and put the following copyright and license
 | 
						||
notices just after the title page:
 | 
						||
 | 
						||
       Copyright (C)  YEAR  YOUR NAME.
 | 
						||
       Permission is granted to copy, distribute and/or modify this document
 | 
						||
       under the terms of the GNU Free Documentation License, Version 1.3
 | 
						||
       or any later version published by the Free Software Foundation;
 | 
						||
       with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
 | 
						||
       Texts.  A copy of the license is included in the section entitled ``GNU
 | 
						||
       Free Documentation License''.
 | 
						||
 | 
						||
   If you have Invariant Sections, Front-Cover Texts and Back-Cover
 | 
						||
Texts, replace the "with...Texts." line with this:
 | 
						||
 | 
						||
         with the Invariant Sections being LIST THEIR TITLES, with
 | 
						||
         the Front-Cover Texts being LIST, and with the Back-Cover Texts
 | 
						||
         being LIST.
 | 
						||
 | 
						||
   If you have Invariant Sections without Cover Texts, or some other
 | 
						||
combination of the three, merge those two alternatives to suit the
 | 
						||
situation.
 | 
						||
 | 
						||
   If your document contains nontrivial examples of program code, we
 | 
						||
recommend releasing these examples in parallel under your choice of
 | 
						||
free software license, such as the GNU General Public License, to
 | 
						||
permit their use in free software.
 | 
						||
 | 
						||
 | 
						||
File: org,  Node: Main Index,  Next: Key Index,  Prev: GNU Free Documentation License,  Up: Top
 | 
						||
 | 
						||
Concept index
 | 
						||
*************
 | 
						||
 | 
						||
 |