Re: [O] [OT] Scanning for archiving

[Pieter Praet]

On Sun, 6 Nov 2011 22:14:54 -0800, TP  wrote:
> On Sun, Nov 6, 2011 at 1:59 PM, Pieter Praet  wrote:
> > On Sat, 5 Nov 2011 16:35:11 -0700, Samuel Wales  
> > wrote:
> >> I used to find that 8-bit 75dpi was legible and small.
> >>
> >
> > True.
> >
> > It all depends on why you're scanning them in the first place.
> >
> > 75dpi is fine when scanning with collaboration/quick-reference in mind,
> > but for archival/backup purposes (i.e. absolute peace of mind when your
> > whole collection of dead trees burns, drowns, or is simply disposed of)
> > or OCR, you'll want to go with 600dpi and beyond.
> 
> One common technique is to always scan 300dpi grayscale (or color) and
> use clever software to upsample to 600dpi b&w (of course somehow
> segmenting scans into "picture" and "text" regions first.
> 

Upsampling defies the first law of thermodynamics?

But seriously, after reading up a bit, I'm convinced :)

Quite a manual process though...  Could you recommend any (FOSS)
software that does this automatically?

> >> What ADF scanners are out there for Linux that have high quality
> >> reliable ADF, [...]
> >
> > I wish I knew...  If anyone on this list can think of a scanner whose
> > ADF doesn't require constant babysitting, I'm betting it won't have a
> > consumer-grade price tag.
> 
> I've heard nice things about the Fujitsu ScanSnap S1500
> (http://www.fujitsu.com/global/services/computing/peripheral/scanners/product/s1500/)
> and S1500M 
> (http://www.fujitsu.com/global/services/computing/peripheral/scanners/product/s1500m/).
> About $450 or so from amazon. The S1300 is about half the price but
> also slower.
> 
> Apparently the S1500's are supported on Linux via Sane
> (http://www.sane-project.org/sane-backends.html#S-FUJITSU). Don't see
> any mention of the S1300 (but it probably also works?).
> 


Peace

-- 
Pieter

Re: [O] [OT] Scanning for archiving

[Pieter Praet]

On Mon, 7 Nov 2011 18:44:24 +0100, Karl Voit  wrote:
> Hi!
> 
> Inspired by «Total Recall»[3], a book of two MS Research guys, I
> started life logging on my own two months ago.
> 

Dammit, that's been on my reading list for almost 2 years now, and
*still* it isn't available in ebook format.  One would think they'd walk
their talk [1], no?

> [...]
> * Pieter Praet  wrote:
> >
> > Using PDF for scanned documents results in *huge* files with a seriously
> > disappointing image quality.  
> 
> I can not copy that at all:
> 
> ,
> | vk@gary ~2d % l 2011-11-02_13-22-45.png
> | -rw--- 1 vk vk 103150 2011-11-02 13:22 2011-11-02_13-22-45.png
> | vk@gary ~2d % convert 2011-11-02_13-22-45.png 2011-11-02_13-22-45.pdf
> | vk@gary ~2d % l 2011-11-02_13-22-45.pdf
> | -rw-r--r-- 1 vk vk 96457 2011-11-07 18:12 2011-11-02_13-22-45.pdf
> | vk@gary ~2d %
> `
> 
> In this example, the compression of PDF is much better than the
> original PNG one. PDF is only a container format.
> 

The conversion to PDF has indeed reduced the filesize, but not for the
reasons you might think: If you don't explicitly provide ImageMagick's
`convert' with a compression level (`-quality' option), it will use a
default of 75%.  Thus I (perhaps incorrectly) infer that you've just
lost 25% of the image quality for a meager 7% reduction in filesize.


I do admit that the whole quality vs. filesize statement I made
regarding using PDF for scanned documents wasn't entirely correct:
I cut some corners.

The real issue is that most folks use their scanner software to save
directly to PDF, and for some reason, scanner software (especially the
proprietary variety) predominantly uses JPEG compression as default when
saving to PDF.

JPEG was developed for storing images with smooth transitions and a high
bit depth (i.e. photographs), not hard transitions and a low bit depth
(i.e. documents), so you're likely to suffer a noticeable degradation in
text quality, even when using 1:1 JPEG compression.

You're using PNG compression though, so the whole JPEG deal doesn't apply.

So, that just leaves the neverending stream of PDF security issues :)

> > Consider storing your scans in DjVu format
> > [1], which was developed specifically for this purpose.
> 
> PDF is a common standard whereas DjVu is something I - as an
> advanced computer user - never faced before in real life. I am not
> sure whether any of my computers can handle DjVu files at all.
> 

How about the Million Book Project / Universal Digital Library [2] ?
Even though every computing device is most likely to support PDF, their
collection is only available in TIFF and DjVu format.

The list of participants and partners [3] (not to mention the magnitude
and cost of their undertaking) is reason enough (for me, at least) to
assume that DjVu is deemed to be rather future-proof.

I'm guessing ISO standardization will be only a matter of time.

> The goals of DjVu sound great but I get everything with PDF too.
> Although I like the idea of OGG Vorbis, I re-ripped all my CDs using
> mp3 again because I could not use many music devices or music
> management software packages.
> 

Ahhh, VHS vs. Betamax, over and over again...

Companies only succeed in getting everyone stuck with mediocre tools if
we allow them to.  You don't *need* all devices/software to support the
superior format.  Just get the ones that do (if there are any...), try
to enlighten the people in you monkeysphere [4], and then let the free
market do its work.  Joe Average Consumer will eventually follow (unless
pornography is at stake, apparently), and the industry will be right on
his tail.

> I stick to the format *any* computer can handle without special
> software products. [...]

Somehow this implies that *every* computer is infected with Adobe's
malware.  I find that rather disconcerting, to be honest :D

> [...] And I do think that I get a higher chance of
> being able to read my documents twenty years from now.
> 

For your sake, I hope you're right!

> For scanned images I'd prefer PNG instead but the OS X Software of
> my OfficeJet offers me the ability to generate PDF files where an
> OCR software adds a searchable text layer above the scanned text.
> This is *very* important to me since I am able to do full text
> search on the content of my archived documents.
> 

May be a bit less convenient in daily usage, but you could stick to your
preference of keeping all your scans in PNG format by keeping the OCR
output in a separate ASCII file:

  #+begin_src sh
for i in $(ls ${HOME}/msg/paper/inbox/*.png) ; do
tesseract ${i} ${i}.txt
done
  #+end_src

That way you can access your data even on text-only machines,
and full-text search is only a `grep' away.

&g

Re: [O] [OT] Scanning for archiving

[Pieter Praet]

On Sat, 5 Nov 2011 16:35:11 -0700, Samuel Wales  wrote:
> I used to find that 8-bit 75dpi was legible and small.
> 

True.

It all depends on why you're scanning them in the first place.

75dpi is fine when scanning with collaboration/quick-reference in mind,
but for archival/backup purposes (i.e. absolute peace of mind when your
whole collection of dead trees burns, drowns, or is simply disposed of)
or OCR, you'll want to go with 600dpi and beyond.

If using DjVu instead of PDF, the storage overhead will be negligible.

> What ADF scanners are out there for Linux that have high quality
> reliable ADF, [...]

I wish I knew...  If anyone on this list can think of a scanner whose
ADF doesn't require constant babysitting, I'm betting it won't have a
consumer-grade price tag.

> [...] are fast, [...]

Pretty much all of them, these days.

> and work well with CLI tools?
> 

As long as it's supported by SANE [1], rats are entirely optional.

> Is OCR at the point where it is feasible using CLI? [...]

Depends on how "fancy" the document layout is.  For most documents worth
scanning (let alone OCR'ing), it always has been.  Also see OCRopus [2].

> [...] Combining that
> with a new feature to have the Org agenda work with indexers (I
> participated in a discussion on that here a long while back) would be
> interesting.
> 

If you don't intend to create a perfect ASCII copy of the document, and
your index is restricted to word occurrence/frequency, it'll do just fine.

> On 2011-11-05, Pieter Praet  wrote:
> > NOTE: When attempting something like this, a fast scanner with a *reliable*
> > automatic document feeder will help prevent premature hair loss ;)
> 
> ...
> 
> > [1] http://djvu.org/resources/whatisdjvu.php
> > [2] http://gscan2pdf.sourceforge.net/


Peace

-- 
Pieter

[1] http://www.sane-project.org/sane-supported-devices.html
[2] http://code.google.com/p/ocropus/

Re: [O] [OT] Scanning for archiving

[Pieter Praet]

On Sat, 5 Nov 2011 14:03:24 -0600, Marcelo de Moraes Serpa 
 wrote:
> Hi list,
> 
> I just bought a scanner and started to scan important documents as a
> backup, and archiving them with meaningful metadata in orgmode files. Then
> a question came to mind - what dpi to use? I'm not really savvy when it
> comes to scanning or printing, and I want like a dpi that allows me to
> reprint the document at an acceptable quality later if necessary, but that
> also doesn't take that much space (600dpi pdfs take around 5MB).
> 
> Any insights welcome,
> 
> Thanks,
> 
> Marcelo.

Using PDF for scanned documents results in *huge* files with a seriously
disappointing image quality.  Consider storing your scans in DjVu format
[1], which was developed specifically for this purpose.

I scan all docs @ 600dpi, predominantly gray-scale (only in colour when
it's *really* necessary) and store in DjVu format, all using gscan2pdf [2].

Even at that seemingly overkill resolution, single-page documents are
generally (if they aren't too "grainy") only a few 100 KiB in size.

gscan2pdf also supports a number of OCR utils, but the UI for this is
clumsy (aren't they all...), so you're better off using the CLI tools
directly.  Tesseract is recommended.


I've used this approach to "convert" piles upon piles of old bank
statements to Ledger format, with very little effort.

NOTE: When attempting something like this, a fast scanner with a *reliable*
automatic document feeder will help prevent premature hair loss ;)


Peace

-- 
Pieter

[1] http://djvu.org/resources/whatisdjvu.php
[2] http://gscan2pdf.sourceforge.net/

Re: [O] [PATCH] org-crypt: when running org-decrypt-entry, only run auto-save-mode check if on an encrypted entry

[Pieter Praet]

On Sat, 8 Oct 2011 18:11:32 +0200, Carsten Dominik  
wrote:
> Accepted, thanks.

Thanks Carsten!


BTW, my FSF copyright assignment is completed (assignment number
#705083) so I should probably be added to the list of signees [1].
Would you like me to provide a patch to that effect?

> - Carsten
> 
> On 28.8.2011, at 15:46, Pieter Praet wrote:
> 
> > * 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).
> > 
> > Signed-off-by: Pieter Praet 
> > ---
> > 
> > lisp/org-crypt.el |   54 
> > +---
> > 1 files changed, 30 insertions(+), 24 deletions(-)
> > 
> > diff --git a/lisp/org-crypt.el b/lisp/org-crypt.el
> > index 5991192..f764404 100644
> > --- a/lisp/org-crypt.el
> > +++ b/lisp/org-crypt.el
> > @@ -116,6 +116,35 @@ nil  : Leave auto-save-mode enabled.
> >  (const :tag "Ask" ask)
> >  (const :tag "Encrypt" encrypt)))
> > 
> > +(defun org-crypt-check-auto-save ()
> > +  "Check whether auto-save-mode is enabled for the current buffer.
> > +
> > +`auto-save-mode' may cause leakage when decrypting entries, so
> > +check whether it's enabled, and decide what to do about it.
> > +
> > +See `org-crypt-disable-auto-save'."
> > +  (when buffer-auto-save-file-name
> > +(cond
> > + ((or
> > +   (eq org-crypt-disable-auto-save t)
> > +   (and
> > +   (eq org-crypt-disable-auto-save 'ask)
> > +   (y-or-n-p "org-decrypt: auto-save-mode may cause leakage. Disable it 
> > for current buffer? ")))
> > +  (message (concat "org-decrypt: Disabling auto-save-mode for " (or 
> > (buffer-file-name) (current-buffer
> > +  ; The argument to auto-save-mode has to be "-1", since
> > +  ; giving a "nil" argument toggles instead of disabling.
> > +  (auto-save-mode -1))
> > + ((eq org-crypt-disable-auto-save nil)
> > +  (message "org-decrypt: Decrypting entry with auto-save-mode enabled. 
> > This may cause leakage."))
> > + ((eq org-crypt-disable-auto-save 'encrypt)
> > +  (message "org-decrypt: Enabling re-encryption on auto-save.")
> > +  (add-hook 'auto-save-hook
> > +   (lambda ()
> > + (message "org-crypt: Re-encrypting all decrypted entries due 
> > to auto-save.")
> > + (org-encrypt-entries))
> > +   nil t))
> > + (t nil
> > +
> > (defun org-crypt-key-for-heading ()
> >   "Return the encryption key for the current heading."
> >   (save-excursion
> > @@ -164,30 +193,6 @@ nil  : Leave auto-save-mode enabled.
> > (defun org-decrypt-entry ()
> >   "Decrypt the content of the current headline."
> >   (interactive)
> > -
> > -  ; auto-save-mode may cause leakage, so check whether it's enabled.
> > -  (when buffer-auto-save-file-name
> > -(cond
> > - ((or
> > -   (eq org-crypt-disable-auto-save t)
> > -   (and
> > -(eq org-crypt-disable-auto-save 'ask)
> > -(y-or-n-p "org-decrypt: auto-save-mode may cause leakage. Disable 
> > it for current buffer? ")))
> > -  (message (concat "org-decrypt: Disabling auto-save-mode for " (or 
> > (buffer-file-name) (current-buffer
> > -  ; The argument to auto-save-mode has to be "-1", since
> > -  ; giving a "nil" argument toggles instead of disabling.
> > -  (auto-save-mode -1))
> > - ((eq org-crypt-disable-auto-save nil)
> > -  (message "org-decrypt: Decrypting entry with auto-save-mode enabled. 
> > This may cause leakage."))
> > - ((eq org-crypt-disable-auto-save 'encrypt)
> > -  (message "org-decrypt: Enabling re-encryption on auto-save.")
> > -  (add-hook 'auto-save-hook
> > -(lambda ()
> > -  (message "org-crypt: Re-encrypting all decrypted entries 
> > due to auto-save.")
> > -  (org-encrypt-entries))
> > -nil t))
> > - (t nil)))
> > -
> >   (require 'epg)
> >   (unless (org-before-first-heading-p)
> > (save-excursion
> > @@ -199,6 +204,7 @@ nil  : Leave auto-save-mode enabled.
> >(outline-invisible-p
> > (forward-line)
> > (when (looking-at "-BEGIN PGP MESSAGE-")
> > + (org-crypt-check-auto-save)
> >   (let* ((end (save-excursion
> > (search-forward "-END PGP MESSAGE-")
> > (forward-line)
> > -- 
> > 1.7.5.4
> > 
> > 
> 

Peace


-- 
Pieter

[1] http://orgmode.org/worg/org-contribute.html#contributors_with_fsf_papers

Re: [O] Problem with org-crypt

[Pieter Praet]

On Wed, 31 Aug 2011 12:04:52 +0200, Christopher Witte  
wrote:
> Hi all,
> 
> I've been using org-crypt and find it a great little addition to 
> org-mode, but I have been noticing some weird behaviour.  When I'm in a 
> file that has NO encrypted entires (or :crypt: tags) and I archive a sub 
> tree, I get asked the question "org-decrypt: auto-save-mode may cause 
> leakage. Disable it for current buffer?".  This must mean 
> org-decrypt-entry is being run but I don't understand why.  I've noticed 
> that org-decrypt-entry is added to the org-reveal-start-hook, I'm not 
> sure why that is.  When I don't add it to that hook, I no longer get 
> asked that question and org-crypt still apears to work as expected, but 
> I'm not sure if this will have broken something else.
> 
> Does anyone know why org-decrypt-entry is added to the 
> org-reveal-start-hook and if it would break anything if I don't add it?
> 
> Thanks for the help
> Chris.
> 

It's a known issue;  Patch available [1].

Bastien's AFK until the 5th, so won't be fixed in mainline before then.

Dropping the `add-hook' line is also a good temporary fix, won't break
anything, only prevents `org-reveal' (`C-c C-r') from decrypting entries.


Peace

-- 
Pieter


[1] id:"1314539207-15985-1-git-send-email-pie...@praet.org"

Re: [O] setting up org-remember

[Pieter Praet]

On Fri, 02 Sep 2011 06:12:22 +0200, David Maus  wrote:
Non-text part: multipart/signed
> At Tue, 30 Aug 2011 11:42:24 +0200,
> Renato wrote:
> >
> > On Mon, 29 Aug 2011 16:07:33 +0200
> > Renato  wrote:
> >
> > > Hello, I'm trying to set up org-remember, however I'm having some
> > > problems.
> >
> > I really didn't expect these multiple very detailed replies, thank you
> > very much guys! So it seems that (require 'org-remember) doesn't solve
> > the problem. I even tried doing M-x load-file
> > RET /usr/share/emacs/23.3/lisp/org/org-remember.el.gz but still I
> > there's no match for org-remember-insinuate.
> 
> Although you are going to upgrade locally to 7.x it could useful to
> check if there is a problem with the Org version shipped with Emacs
> 23.3 on Arch Linux.

Using the latest binary package (emacs-23.3.a-2-i686), running with -Q option:

M-x version
: GNU Emacs 23.3.1 (i686-pc-linux-gnu, GTK+ Version 2.24.5) of 2011-08-21 on 
ovide

M-x org-version
: Org-mode version 6.33x

M-x locate-library org-remember
: Library is file /usr/share/emacs/23.3/lisp/org/org-remember.elc

M-: (org-remember-insinuate)
: (org-remember-apply-template)


Calling `org-remember' pops up a *Remember* buffer, and `org-remember-finalize'
saves cleanly to "~/.notes" (which is the default value of 
`remember-data-file').


No errors, no weird behaviour, everything works as expected: not an Arch issue.

> What exactly do you mean with: "I seem to miss the function
> org-remember-insinuate (No Match)."? Does Emacs throw an error if you
> call `org-remember-insinuate'? Did you try it with emacs -Q to rule
> out a configuration issue (e.g. related to load-path)?
> 
> Best,
>   -- David
> --
> OpenPGP... 0x99ADB83B5A4478E6
> Jabber dmj...@jabber.org
> Email. dm...@ictsoc.de
Non-text part: application/pgp-signature


Peace

-- 
Pieter

Re: [O] setting up org-remember

[Pieter Praet]

On Mon, 29 Aug 2011 20:47:48 +0200, Renato  wrote:
> On Mon, 29 Aug 2011 16:13:22 +0200
> "Sebastien Vauban"  wrote:
> 
> > Hi Renato,
> > 
> > Renato wrote:
> > > Hello, I'm trying to set up org-remember, however I'm having some
> > > problems. I seem to miss the function org-remember-insinuate (No
> > > Match). However that function seems to be defined in
> > > org-remember.el.gz which is in /usr/share/emacs/23.3/lisp/org (and
> > > this path is in load-path). 
> > >
> > > should I post somewhere my .emacs?
> > >
> > > I'm on archlinux, emacs version 23.3.1 and the org-mode shipped
> > > with it (6.33)
> > 
> > If you can, try updating to Org 7.7 or something approaching.
> > Org-remember has been replaced by a very similar, but still different
> > set of variales/templates/etc., package called Org-capture.
> 
> yeah, I've seen it (going through the compact guide for 7.7 which
> treats org-capture). But since I saw -on the org manual I think- that
> upgrading from org-remember to org-capture is rather painless, I was
> hoping to be able to stick to the org shipped with emacs. Archlinux
> doesn't provide binaries for "standalone" org and compiling it myself
> would make future updates more cumbersome - though I'll indeed go that
> route if I can't solve this issue in the next few days.

Seriously?  Not being bolted down to stale software is one of the main
reasons why people run Arch in the first place :D.

There's PKGBUILDs for both the stable [1] as well as the dev [2] version
in the AUR.  Using one of the "AUR Helpers" [3] (Clyde [4] is my personal
favourite) makes keeping up to date only slightly more "cumbersome"
than running `pacman -Syu'.


Even better, while Org *can* be compiled (or rather byte-compiled),
you don't *have* to:

  #+begin_src sh
mdir -p ~/src
git clone git://orgmode.org/org-mode.git ~/src/org-mode
  #+end_src

and stuff this in your `.emacs':

   #+begin_src emacs-lisp
(add-to-list 'load-path "~/src/org-mode/lisp")
(add-to-list 'load-path "~/src/org-mode/contrib/lisp")
(require 'org-install)
  #+end_src

... and an occasional `cd ~/src/org-mode ; git pull' will be all you
need to stay on the cutting edge.


At the pace Org is evolving, running old code will surely cause you more
grief in the long run, so there's really no reason not to keep up to date.

> so, no idea on why I can't call org-remember-insinuate?

Sebastien covered this, but just in case, put this at the top of your `.emacs':

  #+begin_src emacs-lisp
(setq debug-on-error t)
  #+end_src

... which will provide you with a much more informative error message.

> cheers,
> renato
> 
> 


Peace

-- 
Pieter

[1] https://aur.archlinux.org/packages.php?ID=18206
[2] https://aur.archlinux.org/packages.php?ID=25234
[3] https://wiki.archlinux.org/index.php/AUR_Helpers
[4] https://wiki.archlinux.org/index.php/Clyde

Re: [O] [PATCH] Library of Babel source block

[Pieter Praet]

On Sun, 28 Aug 2011 07:11:36 -1000, t...@tsdye.com (Thomas S. Dye) wrote:
> [...]
> I tried to follow Bastien's suggestion about adding a change log to the
> commit message, but ended up with something that looks different than
> his example.  I'm not sure why--perhaps Bastien is not working in magit,
> so his instructions apply to some other context?
> [...]

Bastien was referring to `add-change-log-entry{,-other-window}', which is
part of Emacs [1], and is mainly intended to add entries to a dedicated
ChangeLog file (when this file isn't present, it'll open a new buffer
for the entry).  While it *does* most definitely produce properly formatted
entries when called with point on a diff hunk, it always requires the extra
step of yanking the entry into your commit message buffer.


When using Magit (which I highly recommend) however, you can add properly
formatted entries *much* faster by positioning point on a (staged) diff
hunk in the status buffer, and calling `magit-add-log' (bound to 'C') [2].

If you don't already have a commit buffer ('*magit-edit-log*'), it will
create one for you, so you don't even need to call `magit-log-edit'
(bound to 'c') in advance anymore. :)


Peace

-- 
Pieter

[1] [[info:emacs#Change Log]]
[2] [[info:magit#Staging and Committing]]

[O] [PATCH] org-crypt: when running org-decrypt-entry, only run auto-save-mode check if on an encrypted entry

[Pieter Praet]

* 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).

Signed-off-by: Pieter Praet 
---

 lisp/org-crypt.el |   54 +---
 1 files changed, 30 insertions(+), 24 deletions(-)

diff --git a/lisp/org-crypt.el b/lisp/org-crypt.el
index 5991192..f764404 100644
--- a/lisp/org-crypt.el
+++ b/lisp/org-crypt.el
@@ -116,6 +116,35 @@ nil  : Leave auto-save-mode enabled.
  (const :tag "Ask" ask)
  (const :tag "Encrypt" encrypt)))
 
+(defun org-crypt-check-auto-save ()
+  "Check whether auto-save-mode is enabled for the current buffer.
+
+`auto-save-mode' may cause leakage when decrypting entries, so
+check whether it's enabled, and decide what to do about it.
+
+See `org-crypt-disable-auto-save'."
+  (when buffer-auto-save-file-name
+(cond
+ ((or
+   (eq org-crypt-disable-auto-save t)
+   (and
+   (eq org-crypt-disable-auto-save 'ask)
+   (y-or-n-p "org-decrypt: auto-save-mode may cause leakage. Disable it 
for current buffer? ")))
+  (message (concat "org-decrypt: Disabling auto-save-mode for " (or 
(buffer-file-name) (current-buffer
+  ; The argument to auto-save-mode has to be "-1", since
+  ; giving a "nil" argument toggles instead of disabling.
+  (auto-save-mode -1))
+ ((eq org-crypt-disable-auto-save nil)
+  (message "org-decrypt: Decrypting entry with auto-save-mode enabled. 
This may cause leakage."))
+ ((eq org-crypt-disable-auto-save 'encrypt)
+  (message "org-decrypt: Enabling re-encryption on auto-save.")
+  (add-hook 'auto-save-hook
+   (lambda ()
+ (message "org-crypt: Re-encrypting all decrypted entries due 
to auto-save.")
+ (org-encrypt-entries))
+   nil t))
+ (t nil
+
 (defun org-crypt-key-for-heading ()
   "Return the encryption key for the current heading."
   (save-excursion
@@ -164,30 +193,6 @@ nil  : Leave auto-save-mode enabled.
 (defun org-decrypt-entry ()
   "Decrypt the content of the current headline."
   (interactive)
-
-  ; auto-save-mode may cause leakage, so check whether it's enabled.
-  (when buffer-auto-save-file-name
-(cond
- ((or
-   (eq org-crypt-disable-auto-save t)
-   (and
-(eq org-crypt-disable-auto-save 'ask)
-(y-or-n-p "org-decrypt: auto-save-mode may cause leakage. Disable it 
for current buffer? ")))
-  (message (concat "org-decrypt: Disabling auto-save-mode for " (or 
(buffer-file-name) (current-buffer
-  ; The argument to auto-save-mode has to be "-1", since
-  ; giving a "nil" argument toggles instead of disabling.
-  (auto-save-mode -1))
- ((eq org-crypt-disable-auto-save nil)
-  (message "org-decrypt: Decrypting entry with auto-save-mode enabled. 
This may cause leakage."))
- ((eq org-crypt-disable-auto-save 'encrypt)
-  (message "org-decrypt: Enabling re-encryption on auto-save.")
-  (add-hook 'auto-save-hook
-(lambda ()
-  (message "org-crypt: Re-encrypting all decrypted entries due 
to auto-save.")
-  (org-encrypt-entries))
-nil t))
- (t nil)))
-
   (require 'epg)
   (unless (org-before-first-heading-p)
 (save-excursion
@@ -199,6 +204,7 @@ nil  : Leave auto-save-mode enabled.
   (outline-invisible-p
(forward-line)
(when (looking-at "-BEGIN PGP MESSAGE-")
+ (org-crypt-check-auto-save)
  (let* ((end (save-excursion
(search-forward "-END PGP MESSAGE-")
(forward-line)
-- 
1.7.5.4

Re: [O] disable "org-decrypt: auto-save-mode may cause leakage"

[Pieter Praet]

On Sun, 28 Aug 2011 09:02:58 +0200, Achim Gratz  wrote:
> Pieter Praet  writes:
> > Apparently not config-related.
> 
> So it does happen with just "emacs -Q"?  I cannot reproduce this.

Well, not quite... :) Some minimal config is required.

1. Run EMACS like this:
   (don't forget to adjust the load-path)

   #+begin_src sh
 emacs -Q --eval="(progn
 (setq debug-on-error t)
 (add-to-list 'load-path \"~/src/org-mode/lisp\")
 (require 'org-install)
 (require 'org-crypt)
 (org-crypt-use-before-save-magic))"
   #+end_src

2. Open the ECM (in att) and complete the TODO's in sequence.


When running `org-clock-goto', the user will be prompted:
: org-decrypt: auto-save-mode may cause leakage. Disable it for current buffer? 
(y or n)
... which is rather uncalled for in this context.


I we'd be calling an error @ lisp/org-crypt.el::170, we'd get the following
backtrace upon running `org-clock-goto':

#+begin_example
  Debugger entered--Lisp error: (error "blah")
signal(error ("blah"))
error("blah")
(progn (error "blah") (cond (... ... ...) (... ...) (... ... ...) (t nil)))
(if buffer-auto-save-file-name (progn (error "blah") (cond ... ... ... 
...)))
(when buffer-auto-save-file-name (error "blah") (cond (... ... ...) (... 
...) (... ... ...) (t nil)))
org-decrypt-entry()
run-hooks(org-reveal-start-hook)
org-reveal()
(let* ((recent nil) (m ...)) (org-pop-to-buffer-same-window (marker-buffer 
m)) (if (or ... ...) (widen)) (goto-char m) (org-show-entry) 
(org-back-to-heading t) (org-cycle-hide-drawers (quote children)) (recenter) 
(org-reveal) (if recent (message "No running clock, this is the most recently 
clocked task")) (run-hooks (quote org-clock-goto-hook)))
org-clock-goto(nil)
call-interactively(org-clock-goto nil nil)
#+end_example


So, either org-crypt shouldn't be imposing itself on `org-reveal-start-hook'
(see lisp/org-crypt.el::250) XOR `org-clock-goto' shouldn't call `org-reveal'.
I'll let others decide...


Peace


> Regards,
> Achim.
> -- 
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
> 
> Wavetables for the Waldorf Blofeld:
> http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
> 
> 

Peace

-- 
Pieter

* NOTE here's an encrypted entry (symmetric, pass = "test")  :crypt:
-BEGIN PGP MESSAGE-
Version: GnuPG v1.4.10 (GNU/Linux)

jA0ECgMCBqqZSbotsitg0nwBKep+l0L85gNUFsipCPc6Nn/VKiRoZrbBU37f0+7w
yTBvfSXMpBKc+D8TZ4ZoIPwqNwc52TZA4phh5VQIs5T96PAXYH6yAQIBbG7ggMWV
4zrU6NiHU/dCCznsbObQXGkMg1tVU1Kp6A9EapGBklh24mcrwhG3BZQcqzN2
=uLcl
-END PGP MESSAGE-

* TODO run `org-clock-in' (`C-c C-x C-i') here

* TODO run `org-clock-goto' (`C-c C-x C-j') here

Re: [O] disable "org-decrypt: auto-save-mode may cause leakage"

[Pieter Praet]

On Tue, 19 Jul 2011 01:12:23 +0200, Bastien  wrote:
> Hi Sébastien,
> 
> "Sebastien Vauban"  writes:
> 
> > I simply call C-c C-x C-j to jump to the current clocking entry, and the
> > question "org-decrypt: auto-save-mode may cause leakage. Disable it for
> > current buffer? (y or n)" pops up -- while the current buffer has nothing
> > special, as said above.
>
> Weird.
> 
> Maybe you have some hook in `org-clock-goto-hook' that makes Org visit
> some buffer containing encrypted entries?

Apparently not config-related.

I don't use org-clock.el (and as such don't have any org-clock related
config, `org-clock-goto-hook' is nil), but due to a recent freak
accident involving spastic typing, I've managed to trigger the issue.
Apologies for dismissing it earlier, Sebastien.

`org-clock-goto' erroneously causes `org-decrypt-entry' to be called,
though it's not immediately obvious how or why this would happen.

Maybe Carsten (being listed as sole author for org-clock.el) can provide
some insight?

> -- 
>  Bastien
> 

Peace

-- 
Pieter

Re: [O] Merge org-7.7 into emacs

[Pieter Praet]

On Mon, 15 Aug 2011 16:39:44 +0200, Bastien  wrote:
> Hi Memnon,
> 
> Memnon Anon  writes:
> 
> >http://permalink.gmane.org/gmane.emacs.devel/142944
> >
> > I don't know anything about this, but maybe something can be said/done
> > about it while Bastien enjoys his vacation?
> 
> Thanks for the heads-up -- I just answered to Glenn and fixed the more
> obvious problems.  I'm now waiting Achim's and Pieter's answers about
> their copyright status wrt FSF.
> 
> Best,
> 
> -- 
>  Bastien
> 

Apologies for being so late to the party.  The weather was/is simply too good :)

I've submitted the assignment form request a few days ago, but have yet
to receive confirmation of any sort or form.

Will keep you posted.


Peace

-- 
Pieter

Re: [O] How can I bypass the agenda dispatcher and call a custom block agenda directly?

[Pieter Praet]

On Sat, 27 Aug 2011 13:45:26 + (UTC), Marcus Klemm 
 wrote:
> Bernt Hansen  norang.ca> writes:
> 
> 
> > Certainly this is doable
> > 
> > (org-agenda t "a")
> > 
> > Just bind this to the key of your choice and substitute "a" with the
> > agenda you want to run.
> 
> Doesn't work for me. I get:
> 
> recursive-edit: Wrong type argument: commandp, (org-agenda t "A")
> 
> 

That's because you need to wrap it in a lambda function.

This should work:

#+begin_src emacs-lisp
  (global-set-key (kbd " a") '(lambda ()
 (interactive)
 (org-agenda t "a")))
#+end_src


Peace

-- 
Pieter

Re: [O] how to change the headline starter *

[Pieter Praet]

On Fri, 15 Jul 2011 12:21:01 +0200, Philipp Haselwarter 
 wrote:
> No need to go all flaming because someone thinks the looks of the
> software matter. TBH I don't see what's wrong with that or in what way
> that's the opposite of efficiency.

What I considered "wrong" about it was the OP implying -twice- that a
frivolous feature request such as this could be marked as being a
full-caps "BUG" [1,2].

Considering all the time and effort Org-mode's selfless developers have
sacrificed to deliver this mindblowing piece of software to us, this
could easily be perceived as an insult in my opinion, regardless of
whether or not it was intentional.

I know that this doesn't justify the tone of my impulsive reply in any
way whatsoever, and I do apologize for disrupting the serene atmosphere
which characterizes this list, but... I sent it, and I stand behind it 100%.

Besides, how could someone who cares about how slick and shiny their
software looks *possibly* end up using Emacs?

> Abstracting the user interface from the logic is an important paradigm,
> especially for something like org-mode that you want to run on a wide
> range of devices – think 24" monitors vs 3" mobile devices. You don't
> want to have too much of the looks hardcoded.

Exactly! That is, believe it or not, the whole point.

What the OP is suggesting effectively nullifies the separation between
model and view in that it would allow changing Org-mode's outlining
markup at its very core, potentially leading to a wildgrowth of "custom"
markup formats which could hardly be called "plain text" anymore, not to
mention the avalanche of PEBCAK-related bug reports it may unleash.

> Now if you don't find that to be one of /your/ personal top priorities –
> fine, don't bother. But going all bashing because someone insists on his
> opinion that this is important? I don't see what you're trying to
> achieve here.

Pretty much since the very beginning, Org-mode has been described as:
  "Org is a mode for keeping notes, maintaining TODO lists, and doing
  project planning with a fast and effective plain-text system."

Seeing as how this description hasn't changed ever since, one can safely
assume that keeping the markup format sane (i.e. plain-text) and
consistent (i.e. semi-standardized, so as not to complicate joint
project planning) is a top priority for the entire Org-mode community.

As for my personal priorities: I didn't start using Emacs solely because
Org-mode *requires* me to, but because I care about getting my work done,
as efficiently as possible. Mac/Windows-influenced non-features (and
the code overhead they introduce) will undoubtedly interfere with that.

IOW, a lack of certain "features" is an essential feature in and of itself.

I guess what I'm trying to achieve is to keep Org-mode from slowly and
inconspicuously devolving into something featuring transparent blinking
3D unicorn overlays with cherries on top. That's a gross exaggeration of
course (one would hope), but I'm sure you catch my drift.

> 
> -- 
> Philipp Haselwarter
> 
> 


Peace

-- 
Pieter

[1] 
id:"101625.2577651310651584384.javamail.r...@zimbra29-e5.priv.proxad.net"
[2] 
id:"1240511841.2591431310664738370.javamail.r...@zimbra29-e5.priv.proxad.net"

Re: [O] how to change the headline starter *

[Pieter Praet]

On Thu, 14 Jul 2011 19:32:18 +0200 (CEST), har...@free.fr wrote:
> 
> > b...@altern.org writes:
> >
> > har...@free.fr writes:
> > 
> > > (setq outline-regexp "[-\f]+")
> > > so as to use - as the headline starter character in outline mode.
> > > Switch to another buffer, enter the text
> > >
> > > - first heading
> > > -- second heading
> > >some stuff here
> > >
> > > Activate org-mode. M-x org-mode.
> > 
> > You should not do this.  org-mode lists start with a "-", using
> > this character for headlines will just confuse things.
> 
> Let me rephrase my message then.
> 
> BUG. How to reproduce.
> Starting with emacs -Q (this is emacs 23.2 together with org-mode 6.33),
> execute in the scratch buffer
> (setq outline-regexp "[•\f]+")
> so as to use a bullet as the headline starter character in outline mode.
> Switch to another buffer, enter the text
> 
> • first heading
> •• second heading
>some stuff here
> 
> Activate org-mode. M-x org-mode.
> 
> Then go to the first heading. TAB folds the text as expected.
> Go to the second heading. TAB inserts a TAB instead of folding
> the second heading.
> 
> > Can't you live with the "*" as the headline character?
> 
> That's a pretty rude answer, I must say. I don't know a single
> language (language as e.g. english, russian, spanish...) that
> uses * as an headline character. BTW, I know that bugs should be
> reported through the bug tracker, I will do that asap, and
> no, I don't have a patch, I don't understand how org-mode
> works.
> 
> -- 
> Harven
> 


Harven,

One of Org-mode's fundamental goals is to help people make more
*efficient* (sorry, •efficient•) use of their time. Screwing around
with utterly useless vanity config ("I wanna make it look COOL")
is the exact opposite.


Please don't *insult* our devs by calling this useless BS a "BUG",
let alone ask them to *waste* their precious time and skills on it.


If you manage to implement it yourself, you're welcome to send your
patch to the list. We might need it someday, when we -in a bout of
insanity- decide our target audience somehow includes twelve-year-olds.


If you find that rude, don't worry:

If our product or the technical support pertaining to it proves
unsatisfactory in any way, you're entitled to a full refund.

Just send your proof of purchase to one of our sales reps near you.

You still have the receipt don't you?


Peace

-- 
Pieter

Re: [O] disable "org-decrypt: auto-save-mode may cause leakage"

[Pieter Praet]

On Thu, 14 Jul 2011 16:42:58 +0200, "Sebastien Vauban" 
 wrote:
> Hi Pieter,
> 
> Pieter Praet wrote:
> > On Thu, 14 Jul 2011 15:37:34 +0200, "Sebastien Vauban" 
> >  wrote:
> >> Juan Pechiar wrote:
> >> > On Thu, Jul 14, 2011 at 02:22:32PM +0200, Karl Voit wrote:
> >> >> How can I auto-answer the question from the subject line with «n»
> >> >> (per default) any time it is asked?
> >> >
> >> > You can customize this behaviour via
> >> >
> >> > org-crypt-disable-auto-save
> >> >
> >> > You probably have it set to 'ask'.
> >> 
> >> So did I. This is the default.
> >> 
> >> > Options exist for always enabling/disabling auto save, and for encrypting
> >> > the auto-saved version automatically.
> >> >
> >> > M-x customize-variable RET org-crypt-disable-auto-save RET
> >> 
> >> Shouldn't its default value better be set to 'encrypt?
> >
> > I don't think so.
> >
> > It only re-encrypts entries which are tagged :crypt: (or whatever you
> > have `org-crypt-tag-matcher' set to), so I'd prefer users to be "forced"
> > to at least read the docstring so as not to be using it with a false
> > sense of security.
> >
> > Though this could be easily solved by automatically tagging entries upon
> > encryption, I think it's more "considerate" to simply (ask to) disable
> > `auto-save-mode' for the current buffer, as it's quite annoying to have
> > an entry get re-encrypted while you're in the middle of typing something.
> 
> This is more clear to me, and makes a lot of sense.
> 
> Though, what I find annoying, and the OP as well, is to be asked that question
> for buffers which do not contain any encrypted entry. Would it be possible to
> scan the buffer for such entries, and only ask the user when the buffer is
> potentially exposed?

AFAIK, that should already be the case.


Even when running with the following config...

  #+BEGIN_SRC emacs-lisp
(add-hook 'find-file-hook 'org-decrypt-entries)
  #+END_SRC

... the user shouldn't get prompted needlessly, because `org-decrypt-entries'
applies `org-decrypt-entry' (which does the `auto-save-mode' check) *only*
to entries with a tag matching `org-crypt-tag-matcher' [1].

So prompting should only occur for buffers for which `auto-save-mode' is
enabled AND which contain one or more entries tagged with `crypt'
(regardless of whether the entry is actually encrypted, but that's
beside the point) UNLESS running `org-decrypt-entry' (auto-)manually for
each buffer.


I suspect it's a user config issue.

> Best regards,
>   Seb
> 
> -- 
> Sebastien Vauban
> 
> 


Peace

-- 
Pieter

[1] lisp/org-crypt.el:241

Re: [O] disable "org-decrypt: auto-save-mode may cause leakage"

[Pieter Praet]

On Thu, 14 Jul 2011 15:37:34 +0200, "Sebastien Vauban" 
 wrote:
> Hi all,
> 
> Juan Pechiar wrote:
> > On Thu, Jul 14, 2011 at 02:22:32PM +0200, Karl Voit wrote:
> >> How can I auto-answer the question from the subject line with «n»
> >> (per default) any time it is asked?
> >
> > You can customize this behaviour via
> >
> > org-crypt-disable-auto-save
> >
> > You probably have it set to 'ask'.
> 
> So did I. This is the default.
> 
> > Options exist for always enabling/disabling auto save, and for encrypting
> > the auto-saved version automatically.
> >
> > M-x customize-variable RET org-crypt-disable-auto-save RET
> 
> Shouldn't its default value better be set to 'encrypt?

I don't think so.

It only re-encrypts entries which are tagged :crypt: (or whatever you
have `org-crypt-tag-matcher' set to), so I'd prefer users to be "forced"
to at least read the docstring so as not to be using it with a false
sense of security.

Though this could be easily solved by automatically tagging entries upon
encryption, I think it's more "considerate" to simply (ask to) disable
`auto-save-mode' for the current buffer, as it's quite annoying to have
an entry get re-encrypted while you're in the middle of typing something.


> Best regards,
>   Seb
> 
> -- 
> Sebastien Vauban
> 
> 


Peace

-- 
Pieter

Re: [O] Using MobileOrg without sync?

[Pieter Praet]

On Wed, 13 Jul 2011 11:22:53 +0200, Steinar Bang  wrote:
> > Tassilo Horn :
> 
> > Not sure, but MobileOrg (at least on Android) is not very
> > sophisticated for note taking.  For sure, it's not a stand-alone
> > org-mode for Android as you might have expected.
> 
> Ah, ok.  It looked like it might be, from the screen shots.
> 
> > For example, there's no widget ("activity" in andro-speak) to input
> > timestamps and stuff like that.  I use it, but mainly for viewing my
> > agendas pushed from org-mode and for capturing quick and ugly notes,
> > which I format correctly, timestamp, tag, and refile after pulling
> > them to my emacs.
> 
> Ok.  Looks like something I will try at some point in time, but not
> right now.
> 
> > So I see no reason to use MobileOrg if you don't want to interact with
> > org-mode.  Probably, you'd be better off with a plain text editor (Jota
> > Text Editor is quite good and free software).
> 
> Thanks for the tip!
> 
> So far, I have installed, but not yet tried:
>  Evernote
>   http://gizmodo.com/5427595/evernote-the-android-note-app-you-need-is-here
> 
>  AK Notepad
>   https://market.android.com/details?id=com.akproduction.notepad
> 
>  GDocs (notepad synking with google docs)
>   http://sites.google.com/site/gdocsforandroid/

Also a good candidate:
- http://code.google.com/p/android-shuffle/


Peace

-- 
Pieter

Re: [O] OLUG talk about Org-mode

[Pieter Praet]

On Thu, 14 Jul 2011 03:45:04 + (UTC), Memnon Anon 
 wrote:
> Hi Jonathan,
> 
> Jonathan Leech-Pepin  writes:
> 
> > The direct link to the video on the UStream site is:
> > http://ustream.vo.llnwd.net/pd15/0/1/15/15820/15820239/1_365053_15820239.flv
> 
> If I understood Pieter Praet correctly, this did not work for him:
> 
> ,[ Message ID: <878vsa2msg@praet.org>]
> | I've tried the obvious one [1] but no joy. It's a waste of 225,6 MiB.
> | ...
> | [1] 
> http://ustream.vo.llnwd.net/pd15/0/1/15/15820/15820239/1_365053_15820239.mp4
> `[Archived-At: http://permalink.gmane.org/gmane.emacs.orgmode/43844]

Well, it might work if you're logged in, but since I loathe registering
(yet another account I'll *never* use), I simply snatched that URL out
of the page source, and ended up with a (presumably) DRM-protected file.

> This did work for me:
> 
> ,[ Sebastien Vauban: Message-ID: <804o2qtvbd@somewhere.org> ]
> | http://www.mygooglest.com/sva/OLUG_Meeting_July_2011.flv
> | Please download it, as this link may become unavailable in the future.
> `[Archived-At: http://permalink.gmane.org/gmane.emacs.orgmode/44175]

Indeed it does.

> Memnon
> 
> 


Peace

-- 
Pieter

Re: [O] disable "org-decrypt: auto-save-mode may cause leakage"

[Pieter Praet]

On Thu, 14 Jul 2011 14:22:32 +0200, Karl Voit  wrote:
> Hi!
> 
> How can I auto-answer the question from the subject line with «n»
> (per default) any time it is asked?
> 
> Background story:
> 
> I am using org-decrypt on two files and I've got additional files
> where I do not use any encryption at all.
> 
> But when I start my Emacs with my five most used org-files (which do
> not use encryption), I have to answer five times the question
> mentioned in the subject line above using «n» as answer.
> 
> I've already found the comment on the bottom of [1] and the
> discussion of [2].
> 
> I *do* have deactivated auto-save by using the method explained in
> [3] for my Org-files where I am using encryption. So I am save here
> I guess.
> 
> But what I want to get rid of is this unnecessary question. I do not
> want to be asked and have to answer with «no» because where it
> matters, I already deactivated auto-save. So auto-save should be
> «on» per default.
> 
> How can I accomplish this behavior?
> 
> And: shouldn't this be appended to [1]?
> 
>   1. http://orgmode.org/worg/org-tutorials/encrypting-files.html
>   2. http://permalink.gmane.org/gmane.emacs.orgmode/43262
>   3. http://anirudhs.chaosnet.org/blog/2005.01.21.html
> -- 
> Karl Voit
> 
> 

One only receives that prompt when running `org-decrypt-entry' in a buffer
where `buffer-auto-save-file-name' is non-nil (i.e. a buffer for which
`auto-save-mode' is enabled).

So, I assume you've configured Emacs to automatically run `org-decrypt-entries'
(which calls `org-decrypt-entry') whenever an org file is opened.

For more info, see the `org-crypt-disable-auto-save' variable (introduced in
commit 7bae2235) and this thread:
- http://comments.gmane.org/gmane.emacs.orgmode/41430


Peace

-- 
Pieter

Re: [O] OLUG talk about Org-mode

[Pieter Praet]

On Thu, 07 Jul 2011 15:05:33 +0200, Bastien  wrote:
> Carsten Dominik  writes:
> 
> > http://www.olug.org/2011/06/july-2011-olug-meeting/
> 
> The video is now here:
> 
>   http://www.ustream.tv/recorded/15820239
> 
> Nice chilling out atmosphere!
> 
> It would be great to have the slides (pdf?).

Can someone provide a working download link ?

All that Flash+JS+ads stuff provokes lunch ejection.

I've tried the obvious one [1] but no joy. It's a waste of 225,6 MiB.

Slides would be much appreciated as well.

> 
> -- 
>  Bastien
> 


Peace

-- 
Pieter

[1] http://ustream.vo.llnwd.net/pd15/0/1/15/15820/15820239/1_365053_15820239.mp4

Re: [O] make install-info broken in debian

[Pieter Praet]

On Thu, 30 Jun 2011 05:16:23 -0400 (EDT), Jude DaShiell 
 wrote:
> I don't know how to fix this one.
> 
> Script started on Thu 30 Jun 2011 05:11:30 AM EDT
> root@md:/home/jude/src/org-mode# make install-info-debian
> install-info --infodir=/usr/local/share/info doc/org
> This is not dpkg install-info anymore, but GNU install-info
> [...]

dpkg install-info <--> GNU install-info

Quick fix = downgrade install-info package?


Peace

-- 
Pieter

Re: [O] Changing the font family in HTML export

[Pieter Praet]

On Tue, 28 Jun 2011 11:18:58 +0200, Pieter Praet  wrote:
> On Tue, 28 Jun 2011 11:00:43 +0200, Dror Atariah  wrote:
> > This solved the problem. However, as you pointed out, in case I want to 
> > publish/share this generated html, I have to send as well another file, and 
> > it is not longer self contained. In the automatically, generated html, 
> > there is a section at the beginning:
> > --==--
> > 

Re: [O] Changing the font family in HTML export

[Pieter Praet]

On Tue, 28 Jun 2011 11:00:43 +0200, Dror Atariah  wrote:
> This solved the problem. However, as you pointed out, in case I want to 
> publish/share this generated html, I have to send as well another file, and 
> it is not longer self contained. In the automatically, generated html, there 
> is a section at the beginning:
> --==--
> 

[O] [PATCH] org-crypt: make org-decrypt disable auto-save-mode (configurable)

[Pieter Praet]

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'

Signed-off-by: Pieter Praet 
---
 lisp/org-crypt.el |   60 +---
 1 files changed, 47 insertions(+), 13 deletions(-)

diff --git a/lisp/org-crypt.el b/lisp/org-crypt.el
index 4bff7a1..1ff24b9 100644
--- a/lisp/org-crypt.el
+++ b/lisp/org-crypt.el
@@ -94,6 +94,29 @@ This setting can also be overridden in the CRYPTKEY 
property."
   :type 'string 
   :group 'org-crypt)
 
+(defcustom org-crypt-disable-auto-save 'ask
+  "What org-decrypt should do if `auto-save-mode' is enabled.
+
+t: Disable auto-save-mode for the current buffer
+   prior to decrypting an entry.
+
+nil  : Leave auto-save-mode enabled.
+   This may cause data to be written to disk unencrypted!
+
+'ask : Ask user whether or not to disable auto-save-mode
+   for the current buffer.
+
+'encrypt : Leave auto-save-mode enabled for the current buffer,
+   but automatically re-encrypt all decrypted entries
+   *before* auto-saving.
+   NOTE: This only works for entries which have a tag
+   that matches `org-crypt-tag-matcher'."
+  :group 'org-crypt
+  :type '(choice (const :tag "Always"  t)
+ (const :tag "Never"   nil)
+ (const :tag "Ask" ask)
+ (const :tag "Encrypt" encrypt)))
+
 (defun org-crypt-key-for-heading ()
   "Return the encryption key for the current heading."
   (save-excursion
@@ -142,6 +165,30 @@ This setting can also be overridden in the CRYPTKEY 
property."
 (defun org-decrypt-entry ()
   "Decrypt the content of the current headline."
   (interactive)
+
+  ; auto-save-mode may cause leakage, so check whether it's enabled.
+  (when buffer-auto-save-file-name
+(cond
+ ((or
+   (eq org-crypt-disable-auto-save t)
+   (and
+(eq org-crypt-disable-auto-save 'ask)
+(y-or-n-p "org-decrypt: auto-save-mode may cause leakage. Disable it 
for current buffer? ")))
+  (message (concat "org-decrypt: Disabling auto-save-mode for " (or 
(buffer-file-name) (current-buffer
+  ; The argument to auto-save-mode has to be "-1", since
+  ; giving a "nil" argument toggles instead of disabling.
+  (auto-save-mode -1))
+ ((eq org-crypt-disable-auto-save nil)
+  (message "org-decrypt: Decrypting entry with auto-save-mode enabled. 
This may cause leakage."))
+ ((eq org-crypt-disable-auto-save 'encrypt)
+  (message "org-decrypt: Enabling re-encryption on auto-save.")
+  (add-hook 'auto-save-hook
+(lambda ()
+  (message "org-crypt: Re-encrypting all decrypted entries due 
to auto-save.")
+  (org-encrypt-entries))
+nil t))
+ (t nil)))
+
   (require 'epg)
   (unless (org-before-first-heading-p)
 (save-excursion
@@ -201,19 +248,6 @@ This setting can also be overridden in the CRYPTKEY 
property."
'org-mode-hook
(lambda () (add-hook 'before-save-hook 'org-encrypt-entries nil t
 
-;; FIXME Find a better way to encrypt Org auto-saved buffers?
-;; When `auto-save-default' is non-nil, make sure entries are
-;; encrypted before auto-saving
-;; (when auto-save-default
-;;(add-hook
-;; 'org-mode-hook
-;; (lambda () (add-hook 'auto-save-hook 'org-encrypt-entries nil t
-
-(when (and (functionp 'daemonp)
-  (not (daemonp)) auto-save-default)
-  (message "Warning: turn auto-save-mode off in Org buffers containing crypted 
entries.")
-  (sit-for 1))
-
 (add-hook 'org-reveal-start-hook 'org-decrypt-entry)
 
 (provide 'org-crypt)
-- 
1.7.4.1

Re: [O] [PATCH] org-crypt: only warn about auto-save-mode when running org-decrypt

[Pieter Praet]

On Mon, 27 Jun 2011 18:31:58 +0200, Bastien  wrote:
> Hi Pieter,
> 
> Thanks for the patch at the end of this thread.
> 
> Pieter Praet  writes:
> 
> > Ideally, we'd have a defcustom `org-crypt-auto-save' with the following 
> > options:
> > - 'ask : Ask the user whether or not to decrypt the entry.
> > - 'disable : Disable auto-save-mode for the current buffer before 
> > decrypting.
> > - 'ignore  : Decrypt the entry regardless.
> > - 'encrypt : Re-encrypt the entries before auto-save kicks in.
> >
> > I've implemented this, but it fails miserably:
> >
> > Since the function `auto-save-mode' doesn't set an buffer-local
> > var to indicate whether or not it's enabled for the current buffer, we
> > can only check for `auto-save-default'. 
> 
> I think we should first ask emacs-devel to fix this, then implement your
> clean solution.  Would you like to report this problem?

No need. It appears I'm a veritable moron, with apologies to the Emacs folks.

2 lessons I've learned today:
- DON'T test this stuff in a *scratch* buffer (seriously...)
- DO consume sufficient quantities of coffee (IOW, org-encrypt-entries
  doesn't encrypt entries unless they're *tagged* to be)

> I'm not confident in disabling auto-save-mode globally by default, this
> would surprise users -- even with a **BiG WaRnInG** message.

No worries, it's buffer-local.

And I've now changed the default to "ask first, shoot in the foot later".

> What do you think?

"I should send my patch" comes to mind :)

Traffic allowing (lots of sweaty tourists on the road),
it should be there in T-10sec.

> -- 
>  Bastien


Peace

-- 
Pieter

[O] [PATCH] org-crypt: make org-decrypt disable auto-save-mode (configurable)

[Pieter Praet]

Signed-off-by: Pieter Praet 
---
This is appears to be the only solution that doesn't cause
the production of inordinate amounts of cortisol.

I've also added a warning re the broken state of `auto-save-hook'.


 lisp/org-crypt.el |   36 
 1 files changed, 32 insertions(+), 4 deletions(-)

diff --git a/lisp/org-crypt.el b/lisp/org-crypt.el
index 4bff7a1..0a0ce96 100644
--- a/lisp/org-crypt.el
+++ b/lisp/org-crypt.el
@@ -94,6 +94,15 @@ This setting can also be overridden in the CRYPTKEY 
property."
   :type 'string 
   :group 'org-crypt)
 
+(defcustom org-crypt-disable-auto-save t
+  "What org-decrypt should do if `auto-save-default' is enabled.
+
+t: Disable it for the current buffer prior to decrypting an entry.
+nil  : Leave it enabled."
+  :group 'org-crypt
+  :type '(choice (const :tag "Always" t)
+ (const :tag "Never" nil)))
+
 (defun org-crypt-key-for-heading ()
   "Return the encryption key for the current heading."
   (save-excursion
@@ -142,6 +151,24 @@ This setting can also be overridden in the CRYPTKEY 
property."
 (defun org-decrypt-entry ()
   "Decrypt the content of the current headline."
   (interactive)
+
+  ; auto-save-mode causes leakage, so check whether it's enabled.
+  (when auto-save-default
+; Ideally, we'd check whether it's enabled for the current buffer,
+; using the buffer-local variable `auto-save-mode', but the
+; `auto-save-mode' function doesn't set this, so we have to check
+; the global variable `auto-save-default' instead.
+; Consequently, the following will run regardless of whether
+; `auto-save-mode' is enabled for the current buffer, spamming the
+; *Messages* buffer.
+(if (eq org-crypt-disable-auto-save t)
+(progn
+  (message "org-decrypt: Disabling auto-save-mode for current buffer 
to prevent leakage.")
+  ; The argument to auto-save-mode has to be "-1", since
+  ; giving a "nil" argument toggles instead of disabling.
+  (auto-save-mode -1))
+  (message "org-decrypt: WARNING! auto-save-mode is enabled globally. This 
may cause leakage.")))
+
   (require 'epg)
   (unless (org-before-first-heading-p)
 (save-excursion
@@ -204,15 +231,16 @@ This setting can also be overridden in the CRYPTKEY 
property."
 ;; FIXME Find a better way to encrypt Org auto-saved buffers?
 ;; When `auto-save-default' is non-nil, make sure entries are
 ;; encrypted before auto-saving
+;; NOTE: auto-save-hook does NOT work, so don't rely on it!
 ;; (when auto-save-default
 ;;(add-hook
 ;; 'org-mode-hook
 ;; (lambda () (add-hook 'auto-save-hook 'org-encrypt-entries nil t
 
-(when (and (functionp 'daemonp)
-  (not (daemonp)) auto-save-default)
-  (message "Warning: turn auto-save-mode off in Org buffers containing crypted 
entries.")
-  (sit-for 1))
+;; (when (and (functionp 'daemonp)
+;;(not (daemonp)) auto-save-default)
+;;   (message "Warning: turn auto-save-mode off in Org buffers containing 
crypted entries.")
+;;   (sit-for 1))
 
 (add-hook 'org-reveal-start-hook 'org-decrypt-entry)
 
-- 
1.7.4.1

Re: [O] [PATCH] org-crypt: only warn about auto-save-mode when running org-decrypt

[Pieter Praet]

On Fri, 24 Jun 2011 17:50:04 -0400, Nick Dokos  wrote:
> Pieter Praet  wrote:
> 
> > As auto-save-mode can only cause leakage after org-decrypt has been run,
> > there's no need to check for it (and potentially cause annoyance) so early.
> > 
> > Unfortunately, auto-save-mode doesn't set a buffer-local var to indicate
> > whether it's enabled for the current buffer (checking
> > `buffer-auto-save-file-name' has proven to be unreliable), so we can
> > only check whether it's enabled globally, using `auto-save-default'.
> > 
> 
> That's very nice, but I think you can go one step further: Why not turn
> auto-save-mode off for the buffer when org-decrypt is called?  With a
> warning that says so and says why, of course.

Ideally, we'd have a defcustom `org-crypt-auto-save' with the following options:
- 'ask : Ask the user whether or not to decrypt the entry.
- 'disable : Disable auto-save-mode for the current buffer before decrypting.
- 'ignore  : Decrypt the entry regardless.
- 'encrypt : Re-encrypt the entries before auto-save kicks in.

I've implemented this, but it fails miserably:

Since the function `auto-save-mode' doesn't set an buffer-local
var to indicate whether or not it's enabled for the current buffer, we
can only check for `auto-save-default'. This poses the following problems:

- 'ask will be a serious whiner, prompting the user for each and every
  entry being decrypted, whether or not `auto-save-mode' is enabled for
  the current buffer.
- 'disable will cause (perhaps minor) performance issues, since it will
  try disabling `auto-save-mode' for each and every entry being decrypted,
  even though it may already be disabled for the current buffer.
  If (as per your suggestion) emitting a warning, this will also spam the
  *Message* buffer to no end.

Also, 'encrypt will simply not work, due to `auto-save-hook' not being
called when it's supposed to.


BTW: For those of us running `org-decrypt-entry' with a wrapper function,
do remember one has to call (auto-save-mode -1) instead of (auto-save-mode nil),
since the latter will *toggle* instead of *disable* !

> Nick
> 
> > Signed-off-by: Pieter Praet 
> > ---
> >  lisp/org-crypt.el |   14 +-
> >  1 files changed, 9 insertions(+), 5 deletions(-)
> > 
> > diff --git a/lisp/org-crypt.el b/lisp/org-crypt.el
> > index 4bff7a1..f4c0b8e 100644
> > --- a/lisp/org-crypt.el
> > +++ b/lisp/org-crypt.el
> > @@ -142,6 +142,10 @@ This setting can also be overridden in the CRYPTKEY 
> > property."
> >  (defun org-decrypt-entry ()
> >"Decrypt the content of the current headline."
> >(interactive)
> > +  (when
> > +  (or
> > +   (not auto-save-default)
> > +   (yes-or-no-p "WARNING: auto-save-mode is enabled globally. This may 
> > cause leakage. Continue? "))
> >(require 'epg)
> >(unless (org-before-first-heading-p)
> >  (save-excursion
> > @@ -179,7 +183,7 @@ This setting can also be overridden in the CRYPTKEY 
> > property."
> > (when heading-was-invisible-p
> >   (goto-char heading-point)
> >   (org-flag-subtree t))
> > -   nil))
> > +   nil)))
> >  
> >  (defun org-encrypt-entries ()
> >"Encrypt all top-level entries in the current buffer."
> > @@ -209,10 +213,10 @@ This setting can also be overridden in the CRYPTKEY 
> > property."
> >  ;; 'org-mode-hook
> >  ;; (lambda () (add-hook 'auto-save-hook 'org-encrypt-entries nil t
> >  
> > -(when (and (functionp 'daemonp)
> > -  (not (daemonp)) auto-save-default)
> > -  (message "Warning: turn auto-save-mode off in Org buffers containing 
> > crypted entries.")
> > -  (sit-for 1))
> > +;; (when (and (functionp 'daemonp)
> > +;;(not (daemonp)) auto-save-default)
> > +;;   (message "Warning: turn auto-save-mode off in Org buffers containing 
> > crypted entries.")
> > +;;   (sit-for 1))
> >  
> >  (add-hook 'org-reveal-start-hook 'org-decrypt-entry)
> >  
> > -- 
> > 1.7.4.1
> > 
> > 

Peace

-- 
Pieter

[O] [PATCH] org-crypt: only warn about auto-save-mode when running org-decrypt

[Pieter Praet]

As auto-save-mode can only cause leakage after org-decrypt has been run,
there's no need to check for it (and potentially cause annoyance) so early.

Unfortunately, auto-save-mode doesn't set a buffer-local var to indicate
whether it's enabled for the current buffer (checking
`buffer-auto-save-file-name' has proven to be unreliable), so we can
only check whether it's enabled globally, using `auto-save-default'.

Signed-off-by: Pieter Praet 
---
 lisp/org-crypt.el |   14 +-
 1 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/lisp/org-crypt.el b/lisp/org-crypt.el
index 4bff7a1..f4c0b8e 100644
--- a/lisp/org-crypt.el
+++ b/lisp/org-crypt.el
@@ -142,6 +142,10 @@ This setting can also be overridden in the CRYPTKEY 
property."
 (defun org-decrypt-entry ()
   "Decrypt the content of the current headline."
   (interactive)
+  (when
+  (or
+   (not auto-save-default)
+   (yes-or-no-p "WARNING: auto-save-mode is enabled globally. This may 
cause leakage. Continue? "))
   (require 'epg)
   (unless (org-before-first-heading-p)
 (save-excursion
@@ -179,7 +183,7 @@ This setting can also be overridden in the CRYPTKEY 
property."
(when heading-was-invisible-p
  (goto-char heading-point)
  (org-flag-subtree t))
-   nil))
+   nil)))
 
 (defun org-encrypt-entries ()
   "Encrypt all top-level entries in the current buffer."
@@ -209,10 +213,10 @@ This setting can also be overridden in the CRYPTKEY 
property."
 ;; 'org-mode-hook
 ;; (lambda () (add-hook 'auto-save-hook 'org-encrypt-entries nil t
 
-(when (and (functionp 'daemonp)
-  (not (daemonp)) auto-save-default)
-  (message "Warning: turn auto-save-mode off in Org buffers containing crypted 
entries.")
-  (sit-for 1))
+;; (when (and (functionp 'daemonp)
+;;(not (daemonp)) auto-save-default)
+;;   (message "Warning: turn auto-save-mode off in Org buffers containing 
crypted entries.")
+;;   (sit-for 1))
 
 (add-hook 'org-reveal-start-hook 'org-decrypt-entry)
 
-- 
1.7.4.1

Re: [O] git useage question

[Pieter Praet]

On Sat, 4 Jun 2011 19:26:54 -0400 (EDT), Jude DaShiell 
 wrote:
> 1) so we understand each other.  My complaint has nothing to do with 
>org-mode's documentation and everything to do with the documentation 
>for git itself. [...]

Oh, I see :D

So your query should have been directed to the git mailing list [1],
but I admit that whether it would've garnered any useful responses is
rather doubtful.


Assuming you have no prior experience with distributed version control,
the following should be a very clear and concise introduction:
- http://eagain.net/articles/git-for-computer-scientists/
- http://hoth.entp.com/output/git_for_designers.html
- http://www-cs-students.stanford.edu/~blynn/gitmagic/


It's really worth the effort, as it'll pay back in no time.

Very soon you'll wonder how you've ever been able to work without it ;)


> [...] On Sun, 5 Jun 2011, Pieter Praet wrote:
> 
> > On Sat, 4 Jun 2011 18:05:47 -0400 (EDT), Jude DaShiell 
> >  wrote:
> > > I wouldn't be writing this if the documentation were reasonable.  Once 
> > > org-mode gets cloned, how is git properly used to update the cloned 
> > > instance on a machine?
> > 
> > I wouldn't be writing this if your comment were reasonable.
> > 
> > 
> > The following should be more than sufficient:
> >   - http://orgmode.org/manual/Installation.html#Installation
> >   - http://orgmode.org/worg/org-faq.html#Keeping-current
> > 
> > 
> > In the *highly unlikely* case that it isn't:
> >   You're probably already aware of this (though this awareness may be
> >   temporarily impeded due to Saturday night related inebriation), but
> >   it's worth noting that Org-mode's documentation documents Org-mode.
> > 
> >   Org-mode != git, otherwise it would be called git instead of Org-mode, 
> > see?
> > 
> >   Kindly refer to some relevant (and extremely abundant) documentation:
> >   - http://git-scm.com/documentation
> > 
> > 
> > Peace
> > 
> > 
> 
> 


Peace


[1] http://dir.gmane.org/gmane.comp.version-control.git

-- 
Pieter

Re: [O] git useage question

[Pieter Praet]

On Sat, 4 Jun 2011 18:05:47 -0400 (EDT), Jude DaShiell 
 wrote:
> I wouldn't be writing this if the documentation were reasonable.  Once 
> org-mode gets cloned, how is git properly used to update the cloned 
> instance on a machine?

I wouldn't be writing this if your comment were reasonable.


The following should be more than sufficient:
  - http://orgmode.org/manual/Installation.html#Installation
  - http://orgmode.org/worg/org-faq.html#Keeping-current


In the *highly unlikely* case that it isn't:
  You're probably already aware of this (though this awareness may be
  temporarily impeded due to Saturday night related inebriation), but
  it's worth noting that Org-mode's documentation documents Org-mode.

  Org-mode != git, otherwise it would be called git instead of Org-mode, see?

  Kindly refer to some relevant (and extremely abundant) documentation:
  - http://git-scm.com/documentation


Peace

-- 
Pieter

Re: [O] [OT] Deactivate flyspell on a file by file basis

[Pieter Praet]

On Fri, 03 Jun 2011 11:18:54 -0400, Nick Dokos  wrote:
> Marcelo de Moraes Serpa  wrote:
> 
> 
> > I use flyspell-mode for writing articles, but I don't need it for my 
> > gtd.org file. Is there a way to
> > exclude it (flyspell) from acting based on the filename of the buffer?
> > 
> 
> You can use file local variables for things like this. There is an
> ``eval'' pseudo-variable to allow you to execute code. See the emacs
> manual for details, but it would look something like this (untested and
> you have to put it at the end of the file):
> 
> ...
> # Local Variables:
> # eval: (flyspell-mode 0)
> # End:

Although this can get rather annoying due to
enable-local-variables related popups.


I use something similar to this:

(add-hook 'find-file-hook
  (lambda ()
(or (member (buffer-file-name)
'("/path/to/some/file"
  "/path/to/other/file"))
(flyspell-mode 1

> Nick
> 

Peace

-- 
Pieter

Re: [O] [OT] Deactivate flyspell on a file by file basis

[Pieter Praet]

On Fri, 03 Jun 2011 17:44:26 +0200, Pieter Praet  wrote:
> On Fri, 03 Jun 2011 11:18:54 -0400, Nick Dokos  wrote:
> > Marcelo de Moraes Serpa  wrote:
> > 
> > 
> > > I use flyspell-mode for writing articles, but I don't need it for my 
> > > gtd.org file. Is there a way to
> > > exclude it (flyspell) from acting based on the filename of the buffer?
> > > 
> > 
> > You can use file local variables for things like this. There is an
> > ``eval'' pseudo-variable to allow you to execute code. See the emacs
> > manual for details, but it would look something like this (untested and
> > you have to put it at the end of the file):
> > 
> > ...
> > # Local Variables:
> > # eval: (flyspell-mode 0)
> > # End:
> 
> Although this can get rather annoying due to
> enable-local-variables related popups.

s/enable-local-variables/enable-local-eval

... though enable-local-variables applies as well.

Sorry for the noise.

> 
> I use something similar to this:
> 
> (add-hook 'find-file-hook
>   (lambda ()
> (or (member (buffer-file-name)
> '("/path/to/some/file"
>   "/path/to/other/file"))
> (flyspell-mode 1
> 
> > Nick
> > 
> 
> Peace
> 
> -- 
> Pieter

Peace

-- 
Pieter

Re: [O] Headlines and visual-line-mode

[Pieter Praet]

On Thu, 12 May 2011 03:58:07 -0400, Ethan  wrote:
> [Please CC me!]
> 
> Hi,
> 
> I have a text-mode-hook that turns on visual-line-mode, which means it's on
> in all org files.  Generally I like visual-line-mode and would like it to be
> on in my org-mode buffers, but I'm seeing a bug involving the wrapping of
> headlines.  Specifically, because tags are placed at the right side of the
> frame, and because collapsed headlines are followed by "...", the tags at
> the end of the headline are wrapped, even if the headline is short.  So
> instead of:
> 
> * Music
> :music:...
> 
> I see
> 
> * Music
> :music:...
> 
> Do other people encounter this problem?  The only information I could find
> about org and visual-line-mode was about "clean mode", which I'm not using.

Have you looked at the actual function docstring?

(describe-function 'visual-line-mode)
  Redefine simple editing commands to act on visual lines, not logical lines.
  This also turns on `word-wrap' in the buffer.

Specifically that line about word-wrap should ring a bell.

> I'm using emacs 23.2.1 and Org-mode version 7.5 (release_7.5.204.g7327b)
> from git.
> 
> Thanks!
> 
> Ethan
Non-text part: text/html

Peace

-- 
Pieter