[BUG] LATEX_CLASS_OPTIONS not working

[BUG] LATEX_CLASS_OPTIONS not working

[suvayu ali]

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

Hi,

I think there is a regression bug in latex export. The

#+LATEX_CLASS_OPTIONS: a4paper

directive is supposed to generate the following latex code:

\documentclass{a4paper,article}

Instead it generates:

\documentclassa4paper{article}

A minimal example is attached.

Thanks,

-- 
Suvayu

Open source is the future. It sets us free.

[-- Attachment #2: bug.org --]
[-- Type: text/x-tex, Size: 334 bytes --]

#+LATEX_CLASS: article
#+LATEX_CLASS_OPTIONS: a4paper
#+LATEX_HEADER: \setmainfont{Linux Libertine}

* Top heading
** Meeting
  :PROPERTIES:
  :LaTeX_CLASS: article
  :EXPORT_FILE_NAME: report.pdf
  :EXPORT_TITLE: Report
  :EXPORT_OPTIONS: H:1 num:nil toc:nil ^:{}
  :END:

*** Things
+ Some item
+ Item 2
+ Last item

* Last heading

[-- Attachment #3: bug.tex --]
[-- Type: application/x-tex, Size: 928 bytes --]

Re: [BUG] LATEX_CLASS_OPTIONS not working

[Nick Dokos]

suvayu ali <fatkasuvayu@gmail.com> wrote:

> Hi,
> 
> I think there is a regression bug in latex export. The
> 
> #+LATEX_CLASS_OPTIONS: a4paper
> 
> directive is supposed to generate the following latex code:
> 
> \documentclass{a4paper,article}
> 
> Instead it generates:
> 
> \documentclassa4paper{article}
> 
> A minimal example is attached.
> 

I don't think it's a regression - at least I could only find two commits
that touched the relevant code (lines 1397-1405 in org-latex.el) and
they are from 2008 and 2009.

Also the latex syntax is 

   \documentclass[a4paper]{article}

and an example in the beamer section of the manual

   (info "(org) Beamer class export")

makes me believe that the expectation is that you'll enter

   #+LATEX_CLASS_OPTIONS: [a4paper]

including the square brackets.

Nick

Re: [BUG] LATEX_CLASS_OPTIONS not working

[suvayu ali]

Hi Nick,

On Tue, Mar 6, 2012 at 03:42, Nick Dokos <nicholas.dokos@hp.com> wrote:
> I don't think it's a regression - at least I could only find two commits
> that touched the relevant code (lines 1397-1405 in org-latex.el) and
> they are from 2008 and 2009.
>
> Also the latex syntax is
>
>   \documentclass[a4paper]{article}

Now I am embarrassed. :-| You are correct, I misread the latex
documentation and I didn't check the org manual before reporting.
That's what I get for sending emails after 3:00 AM. :-/

Extremely sorry about the mix up.

-- 
Suvayu

Open source is the future. It sets us free.

Re: [BUG] LATEX_CLASS_OPTIONS not working

[Nick Dokos]

suvayu ali <fatkasuvayu+linux@gmail.com> wrote:

> Hi Nick,
> 
> On Tue, Mar 6, 2012 at 03:42, Nick Dokos <nicholas.dokos@hp.com> wrote:
> > I don't think it's a regression - at least I could only find two commits
> > that touched the relevant code (lines 1397-1405 in org-latex.el) and
> > they are from 2008 and 2009.
> >
> > Also the latex syntax is
> >
> >  \documentclass[a4paper]{article}
> 
> Now I am embarrassed. :-| You are correct, I misread the latex
> documentation and I didn't check the org manual before reporting.
> That's what I get for sending emails after 3:00 AM. :-/
> 

Actually, I think the manual is deficient in this case: you have to
infer the proper format from an example in the beamer section (which is
not even the section where LaTeX_CLASS_OPTIONS is defined): that's
better than no example at all, but I think it would be better to add an
example in section 12.6.2, "Header and sectioning structure". I would
encourage you to submit a doc patch.

> Extremely sorry about the mix up.
> 

Nothing to be sorry or embarrassed about. We are all mistakes and we make
humans :-)

Nick

Re: [BUG] LATEX_CLASS_OPTIONS not working

[suvayu ali]

Hi Nick,

On Wed, Mar 7, 2012 at 23:20, Nick Dokos <nicholas.dokos@hp.com> wrote:
> but I think it would be better to add an
> example in section 12.6.2, "Header and sectioning structure". I would
> encourage you to submit a doc patch.
>

Comments are of course welcome. :)

