Re: [O] Incorrect hexification in URLs in LaTeX Export

[David Maus]

Followup: There has been a discussion about hex-escaping last year
with some back-and-forth on the topic of link escaping:

http://thread.gmane.org/gmane.emacs.orgmode/74983/focus=75002

It's quite a muddy area.

Best,
  -- David

At Sun, 25 May 2014 09:09:50 +0200,
David Maus wrote:
> 
> Hi all,
> 
> At Sun, 25 May 2014 07:56:15 +0200,
> Bastien wrote:
> > 
> > Hi Michael,
> > 
> > "R. Michael Weylandt "
> >  writes:
> > 
> > > TLDR: remove ?\= from org-link-escape-chars.
> > 
> > Done (in master.)
> > 
> > I'm copying David since he's the author of this commit:
> > http://orgmode.org/w/?p=org-mode.git;a=commitdiff;h=1a68b6
> > 
> > David, sorry to jump in, but are there any reason why the
> > characters + ; and = where escaped in this commit?
> > 
> 
> I think the only reason was that these characters already had been
> escaped in `org-link-escape-chars'.
> 
> The commit removed the special rules for the letters with
> diacritics. The previous commit (0c4bb0e) introduced an algorithm that
> covered non-ASCII characters in general, thus special rules for
> letters with diacritics where no longer necessary.
> 
> I can only speculate why they were escaped in the first place: + ; and
> = do have special meaning in HTTP URIs and IIRC Org did not draw a
> strict distinction between escaping for internal purposes and escaping
> of HTTP URIs.
> 
> Best,
>   -- David
> 
> > Thanks in advance,
> > 
> > -- 
> >  Bastien

Re: [O] Incorrect hexification in URLs in LaTeX Export

[David Maus]

Hi all,

At Sun, 25 May 2014 07:56:15 +0200,
Bastien wrote:
> 
> Hi Michael,
> 
> "R. Michael Weylandt "
>  writes:
> 
> > TLDR: remove ?\= from org-link-escape-chars.
> 
> Done (in master.)
> 
> I'm copying David since he's the author of this commit:
> http://orgmode.org/w/?p=org-mode.git;a=commitdiff;h=1a68b6
> 
> David, sorry to jump in, but are there any reason why the
> characters + ; and = where escaped in this commit?
> 

I think the only reason was that these characters already had been
escaped in `org-link-escape-chars'.

The commit removed the special rules for the letters with
diacritics. The previous commit (0c4bb0e) introduced an algorithm that
covered non-ASCII characters in general, thus special rules for
letters with diacritics where no longer necessary.

I can only speculate why they were escaped in the first place: + ; and
= do have special meaning in HTTP URIs and IIRC Org did not draw a
strict distinction between escaping for internal purposes and escaping
of HTTP URIs.

Best,
  -- David

> Thanks in advance,
> 
> -- 
>  Bastien

Re: [O] Encoding Problem in export?

[David Maus]

At Sun, 28 Jul 2013 14:06:54 +0530,
Jambunathan K wrote:
> 
> 
> If Org links are escaped by Org will the URLs be functional outside of
> Org?
> 
> i.e., If I am on some machine, that has no Emacs or Org or if I am using
> a version of Org that uses "new unescape" algorithm but the original
> link was encoded with the "old escape" algorithm, will Copy-pasting the
> link to a browser still work.

I think this is a good point or rather two good points: One is BC. If
we change the escaping algorithm we still have to deal with possibly
tons of old-style-links in user files. 

The other one is that leaving the edge cases aside it is possible to
just copy a link and paste it into the target application -- a percent
sign signifies percent encoding and the target application knows what
to do.

> If Org is a MUST to unescape the link then it would be a good decision
> to re-look at the link syntax so that the questions of escape and
> un-escape is dealt with squarely and have no reasons to arise in future.
> 

I'm not sure if it is worth the effort but, in theory, we could do
define our own URI schema `org' that disallows square brackets. If a
link is created programmatically (org-store-link et al.) we do not
store the URI as-is but as an "Orgmode-Link": Escape the square
brackets and prefix the link with `org:'. If we open a link we check
for the `org:'-prefix, reverse the escaping and handle the link to the
registered module. If the prefix is absent we skip the unescaping
step.

Best,
  -- David
-- 
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de

Re: [O] Encoding Problem in export?

[David Maus]

At Fri, 26 Jul 2013 12:20:37 +0200,
Nicolas Goaziou wrote:
> 
> David Maus  writes:
> 
> Thanks for your answer. It seems I got confused with the current state
> of URI-encoding. Please scratch my previous suggestion and let's start
> over.

The more I think about it the more I grow certain that it is NOT about
URI encoding but protecting a string. Unless we parse the URI and know
the protocol we cannot tell if square brackets are allowed or not.

> 
> Alas, there is a serious flaw in the current implementation. As you
> said:
> 
> > There is, of course, the nasty thing that we don't know if the link in
> > a buffer went through org-link-escape or not. E.g. if you paste
> >
> >  ,
> > | 
> > [[http://redirect.example.org?url=http%3A%2F%2Ftarget.example.org%3Fid%3D33%26format%3Dhtml]]
> >  `
> >
> > into the buffer you'll get a broken link because org-link-open assumes
> > the link to be escaped by org.
> 
> There is, indeed, no easy way to know if a link went through
> `org-link-escape', so we cannot unescape it properly in every situation.
> We could use text properties on escaped links, but that seems awkward.
> 
> I think there is a simpler solution: we never "unescape" links,
> which means that escaping must be at its minimum. For example, we
> could only replace "[" and "]" with, respectively, "%5B" and "%5D"
> and newlines with spaces. It doesn't cripple link's readability very
> mucĥ, and is safe as "[", "]" and "\n" are always forbidden in URI
> anyway.

`[' and `]' are not forbidden per se, they belong to the set of
reserved characters (see RFC 3986, 2.2.).

"characters in the reserved set are protected from normalization and
are therefore safe to be used by scheme-specific and producer-specific
algorithms for delimiting data subcomponents within a URI."
(RFC 3986, p. 12)

Moreover they are explicitly required in the host part to denote a
IPv6 address literal (RFC 3986, 3.2.2).

If I am not mistaken then this is a valid http-URI with a XPointer
fragment pointing to the third `p' element in a locally hosted file:

http://[::1]/foo.xml#xpointer(//p[3])

,[ http://www.w3.org/TR/xptr-framework/#escaping
| IRI references can be converted to URI references for consumption by
| URI resolvers. The disallowed characters in URI references include all
| non-ASCII characters, plus the excluded characters listed in Section
| 2.4 of [RFC 2396], except for the number sign (#) and percent sign (%)
| and the square bracket characters re-allowed in [RFC 2732]. 
`

> When sending the URL to the consuming, there will be problems, according
> to the assumption at the beginning of this message. But that is to be
> expected.

If we escape but don't unescape there are *other* problems: Depending
on the protocol an escaped square bracket and a unescaped square
bracket can have different meaning. The assumption I mentioned referes
to unescaped characters. A consuming application knows the protocol
and can infer the characters that need to be escaped.

> Replacing non-ascii characters would make the link unreadable to a
> human. Also, we don't prevent encoding mismatch (e.g., from UTF-8 to
> ISO-8859-1) when yanking regular text in an Org buffer, so there's
> no particular reason to do it for links.

ACK. It's not about creating URIs but protecting strings, thus the
rules for percent escaping don't have to be applied.

Best,
  -- David

-- 
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de

Re: [O] Encoding Problem in export?

[David Maus]

At Thu, 25 Jul 2013 23:46:34 +0200,
Nicolas Goaziou wrote:
> 
> Hello,
> 
> David Maus  writes:
> 
> >
> > The bottom-line: Org creates link programmatically (org-store-link)
> > and needs a mechanism to protected conflicting characters. It chose
> > percent-escaping and in order to preserve the identity of a link Org
> > has to escape the escape-character.
> >
> > Hope that helps!
> 
> It does.
> 
> I think we are hunting two hares and that's why we are failing so far.
>
>
> There are two URI transformations involved. One is mandatory (escape
> square brackets in URI), and the other one is optional (normalize URI
> for external processes consumption). The former must be bi-directional,
> as escaping brackets must be transparent to the user (e.g., when editing
> a link with `org-insert-link'). The latter needn't and can happen on the
> fly, just before the URI is sent to whatever needs it (e.g., a browser).
> 
> Therefore, I suggest to use three functions:
> 
>   - `org-link-escape will first %-escape "%" characters, and then "["
> and "]" characters. `org-link-unescape' will reverse the operation.
> 
> These function cannot break a link, encoded or not. They are applied
> when a link is created programmatically and read back for user
> editing.

It's not just square brackets, but also non-ascii
characters. Consider a link that contains UTF-8 encoded characters and
is inserted into a Org buffer encoded in ISO-8859-1.

Oh, and: ASCII controll characters. A link description with newlines.

Obviously changing the algorithm of org-link-escape/unescape also
creates a BC-issue.

> 
>   - `org-link-encode'[1] will %-escape every forbidden character in the
> URI. It doesn't need any "reverse" function. It will be called when
> opening a link, or parsing it.
> 
> I think it shouldn't escape "%" characters, though, so that it can
> be applied on both encoded and plain strings. Since it isn't perfect
> (it doesn't parse URI), it should also be very conservative (i.e.
> allow more characters such as "=" or "&") and not get in the way.

You would have to select the list of forbidden characters based on the
link protocol. The assumption underlying the current implementation is
to delegate dealing with forbidden characters to the consuming
application. Thus I would limit this to known URI protocols,
i.e. http: and https:.

Best,
  -- David

> 
> WDYT?
> 
> 
> Regards,
> 
> [1] `url-encode-url' was introduced in Emacs 24.3. It is too young to be
> used mainstream, even though it does a better job than
> `org-link-escape'. We will benefit from it when Emacs 25 is out (i.e.
> when Emacs 23 support is dropped).
> 
> -- 
> Nicolas Goaziou
-- 
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de

Re: [O] Encoding Problem in export?

[David Maus]

Hi Nicolas,
Hi Nick,

At Wed, 24 Jul 2013 13:09:05 +0200,
Nicolas Goaziou wrote:
> 
> Hello,
> 
> Nick Dokos  writes:
> 
> > Maybe the thing to do is to delete '=' from org-link-escape-chars and
> > see what problems arise.
> 
> AFAICT, `url-encode-url' is subtler than that. It encodes characters
> whenever they are really forbidden, which is not the case of
> `org-link-escape'. Hence my initial question: do we need to reinvent the
> wheel?
> 
> > But I did find that '%' was originally in org-link-escape-chars and
> > David Maus hardcoded it (commit 139cc1d4), so that it is *always*
> > escaped.
> 
> I Cc David Maus in case he has time to enlighten us about his choice.
>

IIRC org-link-escape is not used to create URLs but to escape
characters in a link that would otherwise conflict with Orgmode syntax
(e.g. square brackets). Org applies percent escaping to a link before
it is stored in the buffer and applies unescaping when it reads a link
back.

The percent sign is hardcoded because if org-link-escape/unescape is
used in this way we must make sure that the identity of a link is
preserved. If we would *not* escape the percent sign, then an original
link with percent encoded characters would be read back wrongly,
i.e. with the percent escaped characters unescaped.

This broke links.

E.g. consider a redirector link to the target url
`http://target.example.org?id=33&format=html";':

,
| 
http://redirect.example.org?url=http%3A%2F%2Ftarget.example.org%3Fid%3D33%26format%3Dhtml
`

If we don't escape the percent sign but apply unescaping when, say,
the user opens the link we would get:

,
| http://redirect.example.org?url=http://target.example.org?id=33&format=html
`

And voila: The `format' parameter is turned into a query parameter of
redirect.example.org, not target.example.org.

The specs (RFC3986) have to say the following about escaping:

,
|Because the percent ("%") character serves as the indicator for
|percent-encoded octets, it must be percent-encoded as "%25" for that
|octet to be used as data within a URI.  Implementations must not
|percent-encode or decode the same string more than once, as decoding
|an already decoded string might lead to misinterpreting a percent
|data octet as the beginning of a percent-encoding, or vice versa in
|the case of percent-encoding an already percent-encoded string.
`

There is, of course, the nasty thing that we don't know if the link in
a buffer went through org-link-escape or not. E.g. if you paste

,
| 
[[http://redirect.example.org?url=http%3A%2F%2Ftarget.example.org%3Fid%3D33%26format%3Dhtml]]
`

into the buffer you'll get a broken link because org-link-open assumes
the link to be escaped by org.

The bottom-line: Org creates link programmatically (org-store-link)
and needs a mechanism to protected conflicting characters. It chose
percent-escaping and in order to preserve the identity of a link Org
has to escape the escape-character.

Hope that helps!

Best,
  -- David
-- 
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de

Re: [O] org-map-entries broken?

[David Maus]

At Tue, 20 Mar 2012 02:34:40 +0100,
Bastien wrote:
>
> Mike McLean  writes:
>
> > I reverted =e0072f79137bbfabdf848da6865d8e4de776a549= and both
> > behaviors corrected themselves.
>
> I reverted this commit both in maint (included in 7.8.06)
> and master.

Thanks, I'll give a fix for the problem I tried to fix with this
commit a new shot.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de

pgpJsFgamohYt.pgp
Description: OpenPGP Digital Signature

Re: [O] org-protocol in windows and Acrobat Reader

[David Maus]

