Re: [O] bug(?) ox-html always add a timestamp in comment which can't be customized away

2013-06-08 Thread Nick Dokos
Haojun Bao baohao...@gmail.com writes:

 Just checked, it is the same tag (release_8.0.3), there is no change like in 
 your code.

 Could you please run git blame on those lines?

You need to upgrade to latest. Git blame says:

,
| $ git blame -L 1509,1511 lisp/ox-html.el
| d574bf52 (Kodi Arfer 2013-05-30 15:19:57 -0400 1509)  (when (plist-get 
info :time-stamp-file)
| d574bf52 (Kodi Arfer 2013-05-30 15:19:57 -0400 1510)
(format-time-string
| d574bf52 (Kodi Arfer 2013-05-30 15:19:57 -0400 1511)   (concat !--  
org-html-metadata-timestamp-format  --\n)))
`

and the commit shows the change from the code you see to the code I see:

,
| nick@pierrot:~/src/emacs/org/org-mode$ git show d574bf52
| commit d574bf522d1b2ac74cb4245f8742253bde7861df
| Author: Kodi Arfer g...@arfer.net
| Date:   Thu May 30 15:19:57 2013 -0400
| 
| ox-html: Fix handling of time-stamp-file
| 
| * lisp/ox-html.el (org-html--build-meta-info): Insert no timestamp
|   when :time-stamp-file is nil.
| 
| TINYCHANGE
| 
| diff --git a/lisp/ox-html.el b/lisp/ox-html.el
| index 297cb55..949c3ba 100644
| --- a/lisp/ox-html.el
| +++ b/lisp/ox-html.el
| @@ -1506,10 +1506,9 @@ INFO is a plist used as a communication channel.
|iso-8859-1)))
|  (concat
|   (format title%s/title\n title)
| - (format
| -  (when :time-stamp-file
| - (format-time-string
| -  (concat !--  org-html-metadata-timestamp-format  --\n
| + (when (plist-get info :time-stamp-file)
| +   (format-time-string
| +  (concat !--  org-html-metadata-timestamp-format  --\n)))
|   (format
|(if (org-html-html5-p info)
| (org-html-close-tag meta  charset=\%s\ info)
`

Nick


 On Sat, Jun 8, 2013 at 1:30 PM, Nick Dokos ndo...@gmail.com wrote:

 Haojun Bao baohao...@gmail.com writes:

  The culprit code is the following:
 
    (when :time-stamp-file
      (format-time-string
       (concat !--  org-html-metadata-timestamp-format  --\n)))
 
  This `when' condition is always true, because :time-stamp-file is a
  keyword and always eval to itself, never to nil.
 
  So I think org-export-time-stamp-file should be used instead of
  :time-stamp-file.
 

 What version are you using? In the version I have, the code looks like
 this:

      (when (plist-get info :time-stamp-file)
        (format-time-string
          (concat !--  org-html-metadata-timestamp-format  --\n)))

 Org-mode version 8.0.3 (release_8.0.3-197-g221768)
 [nb: this version includes a few local commits (irrelevant to this 
 subject)]
 --
 Nick


-- 
Nick




Re: [O] :session question -- and changes to #+Property: syntax

2013-06-08 Thread Achim Gratz
Eric Schulte writes:
 As I recall I was fully in favor of applying these changes, however I am
 not qualified to address the changes to property behaviors.  Hopefully
 someone who works more on that side of things can address those aspects.

Oh wait, now I understand what you're getting at, let me explain.  The
first patch that makes Org use the same regex in all places where a
property is used does indeed change some behaviour, but not the syntax
of the property line:

:PROPERTY: VALUE

where PROPERTY can contain any non-whitespace character (in
correspondence to how the keyword PROPERTY is treated in org.el since it
is not explicitly specified in org-element).

However, there were other places in Org where a more restricted syntax
for properties in property drawers was used, which would have precluded
the use of : in property names and made it impossible to overwrite an
inherited property from a #+PROPERTY: line that has such a property
name.

I've taken org-element as the authoritative source for the syntax and
eliminated the other interpretations based on the fact that while the
behaviour visible in the buffer (highlighting, prompts, etc.) would hint
differently, the actual property handling was using the syntax used in
org-element already.  Hence if documents existed that had mistakenly
made use of these differences, they were already broken and would be
interpreted via the property API as they are now also shown after this
change.


Regards,
Achim.
-- 
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds




Re: [O] Wrong comment character when adding file local variables?

2013-06-08 Thread Nick Dokos
Rainer M Krug r.m.k...@gmail.com writes:

 On Friday, June 7, 2013, Vitalie Spinu wrote:

 All your examples are placed in fundamental mode. The comments are
 treated by org and thus are correct, local variables are inserted
 according to the major mode.

 The question is why - all .R files are automatically in r mode when I
 open them and all other R files tangle fine. 

That's because the auto-mode-alist tells emacs that .R files should be
in R-mode, so after emacs opens the file, it calls the R-mode function.

 I don't how this could be easily fixed on org side, but you can
 solve it straightforwardly with:

 (add-to-list 'auto-mode-alist (cons NAME\\|DESC 'R-mode))

 Ok - I'check it out on Monday.


That's one way: it's got its downside in that the names have to match,
so you have to remember to modify the auto-mode-alist when you use
different names when tangling.

Another way is to modify the function below:

  I use the following in my .emacs file to set the
  post-tangle-hook to add the local file variables:

  ,
  |  (defvar org-babel-tangled-file nil
  |If non-nill, current file was tangled with org-babel-tangle)
  |  (put 'org-babel-tangled-file 'safe-local-variable 'booleanp)
  |
  |  (defun org-babel-mark-file-as-tangled ()
  (R-mode)  ; 
  | (add-file-local-variable 'org-babel-tangled-file t)
  | (add-file-local-variable 'buffer-read-only t)
  | ;; (add-file-local-variable 'eval: (auto-revert-mode))
  | (basic-save-buffer))
  |
  |  (add-hook 'org-babel-post-tangle-hook
  |'org-babel-mark-file-as-tangled)
  `