<http://patchwork.newartisans.com/patch/1201/>

>> Extremely sorry about the mix up.
>>
>
> Nothing to be sorry or embarrassed about. We are all mistakes and we make
> humans :-)

:)

-- 
Suvayu

Open source is the future. It sets us free.

Problem with choosing mode while editing blocks with C-c '

[suvayu ali]

Hi,

I am having problems editing blocks with C-c '. If the blocks are marked
with upper case letters Emacs brings up the temporary buffer in
picture-mode.

   #+BEGIN_SRC latex

   #+END_SRC

However the buffer mode is chosen correctly if lower case letters are
used.

   #+begin_src latex

   #+end_src

Any ideas what could be wrong?

-- 
Suvayu

Open source is the future. It sets us free.

Re: Problem with choosing mode while editing blocks with C-c '

[Nick Dokos]

suvayu ali <fatkasuvayu+linux@gmail.com> wrote:

> Hi,
> 
> I am having problems editing blocks with C-c '. If the blocks are marked
> with upper case letters Emacs brings up the temporary buffer in
> picture-mode.
> 
>    #+BEGIN_SRC latex
> 
>    #+END_SRC
> 
> However the buffer mode is chosen correctly if lower case letters are
> used.
> 
>    #+begin_src latex
> 
>    #+end_src
> 
> Any ideas what could be wrong?
> 

I can't reproduce it: both of them come up as latex-mode. Did you try
with a new emacs instance?  Perhaps your current one is curdled somehow.

Nick

Re: Problem with choosing mode while editing blocks with C-c '

[Thorsten]

suvayu ali <fatkasuvayu+linux@gmail.com> writes:

Hi,

> I am having problems editing blocks with C-c '. If the blocks are marked
> with upper case letters Emacs brings up the temporary buffer in
> picture-mode.
>
>    #+BEGIN_SRC latex
>
>    #+END_SRC
>
> However the buffer mode is chosen correctly if lower case letters are
> used.
>
>    #+begin_src latex
>
>    #+end_src
>
> Any ideas what could be wrong?

There was a discussion of this topic recently, I had and still have my quote source
blocks in artists (picture) mode and thought this was strange behaviour.
Some stated that this is a feature, while Eric (Schulte) confirmed the
behaviour and agreed that it appears more like a bug than a feature.

I'm not sure how to link to email threads, I hope the following link
works for you:

[[gnus:nntp%2Bnews.gmane.org:gmane.emacs.orgmode#87d3964cpp.fsf@googlemail.com][Email
from Thorsten: {babel} Editing 'quote' source]]

My system:
"GNU Emacs 24.0.93.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.10)
 of 2012-02-07 on arch
Org-mode version 7.8.03
Ma Gnus v0.2"

-- 
cheers,
Thorsten

Re: Problem with choosing mode while editing blocks with C-c '

[Nick Dokos]

Thorsten <quintfall@googlemail.com> wrote:

> suvayu ali <fatkasuvayu+linux@gmail.com> writes:
> 
> Hi,
> 
> > I am having problems editing blocks with C-c '. If the blocks are marked
> > with upper case letters Emacs brings up the temporary buffer in
> > picture-mode.
> >
> >    #+BEGIN_SRC latex
> >
> >    #+END_SRC
> >
> > However the buffer mode is chosen correctly if lower case letters are
> > used.
> >
> >    #+begin_src latex
> >
> >    #+end_src
> >
> > Any ideas what could be wrong?
> 
> There was a discussion of this topic recently, I had and still have my quote source
> blocks in artists (picture) mode and thought this was strange behaviour.
> Some stated that this is a feature, while Eric (Schulte) confirmed the
> behaviour and agreed that it appears more like a bug than a feature.
> 
> I'm not sure how to link to email threads, I hope the following link
> works for you:
> 
> [[gnus:nntp%2Bnews.gmane.org:gmane.emacs.orgmode#87d3964cpp.fsf@googlemail.com][Email
> from Thorsten: {babel} Editing 'quote' source]]
> 
> My system:
> "GNU Emacs 24.0.93.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.10)
>  of 2012-02-07 on arch
> Org-mode version 7.8.03
> Ma Gnus v0.2"
> 