At Thu, 15 Mar 2012 20:16:10 + (UTC),
d.tchin wrote:
>
> Hi,
>
> I try to use a function proposed with org-protocol as explained in this link.
> http://orgmode.org/worg/org-contrib/org-protocol.html#sec-2
>
> I would like to launch a pdf file in Acrobat Reader and to use org-store-
> link.js to capture the full path of the document in an org file.I try to use
> what it was explained on the link I have already and I have a look on the
> following link.
> http://article.gmane.org/gmane.emacs.orgmode/6810
> It doesn't work as I expect.
>
>
> As I just want to capture the full path of the file (example here is file.pdf
> in C:\Temp), I use the following javascript call org-store-link accessible in
> menu File of Acrobat Reader :
> app.addMenuItem({cName:"org-store-link", cParent:"File",
>cExec:"app.launchURL('org-protocol://store-link://'+
> encodeURIComponent(this.URL));"});
>
> I get the following string given to org-protocol:
> org-protocol://store-link://file%3A%2F%2F%2FC%7C%2FTemp%2Ffile.pdf
>
> There is several issue. The escaped character is not interpreted when feed in
> emacs and when I use C-c C-l (org-insert-link) I have the following
> proposition :
> file: (C|).
>
> Then I try the following script, to get '/' character to feed org-protocol:
> app.addMenuItem({cName:"org-store-link", cParent:"File",
>cExec:"app.launchURL('org-protocol://store-link://'+ unescape
> (encodeURIComponent(this.URL)).replace('|',':'));"});
>
>
> I get the following the expected string :
> org-protocol://store-link://file:///C:/Temp/File.pdf
>
>
> Again when I use C-c C-l, I have the proposition : file: (C|).

This indicates that .replace('|',':') didn't work out as expected and
org-protocol received

org-protocol://store-link://file%3A%2F%2F%2FC%7C%2FTemp%2Ffile.pdf
 ^^^

Maybe this could do the trick:

,
| app.addMenuItem({cName:"org-store-link", cParent:"File",
|cExec:"app.launchURL('org-protocol://store-link://'+ unescape
|  (encodeURIComponent(this.URL.replace('|',':';"});
`

I.e. replace | by : in the original URL before encoding it.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpoBuPD2BnXk.pgp
Description: OpenPGP Digital Signature

Re: [O] Japanese strings for Org-mode export

[David Maus]

At Sat, 3 Mar 2012 23:29:43 -0800,
Hideki Saito wrote:
>
> [1  ]
> The attached is alternative of the patch using utf-8 encoding.

Thanks for the translation. I made the modification but we need to use
numeric character entities[1] to avoid rendering problems when
non-UTF8 documents are exported to HTML.

Could I ask you to check if the japanese text is rendered properly
when a document is exported?

Best,
  -- David
[1] http://en.wikipedia.org/wiki/Numeric_character_reference
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpiCHfHld8ng.pgp
Description: OpenPGP Digital Signature

Re: [O] [PATCH] Adding Simplified Chinese(UTF-8) translation for org-exp

[David Maus]

Accepted, thanks!

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de

pgpYIH5MSc3oV.pgp
Description: OpenPGP Digital Signature

Re: [O] [PATCH] org-store-link: Fixed a bug where source block edit buffers were not recognized

[David Maus]

At Wed, 14 Mar 2012 15:37:20 +,
Shaun Johnson wrote:
>
> On 08/03/2012 22:33, Ilya Shlyakhter wrote:
> > attached.
>
> Having just run into this same problem (being unable to create
> and store a code reference link using C-l in a source block edit
> buffer) I would like to second the inclusion of this or an
> equivalent patch. Ilya's patch can be seen on the patchwork server
> at:
>   http://patchwork.newartisans.com/patch/1209/
>
> I am currently using the following patch to work around this
> problem:

http://patchwork.newartisans.com/patch/1209/ was recently accepted --
This problem should be fixed now.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de

pgp4BfyuVPw1B.pgp
Description: OpenPGP Digital Signature

Re: [O] Possible bug in parsing / clarification of syntax

[David Maus]

Hi Simon,

At Sun, 04 Mar 2012 22:30:31 +0100,
Simon Thum wrote:
>
> Hi all,
>
> I have found some irritating behaviour, potentially a bug. I have a
> block agenda which goes like:
>
> tags-todo "@home&TODO=\"TODO\"
>
> and it displays a certain org line that reads
>
>  TODO_ state triggers
>
> Which is just a heading for dealing with TODO state triggers, and I
> appended the _ as I don't want it to be a TODO.
>
> For example, the global TODO list and syntax highlighting does not
> consider it a todo, but C-c a m TODO="TODO" does. TODO="T" does not,
> so it's not very grave.
>
> Most likely, it's simply an inconsistency arising from not having a
> real parser. I just wanted to report it here so it may get fixed.

Thanks for the report. It was indeed a glitch and it should be fixed
by now in current master.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de

pgp0oieyCUBUs.pgp
Description: OpenPGP Digital Signature

Re: [O] Custom agenda and DONE faces

[David Maus]

Hi Hans-Peter,

At Wed, 15 Feb 2012 18:19:54 +0100,
Hans-Peter Deifel wrote:
>
> Hi all,
>
> [...]
>
> I played around in the source code and noticed that the following patch fixes
> the problem, but I don't know the code base well enough to understand why it
> works and what other implications it might have:
>
> [...]

I've applied a fix for this problem to master. Your patch did the
right thing; `org-prepare-agenda' was called by `org-agenda-list'
which already set up the done-keywords. But when `org-agenda-list' was
called in a block agenda `org-prepare-agenda' set the variable to nil
and left early.

Best and thanks,
  -- David


pgpZ3Q3qAZmxu.pgp
Description: OpenPGP Digital Signature

Re: [O] [PATCH] org-attach-store-link-p gets wrong value for attach when using customize-variable

[David Maus]

Hi Henning,

At Mon, 12 Mar 2012 22:17:34 +0100,
Henning Weiss wrote:
> I have attached a very small patch fixing the value
> that org-attach-store-link-p gets through the customize
> interface. The additional quote prevented org-attach-attach from
> calling org-attach-store-link when org-attach-store-link-p was
> configured to "Link to the attach-dir location".

Thanks for spotting this. I pushed a fix to master, removing the
spurios quote.

Best,
  -- David
-- 
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de

Re: [O] bug with org-mode-hook and text-scale-set

[David Maus]

Hi,

At Tue, 13 Mar 2012 14:49:41 +0800,
Du Yanning wrote:
> org-mode 7.8.03
> emacs 23.3, 23.4, 24.0.94
> 
> steps to recreate:
> 
> emacs -q
> 
> copy the following code and paste it into the *scratch* buffer:
> (add-to-list 'auto-mode-alist '("\\.txt\\'" . org-mode))
> (add-hook 'org-mode-hook '(lambda () (text-scale-set 4))) 
> 
> M-x eval-buffer
> 
> then C-x C-f to open a .txt file, and then C-x C-f to open another .txt file.
> Every time a .txt is opened, the font size become larger and larger.
> However, the indicator in the mode line remains +4.

I can confirm this behaviour but I don't think this is an error. The
description of `text-scale-set' reads:

C-h f text-scale-set RET

,
| text-scale-set is an interactive autoloaded Lisp function in
| `face-remap.el'.
| 
| (text-scale-set LEVEL)
| 
| Set the scale factor of the default face in the current buffer to LEVEL.
| If LEVEL is non-zero, `text-scale-mode' is enabled, otherwise it is disabled.
| 
| LEVEL is a number of steps, with 0 representing the default size.
| Each step scales the height of the default face by the variable
|   ^
| `text-scale-mode-step' (a negative number decreases the height by
| the same amount).
`

The first time `org-mode-hook' is run the height of default font is
scaled by 4 levels, i.e. the height of default font is set to a new
value. The second time `org-mode-hook' is run the height is scaled
again, this time based on the new value. And so on.

If you want to set the face height you might use:

(set-face-attribute 'default nil :height 100)

Here `100' means 100% of the font size in pt (afaik).

Best,
  -- David
-- 
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de

pgpXlI3Ly22v6.pgp
Description: OpenPGP Digital Signature

Re: [O] [PATCH] Add missing word to org-contacts y-or-n-p question.

[David Maus]

At Tue, 13 Mar 2012 08:19:39 +0100,
Tassilo Horn wrote:
>
> From 6254305becaaa712f6f0936263a09d9ed974e51b Mon Sep 17 00:00:00 2001
> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux)
> Cancel-Lock: sha1:/pUqi5NalGwuBic1R2H+VziOGlM=
>
> Before it was
>
>   Do you want to this address to %s?
>
> now it is
>
>   Do you want add to this address to %s?

Thanks, patch applied.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de

pgpupVz6LrHyq.pgp
Description: OpenPGP Digital Signature

[O] Small patch for pw client, fix typo in error message

[David Maus]

Hi,

Not sure what the commit policy for the pw client in UTITLITES is, so
this patch first over the list: It fixes a confusing typo in an error
message.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de
From ad7d01046cd08675fd95a266b1397e6c2172f750 Mon Sep 17 00:00:00 2001
From: David Maus 
Date: Sun, 4 Mar 2012 21:31:11 +0100
Subject: [PATCH] UTILITIES/pw: Fix type in error message

* pw (action_update_patch): Fix type in error message.
---
 UTILITIES/pw |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/UTILITIES/pw b/UTILITIES/pw
index 0cf4bfa..1e2f44f 100755
--- a/UTILITIES/pw
+++ b/UTILITIES/pw
@@ -314,7 +314,7 @@ def action_update_patch(rpc, patch_id, state = None, commit 
= None,
 
 if state.lower() in notify_on_state_change:
 if not delegate_id:
-sys.stderr.write("Error: Delete (-d) required for this 
update\n")
+sys.stderr.write("Error: Delegate (-d) required for this 
update\n")
 sys.exit(1)
 
 person = rpc.person_get(delegate_id)
-- 
1.7.2.5



pgph6H3AvOF85.pgp
Description: OpenPGP Digital Signature

Re: [O] [PATCH] org-agenda-list (from git) giving "args-out-of-range error"

[David Maus]

Hi Karl,

At Wed, 29 Feb 2012 13:45:05 -0600,
Karl Fogel wrote:
>
> [1  ]
> Nick Dokos  writes:
> >Exactly what you've done: send the patch to the list.
> >
> >Modulo possible changelog formatting issues (see
> >http://orgmode.org/worg/org-contribute.html#sec-5 for the gory details),
> >the patch looks good to me. Thanks for submitting it!
>
> Oh, thanks -- I should have looked for those guidelines first.  Here is
> the same patch, but with a properly-done log message this time.

I pushed the fix with some small cleanup of the commit
message. Somehow the patchtracker included the mailbody in the commit
message.

Best and thanks for the patch,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de

pgpbs9CEJlZsT.pgp
Description: OpenPGP Digital Signature

[O] [accepted] Fix task cloning for repeating tasks

[David Maus]

Patch 1185 (http://patchwork.newartisans.com/patch/1185/) is now "accepted".

Maintainer comment: none

This relates to the following submission:

http://mid.gmane.org/%3C1330137796-18986-1-git-send-email-bernt%40norang.ca%3E

Here is the original message containing the patch:

> Content-Type: text/plain; charset="utf-8"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Subject: [O] Fix task cloning for repeating tasks
> Date: Sat, 25 Feb 2012 07:43:16 -
> From: Bernt Hansen 
> X-Patchwork-Id: 1185
> Message-Id: <1330137796-18986-1-git-send-email-be...@norang.ca>
> To: emacs-orgmode@gnu.org
> Cc: Bernt Hansen 
> 
> * org.el (org-clone-subtree-with-time-shift): Fix task cloning for
> repeating tasks using .+n and ++n syntax
> 
> Tasks with repeaters using .+n and ++n syntax retain the repeater in
> all of the clones causing duplicate tasks.  These tasks are now
> handled the same as the regular repeating task using +n syntax.
> 
> ---
> Doh!  Let's fix the changelog entry... (missing * in the previous version)
> 
> -Bernt
> 
>  lisp/org.el |6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/lisp/org.el b/lisp/org.el
> index a81f7fc..f24c69f 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -7946,7 +7946,7 @@ the following will happen:
>repeater intact.
>  - the start days in the repeater in the original entry will be shifted
>to past the last clone.
> -I this way you can spell out a number of instances of a repeating task,
> +In this way you can spell out a number of instances of a repeating task,
>  and still retain the repeater to cover future instances of the task."
>(interactive "nNumber of clones to produce: \nsDate shift per clone (e.g. 
> +1w, empty to copy unchanged): ")
>(let (beg end template task idprop
> @@ -7973,7 +7973,7 @@ and still retain the repeater to cover future instances 
> of the task."
>  (setq end (point))
>  (setq template (buffer-substring beg end))
>  (when (and doshift
> -(string-match "<[^<>\n]+ \\+[0-9]+[dwmy][^<>\n]*>" template))
> +(string-match "<[^<>\n]+ [.+]?\\+[0-9]+[dwmy][^<>\n]*>" 
> template))
>(delete-region beg end)
>(setq end beg)
>(setq nmin 0 nmax (1+ nmax) n-no-remove nmax))
> @@ -8004,7 +8004,7 @@ and still retain the repeater to cover future instances 
> of the task."
>   (while (re-search-forward org-ts-regexp nil t)
> (save-excursion
>   (goto-char (match-beginning 0))
> - (if (looking-at "<[^<>\n]+\\( +\\+[0-9]+[dwmy]\\)")
> + (if (looking-at "<[^<>\n]+\\( +[.+]?\\+[0-9]+[dwmy]\\)")
>   (delete-region (match-beginning 1) (match-end 1)))
>   (setq task (buffer-string)))
> (insert task))
> 

Re: [O] [BUG?] subtle sequencing error when setting org-bbdb-old in org-bbdb.el

[David Maus]

At Mon, 27 Feb 2012 17:21:59 -0500,
Nick Dokos wrote:
> 
> David Maus  wrote:
> 
> > > The problem was that org-bbdb is part of org-modules by default and that
> > > was loading org-bbdb way too early, certainly before bbdb itself was
> > > loaded.  That would set the value to nil and nothing I would do could
> > > change it (short of whacking it with a setq).
> > 
> > I pushed a patch that should fix this problem. I wrapped a
> > `eval-after-load' around the `defvar', this should make sure that the
> > variable is set after bbdb was loaded.
> > 
> 
> I still have a problem with one configuration (but not with another),
> but I haven't drilled down to figure out what the problem is. I was
> wondering however if the eval-after-load should be predicated on
> bbdb-com rather than bbdb[fn:1]: with this change, both of my tested
> configurations work (hardly a definitive test but perhaps better than
> nothing).

Thanks for the feedback. Eval after load 'bbdb-com would have been
better -- I just replaced the entire defvar by a check in
`org-bbdb-open' and `org-bbdb-store-link' for the required functions.

So this should really work now.

Best,
  -- David
-- 
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de

Re: [O] [dev] Implement "ref" link types

[David Maus]

At Tue, 21 Feb 2012 10:18:00 +0100,
Nicolas Goaziou wrote:
>
> Hello,
>
> David Maus  writes:
>
> > I don't see why we should drop the link type in fuzzy links. After all
> > they /are/ are special type of link.
>
> There is no link type in fuzzy links : [[something]] matches
> <> in master.
>
> > Without the link type we will run into trouble, won't we?.
> >
> > In the example file:
> >
> > ,
> > | We end the list at item [[itm:last]].
> > `
> >
> > So, itm:last is a fuzzy link but it could as well be a "regular" link
> > of type "itm" with a path component of "last" and no description.
>
> I realize my examples are confusing. I shouldn't have used colons. In
> fact, the output will be the same if the target is <>,
> <> or even <>.
>
> In other words, the "itm:" part wasn't meant as a link type, but as
> a cosmetic part of the name. So the list example could as well be:

Thanks for the clarification.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de

pgpSeuw3JODk6.pgp
Description: PGP signature

Re: [O] [BUG?] subtle sequencing error when setting org-bbdb-old in org-bbdb.el

[David Maus]

Hi Nick,

At Sat, 25 Feb 2012 04:20:10 -0500,
Nick Dokos wrote:
>
> I was bitten by this and it took me a while to figure out what was going
> on, so maybe I can save somebody some time by recording the problem here.
>
> I'm using bbdb 2.36devo (i.e. an old bbdb version - see below for my
> 3.0 troubles), and although org-bbdb-anniversaries was working fine,
> bbdb links did not: C-c l on a bbdb entry would raise an error about
> void function bbdb-record-get-field. Now org-bbdb-store-link contains
> the following code
>
> (if org-bbdb-old
> (bbdb-record-getprop rec 'company)
>   (car (bbdb-record-get-field rec 'organization))
>
> so clearly org-bbdb-old was nil - but why? It seemed to me that it should
> be t since my bbdb was old.
>
> It turns out that org-bbdb.el contains a line that sets org-bbdb-old
> thus:
>
>   (defvar org-bbdb-old (fboundp 'bbdb-record-get-field-internal))
>
> Check whether an "old" bbdb function is present and if so, set
> org-bbdb-old to t. Basically, the variable tells the rest of org-bbdb.el
> whether one's bbdb is old (< 3.0) or not, so that it can use the proper
> compatibility layer. This was not working in my case : the variable
> resolutely held the value nil, no matter what requires/load-library/ etc
> tricks I threw at it.
>
> The problem was that org-bbdb is part of org-modules by default and that
> was loading org-bbdb way too early, certainly before bbdb itself was
> loaded.  That would set the value to nil and nothing I would do could
> change it (short of whacking it with a setq).

I pushed a patch that should fix this problem. I wrapped a
`eval-after-load' around the `defvar', this should make sure that the
variable is set after bbdb was loaded.

>
> Re: the bbdb 3.0 troubles. I have tried switching to bbdb 3.0
> (specifically "BBDB version 3.02 ($Date: 2012/01/02 10:08:06 $)") but
> I've been stymied so far with org-bbdb-anniversaries blowing up (a far
> worse scenario than the link problem above - that's why I'm still using
> 2.36devo and went after the link fix first).
>
> The error I get is "Debugger entered--Lisp error: (void-function
> bbdb-record-getprop)" in org-bbdb-anniv-hash (see backtrace below),
> but I haven't chased down that problem yet. But it seems there are
> people using bbdb 3.0 so I'm wondering what's wrong with my setup.

Can't comment on this.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de

pgpVbuVyFU7os.pgp
Description: PGP signature

Re: [O] Bug: [patch] Fixes behavior of org-agenda-tree-to-indirect-buffer [7.8.02 (release_7.7.796.gc512)]

[David Maus]

At Sat, 25 Feb 2012 08:34:22 -0500,
Dave Abrahams wrote:
>
>
> on Sat Feb 25 2012, David Maus  wrote:
>
> > Hi Dave,
> >
> > At Fri, 17 Feb 2012 22:48:13 -1000,
> > Dave Abrahams wrote:
> >>
> >> [1  ]
> >>
> >>
> >> Remember to cover the basics, that is, what you expected to happen and
> >> what in fact did happen.  You don't know how to make a good report?  See
> >>
> >>  http://orgmode.org/manual/Feedback.html#Feedback
> >>
> >> Your bug report will be posted to the Org-mode mailing list.
> >> 
> >>
> >> This function was misbehaving in a number of ways.  The enclosed patch
> >> represents the changes necessary to make it work properly, accumulated
> >> over several weeks of testing.  Sorry if the description is a bit vague.
> >
> > Thanks for the patch. I implemented the first to modifications (handle
> > org-last-indirect-buffer being nil and window-live-p
> > indirect-window).

Your patch contained three modifications to 
`org-agenda-tree-to-indirect-buffer':

 1. handle the case where there was no indirect buffer yet, i.e.
(eq org-last-indirect-buffer nil)

=> applied

 2. handle the case where the window of the last indirect buffer is no
longer live

=> applied

 3. set the subtree visibility according to the VISIBILITY property
after the indirect buffer was created

=> no applied

The third modification does not fix a bug, but is a useful
feature. This should be implemented in `org-tree-to-indirect-buffer'
and I'm going to do exactly this.

Better?

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de

pgpaTpSXyx0Ga.pgp
Description: PGP signature

Re: [O] Bug: [patch] Fixes behavior of org-agenda-tree-to-indirect-buffer [7.8.02 (release_7.7.796.gc512)]

[David Maus]

Hi Dave,

At Fri, 17 Feb 2012 22:48:13 -1000,
Dave Abrahams wrote:
>
> [1  ]
>
>
> Remember to cover the basics, that is, what you expected to happen and
> what in fact did happen.  You don't know how to make a good report?  See
>
>  http://orgmode.org/manual/Feedback.html#Feedback
>
> Your bug report will be posted to the Org-mode mailing list.
> 
>
> This function was misbehaving in a number of ways.  The enclosed patch
> represents the changes necessary to make it work properly, accumulated
> over several weeks of testing.  Sorry if the description is a bit vague.

Thanks for the patch. I implemented the first to modifications (handle
org-last-indirect-buffer being nil and window-live-p
indirect-window). These were indeed bugs or glitches.

The third modification (set visibility according to property) is a new
feature. Currently org-tree-to-indirect buffer does not use the
VISIBILITY property but it makes sense to me to do so.

I'll check this out and see to implement this.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de

pgpMkODf3Ofje.pgp
Description: PGP signature

Re: [O] [dev] Implement "ref" link types

[David Maus]

At Mon, 20 Feb 2012 23:06:32 +0100,
Nicolas Goaziou wrote:
>
> Completing myself, here is a patch implementing the previous suggestion,
> along with example output obtained with it.  You may need to
> (fmakunbound 'org-e-ascii-target) to avoid an error, since this patch
> removes the function.

I don't see why we should drop the link type in fuzzy links. After all
they /are/ are special type of link.

Without the link type we will run into trouble, won't we?.

In the example file:

,
| We end the list at item [[itm:last]].
`

So, itm:last is a fuzzy link but it could as well be a "regular" link
of type "itm" with a path component of "last" and no description.

If we say that we use itm:last as a fuzzy link iff there is no
registered link type "itm" we might put people into trouble if in some
point in the future Org mode introduces a link of type "itm" and the
fuzzy links stop working.

Or is there any technical reason to use [[itm:last]] instead of
[[ref:itm:last]]?

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de

pgpDlDRSOzYXk.pgp
Description: PGP signature

Re: [O] [PATCH] org-capture, removing whitespace from new captures

[David Maus]

At Sat, 18 Feb 2012 18:19:49 +0100,
Bastien wrote:
>
> Hi David and Paul,
>
> David Maus  writes:
>
> > Instead of adding the :whitespace-cleanup property to the template
> > definition (what requires you to specify e.g. whitespace-cleanup in
> > every single template) why not define a new hook that is run before
> > the finalization starts? I.e. with capture buffer current and still
> > narrowed.
>
> Yes, I think this is more general, feel free to commit this.
>
> Thanks to you and to Paul for his neat suggestion!

And... done.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de

pgpEgAWNlmHwq.pgp
Description: PGP signature

Re: [O] [PATCH] org-capture, removing whitespace from new captures

[David Maus]

Hi Bastien,
Hi Paul,

At Sat, 29 Oct 2011 14:08:52 +0200,
Bastien wrote:
>
> Hi Paul,
>
> Paul  writes:
>
> > In fact adding whitespace-cleanup to org-capture-before-finalize-hook
> > was what I tried first, but it didn't do what I wanted.  This hook is
> > called _after_ the buffer is widened - making whitespace-cleanup
> > operate on the _entire_ buffer, not just the newly added capture.
> >
> > I believe the patch is still required - I should have explained
> > org-capture-before-finalize-hook's behaviour more explicitly in my
> > original submission.
>
> I'm willing to apply this patch -- could you provide it with a
> well-formatted ChangeLog entry?

Instead of adding the :whitespace-cleanup property to the template
definition (what requires you to specify e.g. whitespace-cleanup in
every single template) why not define a new hook that is run before
the finalization starts? I.e. with capture buffer current and still
narrowed.

See attached patch that such a hook called
`org-capture-prepare-finalize-hook'.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de
From f737fbdc6ed1d45d8629eb1347e8c8d828f77e32 Mon Sep 17 00:00:00 2001
From: David Maus 
Date: Sat, 18 Feb 2012 16:41:30 +0100
Subject: [PATCH] New hook: Run before the finalization process starts

* org-capture.el (org-capture-prepare-finalize-hook): New hook. Run
before the finalization process starts.
(org-capture-finalize): Run new hook.
---
 lisp/org-capture.el |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index d77415b..e3bd9f7 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -347,6 +347,13 @@ widened to the entire buffer."
   :version "24.1"
   :type 'hook)
 
+(defcustom org-capture-prepare-finalize-hook nil
+  "Hook that is run before the finalization starts.
+The capture buffer is current and still narrowed."
+  :group 'org-capture
+  :version "24.1"
+  :type 'hook)
+
 ;;; The property list for keeping information about the capture process
 
 (defvar org-capture-plist nil
@@ -530,6 +537,8 @@ captured item after finalizing."
   (buffer-base-buffer (current-buffer)))
 (error "This does not seem to be a capture buffer for Org-mode"))
 
+  (run-hooks 'org-capture-prepare-finalize-hook)
+
   ;; Did we start the clock in this capture buffer?
   (when (and org-capture-clock-was-started
 org-clock-marker (marker-buffer org-clock-marker)
-- 
1.7.2.5



pgpnFSAWSudo2.pgp
Description: PGP signature

Re: [O] Bug: Remote state change of repeating TODO fails with calendar open [7.8.03]

[David Maus]

Hi Thomas,

At Fri, 17 Feb 2012 14:28:39 +0100,
Thomas Morgan wrote:
>
> Changing a repeating TODO's state to DONE remotely from the
> agenda fails to change the date when the calendar is open in
> another window.
>
> The reason is that `org-recenter-calendar' selects the agenda
> window after doing its work, also making the agenda the current
> buffer, but caller `org-auto-repeat-maybe' expects the current
> buffer to be the Org file that contains the TODO item.
>
> Here's how to reproduce it:
>
> Run `emacs -Q -l setup.el'.
> Type `M-x calendar'.
> Type `M-x org-agenda', then `a' for weekly agenda.
> Move point to first TODO.
> Press `t' to try to change TODO state to DONE.
>
> The result is that `Note stored' appears in the echo area but
> there is no change in the agenda view or in the scheduled date
> in `test-case.org'.

Thanks for the report and the detailed analysis. I pushed a fix for
this problem, could you pull and check if the problem is fixed for
you?

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de

pgpCnXKGZRebK.pgp
Description: PGP signature

[O] [Accepted] Fix J in agenda when clock out hook clocks in again

[David Maus]

Patch 1160 (http://patchwork.newartisans.com/patch/1160/) is now "Accepted".

Maintainer comment: none

This relates to the following submission:

http://mid.gmane.org/%3C1328809420-31933-1-git-send-email-bernt%40norang.ca%3E

Here is the original message containing the patch:

> Content-Type: text/plain; charset="utf-8"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Subject: [O] Fix J in agenda when clock out hook clocks in again
> Date: Thu, 09 Feb 2012 22:43:40 -
> From: Bernt Hansen 
> X-Patchwork-Id: 1160
> Message-Id: <1328809420-31933-1-git-send-email-be...@norang.ca>
> To: emacs-orgmode@gnu.org
> Cc: Bernt Hansen 
> 
> * org-clock.el (org-clock-out): Do not delete the current clocking task
> when org-clock-out-hook clocks in another task
> 
> My clock out hook keeps the clock running by automatically clocking in
> a new task (the parent task, or the default task).  This sets a new
> clocking task which was then clobbered at the end of org-clock-out
> so that J in the agenda would return
> 
> "No running clock, use `C-c C-x C-j' to jump to the most recent one"
> 
> We now detect that another task is clocked in and skip clearing the
> org-clock-current-task variable used by the agenda to determine if
> the clock is currently running.
> 
> ---
> lisp/org-clock.el |3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/lisp/org-clock.el b/lisp/org-clock.el
> index a1df776..7dff094 100644
> --- a/lisp/org-clock.el
> +++ b/lisp/org-clock.el
> @@ -1387,7 +1387,8 @@ If there is no running clock, throw an error, unless 
> FAIL-QUIETLY is set."
> (message (concat "Clock stopped at %s after HH:MM = " 
> org-time-clocksum-format "%s") te h m
>  (if remove " => LINE REMOVED" ""))
>(run-hooks 'org-clock-out-hook)
> -   (org-clock-delete-current))
> +   (unless (org-clocking-p)
> + (org-clock-delete-current)))
>  
>  (add-hook 'org-clock-out-hook 'org-clock-remove-empty-clock-drawer)
>  
> 

Re: [O] [BUG] tags sparse tree broken

[David Maus]

At Thu, 9 Feb 2012 03:22:55 +0100,
Suvayu Ali wrote:
>
> [1  ]
> Hi,
>
> I believe the sparse tree search is broken. It has been broken for a
> while I think. Searching for tags returns no matches. I get the
> following backtrace with debug enabled on a minimal emacs on using
> `next-error' after a tag search which should return a positive result.

I pushed a patch to master that should fix the problem. Sparse tree
search for a tag as outlined in the example works now in current
master the same way it did in Org 7.7.

It was not the matching that was broken, but the highlighting of the
matches.

Could you check if this problem is fixed for you?

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de

pgpuufOWRdzef.pgp
Description: PGP signature

Re: [O] save-excursion not saving when I call org-capture-goto-last-stored

[David Maus]

At Sat, 4 Feb 2012 22:01:32 -0500,
Jon Miller wrote:
>
> I'm currently trying to write a function to do some post-capture
> updates to an entry. My intention is to add it to
> org-capture-after-finalize-hook. First step is navigating to the
> captured item but I'd like to return to the current buffer I was in
> before. I'm still a novice with elisp, so I could use a pointer here.
>
> Here is a simplified example:
> M-: (save-excursion (org-capture-goto-last-stored))
>
> Is there a better way to navigate to the last capture and then return
> to my current buffer?

Well, save-excursion does restore the current buffer but is not
switching to it. Executing

,
| (progn
|   (save-excursion
| (org-capture-goto-last-stored))
|   (princ (current-buffer)))
`

in *scratch* tells me that the current-buffer after the excursion is
*scratch*. What you are looking for is saving and restoring the
windows configuration (visible buffers in a frame).

C-h f save-window-excursion RET

This should do the trick:

,
| (progn
|   (save-excursion
| (save-window-excursion
|   (org-capture-goto-last-stored
`

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de

pgp44ZhtQDvFw.pgp
Description: PGP signature

Re: [O] patch to org-refile for more accurate completing-read

[David Maus]

Resend Le Wang's patch as text/plain, so patchtracker picks it up.

diff --git a/lisp/org.el b/lisp/org.el
index 7a68b73..ccdcace 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -10625,7 +10625,8 @@ prefix argument (`C-u C-u C-u C-c C-w')."
   (t (concat "Refile subtree \""
  heading-text "\" to")))
 default-buffer
-org-refile-allow-creating-parent-nodes
+(and (not (equal '(4) goto))
+ org-refile-allow-creating-parent-nodes)
 goto))
  (setq file (nth 1 it)
re (nth 2 it)

Re: [O] [BUG] cannot open menu when in an org buffer

[David Maus]

Hi,

At Tue, 7 Feb 2012 14:26:41 +0100,
suvayu ali wrote:
>
> Hi Nick,
>
> On Tue, Feb 7, 2012 at 03:31, Nick Dokos  wrote:
> > suvayu ali  wrote:
> >
> >> On Sat, Feb 4, 2012 at 18:46, Nick Dokos  wrote:
> >> >
> >> > Confirmed. If I add
> >> >
> >> > (require 'org-clock)
> >> >
> >> > to my minimal .emacs, it goes away. So it seems to be a missing 
> >> > dependenc=
> >> y.
> >> >
> >>
> >> It seems an odd dependency to have.
> >
> > True - org-in-clocktable-p does not have anything to do with clocks, but
> > it ended up in org-clock.el. All of these "where am I" functions should
> > probably be in org.el. In fact, they all are except for
> > org-in-clocktable-p and org-at-item-p. The latter is in org-list.el and
> > it is not giving an error a) because org-in-clocktable-p errors out
> > first and b) because org.el contains a (require 'org-list). So having a
> > (require 'org-clock) in org.el does have a precedent, but of course this
> > way you end up defeating autoloads: the moment org.el is loaded, all of
> > these things are too. There might be a better arrangement but it's like
> > Pascal's letter[fn:1] : it would require time to find it :-)
> >

I pushed a fix to master that relocates org-in-clocktable-p from
org-clock.el to org.el -- the problem should be fixed now. This
shouldn't break things because org-clock requires org.

Best,
  -- David


pgpMIjjZUlSJH.pgp
Description: PGP signature

Re: [O] Non-deadline agenda warnings

[David Maus]

At Mon, 6 Feb 2012 21:26:44 +0100,
Jacek Generowicz wrote:
>
> Hi,
>
> Is it possible to have warnings, such as those for upcoming deatlines,
> appear in the agenda for time-stamped items other than deadlines?

AFAIK you can't.

Best,
  -- David


pgpa4ybD7mbxM.pgp
Description: PGP signature

Re: [O] Title gets a 'nil' appended on org-export-subtree to html

[David Maus]

Hi John,

At Tue, 7 Feb 2012 12:46:30 -0600,
John Hendy wrote:
> 
> I got some weird behavior on a file, so I recreated a smaller example
> and can reproduce it. Here it is:
> 
> --
> 
> #+options:  <:t num:t tasks:nil tags:t
> 
> * test
> ** sub 1
> ** sub 2
> --
> 
> If I go to the first headline, 'test', and do =C-c C-e 1 h= to export
> the subtree as html, my filename/default title ends up as 'test nil.'
> 
> If I export with =C-c C-e h=, I just end up with 'test.'
> 
> If I remove =tags:t= from the options line, the 'nil' also goes away.
> 
> Any thoughts on why this is happening?

I can confirm the bug and it should be fixed in master.

What happend was that Org grabbed the document title from the headline
(good) and tags:t told Org to include the tags (Okay), but then Org
forgot to check if there are actually tags in the headline when
creating the document title with a `format' w/ a placeholder for the
tags.

Best,
  -- David

Re: [O] Problem at capture time

[David Maus]

Hi François,
Hi Bastien,

At Mon, 09 Jan 2012 07:50:54 -0500,
François Pinard wrote:
> 
> Bastien  writes:
> 
> > Hi François, please be patient -- your patches are under radar,
> > resending them does not help.
> 
> OK, sorry.  I do not know enough, yet, how Org works.  I sent a problem,
> got a question, sent a reply which was rejected, then nothing.  A mere
> short acknowledgement would have told me the message was not lost.
> 
> > What helps is to send them using git format-patch, to include a
> > detailed and clean changelog entry, and to make it clear whether the
> > patch is okay or for testing purpose first.  When I read your message,
> > I could not be sure you were yourself confident it was the right fix.
> 
> I'm still not confident.  And I'm not pedant enough -- yet! :-) -- to
> write formal patches when I'm not at least rather sure.
> 
> Besides the lack of confidence in a solution, however, the problem is
> real.  The patch I sent was merely a trail for thinking.  But if nothing
> else, it would do I presume.
> 
> > I will look into this later on.
> 
> Let me the one thanking you for supporting Org mode and its users, even
> those like me! :-)

Sorry for my silence, haven't looked into the Orgmode mailing list for
a while. I just pushed a fix for this problem: If the :exact-position
for a list item is supplied we don't search for the position in an
existing list at all but insert the item whereever :exact-position
points to.

I'll mark the patch in patchwork as superseeded this evening as soon
as I recover my password.

Best,
  -- David
-- 
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpXeMllWqvRS.pgp
Description: PGP signature

Re: [O] Refile fails with blank TODO

[David Maus]

Hi,
At Mon, 12 Dec 2011 15:13:48 -0600,
Nathan Neff wrote:
>
> Hello,
>
> With some help from Nick Dokos, I think I've found a
> bug:
>
> If you have a blank TODO entry in any of your refile targets,
> you will get the error message below.

I pushed a fix for this. Headlines with a blank todo are now ignored
as a possible refile target.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgprZqQZj3BrH.pgp
Description: PGP signature

Re: [O] Capture failure [7.7]

[David Maus]

At Sun, 11 Dec 2011 23:24:28 -0500,
François Pinard wrote:
> 
> Hi, Org mode people.
> 
> I had some misery trying to debug a special personal machinery to
> capture URLs from Chrome into Org.  Not worth detailing here.  And
> moreover, as it works now, I'm happy with this.
> 
> However, I had to make the following modification to get it going.  I'm
> not sure what are the meaning of "beg" and "end" in this function, so
> someone knowledgeable should check if (point) is appropriate as a value.
> 
> One sure thing is that "beg" and "end" should be initialized, as they
> get later consulted in the function, and whenever :exact-position got a
> value, that initialization does not occur.

As far as I can see :exact-position is set when the target is
`file+regexp', `file+function', or `function' and the error would be
triggered if you combine one of these targets with the :prepend
option.

What capture template target are you using?

Best,
  -- David
-- 
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpj5h8Rzudd4.pgp
Description: PGP signature

[O] [PATCH] Escape link path only if path contains space or non-ascii character

[David Maus]

Hi there,

Attached patch should take care of mistakenly double-escaped links as
reported by Jeff Horn in <http://article.gmane.org/gmane.emacs.orgmode/48731>.

This patch might break `org-open-at-point' for some users if the
target application does not deal with (possibly) unescaped URLs. The
alternative to the guesswork would require parsing und analyzing the
link and its components (path, query, fragment) and check for
characters that absolutely need escaping depeding on the link type.

Hopefully this solution is good enough.

Best,
  -- David
From ddb461326896825dce6fd58bfd9e4ea25a3a35ff Mon Sep 17 00:00:00 2001
From: David Maus 
Date: Sun, 18 Dec 2011 19:23:57 +0100
Subject: [PATCH] Escape link path only if path contains space or non-ascii 
character

* org.el (org-open-at-point): Escape link path for http:, https:,
ftp:, news:, and doi: links only if the path contains space or
non-ascii character.

This should take care of mistakenly double-escaped links as reported
by Jeff Horn in <http://article.gmane.org/gmane.emacs.orgmode/48731>.

We are just guessing here and push the responsibility for proper
escaping to the target application.
---
 lisp/org.el |   13 -
 1 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 8a1fbd3..1274f24 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -9569,13 +9569,16 @@ application the system uses for this file type."
(apply cmd (nreverse args1
 
 ((member type '("http" "https" "ftp" "news"))
- (browse-url (concat type ":" (org-link-escape
-   path org-link-escape-chars-browser
+ (browse-url (concat type ":" (if (org-string-match-p "[[:nonascii:] 
]" path)
+  (org-link-escape
+   path org-link-escape-chars-browser)
+path
 
 ((string= type "doi")
- (browse-url (concat "http://dx.doi.org/";
-  (org-link-escape
-   path org-link-escape-chars-browser
+ (browse-url (concat "http://dx.doi.org/"; (if (org-string-match-p 
"[[:nonascii:] ]" path)
+  (org-link-escape
+   path 
org-link-escape-chars-browser)
+path
 
 ((member type '("message"))
  (browse-url (concat type ":" path)))
-- 
1.7.2.5



pgpe7Wxn4TYM0.pgp
Description: PGP signature

Re: [O] [bug] Org link dialog escapes URL spaces incorrectly

[David Maus]

Hi Jeff,

At Wed, 14 Dec 2011 20:30:06 -0500,
Jeff Horn wrote:
>
> On Sun, Nov 13, 2011 at 12:32, Nick Dokos  wrote:
> > Good enough for me. I don't remember whether you supplied a patch for this
> > (sorry, no time to check atm) but if you did, maybe the OP can test it and
> > make sure that it does what he expected (or maybe he's done that already -
> > I can't remember and I'm completely discombobulated right now, even more 
> > than
> > usual).
>
> I was sorry to hear about your family emergency. I hope you are feeling 
> better.
>
> I just tried with the latest source, and the problem still exists for me.
>
> Org-mode version 7.8.02 (release_7.8.02.3.gfb8c)
> GNU Emacs 24.0.90.3 (i386-apple-darwin9.8.0, NS apple-appkit-949.54)
> of 2011-12-14 on braeburn.aquamacs.org - Aquamacs Distribution 3.xdev

Yes, the problem still persists. I was waiting for 7.8 to be
released. I'll send a patch for the issue via mailing list this
evening and I hope this change won't break to much old links.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpGBfz11J2b2.pgp
Description: PGP signature

Re: [O] Is it possible for checkbox items to have :LOGBOOK: drawers?

[David Maus]

At Sat, 10 Dec 2011 18:13:14 +0100,
Steinar Bang wrote:
>
> Platform: Ubuntu 10.10
>   GNU Emacs 23.1.1
>   git version of org-mode
>
> When I create a TODO task, I first create the task, then I create
> checkboxes for the things I would like to do, ie.
>
> * My tasks
> ** TODO here's a new task [/]
>  - [ ] First I need to do this
>  - [ ] Then I need to do that
>  - [ ] Finally I need to finish this
>
> The reason for using checkboxes, is that I find them more visually
> pleasing than nested TODOs.  But when logging progress, I can't use the
> logbook functionality (like I could have done with nested TODOs).  I
> have ended up doing this:
>
> * My tasks
> ** TODO here's a new task [/]
>  - [ ] First I need to do this
>   - Logbook:
> - My first note
> - My second note
>  - [ ] Then I need to do that
>  - [ ] Finally I need to finish this
>
> That works, after a fashion.  But I get no timestamp on the notes,
> unless I remember to do a `C-.'
>
> I've tried putting :LOGBOOK: drawers in the checkboxes, and that seemed
> to work at first, but then I discovered that all notes ended up in the
> topmost checkbox, which just happened to reside under the first
> checkbox.
>
> Is there some variable that I can set to make :LOGBOOK: drawers work
> under checkboxes?  Is there some other similar solution?  (I'm on git
> org-mode at home, and use native emacs 23 org-mode and 7.7 on the
> windows boxes at work)

No, as far as I know it is not possible to attach a Drawer to a list
item.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpAlrNVMYjov.pgp
Description: PGP signature

Re: [O] "org-time-stamp" and "org-time-stamp-inactive" no longer work

[David Maus]

At Fri, 09 Dec 2011 20:49:36 +0100,
Bastien wrote:
>
> Hi,
>
> York Zhao  writes:
>
> > I have noticed this problem for awhile and now I think it is worth 
> > reporting it
> > and hopefully get fixed.
> >
> > Here is what happened when I hit "C-c !" in org buffer:
>
> I can't reproduce this.
>

Me neither.

Matt reported a similar problem in



But it seems the problem just ... fixed itself:

,
| However, oddly, after experiencing the same issue about 6 times in a
| row, the problem mysteriously disappeared just now, and the procedure
| is working fine.  I have no idea what the issue is there -- I'll
| report when I find it again.  Maybe someone on the list can give me
| suggestions for debugging if it shows up again?
`

To narrow down the bug it might be helpful to:

 1. Try to reproduce the bug with a minimal setup, just Emacs +
 uncompiled Org mode;

 2. If this is possible, see if it occurrs if the calendar buffer is
already open (e.g. M-x calendar RET) -- maybe this is some kind of
a weird race condition (?).

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgp1z1Nu6WpEh.pgp
Description: PGP signature

Re: [O] Bug: 2nd, 3rd, ... ext link in normal text NOT exported [7.7]

[David Maus]

At Mon, 5 Dec 2011 17:19:29 +0100,
M. Bauer wrote:
>
> Hi,
>
> as in the last paragraph of the Org v7.7 manual section 4.3 about
> external links, "Org also finds external links in the normal text
> and activates them as links."  While editing, this completely
> works as expected.
>
> But when it comes to exporting, Org will *not* recognize the
> second, third, etc. external link in normal text if it is *not*
> marked by square brackets.  See below for some tests that will
> fail in ASCII, UTF8, and HTML export.
>
> Can you please consider this issue for one of the next versions
> of Org?

Pushed a fix for this to master, all links in the example file are now
exported as expected.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpV4ghLSI8vD.pgp
Description: PGP signature

Re: [O] Bug: 2nd, 3rd, ... ext link in normal text NOT exported [7.7]

[David Maus]

At Mon, 5 Dec 2011 17:19:29 +0100,
M. Bauer wrote:
>
> Hi,
>
> as in the last paragraph of the Org v7.7 manual section 4.3 about
> external links, "Org also finds external links in the normal text
> and activates them as links."  While editing, this completely
> works as expected.
>
> But when it comes to exporting, Org will *not* recognize the
> second, third, etc. external link in normal text if it is *not*
> marked by square brackets.  See below for some tests that will
> fail in ASCII, UTF8, and HTML export.
>
> Can you please consider this issue for one of the next versions
> of Org?

I can confirm this bug for

Org-mode version 7.7 (release_7.7.619.g3aaa5)

on

GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of
2010-12-11 on raven, modified by Debian

Down in `org-export-normalize-links' Org skips the entire line if
there is a bracket link /anywhere/ on the line.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpMB9SwuttZg.pgp
Description: PGP signature

Re: [O] Capture mode fails until "reload org uncompiled" is used

[David Maus]

At Tue, 29 Nov 2011 20:02:22 + (UTC),
Felix wrote:
>
> When I fire up emacs and use C-c c t to enter a task (see .emacs below), I get
> the message "Capture template `t': org-called-interactively-p" and nothing
> happens. However, if I use the menu option "Org->Refresh/Reload->Reload Org
> Uncompiled", then C-c c t works correctly every time. I have provided a
> backtrace below (without "reload org uncompiled", since that fixes the 
> problem).
>
> Any suggestions to fix this so that I don't have to "reload org uncompiled"
> every time I start emacs? Thanks.

`org-called-interactively-p' is a macro, so maybe recompiling Org will
fix the problem. I.e. I cannot reproduce it with

Org-mode version 7.7 (release_7.7.532.gf48321)

GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of
2010-12-11 on raven, modified by Debian

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpKFMIRX5uBZ.pgp
Description: PGP signature

Re: [O] Bug: Cloning tasks deletes clock time in the original [7.7 (release_7.7-571-gf558105)]

[David Maus]

At Sat, 19 Nov 2011 21:37:08 -0500,
Bernt Hansen wrote:
>
> I have the entries I want but my original clock lines have been deleted.
> I would expect this behaviour for the newly created clones only - not
> the original entry.

Pushed a fix for this problem. Could you check it works out for you?

>
> I'm also not sure exactly why I get 3 entries when I ask for two --
> maybe that's a special case of the repeater in the original task but it
> feels weird.

Yes, it's the repeater: You get one for clone for free (C-h f
org-clone-subtree-with-time-shift). I agree it's not that intuitive.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpjAiCYQTt0j.pgp
Description: PGP signature

Re: [O] Bug: Cloning tasks deletes clock time in the original [7.7 (release_7.7-571-gf558105)]

[David Maus]

At Sat, 19 Nov 2011 21:37:08 -0500,
Bernt Hansen wrote:
>
>
> Consider the following org file:
>
> --8<---cut here---start->8---
> * Orig Task 1
> SCHEDULED: <2011-11-19 Sat +1w>
> :LOGBOOK:
> - Note taken on [2011-11-19 Sat 21:24] \\
>   foo
> CLOCK: [2011-11-18 Fri 20:30]--[2011-11-18 Fri 21:24] =>  0:54
> CLOCK: [2011-11-19 Sat 20:23]--[2011-11-19 Sat 21:23] =>  1:00
> :END:
> [2011-11-19 Sat 21:23]
> --8<---cut here---end--->8---
>
> This is a repeating task with some clock time on it.
>
> Now I need to change the 2nd occurrence from now so I clone the task to
> create 2 more followed by the repeater as follows:
>
> On the task do C-c C-x c 2 RET +1w RET
>
> Now I get this so I can edit one of the individual entries
>
> --8<---cut here---start->8---
> * Orig Task 1
> SCHEDULED: <2011-11-19 Sat>
> :LOGBOOK:
> - Note taken on [2011-11-19 Sat 21:24] \\
>   foo
> :END:
> [2011-11-19 Sat 21:23]
> * Orig Task 1
> SCHEDULED: <2011-11-26 Sat>
> :LOGBOOK:
> - Note taken on [2011-11-26 Sat 21:24] \\
>   foo
> :END:
> [2011-11-26 Sat 21:23]
> * Orig Task 1
> SCHEDULED: <2011-12-03 Sat>
> :LOGBOOK:
> - Note taken on [2011-12-03 Sat 21:24] \\
>   foo
> :END:
> [2011-12-03 Sat 21:23]
> * Orig Task 1
> SCHEDULED: <2011-12-10 Sat +1w>
> :LOGBOOK:
> - Note taken on [2011-12-10 Sat 21:24] \\
>   foo
> :END:
> [2011-12-10 Sat 21:23]
> --8<---cut here---end--->8---
>
> I have the entries I want but my original clock lines have been deleted.
> I would expect this behaviour for the newly created clones only - not
> the original entry.
>
> I ran into this for a weekly meeting task I cloned and ended up
> recovering my clock lines from my hourly git repository but this
> shouldn't be necessary.
>
> I'm also not sure exactly why I get 3 entries when I ask for two --
> maybe that's a special case of the repeater in the original task but it
> feels weird.

I can confirm this bug for

Org-mode version 7.7 (release_7.7.583.gedef1)

GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of
2010-12-11 on raven, modified by Debian

Looks like 516b2fbb8763788585ac6a9f60ad7d51c4b0aab3 is the culprit:
`template' also contains the original entry.

I'll see to provide a fix for this.

Best,
  -- David

--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpMkJnxOhRnE.pgp
Description: PGP signature

Re: [O] [test] Mark tests with missing dependencies as "expected to fail"

[David Maus]

At Sun, 13 Nov 2011 12:31:20 -0700,
Eric Schulte wrote:
>
> [1  ]
> David Maus  writes:
>
> > Hi Eric,
> >
> > At Tue, 18 Oct 2011 10:22:34 -0600,
> > Eric Schulte wrote:
> >> Hi David,
> >>
> >> I agree it would be preferable to note that not all tests are run when
> >> dependencies are missing, although I don't think it is extremely
> >> important.  I think some version of the above would be worthwhile if it
> >> could be done in a file-wide manner (as are the current dependency
> >> checks) and wouldn't require duplicating the dependency check or
> >> changing every test form individually.  Perhaps a file-local-variable
> >> could be used to expect failures for every form defined in the file?
> >
> > I tried the approach with a file-local variable but it didn't work
> > out: A macro can be expanded at any time, i.e. looks like there is no
> > way to obtain a reference to the buffer where the macro is defined at
> > expansion time.
> >
> > But finally came up with this one:
> >
>
> Nice macro,
>
> The only downside I see is the requirement to wrap every single deftest
> form which (to me) is too much overhead for too little payoff.  How
> about the following which will register a failing test for each file of
> tests not loaded due to missing dependencies.

The macro operates not just on a single `ert-deftest' form, but all
deftests in BODY. It kind-of works like a file local variable.

The current solution does its job, too -- so there's no need to use
this macro. Getting feedback about tests not run because of missing
dependencies is all I every wanted.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpkNkO2Z5yxV.pgp
Description: PGP signature

Re: [O] [test] Mark tests with missing dependencies as "expected to fail"

[David Maus]

Hi Eric,

At Tue, 18 Oct 2011 10:22:34 -0600,
Eric Schulte wrote:
> Hi David,
>
> I agree it would be preferable to note that not all tests are run when
> dependencies are missing, although I don't think it is extremely
> important.  I think some version of the above would be worthwhile if it
> could be done in a file-wide manner (as are the current dependency
> checks) and wouldn't require duplicating the dependency check or
> changing every test form individually.  Perhaps a file-local-variable
> could be used to expect failures for every form defined in the file?

I tried the approach with a file-local variable but it didn't work
out: A macro can be expanded at any time, i.e. looks like there is no
way to obtain a reference to the buffer where the macro is defined at
expansion time.

But finally came up with this one:

#+begin_src emacs-lisp
(defmacro org-test-with-dependencies (dependencies &rest body)
  "Mark `ert-deftest' forms in BODY with a expected result
depending on DEPENDENCIES.  DEPENDENCIES is an alist with a
human-readable name of the dependency as key. The second element
of each member should be a form that evaluates to a non-nil value
if the dependency is met.

All `ert-deftest' forms in BODY are marked as expected to pass if
all dependencies are met. Otherwise the expected result is set to
`:failed' and the test's bodies modified to signal an error with
an error message indicating the first failing dependency."
  (macrolet ((define-dependencies ()
   `(cond
 ,@(mapcar (lambda (dependency)
 `((not ,(second dependency)) ,(first 
dependency))) dependencies
(let ((missing-dependency (define-dependencies)))
  `(progn
 ,@(mapcar (lambda (sexp)
 (if (and (consp sexp)
  (eq (first sexp) 'ert-deftest))
 (let* ((docstring (if (stringp (fourth sexp)) 
(list (fourth sexp
(deftest-body (nthcdr (if docstring 4 3) 
sexp)))
   `(,@(append (list (first sexp) (second sexp) 
(third sexp)) docstring)
 :expected-result ,@(if missing-dependency
`(:failed (error 
"Missing dependency: %s" ,missing-dependency))
  '(:passed))
 ,@deftest-body))
   sexp)) body)
#+end_src

You wrap it around ert-deftest forms, e.g.

#+begin_src emacs-lisp
(org-test-with-dependencies (("ESS" (featurep 'ess)))
  (ert-deftest test-ob-R/simple-session ()
   (org-test-with-temp-text
   "#+begin_src R :session R\n  paste(\"Yep!\")\n#+end_src\n"
 (should (string= "Yep!" (org-babel-execute-src-block))
#+end_src

#+begin_quote
ELISP> (macroexpand '(org-test-with-dependencies (("ESS" (featurep 'ess))) 
(ert-deftest foo () t)))
(progn
  (ert-deftest foo nil :expected-result :failed
   (error "Missing dependency: %s" "ESS")
   t))

ELISP>
#end_quote

If this is acceptable I'd push it and start to adjust the test
definitions.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpOluycBrzcq.pgp
Description: PGP signature

Re: [O] [bug] Org link dialog escapes URL spaces incorrectly

[David Maus]

First sorry for the late response, some pressing family matters kept
me busy last week.

At Sun, 06 Nov 2011 17:29:06 -0500,
Nick Dokos wrote:
> No, I mean the handling in org-insert-link itself:
>
> line 9048 says
>
>   (setq link (org-extract-attributes
>   (org-link-unescape (org-match-string-no-properties 1

This is step 4: Org reads a bracket link from the buffer and these
links are expected to be escaped (step 2). The unescape restores the
original link.

> but further down, on line 9114 the link is not unescaped:
>
>   (setq link
> (let ((org-completion-use-ido nil)
>   (org-completion-use-iswitchb nil))
>   (org-completing-read
>"Link: "
>(append
> (mapcar (lambda (x) (list (concat x ":")))
> all-prefixes)
> (mapcar 'car org-stored-links))
>nil nil nil
>'tmphist
>(car (car org-stored-links)
Here we read the user's input and provide completion for stored links
and registered link types. There's no need to unescape the link, we
assume that whatever the user enters here is the link in its normal
form.

In both cases the minibuffer contains a link in its normal form. In
the first case obtaining the normal form requires unescaping because
whatever the user enters in the minibuffer is escaped once before
written to buffer.

To make things a little bit clearer lets look into the specs
(RFC3986):

#+begin_quote
2.4.  When to Encode or Decode

   Under normal circumstances, the only time when octets within a URI
   are percent-encoded is during the process of producing the URI from
   its component parts.  This is when an implementation determines which
   of the reserved characters are to be used as subcomponent delimiters
   and which can be safely used as data.  Once produced, a URI is always
   in its percent-encoded form.
#+end_quote

In other words: Steps 2 and 4, escaping and unescaping when a link is
written to or read from the buffer has nothing to do with
percent-escaping of URIs. Org just happens to use the percent-escaping
algorithm to store a link in the buffer and encode special chars
(i.e. brackets).

After reading the specs I'm quite confident that dropping the
percent-escaping of HTTP links in `org-open-at-point' is the right
thing to do: If you paste a URI from the browser or enter it manually
Org does not *produce* the URI and therefor is not responsible for
proper escaping or unescaping.

I think we should remove the percent-escaping in `org-open-at-point'
after 7.8 was released and see if this works out without breaking to
many links.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpEF8T3yHqSi.pgp
Description: PGP signature

Re: [O] [PATCH]: New Add defun org-mode-or-derived-mode-p

[David Maus]

At Thu, 03 Nov 2011 19:35:01 -0200,
Cassio Koshikumo wrote:
>
> Hi, all,
>
> On the last few days I've been working on a major mode derived from org-mode.
> While I was at it, I've encoutered some difficulties related to those reported
> by the OP (Stefan). Specifically: in a lot of places, org-mode will check if
> it's the current major-mode and, if it's not, will refuse to perform some
> important task.
>
> ...
>
> So, finally, here's my question: would it be possible to change all the (eq
> major-mode 'org-mode) tests and replace them with (derived-mode-p 'org-mode)? 
> Is
> there any reason not to do this?

Please see Carsten's post about the issue:

http://article.gmane.org/gmane.emacs.orgmode/47508

If you could provide a list of the functions that need to run in the
derived mode or a patch which changes these functions we could put in
the `derived-mode-p' selectively.

Best,
 -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpIkYAGR4trI.pgp
Description: PGP signature

[O] [test] Failure on GNU Emacs 22.3.2 (i686-pc-linux-gnu) of 2011-05-28 on x60s

[David Maus]

Running the test suit on

GNU Emacs 22.3.2 (i686-pc-linux-gnu) of 2011-05-28 on x60s

currently fails with the backtrace below.

Somehwere/somehow Babel ends up calling `member' with the second
argument not being a list. In Emacs22 this triggers an error, but not
so in Emacs23 and upwards.

Devs don't consider this a bug:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=264

Best,
  -- David

Debugger entered--Lisp error: (wrong-type-argument listp 58)
  member(118 58)
  (or (and (numberp spec) (= spec ch)) (member ch spec))
  (progn (or (and ... ...) (member ch spec)))
  (block matches (or (and ... ...) (member ch spec)))
  matches(118 58)
  (and (matches ch (cdr alts)) (matches last (car alts)))
  (catch (quote --cl-block-matched--) (and (matches ch ...) (matches last ...)))
  (cl-block-wrapper (catch (quote --cl-block-matched--) (and ... ...)))
  (block matched (and (matches ch ...) (matches last ...)))
  matched(118 58)
  (and (= balance 0) (matched ch last))
  (if (and (= balance 0) (matched ch last)) (progn (setq lst ...) (setq partial 
nil)))
  (when (and (= balance 0) (matched ch last)) (setq lst (cons ... lst)) (setq 
partial nil))
  (lambda (ch) (setq balance (+ balance ...)) (setq partial (cons ch partial)) 
(when (and ... ...) (setq lst ...) (setq partial nil)) (setq last ch))(118)
  mapc((lambda (ch) (setq balance (+ balance ...)) (setq partial (cons ch 
partial)) (when (and ... ...) (setq lst ...) (setq partial nil)) (setq last 
ch)) (58 118 97 114 32 105 110 112 117 116 61 34 101 99 104 111 39 100 34))
  (let ((balance 0) (partial nil) (lst nil) (last 0)) (mapc (lambda ... ... ... 
... ...) (string-to-list string)) (nreverse (cons ... lst)))
  (progn (fset (quote matched) (function* ...)) (let (... ... ... ...) (mapc 
... ...) (nreverse ...)))
  (unwind-protect (progn (fset ... ...) (let ... ... ...)) (if 
--cl-letf-bound-- (fset ... --cl-letf-save--) (fmakunbound ...)))
  (let* ((--cl-letf-bound-- ...) (--cl-letf-save-- ...)) (unwind-protect (progn 
... ...) (if --cl-letf-bound-- ... ...)))
  (letf ((... ...)) (let (... ... ... ...) (mapc ... ...) (nreverse ...)))
  (progn (fset (quote matches) (function* ...)) (letf (...) (let ... ... ...)))
  (unwind-protect (progn (fset ... ...) (letf ... ...)) (if --cl-letf-bound-- 
(fset ... --cl-letf-save--) (fmakunbound ...)))
  (let* ((--cl-letf-bound-- ...) (--cl-letf-save-- ...)) (unwind-protect (progn 
... ...) (if --cl-letf-bound-- ... ...)))
  (letf ((... ...)) (letf (...) (let ... ... ...)))
  (letf* ((... ...) (... ...)) (let (... ... ... ...) (mapc ... ...) (nreverse 
...)))
  (flet ((matches ... ...) (matched ... ...)) (let (... ... ... ...) (mapc ... 
...) (nreverse ...)))
  org-babel-balanced-split(":var input=\"echo'd\"" ((32 9) . 58))
  ((lambda (raw) (cons ... ...)) (org-babel-balanced-split arg-string (quote 
...)))
  (mapcar (lambda (arg) (if ... ... ...)) ((lambda ... ...) 
(org-babel-balanced-split arg-string ...)))
  (delq nil (mapcar (lambda ... ...) (... ...)))
  (org-babel-parse-multiple-vars (delq nil (mapcar ... ...)))
  (progn (org-babel-parse-multiple-vars (delq nil ...)))
  (if (> (length arg-string) 0) (progn (org-babel-parse-multiple-vars ...)))
  (when (> (length arg-string) 0) (org-babel-parse-multiple-vars (delq nil 
...)))
  org-babel-parse-header-arguments(":var input=\"echo'd\"")
  (org-babel-merge-params org-babel-default-header-args 
(org-babel-params-from-properties lang) (if (boundp lang-headers) (eval 
lang-headers) nil) (org-babel-parse-header-arguments 
(org-babel-clean-text-properties ...)))
  (list lang (with-temp-buffer (save-match-data ... ... ...)) 
(org-babel-merge-params org-babel-default-header-args 
(org-babel-params-from-properties lang) (if ... ... nil) 
(org-babel-parse-header-arguments ...)) switches block-indentation)
  (let* ((block-indentation ...) (lang ...) (lang-headers ...) (switches ...) 
(body ...) (preserve-indentation ...)) (list lang (with-temp-buffer ...) 
(org-babel-merge-params org-babel-default-header-args ... ... ...) switches 
block-indentation))
  org-babel-parse-src-block-match()
  (setq info (org-babel-parse-src-block-match))
  (save-excursion (goto-char head) (setq info 
(org-babel-parse-src-block-match)) (setq indent (car ...)) (setq info (butlast 
info)) (while (and ... ...) (setf ... ...)) (when (looking-at 
org-babel-src-name-w-name-regexp) (setq name ...) (when ... ...)))
  (if (setq head (org-babel-where-is-src-block-head)) (save-excursion 
(goto-char head) (setq info ...) (setq indent ...) (setq info ...) (while ... 
...) (when ... ... ...)) (when (org-babel-get-inline-src-block-matches) (setq 
info ...)))
  (let ((case-fold-search t) head info name indent) (if (setq head ...) 
(save-excursion ... ... ... ... ... ...) (when ... ...)) (when (and info ...) 
(setf ... ...)) (when info (append info ...)))
  org-babel-get-src-block-info(light)
  (let* ((info ...) (source-name ...)) (when source-name (setq source-name ... 
org-babel-library-of-babel ... lob-ingest-count ...))

Re: [O] [bug] Org link dialog escapes URL spaces incorrectly

[David Maus]

At Sat, 05 Nov 2011 11:38:56 -0400,
Nick Dokos wrote:
>
> David Maus  wrote:
>
> > At Fri, 04 Nov 2011 14:25:42 -0400,
> > Nick Dokos wrote:
> > >
> > > Nick Dokos  wrote:
> > >
> > > > It probably does, but that's probably not the best place to do it: it 
> > > > might be
> > > > better to do it in the (setq link on line 9090 or thereabouts. 
> > > > Otherwise, in
> > > > the *other* case (editing the link at point), we'll end up unescaping 
> > > > twice:
> > > > probably not a problem, since unescaping should be idempotent (in 
> > > > contrast to
> > > > escaping ;-) ) but why do it twice?
> > > >
> > >
> > > Brian Wightman pointed out to me that the idempotent part of the
> > > statement above is definitely wrong (d'oh). The original URL that Jeff
> > > Horn posted, when unescaped once, would be completely free of % signs.
> > > But if the second (doubly-escaped) form is pasted into the minibuffer,
> > > then unescaping once would not be enough. So I presume the thing to do
> > > is to take the URL and unescape it repeatedly until it loses all
> > > escapes, and then escape it *once* before inserting it in the org
> > > buffer.
> > >
> > > Sounds icky, kludgy, dirty. The question is: 1) is it a solution?
> > > and 2) is there a better one?
> >
> > No, this wouldn't be a solution. Consider a link with the sequence
> > %2525 -- Unescape until no more escapes (or rather "escapes") will
> > produce a single `%', not %25. Either escape once, or not at all.
> >
> > What roughly happens is this:
> >
> > 1. The user enters a link via `org-insert-link'
> > 2. Org escapes the link and writes it to the buffer
> > 3. The user opens the link with `org-open-at-poin'
> > 4. Org reads the link from the buffer and unescapes it
> > 5. The link gets escaped and passed to the cosuming application (i.e. 
> > browser)
> >
> > For steps 2 and 4 it is guaranteed that
> >
> > (string= link (org-link-unescape (org-link-escape link)))
> >
> > Thus, the problem is not in 2 or 4, but in 1 or 5.
> >
> > Step 5 assumes, that a link entered by the user in step 1 was an
> > unescaped link and thus needs escaping before it is passed to the
> > cosuming application. If you enter a link in step 1 that already is
> > escaped, this assumption fails and you'll end up with a double-escaped
> > link that is passed to the consumer.
> >
> > In other words, the question is: How to decide whether an arbitrary
> > URL is percent-escaped or not?
> >
> > Now here's the problem: You can't. Is
> >
> > "http://example.tld/foo%40bar";
> >
> > already escaped or not? You can't tell for sure. It depends on the
> > application you copied the link from.[1]
> >
> > What we could do in step 5 is... guess. If the (unescaped) link
> > produced by step 4 does contain characters that need escaping, we
> > escape the link. Otherwise we don't.
> >
> > Not quiet sure about the impact of such a change.
> >
> > Best,
> >  -- David
> >
> > [1] Even worse: It may even depend on /how/ or /where/ you copied the
> > link. E.g. the link to a wikipedia page about set theory is copied as
> >
> > http://de.wikipedia.org/wiki/Menge_%28Mathematik%29
> >
> > if C-c'ed from the address bar but copied as
> >
> > http://de.wikipedia.org/wiki/Menge_(Mathematik)
> >
> > if C-c'ed via "Copy link to clipboard" at another page (Iceweasel
> > 3.6.23).
>
> What a mess - thanks for the clear explanation. Be that as it may, the
> treatment of links in org-insert-link is inconsistent: in one case, the
> link is unescaped once, in the other not at all.

Hm. I still don't see an inconsistency here: `org-insert-link' reads a
link, `org-open-at-point' calls the target application with exactly
this link but applies percent escaping.

Maybe we could drop this last escaping and push the responsibilty of
handling non-conformant URLs to the target application. After all: If
the user enters an unescaped link and the target application can't
handle it, it's the users fault.

> So I presume that a single unescaping is desirable (it would
> e.g. deal with both wikipedia links correctly). But there will be
> corner cases where this will fail and some manual editing of the
> link will be necessary,

If you mean unescape the user input in step 1 (`org-insert-link'):
This could work, too. Besides the edge cases it requires some care to
stored links (via `org-store-links') -- the percent character is a
valid character for certain link types (e.g. message ids).

Personally I start to like the idea of just dopping the escaping
before calling the target application.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpuATnHWpNhE.pgp
Description: PGP signature

Re: [O] [bug] Org link dialog escapes URL spaces incorrectly

[David Maus]

At Fri, 04 Nov 2011 14:25:42 -0400,
Nick Dokos wrote:
>
> Nick Dokos  wrote:
>
> > It probably does, but that's probably not the best place to do it: it might 
> > be
> > better to do it in the (setq link on line 9090 or thereabouts. Otherwise, in
> > the *other* case (editing the link at point), we'll end up unescaping twice:
> > probably not a problem, since unescaping should be idempotent (in contrast 
> > to
> > escaping ;-) ) but why do it twice?
> >
>
> Brian Wightman pointed out to me that the idempotent part of the
> statement above is definitely wrong (d'oh). The original URL that Jeff
> Horn posted, when unescaped once, would be completely free of % signs.
> But if the second (doubly-escaped) form is pasted into the minibuffer,
> then unescaping once would not be enough. So I presume the thing to do
> is to take the URL and unescape it repeatedly until it loses all
> escapes, and then escape it *once* before inserting it in the org
> buffer.
>
> Sounds icky, kludgy, dirty. The question is: 1) is it a solution?
> and 2) is there a better one?

No, this wouldn't be a solution. Consider a link with the sequence
%2525 -- Unescape until no more escapes (or rather "escapes") will
produce a single `%', not %25. Either escape once, or not at all.

What roughly happens is this:

1. The user enters a link via `org-insert-link'
2. Org escapes the link and writes it to the buffer
3. The user opens the link with `org-open-at-poin'
4. Org reads the link from the buffer and unescapes it
5. The link gets escaped and passed to the cosuming application (i.e. browser)

For steps 2 and 4 it is guaranteed that

(string= link (org-link-unescape (org-link-escape link)))

Thus, the problem is not in 2 or 4, but in 1 or 5.

Step 5 assumes, that a link entered by the user in step 1 was an
unescaped link and thus needs escaping before it is passed to the
cosuming application. If you enter a link in step 1 that already is
escaped, this assumption fails and you'll end up with a double-escaped
link that is passed to the consumer.

In other words, the question is: How to decide whether an arbitrary
URL is percent-escaped or not?

Now here's the problem: You can't. Is

"http://example.tld/foo%40bar";

already escaped or not? You can't tell for sure. It depends on the
application you copied the link from.[1]

What we could do in step 5 is... guess. If the (unescaped) link
produced by step 4 does contain characters that need escaping, we
escape the link. Otherwise we don't.

Not quiet sure about the impact of such a change.

Best,
 -- David

[1] Even worse: It may even depend on /how/ or /where/ you copied the
link. E.g. the link to a wikipedia page about set theory is copied as

http://de.wikipedia.org/wiki/Menge_%28Mathematik%29

if C-c'ed from the address bar but copied as

http://de.wikipedia.org/wiki/Menge_(Mathematik)

if C-c'ed via "Copy link to clipboard" at another page (Iceweasel
3.6.23).
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpD1EDf8GgHO.pgp
Description: PGP signature

Re: [O] Org-mode 7.7 Broken with respect to mouse and checklists?

[David Maus]

At Sat, 05 Nov 2011 09:31:25 +0100,
Nicolas Goaziou wrote:
>
> Hello,
>
> Patrick Brennan  writes:
>
> > I have a checklist in this form:
> >
> > - [ ] Item One
> > - [ ] Item Two
> >
> > In Org-mode 7.7, if I put my mouse inside one of the checks and press the
> > left button, I get the following message:
> >
> > org-open-at-point: Wrong type argument: markerp, 471
>
> I cannot reproduce it on development version. You may want to upgrade to
> it, or wait for stable version 7.8 to be released.

I can confirm this bug for Org 7.7, but it's fixed in current
development version.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgp8HLp477SFO.pgp
Description: PGP signature

Re: [O] org-mobile-push problem

[David Maus]

At Wed, 02 Nov 2011 19:28:52 -0400,
Nick Dokos wrote:
>
> i...@bastianebeling.org  wrote:
>
> > > Hi All,
> > >
> > > I'm trying to set up MobileOrg to try it out, but I'm getting the
> > > following error when I run org-mobile-push:
> > >
> > > byte-code: Invalid function: org-eval-in-environment
> >
> >
> > Hi,
> >
> > I have the same problem and get the same error message. My only fix is
> > to hit C-u C-c C-x r (reload Org uncompiled) before running
> > org-mobile-push. I would be very interested in ideas for a real
> > solution, too.
> >
>
> org-eval-in-environment is a macro defined in org-macs.el and macros
> sometimes cause problems with compiled code unless some care is taken.
> With uncompiled code, you just have to make sure that the macro
> definition is loaded, before you do the org-mobile-push: just add
>
> (require 'org-macs)
>
> after you load org in your .emacs (or wherever).
>
> Afaict, it is not called directly from org-mobile-push, but the agenda
> code does call it (and does not require it), so maybe the solution is
> that the (require 'org-macs) should be added to org-agenda.el; you might
> try it and see whether it resolves the problem for you, but I'll let
> David Maus or Achim Gratz or some other macro guru have the final word.

In the past the invalid function error indicated an unclean source
tree, thus a

make clean && make

should fix the error.

A (require 'org-macs) should not be necessary because if the macro
would not have been availabe in `org-agenda' the compiler would have
complained.

Best,
 -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpbogWQsy52f.pgp
Description: PGP signature

Re: [O] Incorrect html export link for "%252F" forward slash

[David Maus]

At Fri, 28 Oct 2011 18:15:47 -0700,
Robert Hotchkiss wrote:
>
>
> Remember to cover the basics, that is, what you expected to happen and
> what in fact did happen.  You don't know how to make a good report?  See
>
>  http://orgmode.org/manual/Feedback.html#Feedback
>
> Your bug report will be posted to the Org-mode mailing list.
> 
>
> Problem: when exporting as html an org file that has links with URLs that 
> contain
> "%252F" for a forward slash, the resulting html link description differs
> significantly from the link definition listed in the orgfile. For
> example, in the following example, the org file link description is
>
> "Cannot reinstall an agent"
>
> Whereas the resulting browser link is
>
>  href="http://publib.boulder.ibm.com/infocenter/tivihelp/v4r1/index.jsp?topic=/com.ibm.tpc_V421.doc/fqz0_r_tbs_agent_cleanup.html";>//publib.boulder.ibm.com/infocenter/tivihelp/v4r1/index.jsp?topic=/com.ibm.tpc_V421.doc/
> fqz0_r_tbs_agent_cleanup.html
>
> and this link is surrounded by additional text, including the original
> link description. The resulting href is correct and thus clicking on the
> links takes the browser user to the correct web page, but the
> extraneous and descriptive text is unexpected behavior.

Thanks for the report. I can confirm this for Org 7.7, it seems to be
fixed in current master, i.e. the link exports to:

,
| Then clean up common agent residue: http://publib.boulder.ibm.com/infocenter/tivihelp/v4r1/index.jsp?topic=%2Fcom.ibm.tpc_V421.doc%2Ffqz0_r_tbs_agent_cleanup.html";>Cannot
 reinstall an agent in TPC 4.2.1 InfoCenter
`

Best
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgptSfIg6NN9p.pgp
Description: PGP signature

[O] [test] Mark tests with missing dependencies as "expected to fail"

[David Maus]

Hi all,

Currently tests with missing dependency are silently skipped -- it
might be worth changing this behavior to not skip them, but mark them
as expected to fail. You can do this in ERT by placing the
keyword :expected-result followed by either :passed or :failed before
the test's body.

Benefit of this is that the tests w/ missing dependencies will show up
in the ERT result page (with a small letter f) but (obviously) don't
count as failures.

The following macro is a first shot at a convenient way to define
tests with dependencies:

#+begin_src emacs-lisp
  (defmacro org-test-deftest-with-dependency (dependency &rest body)
(let* ((docstring (if (stringp (third body)) (list (third body
   (deftest (nthcdr (if docstring 3 2) body))
   (dependency-p (eval dependency)))
  `(ert-deftest ,@(append (list (first body) (second body)) docstring)
   ,@(if dependency-p
 '(:expected-result :passed)
   '(:expected-result :failed (error "Missing dependency")))
 ,@deftest)))
#+end_src

Here DEPENDENCY is a simple form that evaluates to non-nil if the
dependency is met. If marking the tests this way is the agreed way to
go we can extend the syntax of a dependency to an alist with a
human-readable description of the dependency as key and a list of
forms that all must eval to non-nil as value. E.g.

#+begin_src emacs-lisp
  (defvar test-ob-R-dependencies
'(("R executable" (org-test-for-executable "R"))
  ("Package ESS" (featurep 'ess
#+end_src

And change the expander code to map through this alist and as soon one
dependency evals to nil sets a variable `dependency-missing' to the
respective dependency.

Any comments on this?

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpd0RqkU37fe.pgp
Description: PGP signature

Re: [O] Invalid function: org-called-interactively-p

[David Maus]

At Sun, 09 Oct 2011 22:04:47 +0530,
Jambunathan K wrote:
>
>
> Seems like a bug to me.

Not necessarily: From past experience an invalid function error is an
indicator of a mixed up Org mode installation. What roughly happens is
that Emacs tries to look up a function value for
`org-called-interactively-p' but does not get a valid function because
`org-called-interactively-p' is a macro.[1]

Normally a make clean && make in the source tree solves this kind of problem.


Best,
  -- David

[1] http://www.gnu.org/s/emacs/manual/html_node/elisp/Function-Indirection.html
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgp3JUscIeyEI.pgp
Description: PGP signature

Re: [O] [PATCH 0/5] loop over headlines in active region

[David Maus]

At Sat, 8 Oct 2011 22:11:37 +0200,
Carsten Dominik wrote:
>
> Hi David,
>
> On 8.10.2011, at 20:59, David Maus wrote:
>
> > Hi Carsten,
> >
> > At Thu, 6 Oct 2011 10:35:18 +0200,
> > Carsten Dominik wrote:
> >>
> >> Hi David,
> >>
> >> I see that this patch is still on the patchwork server.
> >> What is the status, I remember that you dot a number of
> >> comments
> >
> > Started to make a list of Org's behavior with headlines when region is
> > active but didn't make much progress. Besides that I'm waiting for
> > some feedback by Bastien.
> >
> > Personally I think we can turn the state to "Deferred" -- I don't
> > consider it of high importance. I gave up on using the functionallity
> > in favour of Agenda's bulk operations and rescheduling/deadlining
> > multiple items in the same buffer does not happen that often.
>
> OK, lets do that, I agree.  I guess this applies to the whole batch,
> 910, 911, 925, 926?  I have lost the overview a bit.
> Will you change the status?

Done.

Any information about Bastien's absence? I remember he announce to be
on vacation till Sep 5, but as far as I could see hasn't appeared to
be be active on the list.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpgQwlr1JUFm.pgp
Description: PGP signature

Re: [O] [PATCH 0/5] loop over headlines in active region

[David Maus]

Hi Carsten,

At Thu, 6 Oct 2011 10:35:18 +0200,
Carsten Dominik wrote:
>
> Hi David,
>
> I see that this patch is still on the patchwork server.
> What is the status, I remember that you dot a number of
> comments

Started to make a list of Org's behavior with headlines when region is
active but didn't make much progress. Besides that I'm waiting for
some feedback by Bastien.

Personally I think we can turn the state to "Deferred" -- I don't
consider it of high importance. I gave up on using the functionallity
in favour of Agenda's bulk operations and rescheduling/deadlining
multiple items in the same buffer does not happen that often.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpuj8tHgyAds.pgp
Description: PGP signature

[O] [patch] contrib/lisp/org-elisp-symbol: Set type if symbol is defuned but not fbound

[David Maus]

Another small patch for org-elisp-symbol: Set the symbol type to
"Function or command" if it is defuned but not fbound when
`org-elisp-symbol-store-link' is called.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de
From 09f5f322d418afe34503d8758ad123cd6c8045a0 Mon Sep 17 00:00:00 2001
From: David Maus 
Date: Sun, 25 Sep 2011 18:16:54 +0200
Subject: [PATCH] Set symbol type if defun but symbol not fbound

* org-elisp-symbol.el (org-elisp-symbol-store-link): Set symbol type
if defun but symbol not fbound.

If the symbol is not fbound but defuned, set type to "function or
command".
---
 contrib/lisp/org-elisp-symbol.el |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/contrib/lisp/org-elisp-symbol.el b/contrib/lisp/org-elisp-symbol.el
index 6eb8114..340272b 100644
--- a/contrib/lisp/org-elisp-symbol.el
+++ b/contrib/lisp/org-elisp-symbol.el
@@ -106,6 +106,7 @@
  ((user-variable-p sym-name) "User variable")
  ((string= def "defvar") "Variable")
  ((string= def "defmacro") "Macro")
+ ((string= def "defun") "Function or command")
  (t "Symbol")))
 (args (if (match-string 3)
   (mapconcat (lambda (a) (unless (string-match "^&" a) a))
-- 
1.7.2.5



pgpLXa5JB8hPg.pgp
Description: PGP signature

Re: [O] [PATCH] Modifications to enable test script to run with emacs-23 and emacs-22

[David Maus]

Hi Eric,
Hi Martyn,

At Tue, 20 Sep 2011 09:03:27 -0600,
Eric Schulte wrote:
>
> Applied, Thanks! -- Eric

I noticed that newlines in the commit messages of patches by Martyn
are somehow messed up:

,
| Modifications to enable test script to run with emacs-23 and emacs-22 * 
testing/org-test.el: enable test script to run with emacs-23 and emacs-22 * 
testing/lisp/test-org-exp.el: added org-ascii requirement
`

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpdSTFxk8QrI.pgp
Description: PGP signature

Re: [O] FYI: Org mode testing framework, Emacs 23 and 22

[David Maus]

At Thu, 22 Sep 2011 07:44:42 -0600,
Eric Schulte wrote:
>
> >
> >>
> >> >
> >> > F test-ob-exp/org-babel-exp-src-blocks/w-no-file
> >> > Testing export from buffers which are not visiting any file.
> >> > (wrong-type-argument stringp nil)
> >> >
> >> > F test-ob-exp/org-babel-exp-src-blocks/w-no-headers
> >> > Testing export without any headlines in the org-mode file.
> >> > (wrong-type-argument stringp nil)
> >> >
> >> > F test-ob-lob/export-lob-lines
> >> > Test the export of a variety of library babel call lines.
> >> > (wrong-type-argument stringp nil)
> >> >
> >>
> >> I have no idea what could be going wrong with these executions, would it
> >> be difficult to generate backtraces for these failures?
> >
> > No, its really easy (as expected w/ Emacs): Section on interactive
> > debugging ERT mentions "b" to create the backtrace.
> >
> > In case of w-no-file and w-no-headers `org-todo-line-regexp' is bound
> > to nil, in export-lob-lines `org-maybe-keyword-time-regexp' is bound
> > to nil. Backtraces are attached.
> >
>
> So,
>
> Could it be that for some reason using Emacs22 all variable whose values
> are set in `org-set-regexps-and-options' immediately following
>
>   ;; Compute the regular expressions and other local variables
>
> in org.el are somehow not having their values set?

Nope, turns out that .org is not in Emacs22's auto-mode-alist and thus
the examples files are not opened in Org mode. Pushed a fix, turn on
Org mode before running the test body.

Now I get a beautiful:

,
| Selector: "\\(org\\|ob\\)"
| Passed: 111
| Failed: 0
| Total:  111/111
|
| Started at:   2011-09-25 09:26:09+0200
| Finished.
| Finished at:  2011-09-25 09:26:13+0200
|
| 
...
`

for GNU Emacs 22.3.2 (i686-pc-linux-gnu) of 2011-05-28 on x60s with
Org-mode version 7.7 (release_7.7.323.g07d11) \o/

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpFqAbRYmKJ1.pgp
Description: PGP signature

Re: [O] Bug: unable to open link unless `...from-string' [7.7 (release_7.7.292.g0d4e8.dirty)]

[David Maus]

At Thu, 22 Sep 2011 10:13:18 -0400,
Dave Abrahams wrote:
>
>
> on Thu Sep 22 2011, David Maus  wrote:
>
> >> > The link escaping was changed in November 2010, maybe the link in
> >> > question is an old one?
> >>
> >> Yep.
> >
> > Good. This explains it.
>
> I think it's unfortunate that link escaping should have been changed in
> a backward-incompatible way.  Seems like the "right" thing to do would
> have been to add a fallback to the old interpretation if the new one
> failed.

True, but the problem is that AFAIK there is now way to
programmatically check if the new escpaing/unescaping fails. There is
this function:

http://orgmode.org/worg/org-hacks.html#check-old-link-escapes

,
| Starting with version 7.5 Org uses percent escaping more consistently
| and with a modified algorithm to determine which characters to escape
| and how.
|
| As a side effect this modified behaviour might break existing links if
| they contain a sequence of characters that look like a percent escape
| (e.g. [0-9A-Fa-f]{2}) but are in fact not a percent escape.
|
| The function below can be used to perform a preliminary check for such
| links in an Org mode file. It will run through all links in the file
| and issue a warning if it finds a percent escape sequence which is not
| in old Org's list of known percent escapes.
`

that might at least tell you if there is a problematic link in an Org
mode buffer. What to do if the func finds a possibly problematic
sequence depends on the link. In the "%dave"-case escaping the percent
sign (% => %25) could be sufficient.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpM4W71yYEc4.pgp
Description: PGP signature

Re: [O] Bug: File Links [6.33x]

[David Maus]

At Thu, 22 Sep 2011 18:07:25 -0400,
Nick Dokos wrote:
>
> Edward N. Lewis  wrote:
>
>
> > Links to external pdf files do not work in org-mode. Links do not export 
> > properly
> > into PDF files. Links to web addresses and other file types such as text 
> > files work fine, however.
> >
> > To reproduce: create a link in your org file in any form,
> > e.g. [[file:/full_path/whatever.pdf]],
> > [[file:/full_path/whatever.pdf][Label for file]], file:whatever.pdf.
> >
> > 1) The link will not work from within org-mode.
> > 2) The link will not be properly formatted when viewed in a PDF viewer
> > such as Adobe Acrobat Professional. To make the link work, the link's
> > properties have to be manually edited from within Adobe Acrobat/
> >
> > Emacs  : GNU Emacs 23.2.1 (i386-redhat-linux-gnu, GTK+ Version 2.24.4)
> >  of 2011-05-23 on x86-05.phx2.fedoraproject.org
> > Package: Org-mode version 6.33x
> >
>
> I cannot reproduce this with Org-mode version 7.7
> (release_7.7.311.g0c099), so I'd suspect your 6.33 (which is quite old,
> but unfortunately still ships with older versions of emacs). If you are
> at all serious about using org-mode, you probably need to install the
> 7.7 release (or if you are willing to live on the edge, clone the git
> repository and enjoy all the up-to-date features - and some breakages,
> but ime, breakages get fixed quickly).

I cannot reproduce it with

GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11 on 
raven, modified by Debian

Org-mode version 6.33f (release_6.33f)

neither. The minimal Emacs initfile used:

,
| (add-to-list 'load-path "~/projects/org-mode/org-mode/lisp")
| (add-to-list 'load-path "~/projects/org-mode/org-mode/contrib/lisp")
| (add-to-list 'load-path "~/projects/org-mode/org-mode/testing/")
| (require 'org-install)
| (require 'org)
`

If I use C-c C-o on the links Org starts my PDF viewer (xpdf 3.02), if
I export the document with the link to PDF and open the result with
xpdf the exported link works, too.

What exactly happens if you try to open the link and which properties
do you have to modify to make the exported link working?

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpBeGJfMiNML.pgp
Description: PGP signature

Re: [O] Bug: unable to open link unless `...from-string' [7.7 (release_7.7.292.g0d4e8.dirty)]

[David Maus]

At Tue, 20 Sep 2011 12:24:48 -0400,
Dave Abrahams wrote:
>
>
> on Tue Sep 20 2011, David Maus  wrote:
>
> > The original link is alread "wrong", i.e. unescaped.
> >
> > The key question are
> >
> >  1. How did you create the original link?
>
> I used this code:
> https://github.com/dabrahams/elisp/blob/master/elisp/autoload.d/wl-setup.el#L801
> Is there some encoding step I should have applied?

Nope, the code should do the trick. The escaping is currently done
when the link is inserted via `org-insert-link'.

>
> >  2. When did you create the original link?
>
> It might have been as long as a year ago
>
> > I tried taking a link with `org-store-link' and insert it with
> > `org-insert-link' and the link was properly escaped.
> >
> > The link escaping was changed in November 2010, maybe the link in
> > question is an old one?
>
> Yep.

Good. This explains it.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgptdJKBMFqOP.pgp
Description: PGP signature

Re: [O] Bug: unable to open link unless `...from-string' [7.7 (release_7.7.292.g0d4e8.dirty)]

[David Maus]

At Fri, 16 Sep 2011 14:20:50 -0400,
Dave Abrahams wrote:
>
>
> on Fri Sep 16 2011, David Maus  wrote:
>
> > How did you enter the link into the Org file?
> >
> > The original link
> >
> > [[message://m2k4n46n5p.wl%d...@boostpro.com]]
> >
> > Is unescaped, but Org treats links as always percent-escaped. What
> > happens is that "%da" is treated as a percent escaped character and
> > unescaped after read from buffer.
> >
> > The link should read:
> >
> > message://m2k4n46n5p.wl%25d...@boostpro.com
>
> Yeah, I finally figured that out.
>
> > This is a troublesome situation
> >
> > https://lists.gnu.org/archive/html/emacs-orgmode/2011-09/msg00257.html
> >
> > But up to know I didn't find a solution for it.
>
> Hmm, well, ... the link started out as a a wanderlust link of a form
> more like this:
>
>   
> [[wl:/message-id:""/%%5BGmail%5D/All%20Mail#103387bf-79b8-4389-ad51-955087347...@gmail.com]]
>
> _That_ link used to work.  I transformed links like that by
> search/replace into:
>
>   [[message://m2k4n46n5p.wl%d...@boostpro.com]]
>
> So maybe it's my fault?

The original link is alread "wrong", i.e. unescaped.

The key question are

 1. How did you create the original link?
 2. When did you create the original link?

I tried taking a link with `org-store-link' and insert it with
`org-insert-link' and the link was properly escaped.

The link escaping was changed in November 2010, maybe the link in
question is an old one?

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgp7yKGM9pvf3.pgp
Description: PGP signature

Re: [O] FYI: Org mode testing framework, Emacs 23 and 22

[David Maus]

At Sat, 17 Sep 2011 14:56:09 -0600,
Eric Schulte wrote:
> 
> Hi David,
> 
> >
> > For Emacs22 the only thing we need from simple.el is the definition of
> > special-mode; going to factor it out and trim it to Emacs22.
> >
> 
> Sounds great, thanks.
> 
> >
> > With HEAD at dbf0e6d5bcbe94c8ee57d68889d3c25bf9cdef55 and a fix for
> > the check for featurep 'org (37db5deea5ef75186bb7413b196fa0c96e5bdfb9)
> > I got:
> >
> 
> Thanks for compiling this information.
> 
> >
> >
> > Selector: "\\(org\\|ob\\)"
> > Passed: 99
> > Failed: 10 (10 unexpected)
> > Total:  109/109
> >
> > Started at:   2011-09-16 06:56:59+0200
> > Finished.
> > Finished at:  2011-09-16 06:57:04+0200
> >
> > ..FF...FF..F.F...FF.F..F.
> >
> > F ob-fortran/list-var
> > Test real array input
> > (void-function characterp)
> >
> > F ob-fortran/list-var-from-table
> > Test real array from a table
> > (void-function characterp)
> >
> 
> I've replaced the use of `characterp' in ob-fortran with integerp, which
> should be backwards-compatible with emacs22.
> 
> >
> > F test-ob-exp/org-babel-exp-src-blocks/w-no-file
> > Testing export from buffers which are not visiting any file.
> > (wrong-type-argument stringp nil)
> >
> > F test-ob-exp/org-babel-exp-src-blocks/w-no-headers
> > Testing export without any headlines in the org-mode file.
> > (wrong-type-argument stringp nil)
> >
> > F test-ob-lob/export-lob-lines
> > Test the export of a variety of library babel call lines.
> > (wrong-type-argument stringp nil)
> >
> 
> I have no idea what could be going wrong with these executions, would it
> be difficult to generate backtraces for these failures?
> 
> >
> > F test-ob-sh/dont-error-on-empty-results
> > Was throwing an elisp error when shell blocks threw errors and
> > (void-function org-babel-execute:sh)
> >
> > F test-org-babel/inline-src-blocks
> > (error "No org-babel-execute function for sh!")
> >
> > F test-org-babel/inline-src_blk-default-results-replace-line-1
> > (error "No org-babel-execute function for sh!")
> >
> 
> It looks like you need to load ob-sh.el.
> 
> >
> > F test-org-exp/stripping-commas
> > Test the stripping of commas from within blocks during export.
> > (wrong-type-argument stringp nil)
> >
> > F test-org/org-link-unescape-ascii-extended-char
> > Unescape old style percent escaped character.
> > (ert-test-failed
> >  ((should
> >(string= "àâçèéêîôùû"
> > (org-link-unescape "%E0%E2%E7%E8%E9%EA%EE%F4%F9%FB")))
> >   :form
> >   (string= "àâçèéêîôùû" "\340\342\347\350\351\352\356\364\371\373")
> >   :value nil))
> >
> 
> Hmm, I don't know anything about possible differences in string handling
> between Emacs22 and more modern Emacsen, but I wouldn't be surprised if
> support for accented characters was less complete in Emacs22.  Perhaps
> we should just skip this test on Emacs22.

Nope, this test is fixed. Had to explicitely tell Emacs that the
expected output string is latin-1; i.e. the input is extended ASCII
which is covered by latin-1 encoding. The test failed because
org-link-unescape returned the raw byte sequence.

I am aware that there might be a problem with opening links that
contain extended ASCII characters (=Org's old escaping choice) and I'm
going to test this next. 

The test is fine, though. The expected output is a latin-1 encoded
string.

Best,
  -- David
-- 
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpNWtYccCf5Q.pgp
Description: PGP signature

Re: [O] FYI: Org mode testing framework, Emacs 23 and 22

[David Maus]

At Sat, 17 Sep 2011 14:56:09 -0600,
Eric Schulte wrote:
> 
> Hi David,
> 
> >
> > For Emacs22 the only thing we need from simple.el is the definition of
> > special-mode; going to factor it out and trim it to Emacs22.
> >
> 
> Sounds great, thanks.
> 
> >
> > With HEAD at dbf0e6d5bcbe94c8ee57d68889d3c25bf9cdef55 and a fix for
> > the check for featurep 'org (37db5deea5ef75186bb7413b196fa0c96e5bdfb9)
> > I got:
> >
> 
> Thanks for compiling this information.
> 
> >
> >
> > Selector: "\\(org\\|ob\\)"
> > Passed: 99
> > Failed: 10 (10 unexpected)
> > Total:  109/109
> >
> > Started at:   2011-09-16 06:56:59+0200
> > Finished.
> > Finished at:  2011-09-16 06:57:04+0200
> >
> > ..FF...FF..F.F...FF.F..F.
> >
> > F ob-fortran/list-var
> > Test real array input
> > (void-function characterp)
> >
> > F ob-fortran/list-var-from-table
> > Test real array from a table
> > (void-function characterp)
> >
> 
> I've replaced the use of `characterp' in ob-fortran with integerp, which
> should be backwards-compatible with emacs22.
> 
> >
> > F test-ob-exp/org-babel-exp-src-blocks/w-no-file
> > Testing export from buffers which are not visiting any file.
> > (wrong-type-argument stringp nil)
> >
> > F test-ob-exp/org-babel-exp-src-blocks/w-no-headers
> > Testing export without any headlines in the org-mode file.
> > (wrong-type-argument stringp nil)
> >
> > F test-ob-lob/export-lob-lines
> > Test the export of a variety of library babel call lines.
> > (wrong-type-argument stringp nil)
> >
> 
> I have no idea what could be going wrong with these executions, would it
> be difficult to generate backtraces for these failures?
> 
> >
> > F test-ob-sh/dont-error-on-empty-results
> > Was throwing an elisp error when shell blocks threw errors and
> > (void-function org-babel-execute:sh)
> >
> > F test-org-babel/inline-src-blocks
> > (error "No org-babel-execute function for sh!")
> >
> > F test-org-babel/inline-src_blk-default-results-replace-line-1
> > (error "No org-babel-execute function for sh!")
> >
> 
> It looks like you need to load ob-sh.el.
> 
> >
> > F test-org-exp/stripping-commas
> > Test the stripping of commas from within blocks during export.
> > (wrong-type-argument stringp nil)

And last not least: In this case it is `org-todo-line-regexp' bound to
nil, too.

> >
> > F test-org/org-link-unescape-ascii-extended-char
> > Unescape old style percent escaped character.
> > (ert-test-failed
> >  ((should
> >(string= "àâçèéêîôùû"
> > (org-link-unescape "%E0%E2%E7%E8%E9%EA%EE%F4%F9%FB")))
> >   :form
> >   (string= "àâçèéêîôùû" "\340\342\347\350\351\352\356\364\371\373")
> >   :value nil))
> >
> 
> Hmm, I don't know anything about possible differences in string handling
> between Emacs22 and more modern Emacsen, but I wouldn't be surprised if
> support for accented characters was less complete in Emacs22.  Perhaps
> we should just skip this test on Emacs22.

I'll dig into the link escaping failure.

Best,
  -- David
-- 
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgp068gV55Vhj.pgp
Description: PGP signature

Re: [O] FYI: Org mode testing framework, Emacs 23 and 22

[David Maus]

At Sat, 17 Sep 2011 14:56:09 -0600,
Eric Schulte wrote:
>
> >
> > F test-ob-sh/dont-error-on-empty-results
> > Was throwing an elisp error when shell blocks threw errors and
> > (void-function org-babel-execute:sh)
> >
> > F test-org-babel/inline-src-blocks
> > (error "No org-babel-execute function for sh!")
> >
> > F test-org-babel/inline-src_blk-default-results-replace-line-1
> > (error "No org-babel-execute function for sh!")
> >
>
> It looks like you need to load ob-sh.el.

Yes, (require 'ob-sh) is sufficient to remove these three from the
list of failing tests.

Best,
  -- David

--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpGa49QTgzBi.pgp
Description: PGP signature

Re: [O] emacs-orgmode youtube videos questions

[David Maus]

At Fri, 16 Sep 2011 23:34:44 -0400 (EDT),
Jude DaShiell wrote:
>
> Will mplayer play those videos?

mplayer-mt from debian-multimedia.org on Debian GNU/Linux 6.0.2
(current stable) has no problems to play videos I downloaded with
youtube-dl (from Wheezy). IIRC the mplayer shipped with Debian 6.0.2
had no problems with .flv neither.

> If yes, what kind of .mailcap entry will be needed to enable the
> lynx browser to have mplayer used to play those videos when I hit
> enter on a link?

Can't help with that.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpBPQ3CdlKaM.pgp
Description: PGP signature

Re: [O] Problems with Org-Mode export

[David Maus]

At Fri, 16 Sep 2011 10:50:01 -0700 (PDT),
Michael Hannon wrote:
> Greetings.  I've been having problems lately in exporting Org-Mode source-code
> documents to HTML and/or PDF.
> 
> I'm running Org-Mode 7.7 with Emacs 23 on 64-bit linux (Fedora 15).
> 
> I've appended a document that exhibits at least some of the problem.  The
> problems are similar to the problem described at:
> 
> http://comments.gmane.org/gmane.emacs.orgmode/45316
> 
> and can *sometimes* be circumvented by executing org-reload.
> 
> In the particular example shown below, the HTML export works as expected, but
> the PDF export fails with message:
> 
> org-export-latex-preprocess: Wrong type argument: stringp, nil
> 
> By the way, everything worked fine in the example until I added the last
> source block:
> 
> #+begin_src R
> 
>   x
> 
> #+end_src
> 
> I tried using what I take to be the latest version of Org-Mode:
> 
> Org-mode version 7.7 (release_7.7.290.g65d05)
> 
> but that only made things worse.  I tried an HTML export with this version, 
> and
> it generated a horrendous-looking message that begins with:
> 
> org-babel-R-evaluate: Wrong number of arguments: #[(session body result-type
> result-params column-names-p row-names-p) Æ=}...
> 
> followed by a bunch of stuff containing enough non-printing characters that
> it's hard to reproduce in email, and ending with:
> 
> ...org-mode/lisp/ob-R.elc" . 9734)], 5
> 
> I'd welcome any help/advice that anybody can provide.


Could I ask you to provide the entire backtrace for both errors?

M-x toggle-debug-on-error RET

The backtrace might contain information about the exact place where a
string is expected. If you can't copy it into the email program save
to disk + gzip + attach should do the trick.

Best,
  -- David
-- 
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpAA75epbMNO.pgp
Description: PGP signature

Re: [O] Bug: unable to open link unless `...from-string' [7.7 (release_7.7.292.g0d4e8.dirty)]

[David Maus]

At Fri, 16 Sep 2011 12:03:51 -0400,
Dave Abrahams wrote:
> 
> 
> 
> Remember to cover the basics, that is, what you expected to happen and
> what in fact did happen.  You don't know how to make a good report?  See
> 
>  http://orgmode.org/manual/Feedback.html#Feedback
> 
> Your bug report will be posted to the Org-mode mailing list.
> 
> 
> I have an Org link as follows:
> 
>   [[message://m2k4n46n5p.wl%d...@boostpro.com]]
> 
> When I try to `C-c C-o' it, opening fails because the link-handling code
> sees this string for the link:
> 
>   "m2k4n46n5p.wlÚv...@boostpro.com"
> 
> which you may notice is different.  If I do 
> 
>(org-open-link-from-string "message://m2k4n46n5p.wl%d...@boostpro.com")

How did you enter the link into the Org file?

The original link

[[message://m2k4n46n5p.wl%d...@boostpro.com]]

Is unescaped, but Org treats links as always percent-escaped. What
happens is that "%da" is treated as a percent escaped character and
unescaped after read from buffer.

The link should read:

message://m2k4n46n5p.wl%25d...@boostpro.com

This is a troublesome situation

https://lists.gnu.org/archive/html/emacs-orgmode/2011-09/msg00257.html

But up to know I didn't find a solution for it.

Best,
  -- David
-- 
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpXiewk8yzTV.pgp
Description: PGP signature

Re: [O] FYI: Org mode testing framework, Emacs 23 and 22

[David Maus]

At Tue, 13 Sep 2011 08:48:49 -0600,
Eric Schulte wrote:
> 
> So am I right in thinking that as of right this commit [1] we are
> passing all tests on Emacs 22 through Emacs24?
> 
> Thanks -- Eric
> 
> >
> > This is with
> >
> > GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of
> > 2010-12-11 on raven, modified by Debian
> >
> > Best,
> >   -- David
> > --
> > OpenPGP... 0x99ADB83B5A4478E6
> > Jabber dmj...@jabber.org
> > Email. dm...@ictsoc.de
> 
> 
> Footnotes: 
> [1]  dbf0e6d5bcbe94c8ee57d68889d3c25bf9cdef55
> 
> -- 
> Eric Schulte
> http://cs.unm.edu/~eschulte/

For Emacs22 the only thing we need from simple.el is the definition of
special-mode; going to factor it out and trim it to Emacs22.

With HEAD at dbf0e6d5bcbe94c8ee57d68889d3c25bf9cdef55 and a fix for
the check for featurep 'org (37db5deea5ef75186bb7413b196fa0c96e5bdfb9)
I got:


Selector: "\\(org\\|ob\\)"
Passed: 99
Failed: 10 (10 unexpected)
Total:  109/109

Started at:   2011-09-16 06:56:59+0200
Finished.
Finished at:  2011-09-16 06:57:04+0200

..FF...FF..F.F...FF.F..F.

F ob-fortran/list-var
Test real array input
(void-function characterp)

F ob-fortran/list-var-from-table
Test real array from a table
(void-function characterp)

F test-ob-exp/org-babel-exp-src-blocks/w-no-file
Testing export from buffers which are not visiting any file.
(wrong-type-argument stringp nil)

F test-ob-exp/org-babel-exp-src-blocks/w-no-headers
Testing export without any headlines in the org-mode file.
(wrong-type-argument stringp nil)

F test-ob-lob/export-lob-lines
Test the export of a variety of library babel call lines.
(wrong-type-argument stringp nil)

F test-ob-sh/dont-error-on-empty-results
Was throwing an elisp error when shell blocks threw errors and
(void-function org-babel-execute:sh)

F test-org-babel/inline-src-blocks
(error "No org-babel-execute function for sh!")

F test-org-babel/inline-src_blk-default-results-replace-line-1
(error "No org-babel-execute function for sh!")

F test-org-exp/stripping-commas
Test the stripping of commas from within blocks during export.
(wrong-type-argument stringp nil)

F test-org/org-link-unescape-ascii-extended-char
Unescape old style percent escaped character.
(ert-test-failed
 ((should
   (string= "àâçèéêîôùû"
(org-link-unescape "%E0%E2%E7%E8%E9%EA%EE%F4%F9%FB")))
  :form
  (string= "àâçèéêîôùû" "\340\342\347\350\351\352\356\364\371\373")
  :value nil))


Best,
  -- David
-- 
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpaVINhKP9ar.pgp
Description: PGP signature

Re: [O] [babel] Collection of code block snippets

[David Maus]

Hi Martyn,

At Sat, 10 Sep 2011 09:09:17 +0100,
Martyn Jago wrote:
> I'll do some work on testing against version 23 and 22 and maybe put
> together a how-to get ERT on those earlier systems (on linux).

Just read this through Org mode's patch tracker[1] and coincidentally
started to work on the test framework, too. To get a recent ERT
running on Emac22 we need to backport parts of simple.el as of Emacs23
-- doing this is scheduled for the upcoming weekend in my Org mode.

> For fun I hacked together a test results parser using org babel, which
> calls your script from within a shell block, passing the results to a
> parser block. Output is in the form of org mode headings and
> sub-headings. I've attached it in case you were interested (org babel
> was just great for doing this).

This is great. This would be useful for non-babel tests, too. There
are some tests for link escaping and link export -- I'm going to
extend the latter (that's why I started to work on the testing
framework in the first place).

Best,
  -- David

[1] http://patchwork.newartisans.com
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgp1GJFkpx8Kr.pgp
Description: PGP signature

Re: [O] FYI: Org mode testing framework, Emacs 23 and 22

[David Maus]

At Tue, 13 Sep 2011 08:48:49 -0600,
Eric Schulte wrote:
> This test has been updated so that it no longer calls the left-char
> function.  Please update to the latest git head and this test should
> pass.

All tests pass on Emacs 23.

>
> So am I right in thinking that as of right this commit [1] we are
> passing all tests on Emacs 22 through Emacs24?

No Emacs23 through Emacs24: Backporting simple.el is scheduled for the
upcoming weekend.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgp8Li97WP53Z.pgp
Description: PGP signature

Re: [O] FYI: Org mode testing framework, Emacs 23 and 22

[David Maus]

At Sun, 11 Sep 2011 15:02:08 -0600,
Eric Schulte wrote:
>
> >
> > The test result with failing tests for Emacs23 is attached.
> >
> > ,
> > | Passed: 101
> > | Failed: 8 (8 unexpected)
> > | Total:  109/109
> > |
> > | Started at:   2011-09-11 19:53:46+0200
> > | Finished.
> > | Finished at:  2011-09-11 19:53:51+0200
> > `
> >
> > 7 of the 8 are fortran-tests, the 8th is
> > `org-babel-get-inline-src-block-matches'.
> >
>
> I would imagine that the fortran tests are failing because you do not
> have the gfortran executable in your path.  I had to apt-get install
> fortran for these tests to pass.

m( indeed. After installing gfortran all but one run trough:

,
| Selector: "\\(org\\|ob\\)"
| Passed: 108
| Failed: 1 (1 unexpected)
| Total:  109/109
|
| Started at:   2011-09-13 05:45:38+0200
| Finished.
| Finished at:  2011-09-13 05:45:45+0200
|
| F test-org-babel/org-babel-get-inline-src-block-matches
|(void-function left-char)
`

This is with

GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11 on 
raven, modified by Debian

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpXhiZwrctYz.pgp
Description: PGP signature

Re: [O] Clicking on URL does convert some special characters

[David Maus]

At Wed, 07 Sep 2011 16:01:48 +0530,
Jambunathan K wrote:
> > Hello,
> >
> > I just realized a diff in behavior between 3 URL entered in the Org buffer
> > with slight differences:
> >
> > - http://web.com/file.php?name=Rep&path=%2FPROJ%2FSomeFile.txt
> >   This one is correctly exported, but when clicking on it from the Org 
> > buffer,
> >   the URL opened in the browser is
> >   http://web.com/file.php?name=Rep&path=%252FPROJ%252FSomeFile.txt,
> >   ^^   ^^
> >   hence path not found error.
> >
> > - [[http://web.com/file.php?name=Rep&path=%2FPROJ%2FSomeFile.txt]]
> >   Works OK in Org and in exported HTML file.
> >
> > - 
> > [[http://web.com/file.php?name=Rep&path=%2FPROJ%2FSomeFile.txt][Description]]
> >   Idem.
>
> 2. When the Org buffer is exported to html or odt
>
> , In org-html-handle-links
> |   (setq path (save-match-data (org-link-unescape   <==
> |(match-string 3 line
> |   (setq type (cond
> |   ((match-end 2) (match-string 2 line))
> |   ((save-match-data
> |  (or (file-name-absolute-p path)
> |  (string-match "^\\.\\.?/" path)))
> |"file")
> |   (t "internal")))
> |   (setq path (org-extract-attributes (org-link-unescape path))) <==
> `
>
> link unescape happens twice. Asymmetry due to One link escape + two link
> unescape asymmetry creates problem on export.
>
> Based on historical research, the second org-link-unescape can be
> removed. The fact that attributes can be entered at C-c C-l prompt is
> largely documented and so the second call to org-link-unescape can
> largely be removed.

The three issues (plain links, enter link via C-c C-l, and
double-unescape) are not related in a strict sense. I just pushed:

 - a fix for `org-open-at-point' and plain links; problem was, that in
   contrast to bracket links the plain link was not unescaped when
   read from buffer

 - removed the second `org-link-unescape' in `org-html-handle-links';
   PATH is already unescaped, does not change between first and third
   `setq' and should always be escaped only once. Attached patch is
   for org-lparse.el.

The inconsistency C-c C-l vs. copy'n'paste vs. manually entering a
link is under further review. The base problem is, that we

(a) need to escape certain characters for Org mode (i.e. square brackets)

(b) need to treat links in a Org buffer either as escaped -or- as
unescaped; you can't always tell the difference from the string alone
(e.g. "%25" could be the escaped percent sign or the unescaped
sequence "%25")

(c) don't know if the user enters or pastes a escaped or unescaped
link; if the user manually enters a link with the sequence "%5B" and
we later read that link, we can't tell if it is a bracket escaped by
us or a percent escaped bracket in the original link

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de
From 66f09f4608dae272a0eac432dd097a00f632f1d6 Mon Sep 17 00:00:00 2001
From: David Maus 
Date: Sun, 11 Sep 2011 16:57:01 +0200
Subject: [PATCH] Remove unecessary link unescape

* org-lparse.el (org-lparse-format-org-link): Remove unecessary link
unescape.
---
 contrib/lisp/org-lparse.el |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/contrib/lisp/org-lparse.el b/contrib/lisp/org-lparse.el
index 39d9403..a36b0d7 100755
--- a/contrib/lisp/org-lparse.el
+++ b/contrib/lisp/org-lparse.el
@@ -199,7 +199,7 @@ OPT-PLIST is the export options list."
 (string-match "^\\.\\.?/" path)))
   "file")
  (t "internal")))
-  (setq path (org-extract-attributes (org-link-unescape path)))
+  (setq path (org-extract-attributes path))
   (setq attr (get-text-property 0 'org-attributes path))
   (setq desc1 (if (match-end 5) (match-string 5 line))
desc2 (if (match-end 2) (concat type ":" path) path)
-- 
1.7.2.5



pgpCGmiLOJSAy.pgp
Description: PGP signature

Re: [O] FYI: Org mode testing framework, Emacs 23 and 22

[David Maus]

...Attachment...
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de
Selector: "\\(org\\|ob\\)"
Passed: 101
Failed: 8 (8 unexpected)
Total:  109/109

Started at:   2011-09-11 19:53:46+0200
Finished.
Finished at:  2011-09-11 19:53:51+0200

...F.FF.F

F ob-fortran/command-arguments
Test real array from a table
(wrong-type-argument number-or-marker-p "")

F ob-fortran/fortran-var-program
Test a fortran variable
(wrong-type-argument number-or-marker-p "")

F ob-fortran/input-var
Test :var
(wrong-type-argument number-or-marker-p "")

F ob-fortran/list-var
Test real array input
(ert-test-failed
 ((should
   (equal "1.00 2.00 3.00"
  (org-babel-execute-src-block)))
  :form
  (equal "1.00 2.00 3.00" "")
  :value nil :explanation
  (arrays-of-different-length 14 0 "1.00 2.00 3.00" "" first-mismatch-at 
0)))

F ob-fortran/list-var-from-table
Test real array from a table
(ert-test-failed
 ((should
   (equal "1.00 2.00"
  (org-babel-execute-src-block)))
  :form
  (equal "1.00 2.00" "")
  :value nil :explanation
  (arrays-of-different-length 9 0 "1.00 2.00" "" first-mismatch-at 0)))

F ob-fortran/preprosessor-var
Test preprocessed fortran
(wrong-type-argument number-or-marker-p "")

F ob-fortran/simple-program
Test of hello world program.
(ert-test-failed
 ((should
   (equal "Hello world"
  (org-babel-execute-src-block)))
  :form
  (equal "Hello world" "")
  :value nil :explanation
  (arrays-of-different-length 11 0 "Hello world" "" first-mismatch-at 0)))

F test-org-babel/org-babel-get-inline-src-block-matches
(void-function left-char)



pgphrls7QvMog.pgp
Description: PGP signature

Re: [O] FYI: Org mode testing framework, Emacs 23 and 22

[David Maus]

At Fri, 02 Sep 2011 07:50:02 -0600,
Eric Schulte wrote:
>
> Hi David,
>
> David Maus  writes:
>
> > Just FYI: I've tried to get the testing framework running on Emacs 23
> > and Emacs 22 and succeeded to 50%:
> >
> >  - copying ert.el and ert-x.el from Emacs24 Git repository at
> >git://git.savannah.gnu.org/emacs.git with master on
> >231bffa3e6c37164fa40ad18bd27249cc7704e30 and installing jump.el is
> >sufficient to get the test suit running again
> >
> >  - not so much luck with Emacs22: Recent ERT requires `special-mode',
> >defined in simple.el from 23.x upwards.
> >
>
> Would it be possible to load a more recent version of simple.el in
> Emacs22 to define special mode, and then see if ert loads successfully?

Next on my list.

>
> Also, did all tests pass successfully in Emacs23?
>
> Currently on my system using Emacs24 all tests pass but those related to
> fortran code block support, all of which are failing.

The test result with failing tests for Emacs23 is attached.

,
| Passed: 101
| Failed: 8 (8 unexpected)
| Total:  109/109
|
| Started at:   2011-09-11 19:53:46+0200
| Finished.
| Finished at:  2011-09-11 19:53:51+0200
`

7 of the 8 are fortran-tests, the 8th is
`org-babel-get-inline-src-block-matches'.

>
> Once we have all tests running for Emacs>=22 it would be very nice (and
> not too difficult) to add a post-update hook to the Org-mode git
> repository which could run the test suite and record the results for
> every version of Emacs with something like the following
>
> emacs23 -Q --batch -l $ORGTESTSTUFF --eval "
> (progn (org-test-run-all-tests)
>(htmlize-buffer)
>(write-file "commit-id-23.html"))"

+1

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgplKGyAeCOTP.pgp
Description: PGP signature

[O] ATTN: Working on the HTML exporter and links (Spaghetti alarm)

[David Maus]

Hi,

I did some changes to Org's HTML exporter and link
functionality. Please double check the exporting results, I hope I
didn't mess up things too much this time.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgp2LO5slycpf.pgp
Description: PGP signature

Re: [O] Question about org-mode compilation

[David Maus]

At Sat, 10 Sep 2011 12:08:45 -0500,
Robert Goldman wrote:
>
> Today I was trying to push to mobile org after an update from git, and
> got an invalid function error on org-eval-in-environment.
>
> This macro is defined in org-macs.el and is used in org-agenda.el.
>
> I note that the makefile has org-agenda depending on org.el, but /not/
> on org-macs.el.
>
> Is that an error?
>
> Adding that dependency, then making clean and making all fixes things.
> But I may not have properly cleaned before my last build, so I'm not sure.

Hi Robert,

I checked and don't think the missing dependency in Makefile was cause
of the problem. When org-agenda.el is compiled it requires org.el
which in turn requires org-macs.el -- thus the macro definition is
loaded. Otherwise the compiler would stop.

An invalid function error with a macro is according to my experience
an indicator of mixing up of old and new files. Thus, the make clean
was the action that fixed the issue.

I byte compiled Org and ran a batch-agenda (which uses
org-eval-in-environment) with no error.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpINwgjt7P93.pgp
Description: PGP signature

Re: [O] [PATCH 0/5] loop over headlines in active region

[David Maus]

At Fri, 09 Sep 2011 17:26:43 +0200,
Štěpán Němec wrote:
> 
> The reason I asked (I didn't actually repeat anything, and it's all
> apparently still far from obvious, at least to me) is that I'm confused:
> You say "I didn't implement is as a macro, because A". Now we both agree
> that A is an invalid argument. Given that you now also confirmed you did
> want to implement it as a macro in the first place, I would expect that
> either you do implement it as a macro, or provide a valid argument for
> not doing so. Maybe I really am too dense, but the hitchhiker quotation
> didn't help.

Okay, now I get it. Do I implement a macro for the operation? I Don't
know.

Please see http://thread.gmane.org/gmane.emacs.orgmode/44422/focus=46184

Best,
  -- David
-- 
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpluR4CDEL8P.pgp
Description: PGP signature

Re: [O] [PATCH 0/5] loop over headlines in active region

[David Maus]

At Fri, 09 Sep 2011 12:26:31 +0200,
Štěpán Němec wrote:
> 
> Still, I'd rather we stuck to the point and expressed ourselves in a way
> that doesn't imply the other side is either an idiot ...

Your message simply repeated my conclusion: Yes, the problem of
referencing a free variable in the macro expansion does not apply in
this case. Yes, I should base decisions on valid arguments (Who
shouldn't?). Yes, the fact that I refrained from implementing it as a
macro indicates that I wanted to implement it as a macro in the first
place.

Repeating and stating the very, very obvious is one way to call
someone an idiot.
-- 
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpptcO2Ig7jL.pgp
Description: PGP signature

Re: [O] [PATCH 0/5] loop over headlines in active region

[David Maus]

At Wed, 07 Sep 2011 21:34:41 +0200,
Štěpán Němec wrote:
> 
> On Sun, 28 Aug 2011 15:57:19 +0200
> David Maus wrote:
> 
> > At Thu, 25 Aug 2011 12:08:42 +0200,
> > Štěpán Němec wrote:
> >> 
> >> On Thu, 25 Aug 2011 06:25:29 +0200
> >> David Maus wrote:
> >> 
> >> > As for the macro: What stop me to implement a macro for the generic
> >> > operation is that for now the macro would depend on the global
> >> > customization variable. That's not a problem per se but according to
> >> > my readings about macros (mostly in context of Common Lisp, but that
> >> > shouldn't matter) it should be considered bad style.
> >> 
> >> Could you expand on this a bit? As far as I can tell, you obviously
> >> shouldn't depend on a customisation variable at macro expansion time,
> >> but I don't see how depending on it at run time is any different from a
> >> function doing the same.
> >> 
> >
> > At expansion time the macro performs a transformation of the lisp at
> > the place where the macro is used. At runtime the code of the expanded
> > macro runs in the scope of the function where the macro was expanded
> > into. A macro that uses a variable inside the expanded code that is
> > not under its control (e.g. part of the argument list or gensym'd) is
> > prone to introduce a bug caused by expanding the macro in an
> > environment where this variable is not bound or used with a different
> > semantics.
> >
> > In this particular case this should not be a problem indeed because we
> > use a global dynamically scoped customization variable. Thus,
> > whereever we would use the macro we can be sure the variable in the
> > macro expansion is bound and carries the same meaning.
> 
> So your "what stop me to implement a macro" argument is bogus, isn't it?
> I can't really comment on whether using a macro or not is the right
> thing here, but it seems to me you shouldn't base the decision on an
> invalid argument (IOW, from the fact that you even felt the need to
> explain why you didn't use a macro to begin with, it would appear to be
> the case that you would have preferred the macro way).

"One of the things Ford Prefect had always found hardest to understand
about humans was their habit of continually stating and repeating the
very very obvious, as in /It's a nice day/, or /You're very tall/, or
/Oh dear you seem to have fallen down a thirty-foot well, are you all
right?/ At first Ford had formed a theory to account for this strange
behavior. If human beings don't keep exercising their lips, he
thought, their mouths probably seize up.

After a few months' consideration and observation he abandoned this
theory in favor of a new one. If they don't keep on exercising their
lips, he thought, their brains start working. After a while he
abandoned this one as well as being obstructively cynical and decided
he quite liked human beings after all, but he always remained
desperately worried about the terrible number of things they didn't
know about."

  Douglas Adams, The Hitchiker's Guide to the Galaxy
-- 
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgp5PevHSSLwv.pgp
Description: PGP signature

Re: [O] Clicking on URL does convert some special characters

[David Maus]

At Wed, 07 Sep 2011 11:20:03 +0200,
Sebastien Vauban wrote:
>
> Hello,
>
> I just realized a diff in behavior between 3 URL entered in the Org buffer
> with slight differences:
>
> - http://web.com/file.php?name=Rep&path=%2FPROJ%2FSomeFile.txt
>   This one is correctly exported, but when clicking on it from the Org buffer,
>   the URL opened in the browser is
>   http://web.com/file.php?name=Rep&path=%252FPROJ%252FSomeFile.txt,
>   ^^   ^^
>   hence path not found error.
>
> - [[http://web.com/file.php?name=Rep&path=%2FPROJ%2FSomeFile.txt]]
>   Works OK in Org and in exported HTML file.
>
> - 
> [[http://web.com/file.php?name=Rep&path=%2FPROJ%2FSomeFile.txt][Description]]
>   Idem.

I'll look into this. Looks like the plain link is escaped before
passed to the browser.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgph7DZSNRnVS.pgp
Description: PGP signature

[O] [PATCH] Small fix for contrib/lisp/org-elisp-symbol.el

[David Maus]

Attached patch fixes a small issue with
contrib/lisp/org-elisp-symbol.el, a contributed package that defines a
link type for elisp symbols.

Currently org-elisp-symbol.el uses `eq' to compare a symbol value with
a string. Such a comparism always evals to nil:

#+begin_src emacs-lisp
(let ((foo "foo"))
  (eq foo "foo")) => nil
#+end_src

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de
From 4b5d2e726d8f64e111c42623ae0cd5cf8d82ad70 Mon Sep 17 00:00:00 2001
From: David Maus 
Date: Thu, 1 Sep 2011 06:49:29 +0200
Subject: [PATCH] Use `string=' to compare strings

* org-elisp-symbol.el (org-elisp-symbol-store-link): Use `string=' to
compare strings.

(let ((foo "foo"))
  (eq foo "foo")) => nil
---
 contrib/lisp/org-elisp-symbol.el |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/contrib/lisp/org-elisp-symbol.el b/contrib/lisp/org-elisp-symbol.el
index e614e97..6eb8114 100644
--- a/contrib/lisp/org-elisp-symbol.el
+++ b/contrib/lisp/org-elisp-symbol.el
@@ -104,8 +104,8 @@
 (stype (cond ((commandp sym-name) "Command")
  ((functionp sym-name) "Function")
  ((user-variable-p sym-name) "User variable")
- ((eq def "defvar") "Variable")
- ((eq def "defmacro") "Macro")
+ ((string= def "defvar") "Variable")
+ ((string= def "defmacro") "Macro")
  (t "Symbol")))
 (args (if (match-string 3)
   (mapconcat (lambda (a) (unless (string-match "^&" a) a))
-- 
1.7.2.5



pgpBs3SyLfVdE.pgp
Description: PGP signature

[O] FYI: Org mode testing framework, Emacs 23 and 22

[David Maus]

Just FYI: I've tried to get the testing framework running on Emacs 23
and Emacs 22 and succeeded to 50%:

 - copying ert.el and ert-x.el from Emacs24 Git repository at
   git://git.savannah.gnu.org/emacs.git with master on
   231bffa3e6c37164fa40ad18bd27249cc7704e30 and installing jump.el is
   sufficient to get the test suit running again

 - not so much luck with Emacs22: Recent ERT requires `special-mode',
   defined in simple.el from 23.x upwards.

Emacs 22 version used was: GNU Emacs 22.3.2 (i686-pc-linux-gnu) of 2011-05-28 
on x60s

Not having the test suit running with Emacs22 is a not-so-good because
Org mode claims compatibility with Emacs22:

, [ http://orgmode.org/]
| This package works on GNU Emacs 24, 23 and 22, and (with minor
| restrictions) on XEmacs 21. Emacs 22.2 ships with Org-mode version
| 4.67d, Emacs 23.1 with 6.21b. The latest Emacs development version
| usually contains a fairly recent version, but may lag a bit behind the
| website release.
`

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpNRCQstNeWq.pgp
Description: PGP signature

Re: [O] setting up org-remember

[David Maus]

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.

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


pgpViJTLyQFR5.pgp
Description: PGP signature

Re: [O] [PATCH 2/5] Immediately return if scope is region but no region is active

[David Maus]

Attached patch superseeds the old one, required to be applied after
"Extend scope 'region...".
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de
From 8a0e1630629693a85a824713b1357faa49a372f0 Mon Sep 17 00:00:00 2001
From: David Maus 
Date: Tue, 30 Aug 2011 06:29:29 +0200
Subject: [PATCH 2/4] Immediately return if scope is 'region but no region is 
active

* org.el (org-map-entries): Immediately return if scope is 'region but
no region is active.
---
 lisp/org.el |  117 ++-
 1 files changed, 59 insertions(+), 58 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index b770fa6..d1f9898 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -13604,66 +13604,67 @@ with `org-get-tags-at'.  If your function gets 
properties with
 to t around the call to `org-entry-properties' to get the same speedup.
 Note that if your function moves around to retrieve tags and properties at
 a *different* entry, you cannot use these techniques."
-  (let* ((org-agenda-archives-mode nil) ; just to make sure
-(org-agenda-skip-archived-trees (memq 'archive skip))
-(org-agenda-skip-comment-trees (memq 'comment skip))
-(org-agenda-skip-function
- (car (org-delete-all '(comment archive) skip)))
-(org-tags-match-list-sublevels t)
-matcher file res
-org-todo-keywords-for-agenda
-org-done-keywords-for-agenda
-org-todo-keyword-alist-for-agenda
-org-drawers-for-agenda
-org-tag-alist-for-agenda)
+  (unless (and (eq scope 'region) (not (org-region-active-p)))
+(let* ((org-agenda-archives-mode nil) ; just to make sure
+  (org-agenda-skip-archived-trees (memq 'archive skip))
+  (org-agenda-skip-comment-trees (memq 'comment skip))
+  (org-agenda-skip-function
+   (car (org-delete-all '(comment archive) skip)))
+  (org-tags-match-list-sublevels t)
+  matcher file res
+  org-todo-keywords-for-agenda
+  org-done-keywords-for-agenda
+  org-todo-keyword-alist-for-agenda
+  org-drawers-for-agenda
+  org-tag-alist-for-agenda)
 
-(cond
- ((eq match t)   (setq matcher t))
- ((eq match nil) (setq matcher t))
- (t (setq matcher (if match (cdr (org-make-tags-matcher match)) t
+  (cond
+   ((eq match t)   (setq matcher t))
+   ((eq match nil) (setq matcher t))
+   (t (setq matcher (if match (cdr (org-make-tags-matcher match)) t
 
-(save-excursion
-  (save-restriction
-   (cond ((eq scope 'tree)
-  (org-back-to-heading t)
-  (org-narrow-to-subtree)
-  (setq scope nil))
- ((and (eq scope 'region) (org-region-active-p))
-  (narrow-to-region (region-beginning)
-(save-excursion
-  (goto-char (region-end))
-  (unless (and (bolp) (org-at-heading-p))
-(outline-next-heading))
-  (point)))
-  (setq scope nil)))
-
-   (if (not scope)
-   (progn
- (org-prepare-agenda-buffers
-  (list (buffer-file-name (current-buffer
- (setq res (org-scan-tags func matcher)))
- ;; Get the right scope
- (cond
-  ((and scope (listp scope) (symbolp (car scope)))
-   (setq scope (eval scope)))
-  ((eq scope 'agenda)
-   (setq scope (org-agenda-files t)))
-  ((eq scope 'agenda-with-archives)
-   (setq scope (org-agenda-files t))
-   (setq scope (org-add-archive-files scope)))
-  ((eq scope 'file)
-   (setq scope (list (buffer-file-name
-  ((eq scope 'file-with-archives)
-   (setq scope (org-add-archive-files (list (buffer-file-name))
- (org-prepare-agenda-buffers scope)
- (while (setq file (pop scope))
-   (with-current-buffer (org-find-base-buffer-visiting file)
- (save-excursion
-   (save-restriction
- (widen)
- (goto-char (point-min))
- (setq res (append res (org-scan-tags func matcher))
-res))
+  (save-excursion
+   (save-restriction
+ (cond ((eq scope 'tree)
+(org-back-to-heading t)
+(org-narrow-to-subtree)
+(setq scope nil))
+   ((and (eq scope 'region) (org-region-active-p))
+(narrow-to-region (region-beginning)
+  (save-excursion
+(goto-char (region-end))
+(unless (and (bolp) (org-at-heading-p))
+  (outline-next-head

Re: [O] [PATCH 0/5] loop over headlines in active region

[David Maus]

Hi Carsten,

At Mon, 29 Aug 2011 11:29:04 +0200,
Carsten Dominik wrote:
>
>
> On Aug 28, 2011, at 3:58 PM, David Maus wrote:
>
> > Hi Carsten,
> >
> > At Thu, 25 Aug 2011 08:13:21 +0200,
> > Carsten Dominik wrote:
> >> I am wondering, why did you choose to skip invisible headlines?
> >> I would worry that this introduces inconsistent behavior and also
> >> makes it hard to use this feature in a programmatic way.
> >
> > Good points. I though of skipping invisible headlines as a way to
> > control which headlines are 'looped over' but if this is inconsistent
> > with already present behaviour of Org mode or Emacs in general we can
> > scratch that idea.
>
> Yes, let's do that.
>
> >
> > What brings up the question: What is the current behavior of Org mode
> > with regards to operations in a region?
>
> I think almost everything that iterates over a number of
> headlines will also do the invisible ones.  Exceptions are
> exporting/copying the visible headlines, and probably something else I
> am not remembering.

I'll investigate this. Maybe the customization variable could control
all operations on headlines in active region. Current proposal does
not feel good because it only controls some.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpa2hFgS1kzx.pgp
Description: PGP signature

Re: [O] [PATCH 1/5] Extend scope 'region to include body of last headline in active region

[David Maus]

Hi Carsten,

At Thu, 25 Aug 2011 07:40:52 +0200,
Carsten Dominik wrote:
>
>
> On 25.8.2011, at 06:25, David Maus wrote:
>
> > * org.el (org-map-entries): Extend scope 'region to include entire
> > body of last headline in active region.
> > ---
> > lisp/org.el |8 ++--
> > 1 files changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/lisp/org.el b/lisp/org.el
> > index de8c72b..b69b77c 100644
> > --- a/lisp/org.el
> > +++ b/lisp/org.el
> > @@ -13633,8 +13633,12 @@ a *different* entry, you cannot use these 
> > techniques."
> >(org-narrow-to-subtree)
> >(setq scope nil))
> >   ((and (eq scope 'region) (org-region-active-p))
> > -  (narrow-to-region (region-beginning) (region-end))
> > -  (setq scope nil)))
> > +  (let ((end (save-excursion
> > +   (goto-char (region-end))
> > +   (outline-next-heading)
> > +   (point
> > +(narrow-to-region (region-beginning) end)
> > +(setq scope nil
>
>
> Hi David,
>
> I think the better algorithm here would be this:
> If region-end is at the beginning of a line and that line is a headline,
> use region-end as it is.  If not, jump to the next headline.

Thanks, yes. This makes sense. Attached patch supersedes the previous.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de
From 957dcbe6ae40fa332e48455a260782ba3e61e68d Mon Sep 17 00:00:00 2001
From: David Maus 
Date: Tue, 30 Aug 2011 06:22:12 +0200
Subject: [PATCH 1/4] Extend scope 'region to include entire body of last 
headline in active region

* org.el (org-map-entries): Extend scope 'region to include
entire body of last headline in active region.
---
 lisp/org.el |7 ++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index d63b854..b770fa6 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -13629,7 +13629,12 @@ a *different* entry, you cannot use these techniques."
   (org-narrow-to-subtree)
   (setq scope nil))
  ((and (eq scope 'region) (org-region-active-p))
-  (narrow-to-region (region-beginning) (region-end))
+  (narrow-to-region (region-beginning)
+(save-excursion
+  (goto-char (region-end))
+  (unless (and (bolp) (org-at-heading-p))
+(outline-next-heading))
+  (point)))
   (setq scope nil)))
 
(if (not scope)
-- 
1.7.2.5



pgpqnT8KK8oE5.pgp
Description: PGP signature

Re: [O] Small patch for org-lparse.el -- Macro edebug spec

[David Maus]

At Sun, 28 Aug 2011 16:06:49 +0200,
David Maus wrote:
>
> Attached patch for org-lparse.el adds an edebug specification to
> `with-org-lparse-preserve-paragraph-state'.

And here's the patch.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de
From 7e11e940a0f8d89a21724ee9a7a548292c5ed867 Mon Sep 17 00:00:00 2001
From: David Maus 
Date: Sun, 28 Aug 2011 16:03:38 +0200
Subject: [PATCH] Provide edebug spec for 
with-org-lparse-preserve-paragraph-state

* org-lparse.el (with-org-lparse-preserve-paragraph-state): Provide
edebug spec.
---
 contrib/lisp/org-lparse.el |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/contrib/lisp/org-lparse.el b/contrib/lisp/org-lparse.el
index fd0488b..41c6936 100755
--- a/contrib/lisp/org-lparse.el
+++ b/contrib/lisp/org-lparse.el
@@ -335,6 +335,7 @@ OPT-PLIST is the export options list."
  ,@body
  (when org-lparse-do-open-par
(org-lparse-begin-paragraph
+(def-edebug-spec with-org-lparse-preserve-paragraph-state (body))
 
 (defvar org-lparse-native-backends nil
   "List of native backends registered with `org-lparse'.
-- 
1.7.2.5



pgpYGJiJucFOQ.pgp
Description: PGP signature

[O] Small patch for org-lparse.el -- Macro edebug spec

[David Maus]

Attached patch for org-lparse.el adds an edebug specification to
`with-org-lparse-preserve-paragraph-state'.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpdNxPKq8hcd.pgp
Description: PGP signature

Re: [O] [PATCH 2/5] Immediately return if scope is region but no region is active

[David Maus]

Hi Carsten,

At Thu, 25 Aug 2011 07:43:48 +0200,
Carsten Dominik wrote:
>
>
> On 25.8.2011, at 06:25, David Maus wrote:
>
> > * org.el (org-map-entries): Immediately return if scope is region but
> > no region is active.
> > ---
> > lisp/org.el |  116 
> > ++-
> > 1 files changed, 59 insertions(+), 57 deletions(-)
> >
> > diff --git a/lisp/org.el b/lisp/org.el
> > index b69b77c..27bad52 100644
> > --- a/lisp/org.el
> > +++ b/lisp/org.el
> > @@ -13608,65 +13608,67 @@ with `org-get-tags-at'.  If your function gets 
> > properties with
> > to t around the call to `org-entry-properties' to get the same speedup.
> > Note that if your function moves around to retrieve tags and properties at
> > a *different* entry, you cannot use these techniques."
> > -  (let* ((org-agenda-archives-mode nil) ; just to make sure
> > -(org-agenda-skip-archived-trees (memq 'archive skip))
> > -(org-agenda-skip-comment-trees (memq 'comment skip))
> > -(org-agenda-skip-function
> > - (car (org-delete-all '(comment archive) skip)))
> > -(org-tags-match-list-sublevels t)
> > -matcher file res
> > -org-todo-keywords-for-agenda
> > -org-done-keywords-for-agenda
> > -org-todo-keyword-alist-for-agenda
> > -org-drawers-for-agenda
> > -org-tag-alist-for-agenda)
> > +  (unless (and (eq scope 'region)
> > +  (not (org-region-active-p)))
>
> Would it be good to throw an error here?
>
> (if (and (eq scope 'region) (not (org-region-active-p)))
> (error "No active region")

Not necessarily. I look at map-entries as a function that applies FUNC
to a subset of all headlines. SCOPE, MATCH, and SKIP are selectors
that narrow down the set of headlines.  First SCOPE is applied to the
set containing all headlines, than MATCH is applied to the set of
headlines selected by SCOPE, finally FUNC is applied to all headlines
in the final subset if not SKIP.

If you look at `org-map-entries' this way then calling it with SCOPE
'region but no active region is not an error. How many headlines are
in the active region if there is no active region? Exactly zero. Its
the same with a SCOPE 'file but no headline in current file.

Applying SCOPE to the set of all headings produces the empty set
and `org-map-entries' can simply leave because MATCH and SKIP wouldn't
match anything.

Best,
 -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgp33UKFGiPiv.pgp
Description: PGP signature

Re: [O] [PATCH 0/5] loop over headlines in active region

[David Maus]

Hi Carsten,

At Thu, 25 Aug 2011 08:13:21 +0200,
Carsten Dominik wrote:
> I am wondering, why did you choose to skip invisible headlines?
> I would worry that this introduces inconsistent behavior and also
> makes it hard to use this feature in a programmatic way.

Good points. I though of skipping invisible headlines as a way to
control which headlines are 'looped over' but if this is inconsistent
with already present behaviour of Org mode or Emacs in general we can
scratch that idea.

What brings up the question: What is the current behavior of Org mode
with regards to operations in a region?

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpMdN7x13PuZ.pgp
Description: PGP signature

Re: [O] [PATCH 0/5] loop over headlines in active region

[David Maus]

At Thu, 25 Aug 2011 12:08:42 +0200,
Štěpán Němec wrote:
> 
> On Thu, 25 Aug 2011 06:25:29 +0200
> David Maus wrote:
> 
> > As for the macro: What stop me to implement a macro for the generic
> > operation is that for now the macro would depend on the global
> > customization variable. That's not a problem per se but according to
> > my readings about macros (mostly in context of Common Lisp, but that
> > shouldn't matter) it should be considered bad style.
> 
> Could you expand on this a bit? As far as I can tell, you obviously
> shouldn't depend on a customisation variable at macro expansion time,
> but I don't see how depending on it at run time is any different from a
> function doing the same.
> 

At expansion time the macro performs a transformation of the lisp at
the place where the macro is used. At runtime the code of the expanded
macro runs in the scope of the function where the macro was expanded
into. A macro that uses a variable inside the expanded code that is
not under its control (e.g. part of the argument list or gensym'd) is
prone to introduce a bug caused by expanding the macro in an
environment where this variable is not bound or used with a different
semantics.

In this particular case this should not be a problem indeed because we
use a global dynamically scoped customization variable. Thus,
whereever we would use the macro we can be sure the variable in the
macro expansion is bound and carries the same meaning.

Best,
  -- David
-- 
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgp4wAB3wZmkl.pgp
Description: PGP signature

[O] [PATCH 4/5] Skip invisible headlines when mapping over headlines in active region

[David Maus]

* org.el (org-deadline, org-schedule): Skip invisible headlines when
mapping over headlines in active region.
---
 lisp/org.el |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index d15c946..03c4c13 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11829,7 +11829,7 @@ can either be an Org date like \"2011-07-24\" or a 
delta like \"+2d\"."
   (if (and (org-region-active-p) org-loop-over-headlines-in-active-region)
   (let (org-loop-over-headlines-in-active-region)
(org-map-entries
-`(org-deadline ',remove ,time) 
org-loop-over-headlines-in-active-region 'region))
+`(org-deadline ',remove ,time) 
org-loop-over-headlines-in-active-region 'region (if (outline-invisible-p) 
(org-end-of-subtree nil t
 (let* ((old-date (org-entry-get nil "DEADLINE"))
   (repeater (and old-date
  (string-match
@@ -11873,7 +11873,7 @@ either be an Org date like \"2011-07-24\" or a delta 
like \"+2d\"."
   (if (and (org-region-active-p) org-loop-over-headlines-in-active-region)
   (let (org-loop-over-headlines-in-active-region)
(org-map-entries
-`(org-schedule ',remove ,time) 
org-loop-over-headlines-in-active-region 'region))
+`(org-schedule ',remove ,time) 
org-loop-over-headlines-in-active-region 'region (if (outline-invisible-p) 
(org-end-of-subtree nil t
 (let* ((old-date (org-entry-get nil "SCHEDULED"))
   (repeater (and old-date
  (string-match
-- 
1.7.2.5

[O] [PATCH 5/5] Avoid conflict between bulk command and loop-over-headlines

[David Maus]

* org-agenda.el (org-agenda-bulk-action): Bind
`org-loop-over-headlines-in-active-region' to nil to avoid conflict
with bulk command.
---
 lisp/org-agenda.el |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 07f3c12..bb0062d 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -8306,7 +8306,8 @@ The prefix arg is passed through to the command if 
possible."
  (progn (message "Skipping removed entry at %s" e)
 (setq cntskip (1+ cntskip)))
(goto-char pos)
-   (eval cmd)
+   (let (org-loop-over-headlines-in-active-region)
+ (eval cmd))
(setq org-agenda-bulk-marked-entries
  (delete e org-agenda-bulk-marked-entries))
(setq cnt (1+ cnt
-- 
1.7.2.5