to call R-mode explicitly. That's got its own downside: all your
tangled files are going to be in R-mode.

The point is that you have to tell emacs somehow what you are doing:
it can't guess that you are producing R-mode files without some help.

-- 
Nick




[O] Go to heading using LISP

2013-06-08 Thread Alexander Wingård
Hi!

I want to create special key-bindings that use the org-refile goto
interface to jump to specific headings.

My initial attempt was:
(org-refile 4 gtd.org Projects/Work/Bugs)

But it seems specifying RFLOC is not that simple.

Someone have any idea how to achieve this or another way to jump to a
heading?

Best Regards /Alexander


Re: [O] bug(?) ox-html always add a timestamp in comment which can't be customized away

2013-06-08 Thread Haojun Bao
Thanks, sorry for not checking the latest version.



On Sat, Jun 8, 2013 at 2:04 PM, Nick Dokos ndo...@gmail.com wrote:

 Haojun Bao baohao...@gmail.com writes:

  Just checked, it is the same tag (release_8.0.3), there is no change
 like in your code.
 
  Could you please run git blame on those lines?

 You need to upgrade to latest. Git blame says:

 ,
 | $ git blame -L 1509,1511 lisp/ox-html.el
 | d574bf52 (Kodi Arfer 2013-05-30 15:19:57 -0400 1509)  (when
 (plist-get info :time-stamp-file)
 | d574bf52 (Kodi Arfer 2013-05-30 15:19:57 -0400 1510)
  (format-time-string
 | d574bf52 (Kodi Arfer 2013-05-30 15:19:57 -0400 1511)   (concat !-- 
 org-html-metadata-timestamp-format  --\n)))
 `

 and the commit shows the change from the code you see to the code I see:

 ,
 | nick@pierrot:~/src/emacs/org/org-mode$ git show d574bf52
 | commit d574bf522d1b2ac74cb4245f8742253bde7861df
 | Author: Kodi Arfer g...@arfer.net
 | Date:   Thu May 30 15:19:57 2013 -0400
 |
 | ox-html: Fix handling of time-stamp-file
 |
 | * lisp/ox-html.el (org-html--build-meta-info): Insert no timestamp
 |   when :time-stamp-file is nil.
 |
 | TINYCHANGE
 |
 | diff --git a/lisp/ox-html.el b/lisp/ox-html.el
 | index 297cb55..949c3ba 100644
 | --- a/lisp/ox-html.el
 | +++ b/lisp/ox-html.el
 | @@ -1506,10 +1506,9 @@ INFO is a plist used as a communication channel.
 |iso-8859-1)))
 |  (concat
 |   (format title%s/title\n title)
 | - (format
 | -  (when :time-stamp-file
 | - (format-time-string
 | -  (concat !--  org-html-metadata-timestamp-format  --\n
 | + (when (plist-get info :time-stamp-file)
 | +   (format-time-string
 | +  (concat !--  org-html-metadata-timestamp-format  --\n)))
 |   (format
 |(if (org-html-html5-p info)
 | (org-html-close-tag meta  charset=\%s\ info)
 `

 Nick

 
  On Sat, Jun 8, 2013 at 1:30 PM, Nick Dokos ndo...@gmail.com wrote:
 
  Haojun Bao baohao...@gmail.com writes:
 
   The culprit code is the following:
  
 (when :time-stamp-file
   (format-time-string
(concat !--  org-html-metadata-timestamp-format  --\n)))
  
   This `when' condition is always true, because :time-stamp-file is a
   keyword and always eval to itself, never to nil.
  
   So I think org-export-time-stamp-file should be used instead of
   :time-stamp-file.
  
 
  What version are you using? In the version I have, the code looks
 like
  this:
 
   (when (plist-get info :time-stamp-file)
 (format-time-string
   (concat !--  org-html-metadata-timestamp-format 
 --\n)))
 
  Org-mode version 8.0.3 (release_8.0.3-197-g221768)
  [nb: this version includes a few local commits (irrelevant to this
 subject)]
  --
  Nick
 

 --
 Nick





Re: [O] Avoid escaping braces in LaTeX export?

2013-06-08 Thread Eric S Fraga
Richard Lawrence richard.lawre...@berkeley.edu writes:


[...]

 Still, this won't work directly for cases where I have loaded a LaTeX
 package that provides a command which uses curly braces.  (I could
 redefine such commands, as above, but that could get real ugly, real
 fast...).  It seems like this a general problem that the exporter should
 have a way to handle.

Org is not latex, for better or for worse.  However, it does allow you
to mix the two in various ways.  The inline approach is limited to
{text} that is on the same line.  You could try using visual-line-mode
and have all paragraphs be single lines.

Alternative, you could try (untested):

blah blah blah
#+LATEX: \ic{
some text for the inline comment
#+LATEX: }
more blah

HTH,
eric

-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_8.0.3-193-g334581




[O] different font sizes for headings

2013-06-08 Thread Andrey Tykhonov
Hi all!

I have installed emacs two days ago and org-mode yesterday. I'm new in
it. And currently configuring everything in it. And I just recently found such
screenshot:

https://raw.github.com/juba/color-theme-tangotango/0a501959707b7637c72aba779651ea94cec96963/screenshots/tangotango_org.png

And I'm searching via google how to configure emacs/org-mode so it can
display headings (Level 1 Heading, Level 2 Heading) with different font sizes...

How such thing could be done? Could you help me please?


Thank you in advance!


Regards,
Andrey.



Re: [O] Avoid escaping braces in LaTeX export?

2013-06-08 Thread Richard Lawrence
Eric S Fraga e.fr...@ucl.ac.uk writes:

 Richard Lawrence richard.lawre...@berkeley.edu writes:
 Org is not latex, for better or for worse.  However, it does allow you
 to mix the two in various ways.  The inline approach is limited to
 {text} that is on the same line.  You could try using visual-line-mode
 and have all paragraphs be single lines.

 Alternative, you could try (untested):

 blah blah blah
 #+LATEX: \ic{
 some text for the inline comment
 #+LATEX: }
 more blah

Thanks, Eric; that works, too.

I think for now the best thing is for me to put longer comments in a
custom environment.  Then I can use Org's block syntax, and have other
export backends do the right thing, if I ever use them instead of LaTeX.

I did dig into the exporter code a bit, so in case anyone is bitten by a
similar issue that doesn't have a ready workaround, the places to look
seem to be:
  - org-element.el:org-element-latex-or-entity-successor.  This is where
LaTeX fragments are identified.  (As Eric notes, multi-line commands
will not have their arguments parsed as part of a latex-fragment;
instead, the argument and surrounding braces are parsed as text in
the surrounding paragraph.) 
  - ox-latex.el:org-latex-plain-text.  This is where special characters
that don't get parsed as part of a LaTeX fragment are
protected/escaped.

I still think it might be nice if each of the protections in
org-latex-plain-text could be toggled via an #+OPTIONS keyword, since
more often than not, I find that characters are escaped in LaTeX export
when I would prefer they weren't.  But that might be a peculiar fact
about how I use Org.  Since for now I don't require this behavior, I'm
not going to try to implement it myself, but if anyone else would also
find it useful, let me know and I will take a stab at writing a patch.

Thanks, all, for the help!

-- 
Best,
Richard




[O] add joint work with

2013-06-08 Thread Andrej Depperschmidt
Hello emacs-orgmode list!

I am trying to prepare a talk using ox-beamer and am missing a function
that I am used to.

In beamer latex one can for example write

\author[speaker]{speaker \\ joint work with second author and third author}

Then I get my name and that of my coauthors on the titlepage. My name
can then also appear (depending on the beamer theme) in the footnote on
each slide.

Is it possible to achieve this without exporting to latex and adjusting
the corresponding entries there?

I didn't find an answer on the list. Also in ox-beamer.el the
corresponding section contains only entries with \author{...}, i.e.
without square brackets. Would be nice to have an entry

#+COAUTHOR: second author and third author

that is then put in \author[second author and third author]{...}

Or is there already something similar that I didn't find?

Best regards,
Andrej



Re: [O] link abbreviation with multiple params, e. g. for geo locations

2013-06-08 Thread Eric Schulte
   If yes then I understand only now that the functionality of the new
   variable is of course the same for the changes in both commits and
   therefore the name has to be the same for the changes in both commits.
   But for me it would have helped to have some other name, containing
   neither src-block, which I associate it with #+BEGIN_SRC but
   not #+CALL line or inline call_name, nor head, which I associate
   with #+HEADER. I would like to suggest org-babel-exec-marker. What do
   you and Vitalie (CCed) think?

 I named it with head because head is the local variable in
 org-babel-get-src-block-info referring to that position.  There are
 other functions that use -head: org-babel-goto-src-block-head,
 org-babel-where-is-src-block-head. 

 But, I agree that it might be better called beg, location or position.

 I think src-block is not misleading, there are plenty of
 foo-src-block-bar in babel. 

 May be then:  org-babel-current-src-block-location?


How about the shorter `org-babel-current-src-block'?  It is somewhat
more ambiguous, but the only reasonable options would be location or
name, and not every code block has a name.  I think the added brevity is
worth the ambiguity, but I'm not strongly committed either way.