Wandering aroung org-src.el, I stumbled on the following variable which you
(Thorsten) may find useful in your case:

,----
| org-edit-fixed-width-region-mode is a variable defined in `org-src.el'.
| Its value is artist-mode
| 
| Documentation:
| The mode that should be used to edit fixed-width regions.
| These are the regions where each line starts with a colon.
| 
| You can customize this variable.
`----

Nick

Re: Problem with choosing mode while editing blocks with C-c '

[Nick Dokos]

Thorsten <quintfall@googlemail.com> wrote:

> suvayu ali <fatkasuvayu+linux@gmail.com> writes:
> 
> Hi,
> 
> > I am having problems editing blocks with C-c '. If the blocks are marked
> > with upper case letters Emacs brings up the temporary buffer in
> > picture-mode.
> >
> >    #+BEGIN_SRC latex
> >
> >    #+END_SRC
> >
> > However the buffer mode is chosen correctly if lower case letters are
> > used.
> >
> >    #+begin_src latex
> >
> >    #+end_src
> >
> > Any ideas what could be wrong?
> 
> There was a discussion of this topic recently, I had and still have my quote source
> blocks in artists (picture) mode and thought this was strange behaviour.

BTW, artist-mode is *not* the same as picture-mode.

For the OP (Suvayu): can you do C-h v org-edit-fixed-width-region-mode
RET and post the result? If the value is picture-mode, then I can
vaguely glimpse a (rather far-fetched) possible scenario that might get
you into the problem you describe, but I'd rather try to rule it out
first.

Nick

Re: Problem with choosing mode while editing blocks with C-c '

[suvayu ali]

Hi Nick,

Apologies on not responding sooner. I was preparing my slides for a
presentation tomorrow.

On Wed, Mar 14, 2012 at 01:34, Nick Dokos <nicholas.dokos@hp.com> wrote:
> Thorsten <quintfall@googlemail.com> wrote:
>
>> suvayu ali <fatkasuvayu+linux@gmail.com> writes:
>>
>> Hi,
>>
>> > I am having problems editing blocks with C-c '. If the blocks are marked
>> > with upper case letters Emacs brings up the temporary buffer in
>> > picture-mode.
>> >
>> >    #+BEGIN_SRC latex
>> >
>> >    #+END_SRC
>> >
>> > However the buffer mode is chosen correctly if lower case letters are
>> > used.
>> >
>> >    #+begin_src latex
>> >
>> >    #+end_src
>> >
>> > Any ideas what could be wrong?
>>
>> There was a discussion of this topic recently, I had and still have my quote source
>> blocks in artists (picture) mode and thought this was strange behaviour.
>
> BTW, artist-mode is *not* the same as picture-mode.
>

Actually I keep confusing between the two and I'm not sure which I was
seeing. I also forgot to mention I did not see the problem with a
minimal setup. I got frustrated (I had to get the talk done), so I
restarted Emacs and worked with LaTeX directly. Now in my new session I
cannot replicate my issue. However it still breaks in a different way.
Hitting C-c ' prompts me for a filename or a url.

> For the OP (Suvayu): can you do C-h v org-edit-fixed-width-region-mode
> RET and post the result? If the value is picture-mode, then I can
> vaguely glimpse a (rather far-fetched) possible scenario that might get
> you into the problem you describe, but I'd rather try to rule it out
> first.
>

This variable is set to artist-mode.

