org-url-hexify-p is not respected

org-url-hexify-p is not respected

[James Harkins]

Have to admit, I'm getting a wee bit cross as it's 12:30 at night here, and all I wanted to do was save a link to a beamer-export .org file into another org file, and it keeps giving the link a hex ID that I *do not want*.

I have customized org-url-hexify-p -- C-h v org-url-hexify-p shows:

~~~
org-url-hexify-p is a variable defined in `org.el'.
Its value is nil

Documentation:
When non-nil, hexify URL when creating a link.
~~~

But C-c l creates:

<id:35d46474-b096-4312-a6e9-f3d32b3120f7>

That looks curiously like the hexified link that should not be generated according to the nil value of org-url-hexify-p.

I want the <file:.....> link because <id:...> cannot be resolved after quitting and restarting emacs (which is, IMO, a really massive weakness of org-url-hexify-p's default enabled setting, but I suppose there was a good reason for it).

How do I make org-url-hexify-p behave properly?

Org-mode version 7.9 (release_7.9-34-g4ca67b @ /home/blahblah/share/org-mode.git/lisp/)

Thanks.
hjh


--
James Harkins /// dewdrop world
jamshark70@dewdrop-world.net
http://www.dewdrop-world.net

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman

blog: http://www.dewdrop-world.net/words
audio clips: http://www.dewdrop-world.net/audio
more audio: http://soundcloud.com/dewdrop_world/tracks

Re: org-url-hexify-p is not respected

[James Harkins]

At Mon, 10 Sep 2012 00:37:40 +0800,
James Harkins wrote:
> 
> Have to admit, I'm getting a wee bit cross as it's 12:30 at night here, and all I wanted to do was save a link to a beamer-export .org file into another org file, and it keeps giving the link a hex ID that I *do not want*.
> 
> I have customized org-url-hexify-p -- C-h v org-url-hexify-p shows:

My bad, wrong variable. I should have customized "Org Link To Org Use Id." Now I see hexify is to turn, e.g., <spc> into %20.

I'm still really confused how the ID options work. Last night, I could not get org to generate a link without creating an ID (using the default value of org-link-to-org-use-id). Now, I tried to verify what happens with ID-style links, so I customized org-link-to-org-use-id to be 't' -- and org now refuses to generate the ID. ??? This is even after saving the custom setting, quitting and relaunching emacs. It simply is not making the link according to the variable. (The link target is an org file.)

Anyway, I'm going to set that variable to nil, and just hope that tomorrow org won't interpret nil to mean "I'll make whatever link style I choose, thank you very much."

hjh


--
James Harkins /// dewdrop world
jamshark70@dewdrop-world.net
http://www.dewdrop-world.net

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman

blog: http://www.dewdrop-world.net/words
audio clips: http://www.dewdrop-world.net/audio
more audio: http://soundcloud.com/dewdrop_world/tracks

Re: org-url-hexify-p is not respected

[Nick Dokos]

James Harkins <jamshark70@gmail.com> wrote:


> My bad, wrong variable. I should have customized "Org Link To Org Use
> Id." Now I see hexify is to turn, e.g., <spc> into %20.

>  I'm still really confused how the ID options work. Last night, I
> could not get org to generate a link without creating an ID (using the
> default value of org-link-to-org-use-id). Now, I tried to verify what
> happens with ID-style links, so I customized org-link-to-org-use-id to
> be 't' -- and org now refuses to generate the ID. ??? This is even
> after saving the custom setting, quitting and relaunching emacs. It
> simply is not making the link according to the variable. (The link
> target is an org file.)

C-h v org-link-to-org-use-id RET should help in alleviating (at least
some of) the confusion. Note the default value: you probably want to set
it to create-if-interactive-and-no-custom-id.

>  Anyway, I'm going to set that variable to nil, and just hope that
> tomorrow org won't interpret nil to mean "I'll make whatever link
> style I choose, thank you very much."

Actually, setting it to t gets pretty close to this description :-)

Nick

Re: org-url-hexify-p is not respected

[James Harkins]

At Mon, 10 Sep 2012 00:58:27 -0400,
Nick Dokos wrote:
> >  I'm still really confused how the ID options work. Last night, I
> > could not get org to generate a link without creating an ID (using the
> > default value of org-link-to-org-use-id). Now, I tried to verify what
> > happens with ID-style links, so I customized org-link-to-org-use-id to
> > be 't' -- and org now refuses to generate the ID. ??? This is even
> > after saving the custom setting, quitting and relaunching emacs. It
> > simply is not making the link according to the variable. (The link
> > target is an org file.)
> 
> C-h v org-link-to-org-use-id RET should help in alleviating (at least
> some of) the confusion. Note the default value: you probably want to set
> it to create-if-interactive-and-no-custom-id.

OK, but will this create the IDs or not? Today, I had wanted to enable the IDs in order to provide a scenario where they don't work. For normal use, I *don't* want the IDs because I found they don't persist through Emacs sessions.

"create-if-interactive" -- I'm assuming C-c l is interactive -- "-and-no-custom-id" -- these would be on headlines where there is no existing ID. So it *would* create an ID, right? Not what I ultimately want.

hjh


--
James Harkins /// dewdrop world
jamshark70@dewdrop-world.net
http://www.dewdrop-world.net

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman

blog: http://www.dewdrop-world.net/words
audio clips: http://www.dewdrop-world.net/audio
more audio: http://soundcloud.com/dewdrop_world/tracks

Re: org-url-hexify-p is not respected

[Jambunathan K]

Following creates IDs on a headline.
    M-x org-id-get-create RET 

Then, the following creates a link to IDs
    C-c l on the headline
    C-c C-l at the place where link is to be inserted

,----
| [[id:3f2c3ec7-e3ec-4fc8-9472-6b8fea4789d9][Low level Headline (Translations)]]
| 
| * Low level Headline (Translations)
|   :PROPERTIES:
|   :ID:       3f2c3ec7-e3ec-4fc8-9472-6b8fea4789d9
|   :END:
`----

If all you need is a stable link, you can go with CUSTOM_ID property for
links.  Just type in whatever string you want.  IDs are machine created
but CUSTOM_IDs are man made ones.
 
James Harkins <jamshark70@gmail.com> writes:

> At Mon, 10 Sep 2012 00:58:27 -0400,
> Nick Dokos wrote:
>> >  I'm still really confused how the ID options work. Last night, I
>> > could not get org to generate a link without creating an ID (using the
>> > default value of org-link-to-org-use-id). Now, I tried to verify what
>> > happens with ID-style links, so I customized org-link-to-org-use-id to
>> > be 't' -- and org now refuses to generate the ID. ??? This is even
>> > after saving the custom setting, quitting and relaunching emacs. It
>> > simply is not making the link according to the variable. (The link
>> > target is an org file.)
>> 
>> C-h v org-link-to-org-use-id RET should help in alleviating (at least
>> some of) the confusion. Note the default value: you probably want to set
>> it to create-if-interactive-and-no-custom-id.
>
> OK, but will this create the IDs or not? Today, I had wanted to enable
> the IDs in order to provide a scenario where they don't work. For
> normal use, I *don't* want the IDs because I found they don't persist
> through Emacs sessions.
>
> "create-if-interactive" -- I'm assuming C-c l is interactive --
> "-and-no-custom-id" -- these would be on headlines where there is no
> existing ID. So it *would* create an ID, right? Not what I ultimately
> want.
>
> hjh
>
>
> --
> James Harkins /// dewdrop world
> jamshark70@dewdrop-world.net
> http://www.dewdrop-world.net
>
> "Come said the Muse,
> Sing me a song no poet has yet chanted,
> Sing me the universal."  -- Whitman
>
> blog: http://www.dewdrop-world.net/words
> audio clips: http://www.dewdrop-world.net/audio
> more audio: http://soundcloud.com/dewdrop_world/tracks
>
>

-- 

Re: org-url-hexify-p is not respected

[James Harkins]

At Mon, 10 Sep 2012 12:07:26 +0530,
Jambunathan K wrote:
> If all you need is a stable link, you can go with CUSTOM_ID property for
> links.  Just type in whatever string you want.  IDs are machine created
> but CUSTOM_IDs are man made ones.

I don't want IDs at all. I want [[file:.............]]

hjh


--
James Harkins /// dewdrop world
jamshark70@dewdrop-world.net
http://www.dewdrop-world.net

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman

blog: http://www.dewdrop-world.net/words
audio clips: http://www.dewdrop-world.net/audio
more audio: http://soundcloud.com/dewdrop_world/tracks

Re: org-url-hexify-p is not respected

[Jambunathan K]

James Harkins <jamshark70@gmail.com> writes:

> At Mon, 10 Sep 2012 12:07:26 +0530,
> Jambunathan K wrote:
>> If all you need is a stable link, you can go with CUSTOM_ID property for
>> links.  Just type in whatever string you want.  IDs are machine created
>> but CUSTOM_IDs are man made ones.
>
> I don't want IDs at all. I want [[file:.............]]

Before creating the link, do

    M-x unload-feature RET org-id RET


Then the following will create links that contain headline text instead
of IDs.

   C-c l, C-c C-l


If you want IDs again, do

   M-x load-library RET org-id RET


ps: I haven't followed the discussion closely.

> hjh
>
>
> --
> James Harkins /// dewdrop world
> jamshark70@dewdrop-world.net
> http://www.dewdrop-world.net
>
> "Come said the Muse,
> Sing me a song no poet has yet chanted,
> Sing me the universal."  -- Whitman
>
> blog: http://www.dewdrop-world.net/words
> audio clips: http://www.dewdrop-world.net/audio
> more audio: http://soundcloud.com/dewdrop_world/tracks

Re: org-url-hexify-p is not respected

[James Harkins]

On Tue, Sep 11, 2012 at 9:47 AM, James Harkins <jamshark70@gmail.com> wrote:
> I'm pushing a bit on this because creating an id when linking to an org-mode
> headline is the default behavior, but what I observed (couldn't open the
> link) is fundamentally broken.

OK... mainly to reassure myself that I am in fact not going crazy, I
looked at this a bit more.

If I start a fresh Emacs session and store a link to an org headline,
no ID is created, regardless of the setting of org-link-to-org-use-id,
apparently because my installation does not load the org-id module at
launch. This is also the reason why C-c C-o on an ID link failed in a
new Emacs session. After M-x load-library RET org-id RET, C-c C-o
worked fine.

So then the question is, why was I getting the ID-style links in the
first place? I hadn't loaded that module before (I didn't even know
about load-library before).

I suspect one of the org-mobile functions (which I *am* using) loads
the module. TODOs, scheduled and deadline items receive IDs during
org-mobile-push. This (or something else, but this is the only org
feature where I had ever seen IDs until my confusing experience with
C-c l) probably turned it on, but then gave me no indication that this
would break the link feature if I didn't customize org-modules.

So I think what I will do is add the module. My only real concern is
to get links that work. I had wanted to turn off IDs because it
appeared to me that they were not reliable. Indeed, without
Jambunathan K's comment about load-library, I would still be under the
impression.

So there is some documentation or warning-to-the-user issue lurking.
It seems to be assumed you won't get ID links if you didn't explicitly
load org-id (in which case you know that you need the module to open
the links), but org-id may be loaded silently and end up messing with
the user's brain.

hjh


-- 
James Harkins /// dewdrop world
jamshark70@dewdrop-world.net
http://www.dewdrop-world.net

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman

blog: http://www.dewdrop-world.net/words
audio clips: http://www.dewdrop-world.net/audio
more audio: http://soundcloud.com/dewdrop_world/tracks

Activating modules before org-install (was: org-url-hexify-p is not respected)

[Memnon Anon]

James Harkins <jamshark70@gmail.com> writes:

> So then the question is, why was I getting the ID-style links in the
> first place? I hadn't loaded that module before (I didn't even know
> about load-library before).