I'll happily commit whatever is generally appealing.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte



Re: [O] link abbreviation with multiple params, e. g. for geo locations

2013-06-08 Thread Eric Schulte
 2) Export is not supported (C-c C-c works as expected).

 I can't reproduce this bug.

 From your attached org-entry-get-point-example.org I get with some
 lines omitted

 \section{example of a geo location, realistic to try out}
 \item \texttt{geo\_var is 4.56,7.89} \texttt{geo\_var is 4.56,7.89}
 \section{another geo location}
 \item \texttt{geo\_var is 4.56,7.89} \texttt{geo\_var is 4.44,5.55}

 but expect

 \section{example of a geo location, realistic to try out}
 \item \texttt{geo\_var is 4.56,7.89} \texttt{geo\_var is 4.56,7.89}
 \section{another geo location}
 \item \texttt{geo\_var is 4.44,5.55} \texttt{geo\_var is 4.44,5.55}


I've just pushed up a commit which should fix this problem.  The
org-babel-current-exec-src-block-head variable wasn't bound during
export.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte



Re: [O] :session question -- and changes to #+Property: syntax

2013-06-08 Thread Eric Schulte
Achim Gratz strom...@nexgo.de writes:

 Eric Schulte writes:
 As I recall I was fully in favor of applying these changes, however I am
 not qualified to address the changes to property behaviors.  Hopefully
 someone who works more on that side of things can address those aspects.

 Oh wait, now I understand what you're getting at, let me explain.  The
 first patch that makes Org use the same regex in all places where a
 property is used does indeed change some behaviour, but not the syntax
 of the property line:

 :PROPERTY: VALUE

 where PROPERTY can contain any non-whitespace character (in
 correspondence to how the keyword PROPERTY is treated in org.el since it
 is not explicitly specified in org-element).

 However, there were other places in Org where a more restricted syntax
 for properties in property drawers was used, which would have precluded
 the use of : in property names and made it impossible to overwrite an
 inherited property from a #+PROPERTY: line that has such a property
 name.

 I've taken org-element as the authoritative source for the syntax and
 eliminated the other interpretations based on the fact that while the
 behaviour visible in the buffer (highlighting, prompts, etc.) would hint
 differently, the actual property handling was using the syntax used in
 org-element already.  Hence if documents existed that had mistakenly
 made use of these differences, they were already broken and would be
 interpreted via the property API as they are now also shown after this
 change.