I did a binary search through my setup and found the problem occurs when
case-fold-search is set to nil.

You can replicate this with the following contents in an org file and
(setq case-fold-search nil).

----8<-------------------8<----

* Heading
#+BEGIN_SRC latex
%% this is a LaTeX comment
#+END_SRC

#+begin_src latex
%% this is a LaTeX comment
#+end_src

----8<-------------------8<----

C-c ' on the first block shold prompt you for a file or url and the
second block should present a temporary buffer in latex mode.

I have actually seen both these problem (the artist-mode and prompt for
file or url) for quite a while from time to time. But I could never
replicate them consistently. I guess today is my (somewhat) lucky
day. :)


> Nick
>
>

Hope this helps paint a clearer picture.

--
Suvayu

Open source is the future. It sets us free.

Re: Problem with choosing mode while editing blocks with C-c '

[Nick Dokos]

suvayu ali <fatkasuvayu@gmail.com> wrote:

> Actually I keep confusing between the two and I'm not sure which I was
> seeing. I also forgot to mention I did not see the problem with a
> minimal setup. I got frustrated (I had to get the talk done), so I
> restarted Emacs and worked with LaTeX directly. Now in my new session I
> cannot replicate my issue. However it still breaks in a different way.
> Hitting C-c ' prompts me for a filename or a url.
> 
> > For the OP (Suvayu): can you do C-h v org-edit-fixed-width-region-mode
> > RET and post the result? If the value is picture-mode, then I can
> > vaguely glimpse a (rather far-fetched) possible scenario that might get
> > you into the problem you describe, but I'd rather try to rule it out
> > first.
> >
> 
> This variable is set to artist-mode.
> 
> I did a binary search through my setup and found the problem occurs when
> case-fold-search is set to nil.
> 
> You can replicate this with the following contents in an org file and
> (setq case-fold-search nil).
> 
> ----8<-------------------8<----
> 
> * Heading
> #+BEGIN_SRC latex
> %% this is a LaTeX comment
> #+END_SRC
> #+begin_src latex
> %% this is a LaTeX comment
> #+end_src
> 
> ----8<-------------------8<----
> 
> C-c ' on the first block shold prompt you for a file or url and the
> second block should present a temporary buffer in latex mode.
> 
> I have actually seen both these problem (the artist-mode and prompt for
> file or url) for quite a while from time to time. But I could never
> replicate them consistently. I guess today is my (somewhat) lucky
> day. :)
> 

The case-fold-search problem is in
org-src.el:org-edit-src-code. case-fold-search is let-bound to t, but
the let form evaluates all the VARLIST forms before evaluating the body,
so the very next varlist

	(case-fold-search t)
	(info (org-edit-src-find-region-and-lang))
	...

fails because in its evaluation, case-fold-search is still nil.

The solution is to use a let* form instead: just change the let on line
216 to a let*.

I think this will cure the other problem too: org-edit-special checks
for various things and if any of them succeed it skips the rest. The
behavior you get is the "everything else failed, let's call ffap".
But now since the org-edit-src-code call will (famous last words)
succeed, then it won't fall through.

Nick

Re: Problem with choosing mode while editing blocks with C-c '

[Nick Dokos]

suvayu ali <fatkasuvayu@gmail.com> wrote:


> >> There was a discussion of this topic recently, I had and still have my q=
> uote source
> >> blocks in artists (picture) mode and thought this was strange behaviour.
> >
> > BTW, artist-mode is *not* the same as picture-mode.
> >
> 
> Actually I keep confusing between the two and I'm not sure which I was
> seeing.

Well, they *are* different, but it turns out that if
artist-picture-compatibility is true (which it is by default), then
artist-mode turns on picture-mode, so they are difficult to tell apart
just looking at the modeline.

Nick

Re: Problem with choosing mode while editing blocks with C-c '

[Thorsten]

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