One short question: My ~/.emacs.d/init.el has these lines:
,----
| ;; modules got to be set _before_ org is loaded
| (setq org-modules '(org-bbdb org-bibtex org-gnus org-info org-jsinfo 
|                     org-irc org-vm org-w3m org-crypt org-learn
|                     org-collector org-habit org-depend org-timer))
| 
| ;; load up Org-mode and Org-babel
| (require 'org-install)
`----

Is it true that "modules got to be set _before_ org is loaded"?
IOW: May something weird happen if e.g. module org-id enters the game
later on?

At quick glance on the manual, I saw nothing relevant. 

Of course, I could play it safe with M-x customize-variable org-modules,
but ... well ... customize.

Re: Activating modules before org-install (was: org-url-hexify-p is not respected)

[Jonathan Leech-Pepin]

Helo

On 11 September 2012 09:10, Memnon Anon
<gegendosenfleisch@googlemail.com> wrote:
> James Harkins <jamshark70@gmail.com> writes:
>
>> So then the question is, why was I getting the ID-style links in the
>> first place? I hadn't loaded that module before (I didn't even know
>> about load-library before).
>
> One short question: My ~/.emacs.d/init.el has these lines:
> ,----
> | ;; modules got to be set _before_ org is loaded
> | (setq org-modules '(org-bbdb org-bibtex org-gnus org-info org-jsinfo
> |                     org-irc org-vm org-w3m org-crypt org-learn
> |                     org-collector org-habit org-depend org-timer))
> |
> | ;; load up Org-mode and Org-babel
> | (require 'org-install)
> `----
>
> Is it true that "modules got to be set _before_ org is loaded"?
> IOW: May something weird happen if e.g. module org-id enters the game
> later on?

From what I saw when I was enabling org-habits, if you add it to the
org-modules list after calling (require 'org-install) it will not be
loaded.  So either update the modules list before requiring
=org-install=, use the customize interface or manually (require
'org-<module>).

> At quick glance on the manual, I saw nothing relevant.
>
> Of course, I could play it safe with M-x customize-variable org-modules,
> but ... well ... customize.
>
Regards,

--
Jon

Re: org-url-hexify-p is not respected

[Charles Philip Chan]

[-- Attachment #1: Type: text/plain, Size: 1665 bytes --]

James Harkins <jamshark70@gmail.com> writes:

Hi James:

> So then the question is, why was I getting the ID-style links in the
> first place? I hadn't loaded that module before (I didn't even know
> about load-library before).

I have org-id loaded and "org-link-to-org-use-id" is set to
"create-if-interactive-and-no-custom-id" (which is the default). The
only link by id that I get are TODO keywords entries (created by
"org-mobile-push"). So there must be something in your setup that set it
to "t".

> So I think what I will do is add the module. My only real concern is
> to get links that work. I had wanted to turn off IDs because it
> appeared to me that they were not reliable. Indeed, without
> Jambunathan K's comment about load-library, I would still be under the
> impression.

Why would you need to load it explicitly? org-id is autoloaded by
org-install when needed:

,----[ Comments from org-install ]
| ;;;### (autoloads (org-id-store-link org-id-find-id-file org-id-find
| ;;;;;;  org-id-goto org-id-get-with-outline-drilling org-id-get-with-outline-path-completion
| ;;;;;;  org-id-get org-id-copy org-id-get-create) "org-id" "org-id.el"
| ;;;;;;  (20548 39395 725739 953000))
| ;;; Generated autoloads from org-id.el
`----

There is something very wrong with you setup. I suggest start fresh with
a minimal setup and go from there.

Also what do you mean that they are not reliable. What are your values
for "org-id-track-globally" and "org-id-locations-file"?

Cheers,
Charles

-- 
"The move was on to 'Free the Lizard'"

  -- Jim Hamerly and Tom Paquin (Open Sources, 1999 O'Reilly and Associates)

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: org-url-hexify-p is not respected

[Bastien]

Hi James,

sorry to come back late on this.

I understand what feels wrong: you store links normally (not using ids),
then a library loads org-id.el behind your back, then suddenly storing
links is based on ids, not on text, just because the default value for
`org-link-to-org-use-id' is 'create-if-interactive-and-no-custom-id.

I fixed this in this commit:

  http://orgmode.org/w/org-mode.git?p=org-mode.git;a=commit;h=0906e3

`org-link-to-org-use-id' has been moved to org-id.el, and its default
value is now nil.  I will advertize this change more widely in the next
bugfix release.

Thanks for your patience in struggling with this,

-- 
 Bastien

Re: org-url-hexify-p is not respected

[Michael Brand]

[-- Attachment #1: Type: text/plain, Size: 519 bytes --]

Hi Bastien

On Sun, Sep 23, 2012 at 12:05 PM, Bastien <bzg@altern.org> wrote:
>   http://orgmode.org/w/org-mode.git?p=org-mode.git;a=commit;h=0906e3
>
> `org-link-to-org-use-id' has been moved to org-id.el, and its default
> value is now nil.

The attached patch is to align the doc string to the changed default.

Btw.: I always ask myself why has C-h v (describe-variable) never been
told to not only list the current value but also the default when it
is capable to point to the source with the definition?

Michael

[-- Attachment #2: 0001-org-id-link-to-org-use-id-Align-doc-string.patch.txt --]
[-- Type: text/plain, Size: 885 bytes --]

From 2a4e828b222754617750516bd2eb4678d061e7f0 Mon Sep 17 00:00:00 2001
From: Michael Brand <michael.ch.brand@gmail.com>
Date: Wed, 26 Sep 2012 19:55:50 +0200
Subject: [PATCH] org-id-link-to-org-use-id: Align doc string

* org-id.el (org-id-link-to-org-use-id): Align the doc string to the
changed default.

A leftover of commit 0906e32b.
---
 lisp/org-id.el |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lisp/org-id.el b/lisp/org-id.el
index 14f990d..a641340 100644
--- a/lisp/org-id.el
+++ b/lisp/org-id.el
@@ -105,7 +105,7 @@ create-if-interactive
 
 create-if-interactive-and-no-custom-id
       Like create-if-interactive, but do not create an ID if there is
-      a CUSTOM_ID property defined in the entry.  This is the default.
+      a CUSTOM_ID property defined in the entry.
 
 use-existing
       Use existing ID, do not create one.
-- 
1.7.4.2

Re: org-url-hexify-p is not respected

[Bastien]

Hi Michael,

Michael Brand <michael.ch.brand@gmail.com> writes:

> On Sun, Sep 23, 2012 at 12:05 PM, Bastien <bzg@altern.org> wrote:
>>   http://orgmode.org/w/org-mode.git?p=org-mode.git;a=commit;h=0906e3
>>
>> `org-link-to-org-use-id' has been moved to org-id.el, and its default
>> value is now nil.
>
> The attached patch is to align the doc string to the changed default.

Applied, thanks! 

> Btw.: I always ask myself why has C-h v (describe-variable) never been
> told to not only list the current value but also the default when it
> is capable to point to the source with the definition?

It is the case for me (GNU Emacs 24.2.50.2):

,----
| org-id-link-to-org-use-id is a variable defined in `org-id.el'.
| Its value is create-if-interactive-and-no-custom-id
| Original value was nil
`----

HTH,

-- 
 Bastien

Re: org-url-hexify-p is not respected

[Michael Brand]

Hi Bastien

On Wed, Sep 26, 2012 at 11:50 PM, Bastien <bzg@altern.org> wrote:
> | Original value was nil
> `----

Now I see this additional line that is added just when the value is
different to the original default. Finally it happened with 24.1.

Michael

MobileOrg, webdav, correct use of org-mobile-directory?

[James Harkins]

Okay, I've just about gotten that WebDAV service set up for mobileorg sync. I can both GET and PUT files using cadaver. But org-mode isn't talking to it properly.

According to [1] ("[user]" is a substitute for the real http user name):

org-mobile-directory: /scpc:**user**@localhost:80/webdav/

Then org-mobile-push gets further:

Loading tramp...done
Tramp: Opening connection for [user]@localhost using scpc...
Tramp: Sending command `exec ssh -l [user]  -o ControlPath=/tmp/tramp.26688vS.%r@%h:%p -o ControlMaster=yes -e none localhost'

Tramp: Waiting for prompts from remote shell
Tramp: Sending password
Tramp: Sending command `exec ssh -l [user]  -o ControlPath=/tmp/tramp.26688vS.%r@%h:%p -o ControlMaster=yes -e none localhost'
Tramp: Found remote shell prompt on `localhost'
Tramp: Opening connection for [user]@localhost using scpc...done

... but chokes on something surprising:

org-mobile-check-setup: Variable `org-mobile-directory' must point to an existing directory

Huh? [1] clearly says:

  (setq org-mobile-directory "/scpc:user@remote.host:org/webdav/")

... but:

  (unless (and org-mobile-directory
	       (stringp org-mobile-directory)
	       (string-match "\\S-" org-mobile-directory)
	       (file-exists-p org-mobile-directory)
	       (file-directory-p org-mobile-directory))
    (error
     "Variable `org-mobile-directory' must point to an existing directory"))

I suppose I can hack it by putting the physical location of the webdav share into org-mobile-directory. But, the documentation seems incompatible with the current behavior.

hjh

[1] http://orgmode.org/worg/org-faq.html#mobileorg_webdav


--
James Harkins /// dewdrop world
jamshark70@dewdrop-world.net
http://www.dewdrop-world.net

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman

blog: http://www.dewdrop-world.net/words
audio clips: http://www.dewdrop-world.net/audio
more audio: http://soundcloud.com/dewdrop_world/tracks

Re: MobileOrg, webdav, correct use of org-mobile-directory?

[Nick Dokos]

James Harkins <jamshark70@gmail.com> wrote:

> Okay, I've just about gotten that WebDAV service set up for mobileorg
> sync. I can both GET and PUT files using cadaver. But org-mode isn't
> talking to it properly.

But from what you show below, you are not using cadaver (or anything
webdav-related for that matter) to do the copying. You are using
scp: *that*'s what you've got to get working.

> 
> According to [1] ("[user]" is a substitute for the real http user name):
> 
> org-mobile-directory: /scpc:**user**@localhost:80/webdav/
> 

This looks wrong - if you try it with scp from the command line, can
you copy a file to that destination?

> Then org-mobile-push gets further:
> 
> Loading tramp...done
> Tramp: Opening connection for [user]@localhost using scpc...
> Tramp: Sending command `exec ssh -l [user]  -o ControlPath=/tmp/tramp.26688vS.%r@%h:%p -o ControlMaster=yes -e none localhost'
> 
> Tramp: Waiting for prompts from remote shell
> Tramp: Sending password
> Tramp: Sending command `exec ssh -l [user]  -o ControlPath=/tmp/tramp.26688vS.%r@%h:%p -o ControlMaster=yes -e none localhost'
> Tramp: Found remote shell prompt on `localhost'
> Tramp: Opening connection for [user]@localhost using scpc...done
> 
> ... but chokes on something surprising:
> 
> org-mobile-check-setup: Variable `org-mobile-directory' must point to an existing directory
> 
> Huh? [1] clearly says:
> 
>   (setq org-mobile-directory "/scpc:user@remote.host:org/webdav/")
> 
> ... but:
> 
>   (unless (and org-mobile-directory
> 	       (stringp org-mobile-directory)
> 	       (string-match "\\S-" org-mobile-directory)
> 	       (file-exists-p org-mobile-directory)
> 	       (file-directory-p org-mobile-directory))
>     (error
>      "Variable `org-mobile-directory' must point to an existing directory"))
> 
> I suppose I can hack it by putting the physical location of the webdav share into org-mobile-directory. But, the documentation seems incompatible with the current behavior.
> 

Where does org-mobile-directory point to if not the "physical location
of the webdav share"? The tramp stuff doesn't know or care about webdav
at all: it is just the mechanism that copies files from your local
machine to some other machine, so it needs to know exactly where to copy
it to.

Nick

Re: MobileOrg, webdav, correct use of org-mobile-directory?

[James Harkins]

[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]

On Aug 12, 2012 12:29 PM, "Nick Dokos" <nicholas.dokos@hp.com> wrote:
> But from what you show below, you are not using cadaver (or anything
> webdav-related for that matter) to do the copying. You are using
> scp: *that*'s what you've got to get working.

When configuring a new service, it's useful to conduct a minimal test to
ensure that nothing is wrong with the service. That was the point of using
cadaver.

For my immediate needs, I think I can do without scp, since org-mode and
Apache are on the same machine. The broader point is about the
documentation. It says "do it this way" but "this way" doesn't work.

> > org-mobile-directory: /scpc:**user**@localhost:80/webdav/
> >
>
> This looks wrong - if you try it with scp from the command line, can
> you copy a file to that destination?

1. How do I use scp from the command line?

2. This destination is modeled on the docs, so if it's wrong, then so is
the doc.

> Where does org-mobile-directory point to if not the "physical location
> of the webdav share"? The tramp stuff doesn't know or care about webdav
> at all: it is just the mechanism that copies files from your local
> machine to some other machine, so it needs to know exactly where to copy
> it to.

Well, it almost looks to me like org-mobile-directory is asked to do two
things at once: specify the scp syntax *and* hold a path that can be
resolved on the local file system. This is the source of my confusion.

At best, the docs are unclear.

No matter for me. I'll just set org-mobile-directory to the physical, local
path that is remotely accessible by webdav. But the doc was rather
misleading, suggesting that some editorial attention would be warranted.

hjh

[-- Attachment #2: Type: text/html, Size: 1970 bytes --]

Re: MobileOrg, webdav, correct use of org-mobile-directory?

[Bastien]

Hi James,

James Harkins <jamshark70@gmail.com> writes:

> But the doc was rather misleading, suggesting that some editorial
> attention would be warranted.

Can you send a patch to fix the docs?

Thanks,

-- 
 Bastien

Re: MobileOrg, webdav, correct use of org-mobile-directory?

[James Harkins]

[-- Attachment #1: Type: text/plain, Size: 288 bytes --]

On Aug 12, 2012 4:42 PM, "Bastien" <bzg@gnu.org> wrote:
> > But the doc was rather misleading, suggesting that some editorial
> > attention would be warranted.
>
> Can you send a patch to fix the docs?

I wouldn't mind doing so, but I haven't the foggiest how it's supposed to
work.

hjh

[-- Attachment #2: Type: text/html, Size: 412 bytes --]

Re: MobileOrg, webdav, correct use of org-mobile-directory?

[Nick Dokos]

James Harkins <jamshark70@gmail.com> wrote:

> On Aug 12, 2012 12:29 PM, "Nick Dokos" <nicholas.dokos@hp.com> wrote:
> > But from what you show below, you are not using cadaver (or anything
> > webdav-related for that matter) to do the copying. You are using
> > scp: *that*'s what you've got to get working.
> 
> When configuring a new service, it's useful to conduct a minimal test to ensure that nothing is
> wrong with the service. That was the point of using cadaver.
> 

I agree completely, but the cadaver test does not have anything to do
with copying files to the remote directory, only with the syncing part
from the remote directory to your phone (assuming I've got things right:
I don't have a smart phone, I don't use mobileOrg and I've not read the
docs in detail). In this case, the proper minimal test is scp from the
command line, not cadaver.

OTOH, the cadaver test *is* useful at the other end of the conversation:
if syncing to the phone does not work, then debugging webdav problems
using cadaver is certainly indicated.

> For my immediate needs, I think I can do without scp, since org-mode
> and Apache are on the same machine. The broader point is about the
> documentation. It says "do it this way" but "this way" doesn't work.

I read the page on worg and I agree it's unclear: it talks about using
webdav and then does not use webdav at all, just scp. But I don't agree
that it does not work: I've done a minimal setup with scp and tramp and
org-mobile-push/pull worked fine for me. I suspect that you are still
having some setup problems as indicated in my other email.

> 
> > > org-mobile-directory: /scpc:**user**@localhost:80/webdav/
> > >
> >
> > This looks wrong - if you try it with scp from the command line, can
> > you copy a file to that destination?
> 
> 1. How do I use scp from the command line?
> 

Your other email shows that you figured this out.

> 2. This destination is modeled on the docs, so if it's wrong, then so is the doc.
> 

Not really: the destination in the doc does not specify the port (80).
That's the HTTP port, so scp won't work with that - that's what I picked
up when I said it looked wrong. It needs the sshd port (22 by default
and implied if you leave it out of the scp path in tramp).

> > Where does org-mobile-directory point to if not the "physical location
> > of the webdav share"? The tramp stuff doesn't know or care about webdav
> > at all: it is just the mechanism that copies files from your local
> > machine to some other machine, so it needs to know exactly where to copy
> > it to.
> 
> Well, it almost looks to me like org-mobile-directory is asked to do two things at once: specify the
> scp syntax *and* hold a path that can be resolved on the local file system. This is the source of my
> confusion.
> 

You mean the "remote file system" I think, but that's true: it does
specify the protocol (scp) and the path. I think your confusion is that
you also wanted it to be the webdav path and it just cannot be that.

> At best, the docs are unclear.
> 

Yup.

> No matter for me. I'll just set org-mobile-directory to the physical, local path that is remotely
> accessible by webdav. But the doc was rather misleading, suggesting that some editorial attention
> would be warranted.
> 

Amen to that.

Nick

> hjh
> 
> 

Re: MobileOrg, webdav, correct use of org-mobile-directory?

[Adam Spiers]

Hi all,

I think some confusion has (quite understandably) arisen in this
thread about how the org-mobile + webDAV + tramp + scp combination is
supposed to work.  At risk of getting it all wrong and looking like a
fool, I *think* I can help explain :-)

On Sun, Aug 12, 2012 at 2:11 PM, Nick Dokos <nicholas.dokos@hp.com> wrote:
> James Harkins <jamshark70@gmail.com> wrote:
> > For my immediate needs, I think I can do without scp, since org-mode
> > and Apache are on the same machine.

Correct.

> > The broader point is about the
> > documentation. It says "do it this way" but "this way" doesn't work.

It definitely *can* work (I have it working, finally), but there are
various pitfalls - see below.

> I read the page on worg and I agree it's unclear: it talks about using
> webdav and then does not use webdav at all, just scp.

Yes, it's unclear.  The reason it talks about webDAV is that this is
how the mobile clients (well, Android at least) read and write files.
So when it refers to the webDAV directory, it actually means a
directory on a server which will be read from and written to by *both*
webDAV (on your mobile device) *and* tramp+scp (from emacs on your
computer).

That was the crux of the confusion described here:

  http://stackoverflow.com/questions/11486719/orgmode-cant-authenticate-to-webdav-for-mobile-org-push/

so from emacs, you should use your ssh password, even though the
intended remote target directory is (also) served via webDAV.

For most people, their mobile device cannot reach their computer
(e.g. home computer behind a NAT firewall) when roaming, which means
that the webDAV server needs to be publically accessible via the
internet.  In this case, org-mobile-directory should be a tramp path
beginning "/scp...".

But for other people such as James, the webDAV server runs on the same
machine where they edit their org files.  In this case,
org-mobile-directory can point directly at the path on the local file
system, and there is no need to use tramp.

> But I don't agree that it does not work: I've done a minimal setup
> with scp and tramp and org-mobile-push/pull worked fine for me. I
> suspect that you are still having some setup problems as indicated
> in my other email.

Yes, and I can hazard a guess what it might be, because I just got
bitten by a similar issue :-)  org-mobile-push was working for me when
invoked via emacs run in batch mode from a shell script, but not
in my running emacs instance.  I noticed that

  (file-exists-p org-mobile-directory)

was returning nil in the running emacs instance, which seemed to imply
that org-mobile-directory must refer to a path on the local
filesystem, but I knew that must be wrong otherwise it couldn't be
working in batch mode.  Eventually I had a light bulb moment where I
realised that tramp intercepts functions like file-exists-p, which is
how the above can return non-nil even for values of
org-mobile-directory beginning with "/scp...".  As a result I finally
traced the answer to a corrupt tramp cache entry.  Once I cleared the
cache:

  (setq tramp-cache-data (make-hash-table :test 'equal))

the error

  Variable `org-mobile-directory' must point to an existing directory

finally went away!

> > > > org-mobile-directory: /scpc:**user**@localhost:80/webdav/
> > >
> > > This looks wrong

Yes, it doesn't make sense to use tramp to scp files to localhost :-)

> Your other email shows that you figured this out.
>
> > 2. This destination is modeled on the docs, so if it's wrong, then so is the doc.
>
> Not really: the destination in the doc does not specify the port (80).
> That's the HTTP port, so scp won't work with that - that's what I picked
> up when I said it looked wrong. It needs the sshd port (22 by default
> and implied if you leave it out of the scp path in tramp).

Right, but scp'ing to localhost doesn't make sense.  He should just
use the normal local filesystem path instead and skip tramp.

> > > Where does org-mobile-directory point to if not the "physical location
> > > of the webdav share"? The tramp stuff doesn't know or care about webdav
> > > at all: it is just the mechanism that copies files from your local
> > > machine to some other machine, so it needs to know exactly where to copy
> > > it to.
> >
> > Well, it almost looks to me like org-mobile-directory is asked to
> > do two things at once: specify the scp syntax *and* hold a path
> > that can be resolved on the local file system. This is the source
> > of my confusion.

Hopefully by now I've cleared that up for you :-) It can *either* be
an scp/tramp reference to a remote location, or a normal path to a
local location.  It's never expected to be both at once :-)

> You mean the "remote file system" I think, but that's true: it does
> specify the protocol (scp) and the path. I think your confusion is that
> you also wanted it to be the webdav path and it just cannot be that.

In his case, there is no remote, because his Apache/webDAV server is on
the local machine.

> > At best, the docs are unclear.
>
> Yup.
>
> > No matter for me. I'll just set org-mobile-directory to the
> > physical, local path that is remotely accessible by webdav. But the
> > doc was rather misleading, suggesting that some editorial attention
> > would be warranted.
>
> Amen to that.

Agreed.  If at least one person lets me know that my explanations
above make sense, I might find some time to tweak the FAQ accordingly.

Re: MobileOrg, webdav, correct use of org-mobile-directory?

[Adam Spiers]

On Sun, Aug 19, 2012 at 12:25 AM, Adam Spiers <orgmode@adamspiers.org> wrote:
> Agreed.  If at least one person lets me know that my explanations
> above make sense, I might find some time to tweak the FAQ accordingly.

I went ahead and tweaked it anyway:

http://orgmode.org/worg/org-faq.html#sec-20

However, I can't figure out how to avoid the broken image, or how
to activate ditaa rendering.  Can someone help please?

Re: MobileOrg, webdav, correct use of org-mobile-directory?

[James Harkins]

At Sun, 19 Aug 2012 02:35:20 +0100,
Adam Spiers wrote:
> 
> On Sun, Aug 19, 2012 at 12:25 AM, Adam Spiers <orgmode@adamspiers.org> wrote:
> > Agreed.  If at least one person lets me know that my explanations
> > above make sense, I might find some time to tweak the FAQ accordingly.
> 
> I went ahead and tweaked it anyway:
> 
> http://orgmode.org/worg/org-faq.html#sec-20

Thanks, this is a bit clearer. I would go even further into "for-dummies" territory, such as:

~~~
How does synchronization via WebDAV work?

Synchronization involves two avenues of communication:

1. Between Emacs org-mode and the remotely-accessible share. This line of communication is used for org-mobile-push (C-c C-x RET p) and org-mobile-pull (C-c C-x RET g).

2. Between the remotely-accessible share and the mobile device(s), used when synchronizing MobileOrg on a phone or tablet.

#1 is done one way and one way only: org-mode reads or writes files to a filesystem path. When using Dropbox or Ubuntu One, it is a local directory. The Dropbox or Ubuntu One sync daemon takes care of transferring the data to the remote share. In that case, org-mode does not have to concern itself at all with the cloud storage.

With WebDAV, there are two possibilities:

- The WebDAV server is running on the same machine where org-mode is being used. This can simplify the configuration, but may restrict sync to a local wi-fi network. In this scenario, set org-mobile-directory to the physical path on the local machine housing the WebDAV share.

- Or, the WebDAV server is located on a different machine that is accessible by HTTP from anywhere in the Internet. It may be possible to mount the remote directory locally; if so, org-mobile-directory should be the mounted location. If this is not possible, you can also use scp (secure-copy) to push data and tramp to pull. Both require ssh access to the remote machine. Here, org-mobile directory should look like this:

"/scpc:user@remote.host:org/webdav/"

... where "user" is the ssh username on the remote machine and "remote.host" is the domain name. The physical path to the WebDAV share should follow the colon; it may be different from this example.

Org-mode never uses WebDAV to push or pull data. Do not configure org-mobile-directory with the HTTP URL of the WebDAV share.

#2, communication between the share and the mobile devices, does use WebDAV. Configure MobileOrg with the full URL pointing to the index.org file, e.g., http://a.webdav.server.com/webdav/my_user/mobileorg/index.org.
~~~

hjh


--
James Harkins /// dewdrop world
jamshark70@dewdrop-world.net
http://www.dewdrop-world.net

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman

blog: http://www.dewdrop-world.net/words
audio clips: http://www.dewdrop-world.net/audio
more audio: http://soundcloud.com/dewdrop_world/tracks

Re: MobileOrg, webdav, correct use of org-mobile-directory?

[Rémi Vanicat]

Adam Spiers <orgmode@adamspiers.org> writes:

> On Sun, Aug 19, 2012 at 12:25 AM, Adam Spiers <orgmode@adamspiers.org> wrote:
>> Agreed.  If at least one person lets me know that my explanations
>> above make sense, I might find some time to tweak the FAQ accordingly.
>
> I went ahead and tweaked it anyway:
>
> http://orgmode.org/worg/org-faq.html#sec-20
>
> However, I can't figure out how to avoid the broken image, or how
> to activate ditaa rendering.  Can someone help please?
>

I personally use webdav for both synchronization using the staging
method and the following[1] makefile

then you have to run make pull before pulling, and make push after
pushing to really pull and push file to webdav.

#+begin_src makefile
  ORG_FILES = $(shell ls *.org)
  CHECKSUMS = checksums.dat
  STMP_FILES = $(ORG_FILES:.org=.stmp) checksums.stmp
  # replace with the webdav host:
  HOST=example.org                
  # Put full url of the webdav directory
  URL=http://$(HOST)/mobileorg/   
  # put your username there:
  USER=itsme
  # put your password there
  PASSWD=secret
  # you could also use
  # PASSWD=$(shell gpg --use-agent --no-tty < $(HOME)/.authinfo.gpg | grep $(HOST) | sed "/$(USER)/s/.*password //")
  # if your .authinfo.gpg file contain a line like
  #       
  #       machine example login user password secret
  
  default: push
  push: stamp-sync
  all: default
  
  pull:
          curl -u $(USER):$(PASSWD) $(URL)mobileorg.org -o mobileorg.org
  
  stamp-sync: $(STMP_FILES)
          touch stamp-sync
  
  .SUFFIXES: .dat .org .stmp
  
  .org.stmp:
          curl  -u $(USER):$(PASSWD) -T $< $(URL)
          touch $@
  
  .dat.stmp:
          curl -u $(USER):$(PASSWD) -T $< $(URL)
          touch $@
  
  clean:
          rm *.stmp
#+end_src

-- 
Rémi Vanicat

Re: MobileOrg, webdav, correct use of org-mobile-directory?

[Nick Dokos]

Adam Spiers <orgmode@adamspiers.org> wrote:

> > > > > org-mobile-directory: /scpc:**user**@localhost:80/webdav/
> > > >
> > > > This looks wrong
> 
> Yes, it doesn't make sense to use tramp to scp files to localhost :-)
> 
> > Your other email shows that you figured this out.
> >
> > > 2. This destination is modeled on the docs, so if it's wrong, then so is the doc.
> >
> > Not really: the destination in the doc does not specify the port (80).
> > That's the HTTP port, so scp won't work with that - that's what I picked
> > up when I said it looked wrong. It needs the sshd port (22 by default
> > and implied if you leave it out of the scp path in tramp).
> 
> Right, but scp'ing to localhost doesn't make sense.  He should just
> use the normal local filesystem path instead and skip tramp.
> 

Well, to pick a nit: many times one has to model a multi-machine
situation on a single machine; after everything is debugged, then
various pieces are installed on various machines.

It makes sense in that situation to use tramp/scp and webdav/http even
locallly.

Nick

PS. For another example, sometimes I use tramp/scp to edit local files
    as a different user than the owner of the emacs process, e.g. files
    owned by root, particularly when there is a number of them that need
    to be changed and they are in the same directory: use tramp to open
    the directory as root and then dired to open files. Most of the time
    however, I do such minor changes with "sudo ed" in a shell buffer
    :-)

Re: MobileOrg, webdav, correct use of org-mobile-directory?

[James Harkins]

At Sun, 12 Aug 2012 00:29:20 -0400,
Nick Dokos wrote:
> This looks wrong - if you try it with scp from the command line, can
> you copy a file to that destination?

OK, I played a little more with scp and got closer -- I can copy a file from the command line:

scp /home/[myuser]/tmp/afile.txt [user]@localhost:/var/www/mobileorg/web

And "[user]@localhost:/var/www/mobileorg/web" for org-mobile-directory avoids the directory check error, but then:

org-mobile-create-sumo-agenda: Cannot write to file /scpc:user@localhost:/var/www/mobileorg/web/agendas.org

Same error if I change org-mobile-directory to be /scp:blahblah instead of /scpc.

So: okay at the commandline, not from Emacs.

As mentioned, it's a bit on the academic side because I can just use a local path. But, if I'm going to update the documentation, I'd like to get it to run successfully through scp once.

Thanks.
hjh


--
James Harkins /// dewdrop world
jamshark70@dewdrop-world.net
http://www.dewdrop-world.net

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman

blog: http://www.dewdrop-world.net/words
audio clips: http://www.dewdrop-world.net/audio
more audio: http://soundcloud.com/dewdrop_world/tracks

Re: MobileOrg, webdav, correct use of org-mobile-directory?

[Nick Dokos]

James Harkins <jamshark70@gmail.com> wrote:

> At Sun, 12 Aug 2012 00:29:20 -0400,
> Nick Dokos wrote:
> > This looks wrong - if you try it with scp from the command line, can
> > you copy a file to that destination?
> 
> OK, I played a little more with scp and got closer -- I can copy a file from the command line:
> 
> scp /home/[myuser]/tmp/afile.txt [user]@localhost:/var/www/mobileorg/web
> 

There are two possibilities here: 

o /var/www/mobileorg/web is a directory and you are copying the file
  into that directory under the name "afile.txt".

o /var/www/mobileorg is a directory, /var/www/mobileorg/web either
  does not exist or is a file in that directory and you are copying
  the file into the directory /var/www/mobileorg under the name "web".

The directory check *should* catch this case, but you might want to
double check that the "remote" directory
localhost:/var/www/mobileorg/web does indeed exist and is writable
by [myuser].

> And "[user]@localhost:/var/www/mobileorg/web" for org-mobile-directory avoids the directory check error, but then:
> 
> org-mobile-create-sumo-agenda: Cannot write to file /scpc:user@localhost:/var/www/mobileorg/web/agendas.org
> 

Also check the permissions on /var/www/mobileorg/web: in particular, you
might want to execute the following check (the check that
org-mobile-create-sumo-agenda does) in your *scratch* buffer:

  (file-writable-p "/scpc:nick@pierrot:/var/www/mobileorg/web/agendas.org")

Just cut and paste it into your *scratch* buffer, put the cursor after
the closing paren and press C-j. If it says nil, something is wrong.

One more thing: is tramp enabled in your emacs? Just try to open the
remote directory with

  C-x C-f /scpc:[user]@localhost:/var/www/mobileorg/web RET

I'm not sure that tramp needs any special attention (I cannot find anything
in my setup), but it doesn't hurt to check.

Nick

> Same error if I change org-mobile-directory to be /scp:blahblah instead of /scpc.
> 
> So: okay at the commandline, not from Emacs.
> 
> As mentioned, it's a bit on the academic side because I can just use a local path. But, if I'm going to update the documentation, I'd like to get it to run successfully through scp once.
> 
> Thanks.
> hjh
> 
> 
> --
> James Harkins /// dewdrop world
> jamshark70@dewdrop-world.net
> http://www.dewdrop-world.net
> 
> "Come said the Muse,
> Sing me a song no poet has yet chanted,
> Sing me the universal."  -- Whitman
> 
> blog: http://www.dewdrop-world.net/words
> audio clips: http://www.dewdrop-world.net/audio
> more audio: http://soundcloud.com/dewdrop_world/tracks
> 

Re: MobileOrg, webdav, correct use of org-mobile-directory?

[Nick Dokos]

Nick Dokos <nicholas.dokos@hp.com> wrote:

> 
> Also check the permissions on /var/www/mobileorg/web: in particular, you
> might want to execute the following check (the check that
> org-mobile-create-sumo-agenda does) in your *scratch* buffer:
> 
>   (file-writable-p "/scpc:nick@pierrot:/var/www/mobileorg/web/agendas.org")
> 
> Just cut and paste it into your *scratch* buffer, put the cursor after
> the closing paren and press C-j. If it says nil, something is wrong.
> 

... uhh, make sure to edit the line appropriately: nick@pierrot will not
work for you :-)

Nick

Re: LaTeX beamer export: relative file links?

[Nick Dokos]

James Harkins <jamshark70@gmail.com> wrote:

> I'm writing presentations for my classes using beamer export from org-mode (which is working
> beautifully, btw -- it's faster than LibreOffice impress and I get a convenient plain text archive
> of my slide contents to boot).
> 
> I'm authoring in Linux but I have to show the pdfs in windows. That's generally no problem,
> except... this week I wanted a link on one slide to an mp3 audio example. I entered the link in
> org-mode as a relative path ./blah.mp3, which either org or latex expanded to a UNIX-style full
> path. (I'm guessing org.) Obviously windows would not understand the UNIX path.
> 
> The question, then: Is it possible to use relative paths for file links in latex export? (I admit, I
> haven't searched for customize variables before writing this- apologies if it's obvious. I spent
> most of my research time this week setting up a mingw build environment for SuperCollider, so I'm a
> bit search-fatigued I'm afraid.)
> 

Maybe this:

,----
| org-link-file-path-type is a variable defined in `org.el'.
| Its value is adaptive
| 
| Documentation:
| How the path name in file links should be stored.
| Valid values are:
| 
| relative  Relative to the current directory, i.e. the directory of the file
|           into which the link is being inserted.
| absolute  Absolute path, if possible with ~ for home directory.
| noabbrev  Absolute path, no abbreviation of home directory.
| adaptive  Use relative path for files in the current directory and sub-
|           directories of it.  For other files, use an absolute 
`----

Nick

Re: LaTeX beamer export: relative file links?

[James Harkins]

At Sat, 29 Sep 2012 12:34:05 -0400,
Nick Dokos wrote:
> Maybe this:
> 
> ,----
> | org-link-file-path-type is a variable defined in `org.el'.
> | Its value is adaptive

No. That's about storage of links, but in my org file, the links *are* relative. They become absolute during export.

Less search-fatigued this morning. It seems, from the section of org-export-latex-links pasted below, that file paths are always expanded and this is not configurable.

My test:

# export header stuff omitted except the really critical:

#+TITLE:     Applied Techniques for Digital Audio \newline Introduction to Filters
#+AUTHOR:    H. James Harkins
#+DATE:      26 September 2012

* Section
** Slide
*** Bullet with [[./1346482292091_2436.mp3][inline link]]

C-c C-e l produces:

\item Bullet with \href{file:///media/39ED-A99A/some/folders/omitted/1346482292091_2436.mp3}{inline link}

hjh

	    (path (cond
		   ((member type '("coderef"))
		    raw-path)
		   ((member type '("http" "https" "ftp"))
		    (concat type ":" raw-path))
		   ((and re-radio (string-match re-radio raw-path))
		    (setq radiop t))
		   ((equal type "mailto")
		    (concat type ":" raw-path))
		   ((equal type "file")
		    (if (and (org-file-image-p
			      (expand-file-name
			       raw-path)
			      org-export-latex-inline-image-extensions)
			     (or (get-text-property 0 'org-no-description
						    raw-path)
				 (equal desc full-raw-path)))
			(setq imgp t)
		      (progn (when (string-match "\\(.+\\)::.+" raw-path)
			       (setq raw-path (match-string 1 raw-path)))
			     (if (file-exists-p raw-path)

; hjh editorial comment: It's mandatory... oops!
; expand-file-name is a built-in function in `C source code'.
; (expand-file-name NAME &optional DEFAULT-DIRECTORY)
; ***Convert filename NAME to absolute***, and canonicalize it.

				 (concat type "://" (expand-file-name raw-path))
			       (concat type "://" (org-export-directory
						   :LaTeX org-export-latex-options-plist)
				       raw-path))))))))



--
James Harkins /// dewdrop world
jamshark70@dewdrop-world.net
http://www.dewdrop-world.net

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman

blog: http://www.dewdrop-world.net/words
audio clips: http://www.dewdrop-world.net/audio
more audio: http://soundcloud.com/dewdrop_world/tracks

Re: <M-S-left/right> changed?

[Nick Dokos]

James Harkins <jamshark70@gmail.com> wrote:

> It seems the behavior of <M-S-left> and <M-S-right> has changed.
> Previously, if I selected multiple subtrees and hit M-S-right, all the
> subtrees in the region would be demoted (or promoted, if I hit left
> instead). Now, the behavior is identical to <M-left/right>: only the
> subtree at the point is moved.
> 

I get different behavior from what you describe, with Org-mode
version 7.9.2 (release_7.9.2-948-gab17f9 @
/home/nick/elisp/org-mode/lisp/) and also going back to the version you
mention below and also 7.9.2 for good measure:

M-S-right behaves as you describe (it demotes the current subtree) but
M-right demotes all the headings in the region (nb: *not* subtrees necessarily,
unless the region encompasses the whole subtree). AFAICT, this has been
the case for ever. Cursory examination of the code confirms that this is
expected behavior and checking commit logs on org.el back to Dec. 11 did
not unearth anything (but I am exhausted, so you should apply appropriate
levels of salinity).

So maybe I'm doing things wrong, but I cannot duplicate your results and
I don't see any change in bahavior since 7.9.2. Perhaps you can try it
again, perhaps somebody else can confirm (your story or my story, as the
case might be).

HTH,
Nick

> Example:
> 
> * One
> * Two
> * Three
> * Four
> 
> If I position the point at the beginning of the "Two" line, and then
> hit C-space down down, the region encompasses both headings. I
> expected <M-S-right> to change both into second level entries.
> Instead, it demotes "Four" (which is not even in the region).
> 
> Intentional decision, or regression? I would argue the latter. The old
> behavior was quite useful and I don't know how to get it back.
> 
> My current version is:
> 
> Org-mode version 7.9.2 (release_7.9.2-882-gf47a71.dirty @
> /home/dlm/share/org-mode.git/lisp/)
> 

Re: <M-S-left/right> changed?

[James Harkins]

[-- Attachment #1: Type: text/plain, Size: 585 bytes --]

On Jan 10, 2013 11:40 AM, "Nick Dokos" <nicholas.dokos@hp.com> wrote:
> I get different behavior from what you describe, with Org-mode
> version 7.9.2 (release_7.9.2-948-gab17f9 @
> /home/nick/elisp/org-mode/lisp/) and also going back to the version you
> mention below and also 7.9.2 for good measure:
>
> M-S-right behaves as you describe (it demotes the current subtree) but
> M-right demotes all the headings in the region (nb: *not* subtrees
necessarily,
> unless the region encompasses the whole subtree).

You are... quite right. I got confused between the two.

Thanks :-)
hjh

[-- Attachment #2: Type: text/html, Size: 753 bytes --]

Re: New exporter, beamer confusion

[Nick Dokos]

James Harkins <jamshark70@gmail.com> wrote:

> On Feb 5, 2013 3:51 AM, "Nicolas Goaziou" <n.goaziou@gmail.com> wrote:
> > In particular, "All frames children become block environments". So in
> > your example Third-level is a block environment and Fourth-level is
> > a block within it. There's no flattening going on (look at the tex file
> > to convince yourself).
> 
> Thanks for pointing me to the comments in the .el source file.
> 
> So here's my situation. I have a year's worth of lecture slides that render nicely using the old
> exporter. In the new exporter, the clear hierarchies of "enumerate" environments disappear, replaced
> by flat blocks. This new behavior is not useful to me.
> 
> The comments in the source don't say anything about how I can modify the default "block" behavior.
> As a result, if the new exporter is fundamentally incompatible with the old and the only way is to
> insert properties by hand under every headline (across all of my files, I'd guess the count is in
> the high hundreds, if not >1000)... then the new beamer exporter is not useful to me.
> 

Customizing org-e-beamer-environments-extra should do the trick.  I was
experimenting using the *scratch* buffer, so the following are temporary
settings, cribbed from those experiments: restart emacs and they
disappear.

Something like the following perhaps (very lightly tested - nb: I really
haven't played with the new exporter very much at all):

--8<---------------cut here---------------start------------->8---
(setq blockenv '("block" "b" "\\begin{itemize}\\item %h" "\\end{itemize}"))
(add-to-list 'org-e-beamer-environments-extra blockenv t)
--8<---------------cut here---------------end--------------->8---

I added a beamer entry to org-e-latex-classes as indicated in

  http://thread.gmane.org/gmane.emacs.orgmode/61497/focus=61536

by just copying the article entry and modifying it slightly (again, I
have no idea if the sectioning stuff matters or not, and whether it leads
to problems - improvements/corrections would be welcome):

--8<---------------cut here---------------start------------->8---
(setq beamerclass '("beamer" "\\documentclass[11pt]{beamer}"
  ("\\section{%s}" . "\\section*{%s}")
  ("\\subsection{%s}" . "\\subsection*{%s}")
  ("\\subsubsection{%s}" . "\\subsubsection*{%s}")
  ("\\paragraph{%s}" . "\\paragraph*{%s}")
  ("\\subparagraph{%s}" . "\\subparagraph*{%s}")))

(add-to-list 'org-e-latex-classes beamerclass t)
--8<---------------cut here---------------end--------------->8---

That's enough to export your ECM I think - no guarantees for
anything more complicated.

Nick

> Is there an existing feature request for this? If not, would it help if I logged one? (Even if I
> didn't have existing files -- I like bullet points on slides, not flat text. I don't understand why
> I shouldn't be able to set that as a global or per-file preference.)
> 
> I don't mean to be harsh. I'm glad for the new exporter and I'll use it for the next article I
> write. For beamer, though, currently it sounds like a lot of work to get a result that used to be
> easy.
> 
> hjh
> 
> 
> ----------------------------------------------------
> Alternatives:
> 
> ----------------------------------------------------

Re: New exporter, beamer confusion

[James Harkins]

[-- Attachment #1: Type: text/plain, Size: 3496 bytes --]

On Tue, Feb 5, 2013 at 3:21 PM, Nick Dokos <nicholas.dokos@hp.com> wrote:
> I added a beamer entry to org-e-latex-classes as indicated in
>
>   http://thread.gmane.org/gmane.emacs.orgmode/61497/focus=61536
>
> (again, I
> have no idea if the sectioning stuff matters or not, and whether it leads
> to problems - improvements/corrections would be welcome):

Made no difference for me.

> Customizing org-e-beamer-environments-extra should do the trick.  I was
> experimenting using the *scratch* buffer, so the following are temporary
> settings, cribbed from those experiments: restart emacs and they
> disappear.
>
> Something like the following perhaps (very lightly tested - nb: I really
> haven't played with the new exporter very much at all):
>
> --8<---------------cut here---------------start------------->8---
> (setq blockenv '("block" "b" "\\begin{itemize}\\item %h" "\\end{itemize}"))
> (add-to-list 'org-e-beamer-environments-extra blockenv t)
> --8<---------------cut here---------------end--------------->8---

I'm attaching an org file that illustrates a couple of the beamer
formatting options that I used a lot in the old exporter.

1. I *did* use the block environment to emphasize some text by pulling
it out of the "itemize" bullet lists. If I customize blockenv in org
to render as "itemize," then I lose the ability to do this (or, I have
to call "block" something else).

2. BMCOL (column) layouts are completely ignored.

3. Strong *emphasis* now renders in red, instead of keeping the text's
original color and switching to boldface.

I've also uploaded 3 PDFs to UbuntuOne, the point being to illustrate
how much functionality is lost in the new exporter:

1. Old exporter result
http://ubuntuone.com/2ByUYyYg5wfz07aUuUVPTP

2. New exporter result, without customizing
http://ubuntuone.com/4HSQUoDlZpNHZ46OROZd54

3. New exporter result, with Nick's customization
http://ubuntuone.com/1DnRQultVtdf2OKYjaeSsu


I get the feeling here that the new beamer exporter was written
without a lot of real-world user requirements. Certainly, it's
understandable that HTML, LaTeX article-style and ODT exporters would
be more widely used and more important to get right first. For beamer,
though, I can't reconcile the announcement ("Even though the internals
are completely different, the new exporter mostly behaves like its
predecessor. There are only a few noticeable changes") with the fact
that the new beamer exporter is a rather different animal that
completely breaks compatibility with org files written for the old
exporter, and may actually require a complete redo of the org markup
for each file.

I know my emacs-lisp chops are not up to the task of fixing what is
broken in the new beamer exporter. I can supply a couple dozen source
files, to help decide what level of backward compatibility is
feasible. I'm not sure how else I can help.

At least, it would be good to clarify, with respect to the
announcement, if the new beamer exporter is intended to be reasonably
backward-compatible with the old (with not-too-intrusive tweaks). If
that was the intent, then it's not ready for release. Otherwise, I'd
be happy to help draw up an upgrade path for people like myself who
have developed workflows for the old exporter that will eventually not
be supported anymore.

In the meantime, I must stick with the old exporter, though I'll keep
the discussion alive to hash out on the mailing list what needs to be
done to make the new one production-ready for me.

hjh

[-- Attachment #2: simple-beamer.org --]
[-- Type: application/octet-stream, Size: 2082 bytes --]

#+LANGUAGE:  en
#+OPTIONS:   H:2 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t
#+OPTIONS:   TeX:t LaTeX:t skip:nil d:nil todo:t pri:nil tags:not-in-toc

#+startup: beamer
#+LaTeX_CLASS: beamer
#+LaTeX_CLASS_OPTIONS: [presentation]
#+BEAMER_FRAME_LEVEL: 2
#+BEAMER_THEME: default
#+COLUMNS: %45ITEM %10BEAMER_env(Env) %10BEAMER_act(Act) %4BEAMER_col(Col) %8BEAMER_opt(Opt)
#+PROPERTY: BEAMER_col_ALL 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0.0 :ETC

#+TITLE:     Testing new beamer exporter
#+AUTHOR:    H. James Harkins
#+EMAIL:     jamshark70@yaddayadda.com
#+DATE:      7 November 2012

#+BEGIN_LaTeX
\AtBeginSection[] % Do nothing for \section*
{
\begin{frame}<beamer>
\frametitle{Outline}
\tableofcontents[currentsection]
\end{frame}
}
#+END_LaTeX

* Section A
** Slide 1
*** Third-level
**** Fourth-level
** Ancient history: *Music \emph{n}* languages
*** Early pioneers at *Bell Labs* in New Jersey
**** Max Mathews, Jean-Claude Risset, John Chowning
**** They could make the digital tapes, but not play them
**** Drove the tapes up to Columbia University (NYC)
***** ... just to find out that it didn't work
*** Mainframe, batch processing
**** Prepare /instrument/ and /score/ files
**** Run the program
**** An audio file comes out... hours later
*** Modern version: *csound*
**** Modern CPUs can render faster than real-time
#+LaTeX: \pause
*** *Without these early researchers, there is no Cubase, no Logic... nothing.* :B_block:
    :PROPERTIES:
    :BEAMER_env: block
    :END:
** SuperCollider live
*** Map /processes/ onto MIDI keys
*** /Driver processes/ for complex transitions
*** Map /global controls/ to MIDI controllers
**** Synthesis parameters (filters, etc.)
**** Composition parameters (rhythmic activity, probabilities etc.)
*** This is my own design 					      :BMCOL:
    :PROPERTIES:
    :BEAMER_col: 3.0cm
    :END:
*** SC has no standard GUI!
*** You decide what /you/ need
*** GUI								      :BMCOL:
    :PROPERTIES:
    :BEAMER_col: 7.0cm
    :END:
#+ATTR_LaTeX: width=6.5cm
[[/media/39ED-A99A/cubase/2012audio/10-intro-sc/img/controlpanel.pdf]]

Re: New exporter, beamer confusion

[Sebastien Vauban]

Hi James,

James Harkins wrote:
> 3. Strong *emphasis* now renders in red, instead of keeping the text's
> original color and switching to boldface.

That's because the * are exported as \alert macros in the new exporter
(instead of \textbf in the old one -- for bold face).

As, in the LaTeX's Beamer back-end, you have the ability to either use alert
or bold face, I'd be very happy to do the same from the source Org file,
using:

- `*' for bold (as always),
- `@' for alert (for example[1]).

Though, this is not currently implemented this way, and the default has been
changed between the old and the new exporters.

IIRC, Nicolas' answer was to insert \textbf calls where you want such use of
bold face. Or maybe overwriting one variable which would be the macro used for
translation `*' characters -- but, then, you must anyway use one LaTeX macro
or the other.

Best regards,
  Seb

[1] I think this is Eric Fraga's initial choice of meta-character for alert in
the old exporter (using extra custom code).

-- 
Sebastien Vauban

Re: New exporter, beamer confusion

[Nick Dokos]

James Harkins <jamshark70@gmail.com> wrote:

> ... 
> 
> I get the feeling here that the new beamer exporter was written
> without a lot of real-world user requirements. Certainly, it's
> understandable that HTML, LaTeX article-style and ODT exporters would
> be more widely used and more important to get right first. For beamer,
> though, I can't reconcile the announcement ("Even though the internals
> are completely different, the new exporter mostly behaves like its
> predecessor. There are only a few noticeable changes") with the fact
> that the new beamer exporter is a rather different animal that
> completely breaks compatibility with org files written for the old
> exporter, and may actually require a complete redo of the org markup
> for each file.
> 
> I know my emacs-lisp chops are not up to the task of fixing what is
> broken in the new beamer exporter. I can supply a couple dozen source
> files, to help decide what level of backward compatibility is
> feasible. I'm not sure how else I can help.
> 
> At least, it would be good to clarify, with respect to the
> announcement, if the new beamer exporter is intended to be reasonably
> backward-compatible with the old (with not-too-intrusive tweaks). If
> that was the intent, then it's not ready for release. Otherwise, I'd
> be happy to help draw up an upgrade path for people like myself who
> have developed workflows for the old exporter that will eventually not
> be supported anymore.
> 
> In the meantime, I must stick with the old exporter, though I'll keep
> the discussion alive to hash out on the mailing list what needs to be
> done to make the new one production-ready for me.
> 

I'm sure Nicolas is up to his ears in prep work, but eventually I'm sure
he or somebody else who knows more about it than I do, will comment.

Just as a general precaution, I wouldn't rush to judgement based on
my fumbling attempts: these were small experiments done without knowing
anything about the new exporter to begin with. I hope that they did more
good than harm, but it *is* just a hope on my part. Don't mistake them
for authoritative information.

Nick

Re: New exporter, beamer confusion

[Nicolas Goaziou]

Hello,


> I'm attaching an org file that illustrates a couple of the beamer
> formatting options that I used a lot in the old exporter.

See below.

> 1. I *did* use the block environment to emphasize some text by pulling
> it out of the "itemize" bullet lists. If I customize blockenv in org
> to render as "itemize," then I lose the ability to do this (or, I have
> to call "block" something else).
>
> 2. BMCOL (column) layouts are completely ignored.

No. BMCOL are just different.

> 3. Strong *emphasis* now renders in red, instead of keeping the text's
> original color and switching to boldface.

Indeed. Strong emphasis in Beamer's jargon is \alert{...} (see Beamer
documentation about it). Letter are so large that \textbf{...} doesn't
fill the job well enough. I'm not saying that \textbf{...} is useless
(though I think it), but "alert" was preferred.

> I get the feeling here that the new beamer exporter was written
> without a lot of real-world user requirements.

FWIW, I have used it almost daily since I wrote it.

> Certainly, it's understandable that HTML, LaTeX article-style and ODT
> exporters would be more widely used and more important to get right
> first. For beamer, though, I can't reconcile the announcement ("Even
> though the internals are completely different, the new exporter mostly
> behaves like its predecessor. There are only a few noticeable
> changes") with the fact that the new beamer exporter is a rather
> different animal that completely breaks compatibility with org files
> written for the old exporter, and may actually require a complete redo
> of the org markup for each file.

You are half correct. I admit: I forgot to mention that Beamer back-end
was a bit different from its predecessor. Though, it doesn't require
a complete redo, there's just some work to do at the headline level.

> I know my emacs-lisp chops are not up to the task of fixing what is
> broken in the new beamer exporter.

Nothing is broken in it (at least AFAIK). There are just some changes to
do.

> I can supply a couple dozen source
> files, to help decide what level of backward compatibility is
> feasible. I'm not sure how else I can help.

Let's start slowly. I think you can get how to make the changes yourself
with a couple of examples. Since you seem to like lists (you know that
Till Tantau frowns upon the use of third level lists in presentations,
don't you?), the first rule to know is:

  Headlines will never, ever, become lists in the new Beamer back-end.

If you want lists, use lists. There's a handy command to do that change:
mark the subtree you want to change, and use "C-c -".

New back-end is more block friendly than lists friendly.

> At least, it would be good to clarify, with respect to the
> announcement, if the new beamer exporter is intended to be reasonably
> backward-compatible with the old (with not-too-intrusive tweaks).

It all depends on what you mean by reasonably. You can obtain the same
output, but there are changes to make in Org files.

> If that was the intent, then it's not ready for release. Otherwise,
> I'd be happy to help draw up an upgrade path for people like myself
> who have developed workflows for the old exporter that will eventually
> not be supported anymore.

Thank you. I'll try to help you get started. You might even come to like
the new back-end in the process.

> In the meantime, I must stick with the old exporter, though I'll keep
> the discussion alive to hash out on the mailing list what needs to be
> done to make the new one production-ready for me.

Fair enough.

I'm attaching an updated version of your simple document. Besides moving
subtree to lists, there only other change was at the columns level.

If you use a headline with only a BEAMER_col property, its title will be
ignored and can be used as a container. If you provide it an additional
environment (like block), the new environment will be put in the column
and will fill it. Moreove, the :BEAMER_col: property requires a decimal
number as value, not a length.

Oh, yes, and BEAMER_FRAME_LEVEL doesn't exist anymore. It's H:... in the
OPTIONS line.

#+begin_src org
#+LANGUAGE:  en
#+OPTIONS:   H:2 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t
#+OPTIONS:   TeX:t LaTeX:t skip:nil d:nil todo:t pri:nil tags:not-in-toc

#+startup: beamer
#+LaTeX_CLASS: beamer
#+LaTeX_CLASS_OPTIONS: [presentation]
#+BEAMER_THEME: default
#+COLUMNS: %45ITEM %10BEAMER_env(Env) %10BEAMER_act(Act) %4BEAMER_col(Col) %8BEAMER_opt(Opt)
#+PROPERTY: BEAMER_col_ALL 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0.0 :ETC

#+TITLE:     Testing new beamer exporter
#+AUTHOR:    H. James Harkins
#+EMAIL:     jamshark70@yaddayadda.com
#+DATE:      7 November 2012

#+BEGIN_LaTeX
\AtBeginSection[] % Do nothing for \section*
{
\begin{frame}<beamer>
\frametitle{Outline}
\tableofcontents[currentsection]
\end{frame}
}
#+END_LaTeX

* Section A
** Slide 1
   - Third-level
     - Fourth-level
** Ancient history: *Music \emph{n}* languages
   - Early pioneers at *Bell Labs* in New Jersey
     - Max Mathews, Jean-Claude Risset, John Chowning
     - They could make the digital tapes, but not play them
     - Drove the tapes up to Columbia University (NYC)
       - ... just to find out that it didn't work
   - Mainframe, batch processing
     - Prepare /instrument/ and /score/ files
     - Run the program
     - An audio file comes out... hours later
   - Modern version: *csound*
     - Modern CPUs can render faster than real-time
#+BEAMER: \pause{}
*** *Without these early researchers, there is no Cubase, no Logic... nothing.*
** SuperCollider live
   - Map /processes/ onto MIDI keys
   - /Driver processes/ for complex transitions
   - Map /global controls/ to MIDI controllers
     - Synthesis parameters (filters, etc.)
     - Composition parameters (rhythmic activity, probabilities etc.)
*** Left column (title ignored)                                            :BMCOL:
    :PROPERTIES:
    :BEAMER_col: 0.3
    :END:
    - This is my own design
    - SC has no standard GUI!
    - You decide what /you/ need
*** Right column (title ignored)                                           :BMCOL:
    :PROPERTIES:
    :BEAMER_col: 0.7
    :END:
    - GUI

      #+ATTR_LaTeX: :options "width=6.5cm"
      [[ /media/39ED-A99A/cubase/2012audio/10-intro-sc/img/controlpanel.pdf]]
#+end_src


Regards,

-- 
Nicolas Goaziou

Re: New exporter, beamer confusion

[Eric S Fraga]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

[...]

> Let's start slowly. I think you can get how to make the changes yourself
> with a couple of examples. Since you seem to like lists (you know that
> Till Tantau frowns upon the use of third level lists in presentations,
> don't you?), the first rule to know is:

[...]

Nicolas,

this email has been quite helpful.  I now see where you have gone with
beamer and overall I like your approach.  However, I *still* cannot get
this to work.

Taking your updated version of the example document, I cannot get the
exporter to generate a latex file that will compile because it is
missing a documentclass directive.  Is there something else that needs
to be configured to support beamer, as in maybe org-e-latex-classes?
The default has no mention of beamer and although the documentation
within org-e-beamer.el does allude to org-e-latex-classes, it doesn't
say whether that variable needs to be adapted/updated/changed.

Having looked at the code, I think I do need to add a "beamer" entry to
that variable.  Can you please suggest a default that would work?  And
maybe update the documentation or at least output an error message if
the latex class desired is not actually found in org-e-beamer-template?
That function would appear to do nothing if an appropriate entry is not
found and hence explains why I get an exported file with no
documentclass line!

Thanks,
eric

-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org 7.9.3e-897-g787a07

Re: New exporter, beamer confusion

[Nicolas Goaziou]

Hello,

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> Taking your updated version of the example document, I cannot get the
> exporter to generate a latex file that will compile because it is
> missing a documentclass directive.  Is there something else that needs
> to be configured to support beamer, as in maybe org-e-latex-classes?

Indeed. I added it to ox-beamer.el in-file documentation. You need to
add an entry appropriate for Beamer export. This entry doesn't need to
be named "beamer". For example, after the merge you add the following to
your init file:

#+begin_src emacs-lisp
'(add-to-list 'org-latex-classes
                '("pres"
                  "\\documentclass[presentation]{beamer}
\[DEFAULT-PACKAGES]
\[PACKAGES]
\[EXTRA]"
                  ("\\section{%s}" . "\\section*{%s}")
                  ("\\subsection{%s}" . "\\subsection*{%s}")
                  ("\\subsubsection{%s}" . "\\subsubsection*{%s}")))
#+end_src

Then, the following in your buffer will suffice.

  #+latex_class: pres



Regards,

-- 
Nicolas Goaziou

Re: New exporter, beamer confusion

[Eric S Fraga]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>
>> Taking your updated version of the example document, I cannot get the
>> exporter to generate a latex file that will compile because it is
>> missing a documentclass directive.  Is there something else that needs
>> to be configured to support beamer, as in maybe org-e-latex-classes?
>
> Indeed. I added it to ox-beamer.el in-file documentation. You need to

Thanks.  This will indeed help.

Should there be a check in the exporter, for latex based backends, if
the document class expected is not defined?  This would have made things
a lot quicker to resolve in this case!

Thanks again,
eric
-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org 7.9.3e-904-g338046

Re: New exporter, beamer confusion

[Nicolas Goaziou]

> Should there be a check in the exporter, for latex based backends, if
> the document class expected is not defined?  This would have made things
> a lot quicker to resolve in this case!

What is an "expected document class"? Beamer export can happen with
a "beamer" or an "article" (and probably others) document class. There's
no real way to know if the class used is correct.


Regards,

-- 
Nicolas Goaziou

Re: New exporter, beamer confusion

[Vincent Beffara]

Hi, 
> LaTeX class is never unspecified because `beamer' back-end is
> a derivative of `latex', and, as such, `org-latex-default-class' will be
> used. `beamer' could specify its own default class, but that class would
> still need to be defined in `org-latex-classes'.

Sure, it should be in the default list. What is the drawback?
> '("beamer"
> "\\documentclass[presentation]{beamer}
> \[DEFAULT-PACKAGES]
> \[PACKAGES]
> \[EXTRA]"
> ("\\section{%s}" . "\\section*{%s}")
> ("\\subsection{%s}" . "\\subsection*{%s}")
> ("\\subsubsection{%s}" . "\\subsubsection*{%s}"))

Looks reasonable. 
> > Plain latex export is more problematic because several options are
> > reasonable, but I can't see beamer export with an article class ...
> 
> But it exists, and is documented in the Beamer User Guide. See section
> "21.2. Creating Handouts Using the Article Mode".

Yes, I know that, but the thing is, from a given org-file, I would expect beamer export to make the slides and 'plain' latex export to create the handout. Maybe it is difficult to achieve but it feels like the most useable setup. Is it at all doable?

/v

Re: New exporter, beamer confusion

[Nicolas Goaziou]

Vincent Beffara <vbeffara+ml@gmail.com> writes:

> Sure, it should be in the default list. What is the drawback?

The default list is defined in ox-latex.el, which doesn't know anything
about ox-beamer.el. The drawback is that it doesn't seem clean to me.

I think it's better to make it a fallback value hardcoded (or in
a defconst) in ox-beamer.el instead.

> Yes, I know that, but the thing is, from a given org-file, I would
> expect beamer export to make the slides and 'plain' latex export to
> create the handout. Maybe it is difficult to achieve but it feels like
> the most useable setup. Is it at all doable?

If the author is cautious about keywords used (i.e. #+BEAMER: or
#+LATEX:), it should be possible to export the same document with either
`beamer' or `latex' back-end. Though, I don't know how much difference
there would be between the output from `latex' and a Beamer handout
produced with "article" class.


Regards,

-- 
Nicolas Goaziou

Re: New exporter, beamer confusion

[Rasmus]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> If the author is cautious about keywords used (i.e. #+BEAMER: or
> #+LATEX:), it should be possible to export the same document with either
> `beamer' or `latex' back-end. Though, I don't know how much difference
> there would be between the output from `latex' and a Beamer handout
> produced with "article" class.


There is an auxiliary package called beamerarticle.  It's neat.  It's
described in 21.2.1 in the beamer guide v.3.26.  And there's an
example in the file conference-ornate-20min.en.tex which is shipped
with beamer.

Cool with the #+BEAMER.  I didn't know about this, but it's super
nice.  The other day I was lookking for a replacement to
#+BEAMER_HEADER (I think that was what it was called), which existed
with the 'old' exporter.  Does this variable exist in Beamer yet?

Thanks a lot for your work Nicolas.  It's super cool!

–Rasmus

-- 
In theory, practice and theory are the same. In practice they are not

Re: New exporter, beamer confusion

[Nicolas Goaziou]

Hello,

Rasmus <rasmus@gmx.us> writes:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
>> If the author is cautious about keywords used (i.e. #+BEAMER: or
>> #+LATEX:), it should be possible to export the same document with either
>> `beamer' or `latex' back-end. Though, I don't know how much difference
>> there would be between the output from `latex' and a Beamer handout
>> produced with "article" class.
>
>
> There is an auxiliary package called beamerarticle.  It's neat.  It's
> described in 21.2.1 in the beamer guide v.3.26.  And there's an
> example in the file conference-ornate-20min.en.tex which is shipped
> with beamer.
>
> Cool with the #+BEAMER.  I didn't know about this, but it's super
> nice.  The other day I was lookking for a replacement to
> #+BEAMER_HEADER (I think that was what it was called), which existed
> with the 'old' exporter.  Does this variable exist in Beamer yet?

There is the #+LATEX_HEADER:. Is a keyword specific to Beamer required?
It would by symmetric with #+BEAMER: but I have never needed it before.


Regards,

-- 
Nicolas Goaziou

Re: New exporter, beamer confusion

[Rasmus]

Nicolas,

> There is the #+LATEX_HEADER:. Is a keyword specific to Beamer
> required?  It would by symmetric with #+BEAMER: but I have never
> needed it before.


Something like

#+LATEX_HEADER:\AtBeginSection[]{\frame{\thispagestyle{empty}\tableofcontents[currentsection]}}

is not interesting to a LaTeX article output, but perhpas in a Beamer.
Or it might want to use a more 'fun' font for my slides while sticking
with kpfonts for the article version, e.g.

#+BEAMER_HEADER:\usepackage[math]{anttor}
#+LATEX_HEADER:\usepackage[light]{kpfonts}

But perhaps (probably!) it could be sorted out on the LaTeX side,
e.g. via beamerarticle.

–Rasmus

-- 
Vote for proprietary math!

Re: New exporter, beamer confusion

[Nicolas Goaziou]

Rasmus <rasmus@gmx.us> writes:

>> There is the #+LATEX_HEADER:. Is a keyword specific to Beamer
>> required?  It would by symmetric with #+BEAMER: but I have never
>> needed it before.
>
>
> Something like
>
> #+LATEX_HEADER:\AtBeginSection[]{\frame{\thispagestyle{empty}\tableofcontents[currentsection]}}
>
> is not interesting to a LaTeX article output, but perhpas in a Beamer.
> Or it might want to use a more 'fun' font for my slides while sticking
> with kpfonts for the article version, e.g.
>
> #+BEAMER_HEADER:\usepackage[math]{anttor}
> #+LATEX_HEADER:\usepackage[light]{kpfonts}
>
> But perhaps (probably!) it could be sorted out on the LaTeX side,
> e.g. via beamerarticle.

I have added BEAMER_HEADER keywords.


Regards,

-- 
Nicolas Goaziou

Re: New exporter, beamer confusion

[Eric S Fraga]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

>> Should there be a check in the exporter, for latex based backends, if
>> the document class expected is not defined?  This would have made things
>> a lot quicker to resolve in this case!
>
> What is an "expected document class"? Beamer export can happen with
> a "beamer" or an "article" (and probably others) document class. There's
> no real way to know if the class used is correct.

Sure.  I didn't suggest that there should be a default (although as
others have suggested, a default of "beamer" would be reasonable).  My
point was simply that generating a latex file with no "documentclass"
line doesn't make much sense and this omission should be caught by the
exporter.  It would help any user more quickly figure out what is wrong
with the org file being exported.  Well, it would have helped me! ;-)

Arguably, this is not a problem with the beamer exporter but the latex
one instead.

In any case, I'd like to say thanks!  I had a presentation to give
earlier today and wrote it from scratch using the new exporter.  After
the initial hiccoughs (as documented on this list) and my not having
noted earlier that the ATTR_* syntax had changed (e.g. :options
width=... for images), everything went like a charm.

eric
-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org 7.9.3e-904-g338046

Re: New exporter, beamer confusion

[James Harkins]

[-- Attachment #1: Type: text/plain, Size: 3554 bytes --]

Thanks for all this. I'll look at the new org markup later today. That
should help a lot.

On Feb 6, 2013 3:03 AM, "Nicolas Goaziou" <n.goaziou@gmail.com> wrote:
> > 3. Strong *emphasis* now renders in red, instead of keeping the text's
> > original color and switching to boldface.
>
> Indeed. Strong emphasis in Beamer's jargon is \alert{...} (see Beamer
> documentation about it). Letter are so large that \textbf{...} doesn't
> fill the job well enough. I'm not saying that \textbf{...} is useless
> (though I think it), but "alert" was preferred.

Ok. There was something about customizing this on the list just recently.
I'll use that. (FWIW, I had to produce a number of *gasp cough choke*
PowerPoint shows in my previous job, and they told us not to use red for
*anything* unless it really was a four-alarm-fire "you will really screw
things up if you ignore this" type of point, and I retain this aversion to
red text to this day.)

Btw, *who* preferred \alert? (Orwell, Politics and the English Language:
"Never use the passive [voice] where you can use the active.")

> Since you seem to like lists (you know that
> Till Tantau frowns upon the use of third level lists in presentations,
> don't you?)

I appreciate his contribution to LaTeX, but I'll make my own decisions
about style, thanks.

>   Headlines will never, ever, become lists in the new Beamer back-end.
>
> If you want lists, use lists. There's a handy command to do that change:
> mark the subtree you want to change, and use "C-c -".
>
> New back-end is more block friendly than lists friendly.

Although I'm not happy about manual intervention to convert my prior work,
this is a good step toward consistency. It was odd, in the old framework,
to use headlines for bullet lists and org's numbered lists for numbered
lists. "An org list becomes an output list" is an easier rule to explain.

Still, I wonder if there is a way to make the new backend less unfriendly
toward lists. It's an interesting philosophical question: In what cases is
it better for the tool to adapt to the users' wishes, versus cases where
the tool should encourage (Are blocks in the result actually better than
lists? Who says so, and why should I take his or her word for it?)

> > At least, it would be good to clarify, with respect to the
> > announcement, if the new beamer exporter is intended to be reasonably
> > backward-compatible with the old (with not-too-intrusive tweaks).
>
> It all depends on what you mean by reasonably. You can obtain the same
> output, but there are changes to make in Org files.

"Reasonably" for me would mean tweaking some configuration options and
perhaps changing a few minor details of the markup. If you have to change
the org document's structure (e.g., converting headlines to lists), it
isn't backward compatible.

For comparison: Lilypond updates frequently break some details of backward
compatibility. So, they ship a "convert-ly" script to handle many of those
changes automatically.

> Oh, yes, and BEAMER_FRAME_LEVEL doesn't exist anymore. It's H:... in the
> OPTIONS line.

Right, covered in an earlier message in this thread. I included it here so
you could compile it using the old exporter, for comparison.

> I'm attaching an updated version of your simple document. Besides moving
> subtree to lists, there only other change was at the columns level.

Thanks for this, and the explanation of columns. Actually, I never was
really happy with columns in the old backend. It's quite likely to be
better here!

Really appreciate the details.

hjh

[-- Attachment #2: Type: text/html, Size: 4270 bytes --]

Re: New exporter, beamer confusion

[Eric S Fraga]

James Harkins <jamshark70@gmail.com> writes:

[...]

> Ok. There was something about customizing this on the list just recently.
> I'll use that. (FWIW, I had to produce a number of *gasp cough choke*
> PowerPoint shows in my previous job, and they told us not to use red for
> *anything* unless it really was a four-alarm-fire "you will really screw
> things up if you ignore this" type of point, and I retain this aversion to
> red text to this day.)

#+BEAMER: \setbeamercolor{alerted text}{...some other colour...}

-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org 7.9.3e-897-g787a07

Re: New exporter, beamer confusion

[Rasmus]

James Harkins <jamshark70@gmail.com> writes:

> Btw, *who* preferred \alert? (Orwell, Politics and the English Language:
> "Never use the passive [voice] where you can use the active.")

I prefer alert.  See the Beamer manual (texdoc beamer in texlive) on
change of style and how to use alert (e.g. alert on one particular
(sub)slide of a "multipage slide").  It's the Beamer way.  Surely it
cannot be a bad thing?

> Still, I wonder if there is a way to make the new backend less unfriendly
> toward lists. It's an interesting philosophical question: In what cases is
> it better for the tool to adapt to the users' wishes, versus cases where
> the tool should encourage (Are blocks in the result actually better than
> lists? Who says so, and why should I take his or her word for it?)

Org has many dedicated list symbols namely white space and one of
{[-+*], [0-9][.)]}.  Why should a headline be converted to a list?  It
was always awkward to me.

I don't know how hard it would be to make the "default" block (of
level 3, say) a list block, but I guess that's ultimately what you
want?  Such a behavior shouldn't be the default, IMO, since a headline
is not a list.


> "Reasonably" for me would mean tweaking some configuration options and
> perhaps changing a few minor details of the markup. If you have to change
> the org document's structure (e.g., converting headlines to lists), it
> isn't backward compatible.

I'm sure it would be relatively quick to hack together a couple of
regexps and some lisp to do the conversion if you prefer to use the
new exporter.  E.g. find every occurrence of * in the beginning of the
line of length X and convert each occurrence to "-" with appropriate
white space (e.g. X + N).

What might be useful would be a tag telling Org to use the legacy
exporter on a file basis, although it would also be a short run
solution.

–Rasmus

--
Summon the Mothership!

Re: New exporter, beamer confusion

[Suvayu Ali]

On Wed, Feb 06, 2013 at 01:32:22PM +0100, Rasmus wrote:
> 
> I don't know how hard it would be to make the "default" block (of
> level 3, say) a list block, but I guess that's ultimately what you
> want?  Such a behavior shouldn't be the default, IMO, since a headline
> is not a list.
> 

Nested headlines being translated to lists was always a misfeature in
the old exporter.  This was extensibly discussed on the list before
Nicolas implemented the current beamer exporter.  I do not see any
reason to not "fix" old inconsistent behaviour for the sake of backwards
compatibility.

That said, I think the best way to deal with this is to follow what
Nicolas suggested, mark the subtree and then do `C-c -' to convert these
headlines into lists.  This can be automated to a significant degree by
using keyboard macros or custom lisp.  A well tested keyboard macro can
be easily saved and used as a command.  Since the OP says his old beamer
presentations number in the hundreds, the way I would approach this is
to keep the macro/function handy and convert it if and when these
presentations are required.

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.

Re: New exporter, beamer confusion

[Sebastien Vauban]

Hi Rasmus,

Rasmus wrote:
> James Harkins <jamshark70-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
>> Btw, *who* preferred \alert? (Orwell, Politics and the English Language:
>> "Never use the passive [voice] where you can use the active.")
>
> I prefer alert.  See the Beamer manual (texdoc beamer in texlive) on
> change of style and how to use alert (e.g. alert on one particular
> (sub)slide of a "multipage slide").  It's the Beamer way.  Surely it
> cannot be a bad thing?
>
>> Still, I wonder if there is a way to make the new backend less unfriendly
>> toward lists. It's an interesting philosophical question: In what cases is
>> it better for the tool to adapt to the users' wishes, versus cases where
>> the tool should encourage (Are blocks in the result actually better than
>> lists? Who says so, and why should I take his or her word for it?)
>
> Org has many dedicated list symbols namely white space and one of
> {[-+*], [0-9][.)]}.  Why should a headline be converted to a list?  It
> was always awkward to me.

As a reminder, the conversion of headlines to lists is what "daily" happens
within common Org files converted to LaTeX documents: just play with the H
option, and you'll see your deeper levels converted to LaTeX lists.

So, this ain't specific to Beamer.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: New exporter, beamer confusion

[Nicolas Goaziou]

James Harkins <jamshark70@gmail.com> writes:

> Btw, *who* preferred \alert? (Orwell, Politics and the English Language:
> "Never use the passive [voice] where you can use the active.")

Obviously, me, as the author of the back-end. Org offers only one slot
for "strong emphasis". I had to choose between bold and alert, and so
I did.

> Although I'm not happy about manual intervention to convert my prior work,
> this is a good step toward consistency. It was odd, in the old framework,
> to use headlines for bullet lists and org's numbered lists for numbered
> lists. "An org list becomes an output list" is an easier rule to
> explain.

As explained in this thread, the H:num options item defines a limit
between regular headlines and "low-level" headlines. Low level headlines
are usually turned into lists during export. But, in the Beamer
exporter, it is a better idea to turn them into blocks. Better as in
"closer, by its properties, to an headline".

> Still, I wonder if there is a way to make the new backend less unfriendly
> toward lists. It's an interesting philosophical question: In what cases is
> it better for the tool to adapt to the users' wishes, versus cases where
> the tool should encourage (Are blocks in the result actually better than
> lists? Who says so, and why should I take his or her word for it?)

Nobody is saying that blocks are better than lists in the output. It's
a matter of taste, isn't it? There are also ways to adapt the tool to
your wishes (through hooks, filters, script, macros).
> "Reasonably" for me would mean tweaking some configuration options and
> perhaps changing a few minor details of the markup. If you have to change
> the org document's structure (e.g., converting headlines to lists), it
> isn't backward compatible.

Then, by this definition, it isn't, indeed.

> For comparison: Lilypond updates frequently break some details of backward
> compatibility. So, they ship a "convert-ly" script to handle many of those
> changes automatically.

Even though the required change in our case are rather minimal, they
mostly depend on the user configuration. Hence, I will not attempt to
provide such a script.

But I will provide instructions on how to make the transition, if they
are needed.


Regards,

-- 
Nicolas Goaziou

Re: New exporter, beamer confusion

[James Harkins]

[-- Attachment #1: Type: text/plain, Size: 2046 bytes --]

On Feb 7, 2013 3:57 AM, "Nicolas Goaziou" <n.goaziou@gmail.com> wrote:
> > Btw, *who* preferred \alert? (Orwell, Politics and the English Language:
> > "Never use the passive [voice] where you can use the active.")
>
> Obviously, me, as the author of the back-end. Org offers only one slot
> for "strong emphasis". I had to choose between bold and alert, and so
> I did.

Ok, and as long as I can configure it, no problem.

Aside Re: Orwell, and now veering well off-topic, his point about passive
voice is that it hides human agency and, in the worst cases, suggests that
something simply "is objectively so" rather than "one or more people made
it so, for reasons that may be subjective," or deflects responsibility à la
"mistakes were made." Although the relationship to the present topic is
only tangential, Orwell's caution is at least as relevant today as it was
when he wrote it in 1946. I find for myself that following his advice [6 or
7 rules of thumb at the end of his essay] sounds a little alarm bell when
my thinking is getting sloppy -- so I think it bears repeating. (Apologies
to the scientific authors here, who "are trained" [oops!] to erase
themselves from reports on their experimental procedures by using passive
voice consistently...)

In fact, it wasn't obvious to me whether it was simply your preference, or
if an expert or authority on slideshow style recommends \alert over
\textbf. In the latter case, I would want to know who and why, so I could
read and then make up my own mind.

> > "Reasonably" for me would mean tweaking some configuration options and
> > perhaps changing a few minor details of the markup. If you have to
change
> > the org document's structure (e.g., converting headlines to lists), it
> > isn't backward compatible.
>
> Then, by this definition, it isn't, indeed.

Sure, and that's ok. My frustration stemmed from expecting more
compatibility than there actually is. After adjusting my expectations, I
can figure out how to make it work for me.

hjh

[-- Attachment #2: Type: text/html, Size: 2389 bytes --]

Re: New exporter, beamer confusion

[Eric S Fraga]

Nick Dokos <nicholas.dokos@hp.com> writes:

[...]

> Customizing org-e-beamer-environments-extra should do the trick.  I was

Nick,

thanks for this.  This hint led me to org-e-beamer-select-environment
which, after binding to a key, has allowed me to play sufficiently
enough with the new exporter and beamer that I am now less worried about
the upcoming change in default behaviour!

eric
-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org 7.9.3e-898-gcb1386

How to make the new exporter open PDF using evince?

[James Harkins]

A quick web search didn't turn up anything handy, so I thought I'd ask here.

Is it possible to configure the new exporter to open a PDF (generated
by LaTeX) using evince instead of okular?

That is, if I open a file browser (this is Ubuntu 12.04) and
double-click on a PDF, evince opens it. If I write a beamer
presentation in org and do C-c C-e l O, okular opens it.

I did a couple of customize-apropos searches but didn't see anything obvious.

(I'm aware that some swear by okular, but I think evince handles
paging slightly better when zooming to "best fit" for presentations.
So I'd rather use that.)

hjh


-- 
James Harkins /// dewdrop world
jamshark70@dewdrop-world.net
http://www.dewdrop-world.net

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman

blog: http://www.dewdrop-world.net/words
audio clips: http://www.dewdrop-world.net/audio
more audio: http://soundcloud.com/dewdrop_world/tracks

Re: How to make the new exporter open PDF using evince?

[Mike Gauland]

James Harkins <jamshark70 <at> gmail.com> writes:

> 
> A quick web search didn't turn up anything handy, so I thought I'd ask here.
> 
> Is it possible to configure the new exporter to open a PDF (generated
> by LaTeX) using evince instead of okular?

I think you can do that my changing the order of the entries in /etc/mailcap,
but it's been a while since I've mucked with that.

Re: How to make the new exporter open PDF using evince?

[Nick Dokos]

James Harkins <jamshark70@gmail.com> wrote:

> A quick web search didn't turn up anything handy, so I thought I'd ask here.
> 
> Is it possible to configure the new exporter to open a PDF (generated
> by LaTeX) using evince instead of okular?
> 
> That is, if I open a file browser (this is Ubuntu 12.04) and
> double-click on a PDF, evince opens it. If I write a beamer
> presentation in org and do C-c C-e l O, okular opens it.
> 
> I did a couple of customize-apropos searches but didn't see anything obvious.
> 
> (I'm aware that some swear by okular, but I think evince handles
> paging slightly better when zooming to "best fit" for presentations.
> So I'd rather use that.)
> 

There are too many cooks in this particular kitchen, but checking a
couple of places should be enough in most cases: org-file-apps is the
most immediate place but unless you've customized it, it should say

       ...
       ("\\.pdf\\'" . default)
       ...

which takes us to the next cook: mailcap. ~/.mailcap overrides the
system /etc/mailcap and there may be more (`man 5 mailcap' should reveal
the rest), so check them in order. I prefer xpdf so my mailcap says:

,----
| $ grep pdf ~/.mailcap
| application/pdf; xpdf -q %s
`----

I like putting things in ~/.mailcap, but you can season to taste.

HTH,
Nick

Re: How to make the new exporter open PDF using evince?

[James Harkins]

[-- Attachment #1: Type: text/plain, Size: 211 bytes --]

On Feb 25, 2013 2:52 PM, "Nick Dokos" <nicholas.dokos@hp.com> wrote:
> I like putting things in ~/.mailcap, but you can season to taste.

Ok, that's 2 votes so far for mailcap. I'll try that later. Thanks!

hjh

[-- Attachment #2: Type: text/html, Size: 304 bytes --]

Re: How to make the new exporter open PDF using evince?

[Martin Marier]

Hi James,

Here is a third vote for mailcap.  I have (only) this in my .mailcap
file:

application/pdf; okular '%s';  test=test -n "$DISPLAY"

It does the job.

Cheers,
Martin

PS Cool to see a (notorious) sc user on this list as well.


2013-13-25 08:06   James Harkins <jamshark70@gmail.com>:
> On Feb 25, 2013 2:52 PM, "Nick Dokos" <nicholas.dokos@hp.com> wrote:
>> I like putting things in ~/.mailcap, but you can season to taste.
>
> Ok, that's 2 votes so far for mailcap. I'll try that later. Thanks!
>
> hjh

-- 
Martin Marier
http://www.martinmarier.com

Re: How to make the new exporter open PDF using evince?

[James Harkins]

On Tue, Feb 26, 2013 at 10:40 AM, Martin Marier <mariermartin@gmail.com> wrote:
> Hi James,
>
> Here is a third vote for mailcap.  I have (only) this in my .mailcap
> file:
>
> application/pdf; okular '%s';  test=test -n "$DISPLAY"

Just tried it. Mailcap for the win!

> PS Cool to see a (notorious) sc user on this list as well.

Ha! Well, let's not talk about my TODOs underneath "* SC stuff" that
are still in TODO state...

hjh

LaTeX beamer export: relative file links?

[James Harkins]

[-- Attachment #1: Type: text/plain, Size: 933 bytes --]

I'm writing presentations for my classes using beamer export from org-mode
(which is working beautifully, btw -- it's faster than LibreOffice impress
and I get a convenient plain text archive of my slide contents to boot).

I'm authoring in Linux but I have to show the pdfs in windows. That's
generally no problem, except... this week I wanted a link on one slide to
an mp3 audio example. I entered the link in org-mode as a relative path
./blah.mp3, which either org or latex expanded to a UNIX-style full path.
(I'm guessing org.) Obviously windows would not understand the UNIX path.

The question, then: Is it possible to use relative paths for file links in
latex export? (I admit, I haven't searched for customize variables before
writing this- apologies if it's obvious. I spent most of my research time
this week setting up a mingw build environment for SuperCollider, so I'm a
bit search-fatigued I'm afraid.)

Thanks,
hjh

[-- Attachment #2: Type: text/html, Size: 1009 bytes --]

<M-S-left/right> changed?

[James Harkins]

It seems the behavior of <M-S-left> and <M-S-right> has changed.
Previously, if I selected multiple subtrees and hit M-S-right, all the
subtrees in the region would be demoted (or promoted, if I hit left
instead). Now, the behavior is identical to <M-left/right>: only the
subtree at the point is moved.

Example:

* One
* Two
* Three
* Four

If I position the point at the beginning of the "Two" line, and then
hit C-space down down, the region encompasses both headings. I
expected <M-S-right> to change both into second level entries.
Instead, it demotes "Four" (which is not even in the region).

Intentional decision, or regression? I would argue the latter. The old
behavior was quite useful and I don't know how to get it back.

My current version is:

Org-mode version 7.9.2 (release_7.9.2-882-gf47a71.dirty @
/home/dlm/share/org-mode.git/lisp/)

The only local commit that makes it "dirty" is a change to a
docstring. No code changes. I haven't moved up to 7.9.3 because I just
read a bug report on the list about MobileOrg*, which is essential to
me, so I don't plan to move to that release until I see confirmation
that the fix actually works.

* http://article.gmane.org/gmane.emacs.orgmode/64459

Thanks.
hjh

New exporter, beamer confusion

[James Harkins]

[-- Attachment #1: Type: text/plain, Size: 2409 bytes --]

During the semester break, I want to switch over to the new exporter.
Currently I'm using export mainly for beamer presentations.

I found the org-e-latex-classes entry in an old e-mail post. With
that, M-x org-export-dispatch l P produces a .tex document that
compiles. But the output is not right.

I've typically done my presentations with sections and frames only, no
sub-(sub-)sections. So I got some improvement over my first test by
removing the subsection lines from Nicolas' example entry:

(add-to-list 'org-e-latex-classes
             '("beamer"
               "\\documentclass[presentation]{beamer}
\[DEFAULT-PACKAGES]
\[PACKAGES]
\[EXTRA]"
               ("\\section{%s}" . "\\section*{%s}")
;               ("\\subsection{%s}" . "\\subsection*{%s}")
;               ("\\subsubsection{%s}" . "\\subsubsection*{%s}")
))

Frame display is still incorrect, though. If I write:

* Section A
** Slide 1
*** Third-level
**** Fourth-level

... I expect "**" in the outline to be the frame title, and the third
and fourth level headings go into the frame's body as bullets. But in
the .tex file, there is no \begin{frame} at all. So I get an
enumeration hard-aligned to the top of the frame:

1. Slide 1
	1.1 Third-level
		1.1.1 Fourth-level

Bottom line question, then, is: How can I convert my setup for the old
exporter (pasted below) over to the new exporter, and get compatible
results without having to restructure dozens of org files?

I'm also attaching a very simple org file that I'm using for testing.

Org-mode version 7.9.2 (release_7.9.2-883-g6fb36e.dirty @
/home/dlm/share/org-mode.git/lisp/) ("Dirty" = A tiny patch I have
submitted for a mobileorg problem, which so far has been ignored.)

hjh

*** OLD EXPORTER SETUP

#+LANGUAGE:  en
#+OPTIONS:   H:10 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t
#+OPTIONS:   TeX:t LaTeX:t skip:nil d:nil todo:t pri:nil tags:not-in-toc
#+EXPORT_SELECT_TAGS: export
#+EXPORT_EXCLUDE_TAGS: noexport

#+startup: beamer
#+LaTeX_CLASS: beamer
#+LaTeX_CLASS_OPTIONS: [bigger]
#+BEAMER_FRAME_LEVEL: 2

#+TITLE:     Applied Techniques for Digital Audio \newline Making
music by programming
#+AUTHOR:    H. James Harkins
#+DATE:      7 November 2012

#+BEGIN_LaTeX
\AtBeginSection[] % Do nothing for \section*
{
\begin{frame}<beamer>
\frametitle{Outline}
\tableofcontents[currentsection]
\end{frame}
}
#+END_LaTeX

* Section
** Frame
*** Bullet in frame

[-- Attachment #2: simple-beamer.org --]
[-- Type: application/octet-stream, Size: 788 bytes --]

#+LANGUAGE:  en
#+OPTIONS:   H:10 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t
#+OPTIONS:   TeX:t LaTeX:t skip:nil d:nil todo:t pri:nil tags:not-in-toc

#+startup: beamer
#+LaTeX_CLASS: beamer
#+LaTeX_CLASS_OPTIONS: [presentation]
#+BEAMER_THEME: default
#+COLUMNS: %45ITEM %10BEAMER_env(Env) %10BEAMER_act(Act) %4BEAMER_col(Col) %8BEAMER_opt(Opt)
#+PROPERTY: BEAMER_col_ALL 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0.0 :ETC

#+TITLE:     Testing new beamer exporter
#+AUTHOR:    H. James Harkins
#+EMAIL:     jamshark70@yaddayadda.com
#+DATE:      7 November 2012

#+BEGIN_LaTeX
\AtBeginSection[] % Do nothing for \section*
{
\begin{frame}<beamer>
\frametitle{Outline}
\tableofcontents[currentsection]
\end{frame}
}
#+END_LaTeX

* Section A
** Slide 1
*** Third-level
**** Fourth-level

[-- Attachment #3: simple-beamer.tex --]
[-- Type: application/x-tex, Size: 1128 bytes --]

Re: New exporter, beamer confusion

[Suvayu Ali]

On Mon, Feb 04, 2013 at 12:00:08PM +0800, James Harkins wrote:
> #+OPTIONS:   H:10 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t

The H:10 is your problem.  Since you want 2nd level headlines to be
frames, it should be H:2.

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.

Re: New exporter, beamer confusion

[James Harkins]

Suvayu Ali <fatkasuvayu+linux <at> gmail.com> writes:

> On Mon, Feb 04, 2013 at 12:00:08PM +0800, James Harkins wrote:
> > #+OPTIONS:   H:10 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t
> 
> The H:10 is your problem.  Since you want 2nd level headlines to be
> frames, it should be H:2.

Ah. OK, that's an improvement.

Still a problem, though. The old exporter preserves the outline structure under 
the frame level, as nested bullet lists. The new exporter flattens them.

***** In:

* Section A
** Slide 1
*** Third-level
**** Fourth-level

***** Old exporter:

Slide 1
-------
- Third-level
-- Fourth-level

***** New exporter:

Slide 1
-------
Third-level
Fourth-level

Should the new exporter change the appearance of my presentations so much? I'm 
hoping there's an option for this (as redoing the markup for 20 or more sets of 
class slides is... painful to contemplate).

Thanks,
hjh

Re: New exporter, beamer confusion

[Nicolas Goaziou]

Hello,

James Harkins <jamshark70@gmail.com> writes:

> Suvayu Ali <fatkasuvayu+linux <at> gmail.com> writes:
>
>> On Mon, Feb 04, 2013 at 12:00:08PM +0800, James Harkins wrote:
>> > #+OPTIONS:   H:10 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t
>> 
>> The H:10 is your problem.  Since you want 2nd level headlines to be
>> frames, it should be H:2.
>
> Ah. OK, that's an improvement.
>
> Still a problem, though. The old exporter preserves the outline structure under 
> the frame level, as nested bullet lists. The new exporter flattens them.
>
> ***** In:
>
> * Section A
> ** Slide 1
> *** Third-level
> **** Fourth-level
>
> ***** Old exporter:
>
> Slide 1
> -------
> - Third-level
> -- Fourth-level
>
> ***** New exporter:
>
> Slide 1
> -------
> Third-level
> Fourth-level
>
> Should the new exporter change the appearance of my presentations so much? I'm 
> hoping there's an option for this (as redoing the markup for 20 or more sets of 
> class slides is... painful to contemplate).

Here's an excerpt from ox-beamer.el documentation:

;; - Headlines become frames when their level is equal to
;;   `org-beamer-frame-level' (or "H" value in the OPTIONS line).
;;   Though, if an headline in the current tree has a "BEAMER_env"
;;   (see below) property set to either "frame" or "fullframe", its
;;   level overrides the variable.  A "fullframe" is a frame with an
;;   empty (ignored) title.
;;
;; - All frames' children become block environments.  Special block
;;   types can be enforced by setting headline's "BEAMER_env" property
;;   to an appropriate value (see `org-beamer-environments-default'
;;   for supported value and `org-beamer-environments-extra' for
;;   adding more).

In particular, "All frames children become block environments". So in
your example Third-level is a block environment and Fourth-level is
a block within it. There's no flattening going on (look at the tex file
to convince yourself).


Regards,

-- 
Nicolas Goaziou

Re: New exporter, beamer confusion

[James Harkins]

[-- Attachment #1: Type: text/plain, Size: 1485 bytes --]

On Feb 5, 2013 3:51 AM, "Nicolas Goaziou" <n.goaziou@gmail.com> wrote:
> In particular, "All frames children become block environments". So in
> your example Third-level is a block environment and Fourth-level is
> a block within it. There's no flattening going on (look at the tex file
> to convince yourself).

Thanks for pointing me to the comments in the .el source file.

So here's my situation. I have a year's worth of lecture slides that render
nicely using the old exporter. In the new exporter, the clear hierarchies
of "enumerate" environments disappear, replaced by flat blocks. This new
behavior is not useful to me.

The comments in the source don't say anything about how I can modify the
default "block" behavior. As a result, if the new exporter is fundamentally
incompatible with the old and the only way is to insert properties by hand
under every headline (across all of my files, I'd guess the count is in the
high hundreds, if not >1000)... then the new beamer exporter is not useful
to me.

Is there an existing feature request for this? If not, would it help if I
logged one? (Even if I didn't have existing files -- I like bullet points
on slides, not flat text. I don't understand why I shouldn't be able to set
that as a global or per-file preference.)

I don't mean to be harsh. I'm glad for the new exporter and I'll use it for
the next article I write. For beamer, though, currently it sounds like a
lot of work to get a result that used to be easy.

hjh

[-- Attachment #2: Type: text/html, Size: 1779 bytes --]

Re: New exporter, beamer confusion

[Eric S Fraga]

[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]

Nicolas Goaziou <n.goaziou@gmail.com> writes:


[...]

> Here's an excerpt from ox-beamer.el documentation:
>
> ;; - Headlines become frames when their level is equal to
> ;;   `org-beamer-frame-level' (or "H" value in the OPTIONS line).

Nicolas,

I have decided to bite the bullet and try to get all of my beamer files
working with the new exporter.  I have started simply with the
presentation.org file that I had put on Worg for the tutorial on beamer
for the old exporter.

A truncated version of that file (very minimal and attached) fails
completely to export.  I get the following (truncated) error trace:

,----
| Debugger entered--Lisp error: (wrong-type-argument buffer-or-string-p t)
|   get-text-property(0 org-props t)
|   org-get-text-property-any(0 org-props t)
|   org-beamer-sectioning(1 t)
|   funcall(org-beamer-sectioning 1 t)
|   (if (and (symbolp (nth 2 class-sectionning)) (fboundp (nth 2 class-sectionning))) (funcall (nth 2 class-sectionning) level numberedp) (nth (1+ level) class-sectionning))
|   ...
|   org-e-latex-headline((headline (:raw-value "Introduction" :begin 359 :end 444 ...
`----

I have attached the simple test file.

Where am I going wrong?  If I change H:2 to H:1, it works although
obviously the output is not what I want.  Have I misunderstand something
rather fundamental?

Thanks,
eric

-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org 7.9.3e-898-gcb1386

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: test.org --]
[-- Type: text/org, Size: 443 bytes --]

#+TITLE:     Writing Beamer presentations in org-mode
#+AUTHOR:    Eric S Fraga
#+EMAIL:     e.fraga@ucl.ac.uk
#+DATE:      2010-03-30 Tue

#+startup: oddeven

#+LaTeX_CLASS: beamer
#+LaTeX_CLASS_OPTIONS: [bigger]
#+BEAMER_THEME: Madrid
#+OPTIONS:   H:2

# +COLUMNS: %20ITEM %13BEAMER_env(Env) %6BEAMER_envargs(Args) %4BEAMER_col(Col) %7BEAMER_extra(Extra)

* Introduction
** Overview
- org-mode template
- beamer structure
- beamer settings

Re: New exporter, beamer confusion

[Nicolas Goaziou]

Hello,

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> I have decided to bite the bullet and try to get all of my beamer files
> working with the new exporter.  I have started simply with the
> presentation.org file that I had put on Worg for the tutorial on beamer
> for the old exporter.
>
> A truncated version of that file (very minimal and attached) fails
> completely to export.  I get the following (truncated) error trace:
>
> ,----
> | Debugger entered--Lisp error: (wrong-type-argument buffer-or-string-p t)
> |   get-text-property(0 org-props t)
> |   org-get-text-property-any(0 org-props t)
> |   org-beamer-sectioning(1 t)
> |   funcall(org-beamer-sectioning 1 t)
> |   (if (and (symbolp (nth 2 class-sectionning)) (fboundp (nth 2 class-sectionning))) (funcall (nth 2 class-sectionning) level numberedp) (nth (1+ level) class-sectionning))
> |   ...
> |   org-e-latex-headline((headline (:raw-value "Introduction" :begin 359 :end 444 ...
> `----
>
> I have attached the simple test file.
>
> Where am I going wrong?  If I change H:2 to H:1, it works although
> obviously the output is not what I want.  Have I misunderstand something
> rather fundamental?

I have no problem exporting this file. Though, judging from the
backtrace, you're using the old exporter since `org-beamer-sectioning'
comes from it.


Regards,

-- 
Nicolas Goaziou

Re: New exporter, beamer confusion

[Eric S Fraga]

Nicolas Goaziou <n.goaziou@gmail.com> writes:


[...]

>> I have attached the simple test file.
>>
>> Where am I going wrong?  If I change H:2 to H:1, it works although
>> obviously the output is not what I want.  Have I misunderstand something
>> rather fundamental?
>
> I have no problem exporting this file. Though, judging from the
> backtrace, you're using the old exporter since `org-beamer-sectioning'
> comes from it.

Which is rather strange although that thought had entered my mind.  I do
not understand how I am ending up in that code when I start the exporter
off with the new dispatcher.  Other files work fine but this one
doesn't.

The funny thing is that if I use the old dispatcher, and hence the old
exporter, it works!

There has to be something in my emacs/org configuration somewhere that
is causing problems.

So I try a minimal example (emacs -Q, set up paths to git org, load in
org-e-beamer) and things get even stranger.  The same org file exports
(no error), but to a latex file that has no document class
definition.  The first (non-comment) line of the latex file is
\usetheme{Madrid}.

I am really confused.  The system is rather fragile, it would seem.

I will continue playing...  although I guess I should try to do some
work as well ;-)

-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org 7.9.3e-897-g787a07