Great.  Would you be willing to go ahead and apply these changes
(including documentation)?  If it upsets anyone we'll sort things out on
the mailing list.

There are stable releases precisely so that we can experiment
interactively on the development head.

Thanks,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte



Re: [O] Automatically adding local variables to tangled file

2013-06-08 Thread Eric Schulte

 We already set the permission of tangled files to be executable when
 they include a shebang line.  Perhaps we could add an option (or change
 the default) to set the permissions of tangled files to be read only.

 Perhaps this could be done using the post-tangle hook with something
 like the following.

 ;; -*- emacs-lisp -*-
 (defun org-babel-mark-tangled-as-read-only ()
   Mark the current file read only.
 If it is executable keep it executable.
   (if (= #o755 (file-modes (buffer-file-name)))
   (set-file-modes (buffer-file-name) #o555)
   (set-file-modes (buffer-file-name) #o444)))

 (add-hook 'org-babel-post-tangle-hook 
 'org-babel-mark-tangled-as-read-only)


 I think that would be a good idea to add this in a way so that it is
 controled by a variable

I've added a :tangle-mode header argument which may be used to control
the permissions of tangled files.  See the manual for instructions on
it's usage.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte



Re: [O] link abbreviation with multiple params, e. g. for geo locations

2013-06-08 Thread Vitalie Spinu
  Eric Schulte schulte.e...@gmail.com
  on Sat, 08 Jun 2013 12:05:32 -0600 wrote:

[...]

  
  May be then:  org-babel-current-src-block-location?
  

  How about the shorter `org-babel-current-src-block'?  It is somewhat
  more ambiguous, but the only reasonable options would be location or
  name, and not every code block has a name.  I think the added brevity is
  worth the ambiguity, but I'm not strongly committed either way.

I personally find it quite confusing.  Babel names that contain
src-block semantically refer to the whole thing. This one refers to the
pointer. If brevity is very important I would rather drop current:

`org-babel-src-block-location'

or probably even more suggestive:

`org-babel-src-block-beginning'.


Vitalie



Re: [O] link abbreviation with multiple params, e. g. for geo locations

2013-06-08 Thread Eric Schulte
Vitalie Spinu spinu...@gmail.com writes:

   Eric Schulte schulte.e...@gmail.com
   on Sat, 08 Jun 2013 12:05:32 -0600 wrote:

 [...]

   
   May be then:  org-babel-current-src-block-location?
   

   How about the shorter `org-babel-current-src-block'?  It is somewhat
   more ambiguous, but the only reasonable options would be location or
   name, and not every code block has a name.  I think the added brevity is
   worth the ambiguity, but I'm not strongly committed either way.

 I personally find it quite confusing.  Babel names that contain
 src-block semantically refer to the whole thing. This one refers to the
 pointer. If brevity is very important I would rather drop current:

 `org-babel-src-block-location'

 or probably even more suggestive:

 `org-babel-src-block-beginning'.


I like current because it is similar to other variables which are
dynamically bound by Org-mode and without it there is no indication that
it points to a block which is active *now*.

I've changed the variable name to your previous suggestion of
`org-babel-current-src-block-location'.  If anyone really wants brevity
they can add the following to their config.

;; -*- emacs-lisp -*-
(defun loc () org-babel-current-src-block-location)

Cheers,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte



[O] 'listings' package used but not required in LaTeX export

2013-06-08 Thread Thorsten Jolitz

Hi List, 

at the risk that this is caused by some personnal configuration I'm not
aware of at the moment, I report it nevertheless:

When I export an .org buffer with source code blocks (e.g. R) to LaTeX,
functions from the 'listings' package are used in the LaTeX sources,
like e.g. 

,-
| \lstset{language=R,numbers=none}
| \begin{lstlisting}
`-

but there is no 

,--
| \usepackage{listings}
`--

statement in the preamble. This is about exporting with no further
options or properties set, the default case so to say. 

PS
Emacs Version:
(24.3.1 24 3 gnu/linux hostname x86_64-unknown-linux-gnu x nil)

Org-mode version 8.0.3 (release_8.0.3-165-g60ca9e @
/home/tj/gitclone/org-mode/lisp/)

-- 
cheers,
Thorsten





Re: [O] :session question -- and changes to #+Property: syntax

2013-06-08 Thread Achim Gratz
Eric Schulte writes:
 Great.  Would you be willing to go ahead and apply these changes
 (including documentation)?  If it upsets anyone we'll sort things out on
 the mailing list.

All right, then.  I've pushed the first part as it is a preparation for
the actual change.  I can push that second part as well, but I'll need
another week or so for properly documenting it in the manual and setting
up a test.  Unless someone urgently wants to do something with it, I'd
rather push these things together.


Regards,
Achim.
-- 
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+

Waldorf MIDI Implementation  additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs




Re: [O] Automatically adding local variables to tangled file

2013-06-08 Thread Achim Gratz
Eric Schulte writes:
 I've added a :tangle-mode header argument which may be used to control
 the permissions of tangled files.  See the manual for instructions on
 it's usage.

The change in org-babel-read now requires that :shebang values are
quoted.  I've changed the test file accordingly as otherwise the file
couldn't be ingested.  In general I'd suggest that reading header
arguments as eLisp should at be protected against an error propagating
out of the reader function.


Regards,
Achim.
-- 
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada




Re: [O] Automatically adding local variables to tangled file

2013-06-08 Thread Eric Schulte
Achim Gratz strom...@nexgo.de writes:

 Eric Schulte writes:
 I've added a :tangle-mode header argument which may be used to control
 the permissions of tangled files.  See the manual for instructions on
 it's usage.

 The change in org-babel-read now requires that :shebang values are
 quoted.

Oh, I should have realized that shebang values weren't normally quoted.
I've reverted this portion of my tangle-mode patch, so the reader no
longer tries to read #-prefixed strings a elisp.  Hopefully this won't
affect too many people.

 I've changed the test file accordingly as otherwise the file couldn't
 be ingested.  In general I'd suggest that reading header arguments as
 eLisp should at be protected against an error propagating out of the
 reader function.


I think in most cases it would be better to know if an error has
occurred than not, and I think any sort of message output would quickly
be overwritten by the remainder of the code block execution.

Thanks for catching this quickly!



 Regards,
 Achim.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte



Re: [O] 'listings' package used but not required in LaTeX export

2013-06-08 Thread Rasmus
Thorsten Jolitz tjol...@gmail.com writes:

 but there is no 

 ,--
 | \usepackage{listings}
 `--

This is a feature to my understanding.

Several packagess can format, and I for instance prefer pygments if I
need code formatting.

You could add listings to your packages list, either
org-latex-packages-alist or even org-latex-default-packages-alist, if
you really want to.

You could probably also write a clever filter to load a package if it
is missing.

–Rasmus

-- 
When in doubt, do it!




Re: [O] 'listings' package used but not required in LaTeX export

2013-06-08 Thread Thorsten Jolitz
Rasmus ras...@gmx.us writes:

 Thorsten Jolitz tjol...@gmail.com writes:

 but there is no 

 ,--
 | \usepackage{listings}
 `--

 This is a feature to my understanding.

mmhh ... I would rather say that the defaults can be as simple as
possible (or desired), but should result in reasonable output without
any user interaction. But without adding a \usepackage{listings} or
modifying the variables you mention the LaTeX output is unusable in this
case.

 Several packagess can format, and I for instance prefer pygments if I
 need code formatting.

Then the default should be loading one of them rather than using package
macros in the exported LaTeX sources without loading a package that
contains those macros. 

 You could add listings to your packages list, either
 org-latex-packages-alist or even org-latex-default-packages-alist, if
 you really want to.

 You could probably also write a clever filter to load a package if it
 is missing.

I could, and thanks for the tips, but I still think this can be
considered a bug (if I'm not the only one having the problem). 

-- 
cheers,
Thorsten




Re: [O] Go to heading using LISP

2013-06-08 Thread Eric Abrahamsen
Alexander Wingård alexander.wing...@gmail.com writes:

 Hi!

 I want to create special key-bindings that use the org-refile goto
 interface to jump to specific headings.

 My initial attempt was:
 (org-refile 4 gtd.org Projects/Work/Bugs)

 But it seems specifying RFLOC is not that simple.

 Someone have any idea how to achieve this or another way to jump to a
 heading?

Is the `org-goto' interface close enough? It only does the current
buffer, but you can set org-goto-interface to make it behave a fair bit
like refile...

Yours
Eric




[O] org-mouse broken

2013-06-08 Thread Samuel Wales
In recent git master, when org-mouse is loaded, the mouse is not
active in the stars of headlines.

After reverting the Org buffer, the mouse is active.

This is an insufficient bug report, but I cannot do better at this
time.  I hope that somebody can think of recent activity in the git
repo that could have affected this.

Thanks.

Samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  ANYBODY can get it.