> Thorsten <quintfall@googlemail.com> wrote:
>
>> suvayu ali <fatkasuvayu+linux@gmail.com> writes:
>> 
>> Hi,
>> 
>> > I am having problems editing blocks with C-c '. If the blocks are
>> > marked
>> > with upper case letters Emacs brings up the temporary buffer in
>> > picture-mode.
>> >
>> >    #+BEGIN_SRC latex
>> >
>> >    #+END_SRC
>> >
>> > However the buffer mode is chosen correctly if lower case letters are
>> > used.
>> >
>> >    #+begin_src latex
>> >
>> >    #+end_src
>> >
>> > Any ideas what could be wrong?
>> 
>> There was a discussion of this topic recently, I had and still have
>> my quote source
>> blocks in artists (picture) mode and thought this was strange behaviour.
>> Some stated that this is a feature, while Eric (Schulte) confirmed the
>> behaviour and agreed that it appears more like a bug than a feature.
>> 
>> I'm not sure how to link to email threads, I hope the following link
>> works for you:
>> 
>> [[gnus:nntp%2Bnews.gmane.org:gmane.emacs.orgmode#87d3964cpp.fsf@googlemail.com][Email
>> from Thorsten: {babel} Editing 'quote' source]]
>> 
>> My system:
>> "GNU Emacs 24.0.93.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.10)
>>  of 2012-02-07 on arch
>> Org-mode version 7.8.03
>> Ma Gnus v0.2"
>> 
>
> Wandering aroung org-src.el, I stumbled on the following variable which you
> (Thorsten) may find useful in your case:
>
> ,----
> | org-edit-fixed-width-region-mode is a variable defined in `org-src.el'.
> | Its value is artist-mode
> | 
> | Documentation:
> | The mode that should be used to edit fixed-width regions.
> | These are the regions where each line starts with a colon.
> | 
> | You can customize this variable.
> `----

Thanks, I chose fundamental mode instead of artist mode, since it seems
more natural for quotes. I don't know which other types of fixed-width
regions there are, but for me quotes seem to be the most frequently used
regions of this type. If thats generally the case, wouldn't fundamental
mode be a smarter choice as a default mode in this case (principle
of least surprise)?

-- 
cheers,
Thorsten

Re: Problem with choosing mode while editing blocks with C-c '

[suvayu ali]

Hey Nick,

On Wed, Mar 14, 2012 at 04:11, Nick Dokos <nicholas.dokos@hp.com> wrote:
> suvayu ali <fatkasuvayu@gmail.com> wrote:
>
>
>> >> There was a discussion of this topic recently, I had and still have my q=
>> uote source
>> >> blocks in artists (picture) mode and thought this was strange behaviour.
>> >
>> > BTW, artist-mode is *not* the same as picture-mode.
>> >
>>
>> Actually I keep confusing between the two and I'm not sure which I was
>> seeing.
>
> Well, they *are* different, but it turns out that if
> artist-picture-compatibility is true (which it is by default), then
> artist-mode turns on picture-mode, so they are difficult to tell apart
> just looking at the modeline.
>

Yup, your analysis was spot on. :) Changing the let to let* and
reevaluating the defun fixed the issue.

I hadn't grasped this subtlety about let*, dependencies on preceding
bindings hidden behind function calls!

> Nick

Thanks a lot. :)

-- 
Suvayu

Open source is the future. It sets us free.

Re: Problem with choosing mode while editing blocks with C-c '

[Suvayu Ali]

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

Sorry the quoting was all wrong! Gmail was behaving weirdly. I wanted to
quote the other message.

On Wed, Mar 14, 2012 at 03:59, Nick Dokos <nicholas.dokos@hp.com> wrote:
> The case-fold-search problem is in
> org-src.el:org-edit-src-code. case-fold-search is let-bound to t, but
> the let form evaluates all the VARLIST forms before evaluating the
> body, so the very next varlist

>        (case-fold-search t)
>        (info (org-edit-src-find-region-and-lang))
>        ...

> fails because in its evaluation, case-fold-search is still nil.

> The solution is to use a let* form instead: just change the let on
> line 216 to a let*.


