* org-crypt.el (org-encrypt-string, org-encrypt-entry)
(org-decrypt-entry): Fix warning.
TINYCHANGE
epg-context is let-bounded in org-crypt and then epg local set it in
this context. It should just be set as local var instead of being let
bounded.
See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15081
* ox.el (org-export-stack-mode)
* org-crypt.el (org-crypt-check-auto-save)
(org-crypt-use-before-save-magic): Use `org-add-hook' when the
hooks are local hooks.
* org-indent.el (org-indent-mode)
* org-agenda.el (org-agenda-mode): Use `org-add-hook' and
merge upstream change from Emacs revno r112320.
* org-capture.el (org-capture-finalize): Maybe re-encrypt
the target headline if it was decrypted.
(org-capture-set-target-location): Maybe decrypt the target
headline.
* org-crypt.el (org-at-encrypted-entry-p): New function.
Thanks to Guilherme Gondim for suggesting this.
lisp/org.el (org-scan-tags): Require todo-only argument, and document
that it should be the same one set by make-org-tags-matcher.
Fix documentation to explain that todo-only is really
not-done-todo-only.
(org-make-tags-matcher): If todo part of matcher starts with /!,
matcher now always checks that the TODO keyword is present and
is a not-done state. This matters e.g. for org-map-entries
which unlike org-scan-tags does not do its own separate todo-only
filtering. Added docs to explain matcher dependencies.
(org-map-entries): Make sure todo-only is correctly passed from
org-make-tags-matcher to org-scan-tags.
* lisp/org-clock.el: (org-clock-get-table-data): Make sure todo-only
does not leak when it is set by make-org-tags-macher.
* lisp/org-crypt.el: (org-encrypt-entries, org-decrypt-entries): Make
sure todo-only is correctly passed from org-make-tags-matcher to
org-scan-tags.
* contrib/lisp/contacts.el: (org-contacts-filter) : Make sure todo-only
is correctly passed from org-make-tags-matcher to org-scan-tags.
I started from the 78ec8e commit then cherry-picked and squashed
commits that have been done in master since then, except the bad
commits that overwrote the tree (in master) with the tree in maint.
This commit also bumps the version number to 7.8.06.
The only "fix" that was made between 78ec8e and the previous commit
is e0072f which has been reported to break stuff.
This fixes a wrong merge that should not have happened:
commit 7e903a merges the master branch into the maint branch,
while we really want to keep the maint branch a bugfix-only
branch.
This commit reverts back the maint branch to its state before
merging the master branch. From there, we will fix remaining
problems with the maint branch (e.g. copyright issues) then
release this maint branch as Org-mode 7.8.05.
* lisp/org-crypt.el (org-crypt-check-auto-save): New function, see next change.
* lisp/org-crypt.el (org-decrypt-entry): Break the auto-save-mode check out
into a separate function, and call it at a later point, to assure it only
runs when visiting an encrypted entry.
Currently `org-decrypt-entry' is doing the auto-save-mode check whenever
it's run, regardless of context, while this only makes sense when run on
an entry which is actually encrypted (or looks like it, at least).
TINYCHANGE
Also remove blank lines before the ";;; org*el ends here" declarations.
Having a "Version" header forced us to update every file when releasing a
new version of Org; it also forced us to update every file when merging Org
with Emacs trunk, thus cluttering the diffs between the previously merged
version and the new one with useless information.
Glenn Morris suggested this in emacs-devel:
http://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00322.html
As auto-save-mode can only cause leakage when there's actual decrypted
data lying around, don't check for it (and potentially cause annoyance)
on init, but only when org-decrypt-entry is called.
* lisp/org-crypt.el:
- add defcustom `org-crypt-disable-auto-save'
- `org-decrypt-entry': before decrypting, check whether
`auto-save-mode' is enabled for the current buffer, and act
on it according to how `org-crypt-disable-auto-save' is set.
- remove comment re "encrypt[ing] Org auto-saved buffers"
- remove on-init check for `auto-save-default'
* lisp/org-crypt.el (org-encrypt-string): New function.
(org-encrypt-entry): Use org-encrypt-string to encrypt, so we use cached
crypted values.
(org-decrypt-entry): Store crypted text in decrypted text.
Signed-off-by: Julien Danjou <julien@danjou.info>
* org-crypt.el (org-decrypt-entry): Delete \n on top level heading.
This avoids a display bug showing the heading outlined where the text
is not since it does not have the outline property.
Restore subtree visibility state after decryption.
Cc: John Wiegley <johnw@gnu.org>
Cc: Peter Jones <pjones@pmade.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
I just found a left over in org-list.el. :)
Updated patch attached.
>From bf6c65a42e04d4753c58795442a479685bb5f318 Mon Sep 17 00:00:00 2001
From: Julien Danjou <julien@danjou.info>
Date: Wed, 26 Jan 2011 11:14:11 +0100
Subject: [PATCH] org: remove org-invisible-p
* org.el: Remove org-invisible-p: outline-invisible-p is
available in Emacs 22 and in recent XEmacs 21. Replace in
various files.
Signed-off-by: Julien Danjou <julien@danjou.info>
This patch 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
No attempt is made to provide missing docstrings or document arguments.
Cheers,
Phil
Patch by Peter Jones, following a bug report by Xiao-Jong Jin, who wrote:
> If you have the follow org file
>
> * test crypt :crypt:
> ** subheading 1
> text 1
> ** subheading 2
> text 2
>
> with setup as
>
> (require 'org-crypt)
> (setq org-tags-exclude-from-inheritance '("crypt"))
> (setq org-crypt-key "CBC0714E") ; my key
>
> On calling org-encrypt-entry on the first head line, only
> subheading 1 get encrypted, subheading 2 remains plain text.
> But, if you add an empty line or some text under the first
> heading, both subheading 1 and 2 are encrypted.