* contrib/lisp/org-wikinodes.el: New file.
* lisp/org-exp.el (org-export-preprocess-after-radio-targets-hook):
(org-export-define-heading-targets-headline-hook): New hooks.
* lisp/org.el (org-modules): Add entry for org-wikinodes.el.
(org-font-lock-set-keywords-hook): New hook.
(org-open-at-point-functions): New hook.
(org-find-exact-headling-in-buffer):
(org-find-exact-heading-in-directory): New functions.
(org-mode-flyspell-verify): Better cursor position for checking if
flyspell should ignore a word.
* lisp/org.el (org-link-search-must-match-exact-headline): New option.
(org-link-search-inhibit-query): New variable.
(org-link-search): Search for exact headline match in Org files
* doc/org.texi (Internal links): Document the changes in internal links.
Internal links used to do a fuzzy text search for the link text. This
patch changes the behavior for Org files. Here a link [[My Target]]
now searches for an exact headline match, i.e. for a headline that
does look like "* My Target", optionally with TODO keyword, priority
cookie and tags.
The new option `org-link-search-must-match-exact-headline' is
`query-to-create' by default. This means that a failed link search
will offer to create the headline as a top-level headline at the end
of the buffer. This corresponds to a wiki-like behavior where missing
targets are automatically created. If you do not like this behavior,
change the option to t.
This parameter default to 140 and controls the resolution of images
created from LaTeX fragments for HTML output. There is no :resolution
parameter: the resolution of images produced for a buffer is computed
from the font height.)
This was suggested by Uriel (amscopub-mail@yahoo.com).
From: Alexandre Passos <alexandre.tp@gmail.com>
> I was editing an org document on a server earlier today, remotely
> using tramp, and continuously exporting it to html. When I added
> LaTeX, it exported once and then not anymore, failing because it
> couldn't create a directory anymore. So I found out that patching
> org-export-latex to pass a "t" parameter to org-make-directory fixes
> this, and it continues to work perfectly. This is the modified version
> of that function, if anyone else is interested in this constrained
> case. The only change I made was right under the "make sure directory
> exists" comment.
Hello,
Like what is already done with drawers, point should not move when
cycling visibility of headings and list items.
The call to `org-back-to-heading' this patch removes seems redundant
anyways.
Regards,
-- Nicolas
>From 17cd55557d747366c90fad47b44edeac2daf920b Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou <n.goaziou@gmail.com>
Date: Sun, 25 Jul 2010 23:14:08 +0200
Subject: [PATCH] Cursor stays at same column when cycling visibility.
* org.el (org-cycle-internal-local): Removed an unnecessary call to
`org-back-to-heading' that was preventing point to stay at its
column when cycling visibility.
* lisp/org.el (org-insert-time-stamp): Fix org-insert-time-stamp so
that the value of org-last-inserted-timestamp includes time range.
Previously, org-last-inserted-timestamp included only the
beginning of a time range (e.g., 10:00 instead of 10:00-12:00).
This caused parsing problems elsewhere, such as when rescheduling
items with repeating timestamps and a time range (the repeater
was removed during rescheduling).
This is the eighth patch in a series that makes some straightforward
corrections to a number of docstrings. Each change is normally to:
- correct a typo, or
- fix up hyperlinks to function or variable names, or
- ensure slightly better conformance with the documentation guidelines
and tips given in the Elisp manual
* lisp/ob-ref.el (org-babel-ref-resolve-reference): removed an error
introduced while fixing compiler warnings -- required mirroring of
the count cl-seqs function under the org-mode namespace.
* lisp/org.el (org-count): adding an org-mode version of the cl-seqs
count function
* lisp/org-list.el (org-list-send-list): Parse list from its true beginning.
* lisp/org.el (org-ctrl-c-ctrl-c): Maybe send the list when at a list item.
* doc/org.texi (Radio lists): Fix bug in description of radio lists.
* lisp/org.el (org-insert-link): Correctly determine if we should use
a relative path.
Aidan Gauland writes:
> If I create a link with C-c C-l and give it a relative "file:" link, a
> link is created with an absolute path. For example, C-c C-l
> file:../foo.org <RET> foo puts
> [[file:~/path/to/working-directory/foo.org][foo]] in the buffer. I was
> expecting [[file:../foo.org][foo]].
For some reason ob-R refuses to compile when it requires ob-comint.
When (require 'ob-comint) is not included in ob-R.el everything
compiles without error, but warnings are thrown because the
arguments to a macro defined in ob-comint are mis-interpreted as
functions.
When (require 'ob-comint) is added to ob-R.el then it throws errors
complaining that the last argument to a function is nil and should
be a string. I don't understand this error at all and can't fix it.
* lisp/org.el (org-babel-load-languages): this variable controls which
languages will be loaded by org-babel. It is customizable through
the customize interface.
(org-babel-do-load-languages): load those languages in
org-babel-load-languages and disable those with nil cdr's
* lisp/babel/ob.el (org-confirm-babel-evaluate): variable used to
control evaluation of code blocks, default value it t, meaning all
code block evaluation requires confirmation
(org-babel-confirm-evaluate): function used to request confirmation
of code block evaluation from the user
(org-babel-execute-src-block): this function is the single point of
entry for evaluation of code blocks (whether initiated through lob
call, through direct code block evaluation, or as part of file
exportation). Every time this function is called it will now
request confirmation from the user. The newly added
`org-confirm-babel-evaluate' variable can be used to configure this
behavior.
(org-babel-no-eval-on-ctrl-c-ctrl-c): This variable can be used to
inhibit evaluation of code blocks with C-c C-c.
* lisp/org.el (org-ctrl-c-ctrl-c): added documentation of code block
evaluation behavior
* lisp/babel/ob-keys.el (org-babel-key-bindings): adding keybindings
for executing code blocks and for opening their results
* lisp/org.el (org-entry-get-with-inheritance): New argument LITERAL-NIL.
(org-entry-get): Pass `literal-nil' into
`org-entry-get-with-inheritance'.
(org-todo): React to nil values of the LOGGING property.
* lisp/org.el (org-switchb): Renamed from `org-iswitchb'. Improve
docstring.
(org-iswitchb): New alias.
(org-ido-switchb): Make alias point to `org-switchb'.
* lisp/org.el (org-time-string-to-absolute): Ignore cyclic repeater
when displaying items on todays agenda date.
Ignore the cyclic repeater when displaying items on today's agenda
date. If you have a weekly task and miss the date the agenda view
will show more than a week late now instead of resetting on the
cyclic repeating date. This makes it much more obvious when you
missed a repeating task after the repeater.
* 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-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