On Wed, Mar 14, 2012 at 09:41, suvayu ali <fatkasuvayu@gmail.com> wrote:
> Yup, your analysis was spot on. :) Changing the let to let* and
> reevaluating the defun fixed the issue.
>
> I hadn't grasped this subtlety about let*, dependencies on preceding
> bindings hidden behind function calls!

I am attaching the changes as a patch. Let me know if it is okay.

Thanks,

-- 
Suvayu

Open source is the future. It sets us free.

[-- Attachment #2: 0001-Change-let-bind-to-a-let-in-org-edit-src-code.patch --]
[-- Type: text/x-patch, Size: 2038 bytes --]

From 48eb85df419c38a57d35808ca3a3bc9d86e05c33 Mon Sep 17 00:00:00 2001
From: Suvayu Ali <fatkasuvayu+linux@gmail.com>
Date: Wed, 14 Mar 2012 09:49:40 +0100
Subject: [PATCH] Change let bind to a let* in org-edit-src-code

	* org-src.el (org-edit-src-code): Change let bind to let*,
          e.g. if case-fold-search is bound to nil globally, the
          (case-fold-search t) doesn't work until we get to the body.

	  The fix and analysis was provided by Nick Dokos on this
          email message thread:
          <http://thread.gmane.org/gmane.emacs.orgmode/53335/focus=53342>

	  TINY CHANGE
---
 lisp/org-src.el |   20 ++++++++++----------
 1 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/lisp/org-src.el b/lisp/org-src.el
index 9cd56d2..dfaa72d 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -213,16 +213,16 @@ (defun org-edit-src-code (&optional context code edit-buffer-name)
   (interactive)
   (unless (eq context 'save)
     (setq org-edit-src-saved-temp-window-config (current-window-configuration)))
-  (let ((mark (and (org-region-active-p) (mark)))
-	(case-fold-search t)
-	(info (org-edit-src-find-region-and-lang))
-	(full-info (org-babel-get-src-block-info 'light))
-	(org-mode-p (derived-mode-p 'org-mode)) ;; derived-mode-p is reflexive
-	(beg (make-marker))
-	(end (make-marker))
-	(allow-write-back-p (null code))
-	block-nindent total-nindent ovl lang lang-f single lfmt buffer msg
-	begline markline markcol line col transmitted-variables)
+  (let* ((mark (and (org-region-active-p) (mark)))
+	 (case-fold-search t)
+	 (info (org-edit-src-find-region-and-lang))
+	 (full-info (org-babel-get-src-block-info 'light))
+	 (org-mode-p (derived-mode-p 'org-mode)) ;; derived-mode-p is reflexive
+	 (beg (make-marker))
+	 (end (make-marker))
+	 (allow-write-back-p (null code))
+	 block-nindent total-nindent ovl lang lang-f single lfmt buffer msg
+	 begline markline markcol line col transmitted-variables)
     (if (not info)
 	nil
       (setq beg (move-marker beg (nth 0 info))
-- 
1.7.7.6

Re: Problem with choosing mode while editing blocks with C-c '

[Nick Dokos]

Suvayu Ali <fatkasuvayu+linux@gmail.com> wrote:

> On Wed, Mar 14, 2012 at 09:41, suvayu ali <fatkasuvayu@gmail.com> wrote:
> > Yup, your analysis was spot on. :) Changing the let to let* and
> > reevaluating the defun fixed the issue.
> >
> > I hadn't grasped this subtlety about let*, dependencies on preceding
> > bindings hidden behind function calls!
> 
> I am attaching the changes as a patch. Let me know if it is okay.
> 

Perfect. Thanks!

Nick

Re: Problem with choosing mode while editing blocks with C-c '

[Bastien]

Hi Suvayu,

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

> On Wed, Mar 14, 2012 at 09:41, suvayu ali <fatkasuvayu@gmail.com> wrote:
>> Yup, your analysis was spot on. :) Changing the let to let* and
>> reevaluating the defun fixed the issue.
>>
>> I hadn't grasped this subtlety about let*, dependencies on preceding
>> bindings hidden behind function calls!
>
> I am attaching the changes as a patch. Let me know if it is okay.

Applied, thanks to you and Nick!

-- 
 Bastien