* lisp/org-html.el (org-export-html-preprocess): Call org-format-latex,
possibly with a protect-only argument.
* lisp/org.el (org-format-latex): New argument PROTECT-ONLY.
with the switch #+OPTIONS: LaTeX:verbatim ,
LaTeX code will be exported verbatim to HTML, so that jsmath can grab
and convert it.
Proposed by Christian Moe.
* lisp/org-exp.el (org-export-handle-table-metalines): this function
removes table specific meta-lines, now that we aren't wiping
everything that looks remotely like a comment at the end of the
export process we have to be sure to catch all of the specific lines
in org-exp.el
* lisp/org-exp.el: (org-export-select-backend-specific-text) Properly
get rid of #+Backend and #+ATTR_Backend specifics to backends not
matching the one we're exporting to.
This patch changes the functionality of orgtbl-to-orgtbl so that it will
remove newline characters from the text of table cells and replace them
with "\n". This protects the final table from such newlines.
This patch will probably only have any noticeable effect for tables
imported form external files, or from the results of code blocks.
Best -- Eric
>From 34aacc9aa037e8f17c8d32ed61a25f0a350713a0 Mon Sep 17 00:00:00 2001
From: Eric Schulte <schulte.eric@gmail.com>
Date: Fri, 18 Jun 2010 12:38:26 -0700
Subject: [PATCH] org-table: will now strip newlines from the text of table cells
* lisp/org-table.el (orgtbl-to-generic): added the :remove-newlines
option which will strip newline characters from the text of table
cells and replace then with "\n"
(orgtbl-to-orgtbl): now using the new :remove-newlines option to
orgtbl-to-generic
Patch by Carsten
* lisp/org-exp.el (org-export-mark-blockquote-verse-center): fixed
small bug, now grabbing match data before overwritten by looking-at
this fixes a problem with remainders of #+end_quote lines appearing
in exported output
* lisp/org-latex.el (org-export-latex-fixed-width): now checking
org-example rather than org-protected on verbatim export, because by
default all ": " prefixed lines are marked protected
thanks to Christopher Allan Webber for catching this
* lisp/babel/langs/ob-python.el (org-babel-python-table-or-string):
now more careful not to replace "None"s which are not isolated
portions of lists
Thanks to Christopher Witte for raising these issues
* lisp/babel/langs/ob-haskell.el (org-babel-expand-body:haskell):
replaced missing () wrapping, and now using correct variable
expansion
(org-babel-execute:haskell): now using
org-babel-haskell-initiate-session to start sessions
(org-babel-haskell-initiate-session): only starting sessions if none
exists, also added a .25 second wait on brand new sessions to allow
the Haskell interpreter to fire up
(org-babel-load-session:haskell): now optionally accepts processed
params to avoid over-execution of variable resolution
(org-babel-prep-session:haskell): now optionally accepts processed
params to avoid over-execution of variable resolution, also placing
the variable definitions directly in the session instead of loading
them from a separate file
* lisp/org-entities.el (org-entities): Restructure the list.
(org-entities-help): Turn the help output into a buffer
in Org-mode, so that it becomes easier to find a symbol
in the structure.
(org-entities-create-table): Deal with new structure.
Thanks to Daniel Mahler for finding this problem and proposing the fix
* lisp/babel/ob.el (unless): ensure `declare-function' is available in
all Emacsen
* lisp/org-macs.el (org-not-nil): Return the value if not interpreted
as nil.
* lisp/org.el (org-entry-get):
(org-entry-get-with-inheritance): Interpret the value "nil"
as nil for properties.
Bernt Hansen writes:
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
> > On Jun 25, 2010, at 3:23 PM, Robert Goldman wrote:
> >
> > > Question: what is the proper way to get a NIL into a property? Are
> > > we
> > > to use () instead of "nil"? Or are property values always interpreted
> > > as strings?
> > >
> > > Apologies in advance if this is a stupid question!
> >
> > Not a stupid question at all.
> >
> > There is no way, currently. Property values are string - the only
> > way to make
> > org-entry-get return nil is to not have the property defined at all.
>
> I've wanted a similar thing in the past for the LOGGING property where
> the parent task has special logging set via the LOGGING property but I
> want to undo that for some of the child tasks so they use the default
> logging setup.
>
> Having a way to undefine a property would be good in general I think.
-Bernt
* lisp/org-macs.el (org-not-nil): New function.
* lisp/org.el (org-block-todo-from-children-or-siblings-or-parent):
Use `org-not-nil' to interpret a property value of nil.
Robert Goldman writes:
> I have found what I believe to be a bug in handling ordered subtasks.
> Here is the behavior:
>
> I have a top level set of tasks that is ordered.
>
> One of the outline items below the top level set is a grab bag of tasks
> that will be performed in parallel. So this task is NOT ordered
> (ORDERED: nil).
>
> The problem is that the blocking behavior from ordered tasks seems to be
> inherited from the top level task list into the second level of the
> outline, even though the ORDERED property at the second level is
> explicitly overridden.
>
> I am attaching an org file that displays this issue. To see the
> problem, put your cursor on the "Bar" task and attempt to change its
> status to DONE.
The problem was here that the value of the property is the string
"nil", which is of course not nil.
This patches introduces a special case to interpret "nil" as nil.
* lisp/babel/langs/ob-emacs-lisp.el
(org-babel-expand-body:emacs-lisp): removed extra call to
`org-babel-process-params' which was causing referenced code blocks
to be run multiple times
(org-babel-execute:emacs-lisp): now passing processed-params through
to `org-babel-expand-body:emacs-lisp' which keeps references from
being evaluated multiple times
* lisp/org-agenda.el (org-agenda-get-timestamps): No errors
while getting TODO state.
(org-agenda-highlight-todo): No error when no keyword has
been matched.
Eric Arneson writes:
> I've discovered a bug in `org-agenda-get-timestamps' wherein an active
> timestamp before the first headline causes it to fail. I realize that
> this is probably an error in my use of active timestamps, but there was
> no really handy error message and this bugged me for weeks.
>
> I'm not familiar enough with org-mode to know what the correct behavior
> should be here (it'd be nice to get an error message saying "Don't use
> active timestamps that way!"), but here's an example .org file that will
> trigger the bug:
>
> --8<---------------cut here---------------start------------->8---
> #+BEGIN: clocktable :maxlevel 3 :scope today
> Clock summary at [2010-06-20 Sun 13:09]
>
> | L | Headline | Time |
> |---+---------------------------------------+--------|
> | | *Total time* | *0:13* |
> |---+---------------------------------------+--------|
> | 1 | Track down funky bug <2010-06-20 Sun> | 0:13 |
> #+END:
>
> * Track down funky bug <2010-06-20 Sun>
> :LOGBOOK:
> CLOCK: [2010-06-20 Sun 12:43]
> CLOCK: [2010-06-20 Sun 12:30]--[2010-06-20 Sun 12:43] => 0:13
> :END:
> --8<---------------cut here---------------end--------------->8---
>
> I hope this can help somebody else track down the right place to fix
> this bug.
* lisp/babel/ob-exp.el (org-babel-exp-results): now checking to see if
return value of `org-babel-ref-literal' is equal to the null
indicator flag -- meaning it's now possible to accept a value of
null
* lisp/babel/ob-ref.el (org-babel-ref-parse): now checking to see if
return value of `org-babel-ref-literal' is equal to the null
indicator flag -- meaning it's now possible to accept a value of
null
(org-babel-ref-literal): now returning a null indicator flag when
the value is *not* a literal value, meaning it is possible to pass
in a literal value of null
Carsten Dominik <carsten.dominik@gmail.com> writes:
> 3 Why a new name?
> ~~~~~~~~~~~~~~~~~~
>
> I have - at least for now - chosen a new name for the new setup:
> ` org-capture'. There are two reasons for this:
In the manual it is "Capture - Refile - Archive". I remember searching
for "Remember" and never found it :)
> 5 Setup
> ~~~~~~~~
>
> To use the new setup, do the following:
>
> 1. Run
>
> M-x org-capture-import-remember-templates RET
Worked perfectly here :)
I tested all my important templates and they work.
Abandoning org-remember seems painless.
> '(("t" "templates adding table lines")
> ("ta" "add to table a" table-line (file+headline "~/notes.org" "Table A))
> ("tb" "add to table b" table-line (file+headline "~/notes.org" "Table B))
> ("tc" "add to table c" table-line (file+headline "~/notes.org" "Table C)))
>
> When starting capture, you can then first press "t" and then see
> the individual options.
This is great. Number of templates is constantly growing and the new
features will increase the speed of this process.
> 7 Request for comments
> ~~~~~~~~~~~~~~~~~~~~~~~
>
> None of what I describe is set in stone yet - let me know if you have
> comments, change requests or other ideas.
>
> My feeling right now is that this should become the default capture
> system, and that we will keep the current org-remember in the
> distribution for quite some time, for compatibility.
Good track I guess.
Here's the tested and working patch for org-protocol.el.
To use `org-remember' and/or `org-capture' alike, copy your org-remember
link and change
javascript:location.href='org-protocol://remember://'+...
to
javascript:location.href='org-protocol://capture://'+...
The template char used is the same for both --- which is OK for me, but
could be changed.
* lisp/org.el (org-timestamp-change): New optional argument UPDOWN.
Use this to identify calls from org-timestamp-up/down, so that we can
skip by rounding minutes in this case.
(org-timestamp-up):
(org-timestamp-down):
(org-timestamp-up-day):
(org-timestamp-down-day): Call org-timestamp-change with the
updown argument.
This function used to look only if there was a prefix argument in the
current interactive call. Now we have an explicit marker indicating
that the function is called from the updown commands.
Bernt Hansen writes:
> I was talking to Jeff Stern about tags todo matching offlist and we
> think the documentation for tags-todo matching can probably be improved.
>
> The description of C-c a M at
> http://orgmode.org/manual/Matching-tags-and-properties.html
> states
>
> C-c a M
>
> Like C-c a m, but only select headlines that are also TODO items 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 Tag searches.
>
> When I read this I think TODO items is any todo keyword but this isn't
> the case. It is only non-done TODO state keywords. This makes
> tags-todo matching not work for finding tasks to archive (normally
> DONE | CANCELLED keywords in my setup)
>
> Should we explicitly state that 'headlines that are also TODO items'
> does not match DONE state keywords? Or alternatively should TODO items
> and DONE items be separate (and explicitly defined) in the documentation
> -- like org-todo-keywords and org-done-keywords?
>
> I still think 'TODO keyword' matches any todo keyword defined in
> org-todo-keywords and maybe I need to be re-educated :)
Bernt is right, and this patch tries to clarify the issue.
* lisp/org-agenda.el (org-agenda-action): Make `c' key call org-capture.
* lisp/org-capture.el: New file.
* lisp/org-compat.el (org-get-x-clipboard): Function moved here from
remember.el.
* lisp/org-mks.el: New file
* lisp/org.el (org-set-regexps-and-options): Allow statistic cookies as
part of complex headlines.
(org-find-olp): New argument THIS-BUFFER. When set, assume that the
OLP does not contain a file name.
* lisp/org.el (org-mode): Set `comment-start' instead of changing the
syntax of the `#' character.
Leo writes:
> Setting a comment starter without a corresponding comment ender is
> problematic and the # creeps in mysteriously under auto-fill. For
> example, in my current running emacs, this happens almost certainly in
> all org files that has # in their header. The only (temporary) solution
> seems to reboot emacs (which is painful and disruptive).
>
> If you try eval (forward-comment 1) at the beginning of an org file that
> has some "#+..." it will move to the end of file (the whole file is
> regarded as one single comment). So when auto-fill a long text, it will
> find the common prefix to be #.
>
> In addition, I don't think org mode has clear comment syntax or ideas on
> what to do with it.
>
> I can't see any gain from (modify-syntax-entry ?# "<") so I am proposing
> removing it entirely and get rid of this mysterious and annoying bug
> once and for all.
>
> The attached patch may (though I think it is quite safe) cause some bugs
> but those will be fixable unlike the one mentioned above.
>
> Best wishes,
>
> Leo
* lisp/org-exp.el (org-export-format-source-code-or-example): Mark examples
by a property. o
* lisp/org-html.el (org-export-html-close-lists-maybe): Check if raw
HTML stuff was actually made from an example
Daniel Mahler writes:
> 2. I would like to embed source blocks in numbered lists, without
> breaking the numbering ie:
>
> 1) get ready
> #+BEGIN_SRC sh
> get_ready
> #+END_SRC
> 2) go
> #+BEGIN_SRC sh
> go
> #+END_SRC
>
> currently the src blocks cause the numbering to reset, so all
> items in a sequence like this are numbered 1
This patch fixes this issue - but I cannot say anymore why the code in
org-export-html-close-lists-maybe does in fact work. The code looks
wrong, but it seems to work. What looks wrong is that i does not
check for the true indentation in the case when the line is not
protected. It must be that this case is covered by some other code
further down in the exporter.
* lisp/babel/ob.el (org-babel-src-block-regexp):
ensure no whitespace in language names
(org-babel-inline-src-block-regexp):
ensure no whitespace in language names
- Removed the org-babel-tangle-langs variable.
- Added the org-babel-tangle-lang-exts alist for associating
languages with file extensions
- Comments now only added when the :comments header argument is set
to yes
* lisp/babel/ob-tangle.el (org-babel-tangle-w-comments):
this is now a defcustom
(org-babel-tangle-lang-exts): alist associating languages with file
extension, this is also a defcustom
(org-babel-spec-to-string): no longer using the complex tangle-lang
variables
