Re: [O] Updated syntax for #+bind and no LaTeX \maketitle command?

2013-05-24 Thread Nick Dokos
Nick Dokos ndo...@gmail.com writes:

 #+bind: org-latex-title-command 

 This is still generating a \maketitle line in my .tex file.

 What's the proper way to do this on Org 8.0?



 I suspect this is the same problem as the one discussed in the following:

http://thread.gmane.org/gmane.emacs.orgmode/72085

 Nicolas suggested using a file local variable for that problem and I've
 verified that that solution also works for this one. Just add

 # Local Variables:
 # org-latex-title-command: 
 # End:

 at the end of your file.

No, I'm wrong: it's not the same problem. And using BIND should
work in this case, assuming that it is allowed.

Check the value of org-export-allow-bind-keywords. If nil, then
BIND keywords seem to be ignored silently.

-- 
Nick




Re: [O] [bug] org-capture fails with undefined org-time-was-given variable

2013-05-24 Thread Eric S Fraga
Dear Nick  Bastien,

Thanks for your responses.

Both of you indicated that you don't have the problem with Emacs -Q.  I
don't either.  Sorry, I should have tried a minimal example before
posting.

In any case, I have tracked down the offending line in my customisation
that leads to the error:

  (setq org-popup-calendar-for-date-prompt nil)

The default is t which allows my capture to work but I don't want a
calendar popup.  Note that there is a new name for this variable,
org-read-date-popup-calendar but it makes no difference which name I
use.

I have tried tracing this through but have failed to figure out why the
setting of this variable makes a difference.  See below.

 Org-mode version 8.0.3 (release_8.0.3-144-gbd09fe @
 /home/nick/elisp/org-mode/lisp/)

 That includes a bunch of private commits, but when I look at git history
 I don't find the commit you mention in your org version, f1b99a, so
 maybe you have your own bunch of private commits and one or more of them
 broke something? Maybe try a vanilla org?

My org *is* vanilla!  I try to keep it as such.  I live dangerously
enough by tracking the development version on a relative frequent basis
... :-)

It's very strange that you could not find the commit.  But I have
updated org since then unfortunately so cannot reproduce the
situation.  I am sending this email from a different system so it has a
different org version (long story).

 The variable is indeed not to be set by you: it's a dynamically scoped
 variable, so somebody binds it at some level and then every callee
 (direct or indirect) can access it. Stepping through
 org-capture-set-location shows that it is unbound up until the call to
 org-read-date (line 907-909 in org-capture.el) and it is bound on return
 from that function, at least in my case.

Yes.  The only place I can find where the variable is actually given a
value is in org-data-analyze (sic) but I can't figure out the trail that
leads to this happening (it involves org-end-time-was-given).

I may try later to see if I can figure this out.  In any case, this is
not mission critical in any sense!  I was just surprised when the error
happened.

Thanks again,
eric

-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_8.0.2-101-gce5988




[O] Rendering of source code on worg

2013-05-24 Thread Guido Van Hoecke
Hi,

I think that the default rendering of source code on the worg side was
closely resmbling the default rendering on emacs.

I have the impression that somehow this is no longer the case, as
visible a.o. at
http://orgmode.org/worg/org-configs/org-config-examples.html

Is this a deliberate choice?


Guido

--
Machine-independent program:
A program that will not run on any machine.



Re: [O] Using org to create a TOC for a compilation of separate PDF documents

2013-05-24 Thread AW
Am Donnerstag, 23. Mai 2013, 23:48:03 schrieb Marcin Borkowski:
 Dnia 2013-05-23, o godz. 15:21:56
 
 John Hendy jw.he...@gmail.com napisał(a):
  I have a use case and am not sure if Org would help or not. I've
  downloaded a bunch of technical data sheets on various materials from
  a vendor. I'd like to create a booklet of them with a cover page
  table of contents.
  
  I can create the booklet very easily with Stapler (or similar), but am
  not sure on the best way to generate a clickable linked PDF of the
  individual materials contained in the compiled document.[1] What I'm
  not sure on is how to create a table of contents.
  
  Ideally, I could do something like generate a page count of each
  document and then use this to create the page numbers I'd use to
  create links to, which I thought I could do with Org. Even better
  would be to have [back to top] links as well, since this will end up
  being a multi-hundred page booklet (~100 documents of 2-4 pages each).
  
  Any thoughts on this?
  
  Is it easier to just generate a list of files and use Org to include
  them somehow via LaTeX instead of using Stapler to combine them?
 
 I'd just use LaTeX's pdfpages package, possibly with hyperref.  (If you
 encounter any problems, email me - I've done similar things before, so
 I guess I could help you.)
 

You don't have to do that manually. Some time ago members of the German TEX-D-
List put together a bash script, which takes all the PDFs recursivly and 
creates a *.tex file:

#+begin_src bash

#!/bin/bash
#
# pdfdir OUTPUT_FILE
#
# produces one big PDF file of all PDF files in .
#
if [ $# -ne 1 ] || [ -z $1 ]; then
  echo Syntax: pdfdir OUTPUT_FILE
  exit 1
fi
FILE=$(echo $1|sed -e 's/\.\(pdf\|tex\)$//')
for F in $FILE $FILE.tex $FILE.pdf $FILE.aux $FILE.log ; do
  if [ -e $F ]; then
echo $F already exists.
exit 2
  fi
done
cat $FILE.tex EOF
\documentclass{article}%
\usepackage{pdfpages}%
\usepackage{grffile}%
\listfiles%
\begin{document}%
%\tableofcontents%
EOF
# Helperfunction
exist_pdf_files () {
  [ $(find -L $1 -name \*.pdf -o -name \*.PDF -type f 2/dev/null|wc -l) -eq 
0 ]  return 1
  return 0
}
list_directories () {
  find -L $1 -maxdepth 1 -mindepth 1 -type d 2/dev/null | sort
}
list_pdf_files () {
  #  around filenames:
  find -L $1 -maxdepth 1 -mindepth 1 -name \*.pdf -o -name \*.PDF -type f 
2/dev/null | sort | \
sed -e 's/^/\\includepdf[pages=-]{/; s/$/}%/'
  # without  around filenames:
 # find -L $1 -maxdepth 1 -mindepth 1 -name \*.pdf -o -name \*.PDF -type f 
2/dev/null | sort | \
  #  sed -e 's/^/\\includepdf[pages=-]{/; s/$/}%/'
}
tex_headline () {
echo $1 | sed -e 's/_/\\_/g'
}
# folder level were we are (level 0):
list_pdf_files . $FILE.tex
# level 1:
list_directories . | while read -r DIR1; do
  # Are there PDF files a level down?
  exist_pdf_files $DIR1 || continue
  # Yes...
  tex_headline \section{${DIR1##*/}}%
  # ... those are ...:
  list_pdf_files $DIR1
  # Level 2:
  list_directories $DIR1 | while read -r DIR2; do
exist_pdf_files $DIR2 || continue
tex_headline \subsection{${DIR2##*/}}%
list_pdf_files $DIR2
# Level 3:
list_directories $DIR2 | while read -r DIR3; do
  exist_pdf_files $DIR3 || continue
  tex_headline \subsubsection{${DIR3##*/}}%
  list_pdf_files $DIR3
  # Level 4:
  list_directories $DIR3 | while read -r DIR4; do
exist_pdf_files $DIR4 || continue
tex_headline \paragraph{${DIR4##*/}}%
list_pdf_files $DIR4
# Level 5:
list_directories $DIR4 | while read -r DIR5; do
  exist_pdf_files $DIR5 || continue
  tex_headline \subparagraph{${DIR5##*/}}%
  list_pdf_files $DIR5
done
  done
done
  done
done $FILE.tex
echo \end{document}% $FILE.tex
echo Compile source now? [J/n]
read -r ANSWER
case $ANSWER in
[JjYy]) ;;
*) exit 0 ;;
esac
pdflatex $FILE
[ $? -eq 0 ]  rm -f $FILE.aux $FILE.log $FILE.tex



#+end_src

I found that very helpfull, but I did not use it recently.

Regards,

Alexander

  Thanks for any suggestions!
  John
 
 Best,


book-from-PDF.sh
Description: application/shellscript


Re: [O] (Potential) new feature for Org-mode: hidden-lines cookies

2013-05-24 Thread Sebastien Vauban
Hi Suvayu,

Suvayu Ali wrote:
 On Thu, May 23, 2013 at 10:39:03AM +0200, Sebastien Vauban wrote:
 Suvayu Ali wrote:
  Now I wonder if such a feature already exists in Org-mode (I would not
  be surprised, but I'm not aware of it) and if anybody would be
  interested in having such a feature?
 
  As per my understanding, there is no such feature; and as a user, I
  would love it!
 
 It does exist in the Org-mode clone for Vim, but not yet in Org...

 VimOrganizer although really cool,

Never used it, but it looks like it's cool (on Vimeo)...

 is not Emacs Org-mode ;).

... Yes, that's why that feature deserves to be in Emacs Org-mode as well! ;-)

Best regards,
  Seb

-- 
Sebastien Vauban




[O] Status fix for Regression in fill-paragraph behavior?

2013-05-24 Thread Wagemans, Peter

In org 7.8.11 with emacs 24.2 fill-paragraph used to recognize
paragraph fill prefixes as usual for mail citations. This seems to be
no longer the case (which I noticed first with org 7.9.3 with emacs
24.3). Apparently this has been noticed before and a bug reported,
according to


http://list-archives.org/2013/03/13/emacs-orgmode-gnu-org/o-regression-in-%60fill-paragraph-behavior/f/2446639327

On this page, Bastien says it has been fixed, to be included in 8.0.
However, in my setup 8.0.3 still doesn't do fill-paragraph as expected
for mail citations. Is the fix present in 8.0.3? If yes, is some
configuration needed in the new version to restore this functionality?
If no, is the fix available elsewhere?

Regards,

Peter Wagemans





Re: [O] Org-mode styled beamer presentations

2013-05-24 Thread Eric S Fraga
Marcin Borkowski mb...@wmi.amu.edu.pl writes:

 shameless plug

 Hi list,

 many of you use Org-mode to create Beamer presentations.  How about the
 other way round?  I wrote an Org-mode styled Beamer theme.  Please use,
 enjoy and report bugs and feature requests!

 https://twitter.com/marcin_mbork/status/335890494980767746
 http://mbork.pl/2013-05-18_A_presentation_on_LaTeX_editing_%28en%29
 https://github.com/mbork/beamerorgtheme

 /shameless plug

 Best,

Very cute!  I like it.

Now I just need to customise it so that it matches my usual colour theme
in Emacs which has a black background!  Ahh, a perfect excuse to not get
any more work done today ;-)

thanks,
eric

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




Re: [O] Org-mode styled beamer presentations

2013-05-24 Thread Eric S Fraga
Eric S Fraga e.fr...@ucl.ac.uk writes:

 Marcin Borkowski mb...@wmi.amu.edu.pl writes:

 shameless plug

 Hi list,

 many of you use Org-mode to create Beamer presentations.  How about the
 other way round?  I wrote an Org-mode styled Beamer theme.  Please use,
 enjoy and report bugs and feature requests!

 https://twitter.com/marcin_mbork/status/335890494980767746
 http://mbork.pl/2013-05-18_A_presentation_on_LaTeX_editing_%28en%29
 https://github.com/mbork/beamerorgtheme

 /shameless plug

 Best,

 Very cute!  I like it.

 Now I just need to customise it so that it matches my usual colour theme
 in Emacs which has a black background!  Ahh, a perfect excuse to not get
 any more work done today ;-)

 thanks,
 eric

Well, that was too easy... see attached for a slightly different version
of your colour theme which gives black background with yellowish-white
foreground and red highlighting...

I guess I have to get back to work now! ;-)

In fact, I have a talk to prepare for next week.  I think I'll use this
style!  The audience should be sufficiently geeky to appreciate it for
once.

Thanks again,
eric


-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_8.0.3-148-g36848f
%% beamercolorthemeorg.sty
%%
%% Copyright 2007 by Till Tantau and 2013 by Marcin Borkowski
%%
%% This beamer theme is based on Till Tantau's default Beamer theme,
%% with modifications by Marcin Borkowski.
%
% This work may be distributed and/or modified under the
% conditions of the LaTeX Project Public License, version 1.3c,
% found in the file lppl.txt.
%
% This work has the LPPL maintenance status `maintained'.
% 
% The Current Maintainer of this work is Marcin Borkowski mb...@mbork.pl.
%
% This work consists of the files:
%   beamercolorthemeorg.sty
%   beamerfontthemeorg.sty
%   beamerinnerthemeorg.sty
%   beamerouterthemeorg.sty
%   beamerthemeorg.sty
%   beamerthemeorg-demo.tex

\ProvidesPackage{beamercolorthemeorg}[2013/05/18 Org-inspired color theme for Beamer]

\modepresentation

\usecolortheme{rose}

\definecolor{progressbar@oz}{rgb}{0.7765,0.2431,0.1882}  % colour from the UCL Australia logo background

\setbeamercolor{background canvas}{bg=black,fg=white} 
\usebeamercolor[fg]{background canvas}
\setbeamercolor*{normal text}{fg=yellow!20!white,bg=black}
\setbeamercolor*{alerted text}{fg=progressbar@oz}


\setbeamercolor{structure}{bg=black,fg=progressbar@oz}


\setbeamercolor{org keywords}{use=structure,fg=structure.fg!40!bg}
\setbeamercolor{org keywords dimmed}{use=structure,fg=structure.fg!80!bg}
\setbeamercolor{framesubtitle}{use=structure,fg=structure.fg!70!bg}
\setbeamercolor{dimmed text}{use=structure,fg=structure.fg!40!bg}
\setbeamercolor{alerted text}{use=palette secondary,fg=palette secondary.fg}
\newcommand{\dimmed}[1]{{\usebeamercolor{dimmed text}\color{fg}#1}}

\mode
all

 Emacs food

% Local Variables:
% TeX-command-default: LaTeX
% TeX-master: beamer-test.tex
% End:


[O] Importing all files into .org document source blocks

2013-05-24 Thread Rainer M. Krug
Hi

I would like to import all files in a directory into an org document,
and each file should be in one source block, so that tangling the
document, will result in all files created.

My reasoning: I am using org-mode to keep track of installations on my
machine (apt-get as well as other installs) to make it easier to
re-install a new version of the Linux when necessary.

Now apart from the installation commands, I also have to keep track of
the installation sources. I was thinking of having them in the document,
where each source (i.e. each file in /etc/apt/sources.list.d/.) has it's
own source block, so that I can easily change the Ubuntu version and
tangle the document to obtain the new sources. 

Now I am lazy, and adding each file manually is prone to errors
(i.e. forgetting one). Therefore my question:

Is there a way of importing all files in a directory
(/etc/apt/sources/list.d/) into an org document, with each being in a
separate code block?

Thanks,

Rainer

-- 
Rainer M. Krug


pgpMRzmiCTRVr.pgp
Description: PGP signature


Re: [O] org-element

2013-05-24 Thread Nicolas Goaziou
Hello,

Daimrod daim...@gmail.com writes:

 I'm playing a bit with org-element for org-contacts and I wanted to know
 what is the prefered way to change an element.

 For example, ATM, when I want to change an element property to add a new
 value, I do:

 #+BEGIN_SRC emacs-lisp
   (org-entry-put nil property
  (concat (org-entry-get nil property)
new-value))
 #+END_SRC

See `org-element-put-property' and friends.


Regards,

-- 
Nicolas Goaziou



Re: [O] Status fix for Regression in fill-paragraph behavior?

2013-05-24 Thread Nicolas Goaziou
Hello,

Wagemans, Peter peter.wagem...@kpn.com writes:

 In org 7.8.11 with emacs 24.2 fill-paragraph used to recognize
 paragraph fill prefixes as usual for mail citations. This seems to be
 no longer the case (which I noticed first with org 7.9.3 with emacs
 24.3). Apparently this has been noticed before and a bug reported,
 according to

 
 http://list-archives.org/2013/03/13/emacs-orgmode-gnu-org/o-regression-in-%60fill-paragraph-behavior/f/2446639327

 On this page, Bastien says it has been fixed, to be included in 8.0.
 However, in my setup 8.0.3 still doesn't do fill-paragraph as expected
 for mail citations. Is the fix present in 8.0.3? If yes, is some
 configuration needed in the new version to restore this functionality?
 If no, is the fix available elsewhere?

You can wrap your mail citation within a Verse block (or an example
block).


Regards,

-- 
Nicolas Goaziou



Re: [O] org-blog 0.9 release

2013-05-24 Thread Michael Alan Dorman
Matt Price mopto...@gmail.com writes:
 On Wed, May 1, 2013 at 7:04 AM, Puneeth Chaganti puncha...@gmail.com wrote:
 On Wed, May 1, 2013 at 4:18 PM, Michael Alan Dorman
 If you don't mind, I will start looking at the org2blog code and seeing
 how cleanly I can implement these additional capabilities as handlers or
 filters for the exporter---and then maybe we could look for that
 back-end to live in contrib, and both our codebases could take advantage
 of it?

 That seems like a good plan.  I've been meaning to get this going for
 some time, but have been quite busy off-late.  I'll try to make some
 time for it, soon.

 Was there ever any progress on this?  I code so slowly I'd not likely
 be much help with the actual implementation but would be happy to pull
 from git and do some testing if that's of any use.

Well, it's not an ex-parrot---which is to say, I still have the
intention to work on it---but 1) my $DAYJOB has gotten busy, and 2) with
many of the additional features being Wordpress-specific, it demands
that I do some significant refactoring of my code for me to do it in a
way that doesn't tie the whole thing to Wordpress.

That said: Puneeth, it seems like most of your additional features are
currently implemented as post-processing bits---could you just grab the
new-exporter-based code that I have now and use that?  It's not an
all-singing, all-dancing solution, but it might get your users able to
use 8.0 sooner.

Mike.



Re: [O] Indentation of code blocks within lists

2013-05-24 Thread Nicolas Goaziou


Hello,

Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org
writes:

 That won't help you, but I've already sent questions on this problem, last
 year (Org  8). See my post on
 http://lists.gnu.org/archive/html/emacs-orgmode/2012-02/msg00247.html.

 Though, it's (for me) still unfixed as of today.

 The good news is that Nicolas seemed OK to look at it, and find a solution for
 it...

AFAICS, your problem was solved. Could you point to what is still wrong?

I also cannot reproduce OP's problem. It may be related to
`org-src-preserve-indentation' value.


Regards,

-- 
Nicolas Goaziou




Re: [O] Status fix for Regression in fill-paragraph behavior?

2013-05-24 Thread Wagemans, Peter

Nicolas Goaziou wrote:

 You can wrap your mail citation within a Verse block (or an example
 block).

That appears to inhibit paragraph filling. The desired and previously
existing functionality is paragraph filling that preserves the
paragraph citation prefix.

Also, I often compose complete text mail bodies including citations in
an org-mode document and then you don't want org-mode block directives
in the mail text.

Does the above reply mean that the regression hasn't been fixed yet?
Is it still being worked on?

Regards,

Peter Wagemans




Re: [O] [NEW FEATURE] org-hlc.el - hidden-lines-cookies (hlc) for Org-mode

2013-05-24 Thread Thorsten Jolitz
Carsten Dominik carsten.domi...@gmail.com writes:

Hi Carsten, Hi List,

 ,
 | Behind every folded headline, a little 'cookie' shows the number of
 | hidden lines till the next visible headline.
 `

 However, I don't think the implementation is the right
 one.

it happened again - François Pinard already had a fully fledged
implementation of my new org-mode feature: 'org-weights.el'

,--
| https://github.com/pinard/org-weights
`--

But this time I was saved from implementing a completely independent
version of the same idea (see 'outorg.el' vs 'poporg.el') but rather
forked his library on github and merged my ideas/code with his:

,
| https://github.com/tj64/org-weights
`

Although the details are still a bit buggy, the general mechanism
already works.

1. 'org-weights' works with Org-mode as well as with outshine buffers
now (including Emacs Lisp files with conventional headers (^;;;+ ). It
might even work with plain outline buffers.

2. 'org-weights' now offers to display the headline-weights (number of
subtrees and number of paragraphs) or hidden-lines-cookies (the number
of (hidden) lines till the next visible headline.

Here are a few examples (don't bother about the numbers, they are made
up, since I cannot copy overlays):

1. Org-mode/subtree-weights:

,---
| * Header 1   *2 + 1...
| ** Header 2a **   1
|
| text text text text text
| text text text text text
|
| ** Header 2b **   1
`---

2. Outshine Emacs Lisp/subtree-weights:

,--
| ;; * Header 1   *2 + 1...
| ;; ** Header 2a **   1
|
| text text text text text
| text text text text text
|
| ;; ** Header 2b **   1
|
`--

3. Conventional Emacs-Lisp/hidden-lines-cookies

,
| ;;; Header 1   [#1]
|  Header 2a  [#4]
|
| text text text text text
| text text text text text
|
|  Header 2b [#2]
|
`

4. Outshine PicoLisp/hidden-lines-cookies

,
| ## * Header 1   [#1]
| ## ** Header 2a  [#4]
|
| text text text text text
| text text text text text
|
| ## ** Header 2b [#2]
|
`

'org-weights' is implemented with overlays, so the files are not
touched. Command 'org-weights-mode' toggles activation, and
'org-weights-or-cookies' switches between subtree-weights and
hidden-lines-cookies.

Actually the hidden-lines-cookies are not really about hidden-lines
anymore in this implementation, because I adapted to the semantics of
'org-weights' that shows the overlay-info for *all* headlines except the
one where point is on.

Besides the still buggy details for outshine buffers (the calculated
numbers are not always quite right), one problem I hit is that a
visibility change does not uptdate all cookies/weights at once, they are
only updated headline per headline when point is moved up and down.

Is that for performance reasons?

--
cheers,
Thorsten




Re: [O] Status fix for Regression in fill-paragraph behavior?

2013-05-24 Thread Nicolas Goaziou
Wagemans, Peter peter.wagem...@kpn.com writes:

 Nicolas Goaziou wrote:

 You can wrap your mail citation within a Verse block (or an example
 block).

 That appears to inhibit paragraph filling. The desired and previously
 existing functionality is paragraph filling that preserves the
 paragraph citation prefix.

Then try editing your text in a block like:

  #+BEGIN_SRC message
   ...
  #+END_SRC

You can edit the message with C-c ' and benefit from Message mode's
filling mechanism. Org recognizes its own prefixes and cannot cope with
other modes'.

 Also, I often compose complete text mail bodies including citations in
 an org-mode document and then you don't want org-mode block directives
 in the mail text.

I think you want to edit your message in Message mode, not in Org mode,
then.

 Does the above reply mean that the regression hasn't been fixed yet?
 Is it still being worked on?

I wouldn't call it a regression since this behaviour never was defined
as a feature in the first place.

Recognizing citation prefix means recognizing a new type of data in Org
syntax. I don't think it's worth it considering Org is not to replace
Message.


Regards,

-- 
Nicolas Goaziou



Re: [O] [NEW FEATURE] org-hlc.el - hidden-lines-cookies (hlc) for Org-mode

2013-05-24 Thread Thorsten Jolitz
Nick Dokos ndo...@gmail.com writes:

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

 , and it should be hooked somehow into the folding/unfolding routines
 to auto-update.

 Thats what I thought too, but I ran into a problem I could not solve so
 far, so this user-command based implementation (show the cookies on
 demand) is kind of the second-best solution (better then nothing). 

 Here is a thread related to the problem mentioned, unfortunately with no
 posts except my own so far:

 ,---
 | http://lists.gnu.org/archive/html/help-gnu-emacs/2013-05/msg00511.html
 `---

 You can try increasing max-specpdl-size: read the doc for it. If you are
 asking for a bounded amount of resources but that amount is bigger than
 what emacs is willing to give you, then increasing the size should work.
 OTOH, if you are asking for unlimited resources (e.g. you have an
 infinite recursion somewhere), then increasing the limit will only allow
 you to go a little further before blowing up again.

 So try making it 10 or even 100 times bigger and see what you get (and
 try it on a throwaway emacs instance, not the working instance). If it
 still blows up, you'll have to look at your code carefully: chances are
 there is a programming error.

I read about that, but I did not simply want to increase the limit
because looking at my code I thought it should not use so much bindings. 

However, the problem is more or less obsolete now since I switched to a
completely different implementation using overlays - see my post with
regards to 'org-weights.el'.

Thanks for the info anyway. 

-- 
cheers,
Thorsten




[O] Bad formatting in documentation

2013-05-24 Thread Alexis Praga
Hi,

I just stumbled upon a bad formatting on the website (
http://orgmode.org/worg/org-faq.html ).
In Why doesn't C-c a call the agenda? Why don't some org keybindings
work?, we can see

#+BEGIN_SRC emacs-lisp ;; The following lines are always needed. Choose
your own keys. (add-to-list 'auto-mode-alist '(\\.org\\' . org-mode))
(global-set-key \C-cl 'org-store-link) (global-set-key \C-ca
'org-agenda) (global-set-key \C-cb 'org-iswitchb) #+END_SRC emacs-lisp



-- 

   Alexis Praga
___

Ph.D Student
CERFACS
alexis.pr...@gmail.com


[O] Fwd: File local variables not being processed

2013-05-24 Thread Daniel.
Hi, I have a todo.org file with some local variables, here is the file
content

# Local Variables:
# eval: (setq org-todo-keyword-faces
#  '((TOSTART . red)
#(PLANING . yellow)
#(DOING . yellow)
#(CHECKING . yellow)
#(WAITING . green)
#(DOCUMENTING . yellow)))
# End:

#+TODO: TOSTART PLANING DOING CHECKING WAITING DOCUMENTING RELEASE


* TOSTART DO SOMETHING

And here is the snippet of my .emacs

;; TODO file:
(defvar todo-file ~/todo.org
  My todo list!)
(setq enable-local-variables :all)
(setq enable-local-eval t)
(find-file todo-file)


Still I don't get the org-mode colors specified on local variables.. If I
put the same sexp on my .emacs it works..

Any ideias?



-- 
*Do or do not. There is no try*
*  **Yoda Master*



-- 
*Do or do not. There is no try*
*  **Yoda Master*


[O] Per file ID

2013-05-24 Thread Klaus-Dieter Bauer
Hello!

I intend to use org-mode for organizing my research notes; I prefer however
a wiki style with many files rather than one big file.

I found that the ID mechanism is quite robust for linking across files, but
most of the time I'd like to link to a file, not a heading in that file, by
ID. Is that possible in org-mode?

As a workaround I'll use toplevel headings instead of the title.

kind regards, Klaus


Re: [O] Fwd: File local variables not being processed

2013-05-24 Thread Nick Dokos
Daniel. danielhi...@gmail.com writes:

 Hi, I have a todo.org file with some local variables, here is the file content

 # Local Variables:
 # eval: (setq org-todo-keyword-faces 
 #  '((TOSTART . red)
 #    (PLANING . yellow)
 #    (DOING . yellow)
 #    (CHECKING . yellow)
 #    (WAITING . green)
 #    (DOCUMENTING . yellow)))
 # End:

 #+TODO: TOSTART PLANING DOING CHECKING WAITING DOCUMENTING RELEASE

 * TOSTART DO SOMETHING

 And here is the snippet of my .emacs

 ;; TODO file:
 (defvar todo-file ~/todo.org
   My todo list!)
 (setq enable-local-variables :all)
 (setq enable-local-eval t)
 (find-file todo-file)

 Still I don't get the org-mode colors specified on local variables.. If I put 
 the same sexp on my .emacs it works.. 


No ideas about what's wrong with your setup (unless you are testing on a
file different from the short one you posted - see below), but it works
fine here.  You can always check whether the setup was effective, using
C-h v org-todo-keyword-faces RET.

One thing that you want to change is to put the local variable section
at the end of the file: emacs starts looking at the end and looks back a
certain distance - 3000 characters by default - and only within the last
page of the file, i.e.  not above a ^L (formfeed) character.

It should still work for a short enough file like the one you posted,
but once you start adding entries, the local variable section will
soon become invisible to emacs.

-- 
Nick




Re: [O] Indentation of code blocks within lists

2013-05-24 Thread Francesco Pizzolante


Hi Nicolas,

 I also cannot reproduce OP's problem. It may be related to
 `org-src-preserve-indentation' value.

Thanks for your answer.

I checked the `org-src-preserve-indentation' variable and saw that it was non
`nil'.

Setting this variable to `nil' fixes the demonstrated issue. But, even then, I
still have an indentation problem.

In the following example (with `org-src-preserve-indentation' set to `nil'):

- in the first headline, I have a code block in a list which is correctly
  exported ignoring the spaces due to the indentation of the Org list;

- in the second headline, I have the same source code but it is split in
  several code blocks in order to better document it. The last 2 blocks are
  not correctly exported as *all spaces before the code* (even those I
  manually added) are ignored.

--8---cut here---start-8---
* First situation

My list:

- Example which works

  #+begin_src emacs-lisp
  (if complex-condition
  then-block
else-block)
  #+end_src

* Second situation

My list:

- Example which does not work anymore

  #+begin_src emacs-lisp
  (if complex-condition
  #+end_src

  The then block does this:

  #+begin_src emacs-lisp
  then-block
  #+end_src

  The else-block does that:

  #+begin_src emacs-lisp
else-block)
  #+end_src
--8---cut here---end---8---

I think that only the spaces due to the Org indentation (here the number of
spaces before the `#' which delimits the source block, hence 2 spaces) should
be ignored.

IOW, just the margin should be removed, and the margin is (IMO) defined as
the spaces from column 0 up to the `#' character.

Thanks for your help.

Regards,
 Francesco





[O] [BUG] org-agenda-open-link does not open bbdb links

2013-05-24 Thread Matt Lundin
The function org-agenda-open-link does not open bbdb links.

The reason is that bbdb agenda lines contain links that are not found in
the entry. 

Because the agenda line is added to the strings scanned by
org-offer-links-in-entry, it is added to the list of links (lk). I.e.,
both buffer and lk are defined, which triggers the first cond statement.
The function then proceeds to search for this link in the buffer. It
does not find it, since a bbdb-anniversary entry typically looks like
this:

* Anniversaries
  :PROPERTIES:
  :CATEGORY: anniv
  :END:
%%(org-bbdb-anniversaries)

But as a result, the function org-offer-links-in-entry never gets to the
second cond statement, which would indeed open the link found in the
agenda buffer.

It seems to me that feeding the agenda line as a prefix to
org-offer-links-in-entry is redundant, since the second cond statement
explicitly looks for links in the agenda line.

The following change fixes the problem, but before I submit it as a
properly formatted patch, I want to make sure that it does not interfere
with some other functionality.

Best,
Matt

--8---cut here---start-8---
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index c615b58..1cc1c28 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -8449,8 +8449,7 @@ It also looks at the text of the entry itself.
   (let* ((marker (or (org-get-at-bol 'org-hd-marker)
 (org-get-at-bol 'org-marker)))
 (buffer (and marker (marker-buffer marker)))
-(prefix (buffer-substring (point-at-bol) (point-at-eol)))
-(lkall (org-offer-links-in-entry buffer marker arg prefix))
+(lkall (org-offer-links-in-entry buffer marker arg))
 (lk0 (car lkall))
 (lk (if (stringp lk0) (list lk0) lk0))
 (lkend (cdr lkall))
--8---cut here---end---8---



Re: [O] [NEW FEATURE] org-hlc.el - hidden-lines-cookies (hlc) for Org-mode

2013-05-24 Thread François Pinard
Thorsten Jolitz tjol...@gmail.com writes:

 it happened again [...]- François Pinard already had a fully fledged
 implementation of my new org-mode feature: 'org-weights.el'

You're quite generous when you say full fledged :-).  There are many
details in which I find org-weights.el unsatisfactory, but as it is
sufficient as it stands for my day-to-day usage, I'm not overly pushing
on it (the pun is purely accidental).

 | * Header 1   *2 + 1...

 | ## * Header 1   [#1]

I find the *2 + 1 far too verbose, in that it uses too much horizontal
space, I much prefer the compact aspect of [#1].  What would be ideal,
but I do not know if it can be organized, would keep the weights or
hidden-lines information always glued to the ellipsis, and not hiding
any underlying text as org-weights currently does.  On the other hand,
there are some virtue to the vertical alignment of weight information.
Sigh!  Nothing is perfect...

 [...] shows the overlay-info for *all* headlines except the one where
 point is on.

That exception is a sad and questionable workaround, for being able to
edit the current line.  When, in normal and standard Org mode, I edit a
line which has an ellipsis at the end, I may edit the line like any
other one without seeing undesired effects.  org-weights should be
equally capable, and there should be no reason (ideally) to hide the
information for the line where the point is, merely for editing to work.

 one problem I hit is that a visibility change does not uptdate all
 cookies/weights at once, they are only updated headline per headline
 when point is moved up and down.  Is that for performance reasons?

See the Caveats section at the end of org-weights documentation.
Normally, the information to be updated may be minimized to the header
above the line holding point, and then, recursively up.  But there is a
bug in this optimization when a header is demoted (as explained in
Caveats).  Another performance-related detail is the quadratic behaviour
which may be seen in big, deeply nested Org files: it could be avoided
by cleverly saving (in a hidden way) information on computations already
done, and reusing it instead of recomputing it many times.  But as usual
with most cached optimization, it is difficult to get fully right.

François



Re: [O] Org-mode styled beamer presentations

2013-05-24 Thread Marcin Borkowski
Dnia 2013-05-24, o godz. 11:41:49
Eric S Fraga e.fr...@ucl.ac.uk napisał(a):

 Eric S Fraga e.fr...@ucl.ac.uk writes:
 
  Marcin Borkowski mb...@wmi.amu.edu.pl writes:
 
  shameless plug
 
  Hi list,
 
  many of you use Org-mode to create Beamer presentations.  How
  about the other way round?  I wrote an Org-mode styled Beamer
  theme.  Please use, enjoy and report bugs and feature requests!
 
  https://twitter.com/marcin_mbork/status/335890494980767746
  http://mbork.pl/2013-05-18_A_presentation_on_LaTeX_editing_%28en%29
  https://github.com/mbork/beamerorgtheme
 
  /shameless plug
 
  Best,
 
  Very cute!  I like it.

Thanks!

  Now I just need to customise it so that it matches my usual colour
  theme in Emacs which has a black background!  Ahh, a perfect excuse
  to not get any more work done today ;-)
 
  thanks,
  eric
 
 Well, that was too easy... see attached for a slightly different
 version of your colour theme which gives black background with
 yellowish-white foreground and red highlighting...

Yep, modifying beamer color themes is usually rather easy: often you
just give a few basic (as in basis of a linear space) colors and the
rest are just linear (or even convex) combinations of those.

 I guess I have to get back to work now! ;-)
 
 In fact, I have a talk to prepare for next week.  I think I'll use
 this style!  The audience should be sufficiently geeky to appreciate
 it for once.

Great!  My audience was also quite geeky; in fact, one colleague asked
me for the source of this theme, so that he could learn to make a Vim
Beamer theme;)...

 Thanks again,
 eric

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University



Re: [O] Updated syntax for #+bind and no LaTeX \maketitle command?

2013-05-24 Thread John Hendy
On Fri, May 24, 2013 at 1:36 AM, Nick Dokos ndo...@gmail.com wrote:
 Nick Dokos ndo...@gmail.com writes:

 #+bind: org-latex-title-command 

 This is still generating a \maketitle line in my .tex file.

 What's the proper way to do this on Org 8.0?



 I suspect this is the same problem as the one discussed in the following:

http://thread.gmane.org/gmane.emacs.orgmode/72085

 Nicolas suggested using a file local variable for that problem and I've
 verified that that solution also works for this one. Just add

 # Local Variables:
 # org-latex-title-command: 
 # End:

 at the end of your file.

 No, I'm wrong: it's not the same problem. And using BIND should
 work in this case, assuming that it is allowed.

 Check the value of org-export-allow-bind-keywords. If nil, then
 BIND keywords seem to be ignored silently.

Thanks all! Not knowing about the org-export-allow-bind-keywords was
my issue, and setting it to =t= fixed it. Out of curiosity, what's the
difference between org-export-allow-BIND and
org-export-allow-bind-keywords? They M-x help on them sounds very
similar.

#+begin_help org-export-allow-bind-keywords
Documentation:
Non-nil means BIND keywords can define local variable values.
This is a potential security risk, which is why the default value
is nil.  You can also allow them through local buffer variables.
#+end_help

#+begin_help org-export-allow-BIND
Documentation:
Non-nil means allow #+BIND to define local variable values for export.
This is a potential security risk, which is why the user must confirm the
use of these lines.
#+end_help

Ah, nevermind. Based on the customize-variable menu option, I'm
thinking the latter is how org should automatically accept #+bind
settings, and the former is whether to allow #+bind settings at all.
Oddly, my value for org-export-allow-bind is set to confirm but I
just tested things and didn't get asked...



John


 --
 Nick





Re: [O] org-element

2013-05-24 Thread Daimrod
Nicolas Goaziou n.goaz...@gmail.com writes:

 Hello,

Hello Nicolas,

 Daimrod daim...@gmail.com writes:

 I'm playing a bit with org-element for org-contacts and I wanted to know
 what is the prefered way to change an element.

 For example, ATM, when I want to change an element property to add a new
 value, I do:

 #+BEGIN_SRC emacs-lisp
   (org-entry-put nil property
  (concat (org-entry-get nil property)
new-value))
 #+END_SRC

 See `org-element-put-property' and friends.

I've tried to use `org-element-put-property' but it only modifies the
object in memory, not the element in the file. Is there a way to write
the object into a file?

 Regards,

-- 
Daimrod/Greg


pgpx5qxLaG4B3.pgp
Description: PGP signature


[O] Error with \usepackage{amsmath} due to \iint already being defined

2013-05-24 Thread John Hendy
I tracked down an error about \iint already being defined to a clash
between wasysym and amsmath. I brought in amsmath, but it appears that
wasysym is an Org LaTeX export default package.

What is it's purpose? Is there a better way round this than just
commenting out the wasysym package in the .tex file manually?

I forget exactly what I use from amsmath, but I do use it a reasonable
amount through my documents so I keep #+latex_header:
\usepackage{amsmath} in my setupfile.

This doesn't appear to be a major problem with respect to export, but
it does trigger [LaTeX error] in the minibuffer, so I have to check to
see if it was something to care about or not.


John



[O] LaTeX appears not to like default Org tag export format (\hfill)?

2013-05-24 Thread John Hendy
I'm getting errors on tag export:

Package hyperref Warning: Token not allowed in a PDF string (PDFDocEncoding):
(hyperref)removing `\hfill' on input line 1706.

The tags get converted to this:

\subsection{Headline title\hfill{}\textsc{tag}}

It looks like LaTeX doesn't like that.

Any suggestions?


John



Re: [O] Error with \usepackage{amsmath} due to \iint already being defined

2013-05-24 Thread Vincent Beffara

Hi,

 I tracked down an error about \iint already being defined to a clash
 between wasysym and amsmath. I brought in amsmath, but it appears that
 wasysym is an Org LaTeX export default package.

Just put this in the LaTeX header before you load amsmath:

\usepackage{savesym}
\savesymbol{iint}
\savesymbol{iiint}

HTH,
/v

-- 
Vincent Beffara




Re: [O] Status fix for Regression in fill-paragraph behavior?

2013-05-24 Thread Samuel Wales
On 5/24/13, Wagemans, Peter peter.wagem...@kpn.com wrote:
 In org 7.8.11 with emacs 24.2 fill-paragraph used to recognize
 paragraph fill prefixes as usual for mail citations. This seems to be
 no longer the case (which I noticed first with org 7.9.3 with emacs
 24.3). Apparently this has been noticed before and a bug reported,
 according to

filladapt.el works.

Samuel

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

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



Re: [O] Bad formatting in documentation

2013-05-24 Thread Bastien
Hi Alexis,

Alexis Praga alexis.pr...@gmail.com writes:

 I just stumbled upon a bad formatting on the website (
 http://orgmode.org/worg/org-faq.html ).
 In Why doesn't C-c a call the agenda? Why don't some org keybindings
 work?, we can see

 #+BEGIN_SRC emacs-lisp ;; The following lines are always needed. Choose
 your own keys. (add-to-list 'auto-mode-alist '(\\.org\\' . org-mode))
 (global-set-key \C-cl 'org-store-link) (global-set-key \C-ca
 'org-agenda) (global-set-key \C-cb 'org-iswitchb) #+END_SRC
 emacs-lisp

Fixed, thanks.

-- 
 Bastien



Re: [O] Org sources and PDF files on Worg

2013-05-24 Thread Bastien
Hi Rasmus,

Rasmus ras...@gmx.us writes:

 Couldn't we just compare input and output?  Or is that not safe
 enough?  E.g. in an over-simplistic form obtain dead pages via
 something like this:

If you can write a general function that will work for any defined
publishing project, that'd be cool.  Maybe as an addition for
worg/org-hacks.org.

-- 
 Bastien



Re: [O] Per file ID

2013-05-24 Thread Bastien
Hi Klaus-Dieter,

Klaus-Dieter Bauer bauer.klaus.die...@gmail.com writes:

 I found that the ID mechanism is quite robust for linking across
 files, but most of the time I'd like to link to a file, not a heading
 in that file, by ID. Is that possible in org-mode?

Well, no, sorry!

-- 
 Bastien



Re: [O] Error with \usepackage{amsmath} due to \iint already being defined

2013-05-24 Thread John Hendy
On Fri, May 24, 2013 at 12:22 PM, Vincent Beffara vbeff...@ens-lyon.fr wrote:

 Hi,

 I tracked down an error about \iint already being defined to a clash
 between wasysym and amsmath. I brought in amsmath, but it appears that
 wasysym is an Org LaTeX export default package.

 Just put this in the LaTeX header before you load amsmath:

 \usepackage{savesym}
 \savesymbol{iint}
 \savesymbol{iiint}


Does this savewasysym's definition if iint instead of amsmath's? In
the case that I actually use \iint (super unlikely, but not
impossible), which package's is preferred?


Thanks,
John

 HTH,
 /v

 --
 Vincent Beffara





Re: [O] Rendering of source code on worg

2013-05-24 Thread Bastien
Hi Guido,

Guido Van Hoecke gui...@gmail.com writes:

 I think that the default rendering of source code on the worg side was
 closely resmbling the default rendering on emacs.

 I have the impression that somehow this is no longer the case, as
 visible a.o. at
 http://orgmode.org/worg/org-configs/org-config-examples.html

 Is this a deliberate choice?

The .emacs.el on orgmode.org contains:

  (set-face-foreground 'font-lock-keyword-face DeepSkyBlue1)
  (set-face-foreground 'font-lock-string-face Goldenrod)

This is used when publishing Worg files on the server.

If you can find better colors, please submit some.

Thanks,

-- 
 Bastien



Re: [O] [NEW FEATURE] org-hlc.el - hidden-lines-cookies (hlc) for Org-mode

2013-05-24 Thread Thorsten Jolitz
François Pinard pin...@iro.umontreal.ca writes:

Hi Francios, 

 You're quite generous when you say full fledged :-).  There are many
 details in which I find org-weights.el unsatisfactory, but as it is
 sufficient as it stands for my day-to-day usage, I'm not overly pushing
 on it (the pun is purely accidental).

 | * Header 1   *2 + 1...

 | ## * Header 1   [#1]

 I find the *2 + 1 far too verbose, in that it uses too much horizontal
 space, I much prefer the compact aspect of [#1].  

The weights are a bit heavy, and I had to move them to column 65 to make
them fit in a vertically splitted screen. But they carry more
information of course, the question is if one can process this
information quickly enough, or if one single number is not enough to
give an impression of the subtrees 'weight'. Or maybe 

,--
| * Header 1   [2/1]...
`--

is easier on the eyes than 

,---
| * Header 1   *2 + 1...
`---

 What would be ideal, but I do not know if it can be organized, would
 keep the weights or hidden-lines information always glued to the
 ellipsis, and not hiding any underlying text as org-weights currently
 does. On the other hand, there are some virtue to the vertical
 alignment of weight information. Sigh! Nothing is perfect...

It would be easy to make the position of the weight/cookie a user option
- either direcctly behind the headline text, or aligned at a certain
column. 

 [...] shows the overlay-info for *all* headlines except the one where
 point is on.

 That exception is a sad and questionable workaround, for being able to
 edit the current line.  When, in normal and standard Org mode, I edit a
 line which has an ellipsis at the end, I may edit the line like any
 other one without seeing undesired effects.  org-weights should be
 equally capable, and there should be no reason (ideally) to hide the
 information for the line where the point is, merely for editing to work.

I would still like to have my original idea (which was actually a user
request for outshine.el by Jonas Bernoulli): show the number of hidden
lines only when the headline is folded, and update with every visibility
change.

 one problem I hit is that a visibility change does not uptdate all
 cookies/weights at once, they are only updated headline per headline
 when point is moved up and down.  Is that for performance reasons?

 See the Caveats section at the end of org-weights documentation.
 Normally, the information to be updated may be minimized to the header
 above the line holding point, and then, recursively up.  But there is a
 bug in this optimization when a header is demoted (as explained in
 Caveats).  Another performance-related detail is the quadratic behaviour
 which may be seen in big, deeply nested Org files: it could be avoided
 by cleverly saving (in a hidden way) information on computations already
 done, and reusing it instead of recomputing it many times.  But as usual
 with most cached optimization, it is difficult to get fully right.

This task seems to bring Emacs to its limits, at least in 5000+ lines
outshine buffers (e.g. my init.el). 

So maybe its not that suited for a visibility-change hook, but rather
for occasional activation by an explicit user command?

-- 
cheers,
Thorsten




Re: [O] Rendering of source code on worg

2013-05-24 Thread Guido Van Hoecke
Hi Bastien,

Bastien b...@gnu.org writes:

 Hi Guido,

 Guido Van Hoecke gui...@gmail.com writes:

 I think that the default rendering of source code on the worg side was
 closely resmbling the default rendering on emacs.

 I have the impression that somehow this is no longer the case, as
 visible a.o. at
 http://orgmode.org/worg/org-configs/org-config-examples.html

 Is this a deliberate choice?

 The .emacs.el on orgmode.org contains:

   (set-face-foreground 'font-lock-keyword-face DeepSkyBlue1)
   (set-face-foreground 'font-lock-string-face Goldenrod)

 This is used when publishing Worg files on the server.

 If you can find better colors, please submit some.

I never intended to comment nor judge the specific colors used.

I was under the impression that the elisp fragments on the website used
to have exactly the same font and faces as in stock emacs elisp
buffers. Apparently this is not the case, and I still don't know where I
got that wrong idea.

Anyhow, sorry for the noise,


Guido

--
The problems of business administration in general, and database management in
particular are much too difficult for people that think in IBMese, compounded
with sloppy English.
-- Edsger W. Dijkstra



[O] [PATCH] org-mouse: Fix incorrect replacement for checkbox lists

2013-05-24 Thread Ilya Zonov
Hi,

I have prepared patch which fixes incorrect replacement with org-mouse
popup function for checkbox lists: All Set and All Clear. Please, check
it. See attachment.

-- 
*Илья Зонов* (*Ilya Zonov*) aka *puzan*
Нижний Новгород, Россия (Nizhny Novgorod, Russia)


0001-org-mouse-Fix-incorrect-replacement-for-checkbox-lis.patch
Description: Binary data


Re: [O] org-element

2013-05-24 Thread Nicolas Goaziou
Daimrod daim...@gmail.com writes:

 Nicolas Goaziou n.goaz...@gmail.com writes:

 See `org-element-put-property' and friends.

 I've tried to use `org-element-put-property' but it only modifies the
 object in memory, not the element in the file. Is there a way to write
 the object into a file?

I misread your question.

org-element.el doesn't provide functions to modify the buffer, but you
may use `org-element-interpret-data' to create Org syntax from an
object.

You may also want to have a look at org-sync.el.


Regards,

-- 
Nicolas Goaziou



Re: [O] Error with \usepackage{amsmath} due to \iint already being defined

2013-05-24 Thread Marcin Borkowski
Dnia 2013-05-24, o godz. 12:35:59
John Hendy jw.he...@gmail.com napisał(a):

 On Fri, May 24, 2013 at 12:22 PM, Vincent Beffara
 vbeff...@ens-lyon.fr wrote:
 
  Hi,
 
  I tracked down an error about \iint already being defined to a
  clash between wasysym and amsmath. I brought in amsmath, but it
  appears that wasysym is an Org LaTeX export default package.
 
  Just put this in the LaTeX header before you load amsmath:
 
  \usepackage{savesym}
  \savesymbol{iint}
  \savesymbol{iiint}
 
 
 Does this savewasysym's definition if iint instead of amsmath's? In
 the case that I actually use \iint (super unlikely, but not
 impossible), which package's is preferred?

See http://www.ctan.org/pkg/savesym - it saves wasysym's \iint
as\origiint.  (BTW: nice package this savesym: not complicated, but
handy.  Thanks for the pointer, Vincent!)

And you can always use a poor man's savesym, that is,
\let\iint\relax

 Thanks,
 John

Regards,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University



Re: [O] LaTeX appears not to like default Org tag export format (\hfill)?

2013-05-24 Thread Marcin Borkowski
Dnia 2013-05-24, o godz. 12:07:55
John Hendy jw.he...@gmail.com napisał(a):

 I'm getting errors on tag export:
 
 Package hyperref Warning: Token not allowed in a PDF string
 (PDFDocEncoding): (hyperref)removing `\hfill' on
 input line 1706.
 
 The tags get converted to this:
 
 \subsection{Headline title\hfill{}\textsc{tag}}
 
 It looks like LaTeX doesn't like that.
 
 Any suggestions?

First: I can't resist telling a joke.

A guy is standing on the corner of the street smoking one cigarette
after another. A lady walking by notices him and says Hey, don't you
know that those things can kill you? I mean, didn't you see the giant
warning on the box?! That's OK says the guy, puffing casually I'm a
computer programmer So? What's that got to do with anything? We
don't care about warnings. We only care about errors.

Now, to the point: indeed, this is only a warning and you don't have to
worry about it.  If you really do not like this warning, try putting
this into your preamble (untested, but should work):

\pdfstringdefDisableCommands{\def\hfill{ }}

Explanation: it is not LaTeX which dislikes \hfill (though it's a
plain TeX macro, not a LaTeX one), but hyperref.  More precisely, the
argument to \section lands not only in the ToC, but also in the pdf
bookmarks, and what can go there is seemingly quite restricted (I
don't know/care much about the exact details, frankly speaking).  The
above spell tells hyperref to (temporarily) change \hfill to a space in
that context. (See hyperref's docs and/or source for more info.)

 John

HTH,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University



Re: [O] Error with \usepackage{amsmath} due to \iint already being defined

2013-05-24 Thread Nick Dokos
John Hendy jw.he...@gmail.com writes:

 On Fri, May 24, 2013 at 12:22 PM, Vincent Beffara vbeff...@ens-lyon.fr 
 wrote:

 Hi,

 I tracked down an error about \iint already being defined to a clash
 between wasysym and amsmath. I brought in amsmath, but it appears that
 wasysym is an Org LaTeX export default package.

 Just put this in the LaTeX header before you load amsmath:

 \usepackage{savesym}
 \savesymbol{iint}
 \savesymbol{iiint}


 Does this savewasysym's definition if iint instead of amsmath's? In
 the case that I actually use \iint (super unlikely, but not
 impossible), which package's is preferred?


The wasysym docs say that there should be no conflict, but that seems
to be wrong: ISTR multiple instances of this conflict.

If you prefer the amsmath integral signs over the wasysym ones, then
probably the best thing to do is to load wasysym with the
``nointegrals'' option:

   \usepackage[nointegrals]{wasysym}

This can be done permanently by customizing
org-latex-default-packages-alist and adding the option to the wasysym
entry.

-- 
Nick




Re: [O] LaTeX appears not to like default Org tag export format (\hfill)?

2013-05-24 Thread Nick Dokos
John Hendy jw.he...@gmail.com writes:

 I'm getting errors on tag export:

 Package hyperref Warning: Token not allowed in a PDF string (PDFDocEncoding):
 (hyperref)removing `\hfill' on input line 1706.

 The tags get converted to this:

 \subsection{Headline title\hfill{}\textsc{tag}}

 It looks like LaTeX doesn't like that.

LaTeX has no problem with it: it's hyperref that does not like it. 

 Any suggestions?


It's a warning, not an error, so unless it causes a real problem,
I'd ignore it.

Nick




Re: [O] Error with \usepackage{amsmath} due to \iint already being defined

2013-05-24 Thread Marcin Borkowski
Dnia 2013-05-24, o godz. 14:38:42
Nick Dokos ndo...@gmail.com napisał(a):

 John Hendy jw.he...@gmail.com writes:
 
  On Fri, May 24, 2013 at 12:22 PM, Vincent Beffara
  vbeff...@ens-lyon.fr wrote:
 
  Hi,
 
  I tracked down an error about \iint already being defined to a
  clash between wasysym and amsmath. I brought in amsmath, but it
  appears that wasysym is an Org LaTeX export default package.
 
  Just put this in the LaTeX header before you load amsmath:
 
  \usepackage{savesym}
  \savesymbol{iint}
  \savesymbol{iiint}
 
 
  Does this savewasysym's definition if iint instead of amsmath's? In
  the case that I actually use \iint (super unlikely, but not
  impossible), which package's is preferred?
 
 
 The wasysym docs say that there should be no conflict, but that seems
 to be wrong: ISTR multiple instances of this conflict.
 
 If you prefer the amsmath integral signs over the wasysym ones, then
 probably the best thing to do is to load wasysym with the
 ``nointegrals'' option:
 
\usepackage[nointegrals]{wasysym}
 
 This can be done permanently by customizing
 org-latex-default-packages-alist and adding the option to the wasysym
 entry.

Nick: good to know about org-latex-default-packages-alist!

Carsten/Bastien (I forward to both of you, since I don't know who is
to gitblame for that:P): looking at its docstring, I guess there are
two minor bugs here: first, it is not technically an alist, but a
normal list, second, apparently the docstring doesn't mention that an
element of this list might be a string (inserted then verbatim into
preamble) and not a list.

Also, taking into account the number of problems with wasysym's
conflicts, I'd suggest dropping it (and maybe several other packages)
from it.

Further, this seems to be a bit of work - I can't promise
anything /now/ - but I'll try to look into it and check which package
is needed for which entity; loading a big package for a few commands
might be an overkill.  Would it be possible for the LaTeX exporter to
include some packages only if they are really needed, i.e., if some
entity is actually used in the document?  This would both speed up
compilation time and (maybe more importantly) reduce the risk of such
conflicts. (Not to mention the inelegance of a large preamble
consisting of loading unnecessary packages - as a person responsible
for converting LaTeX files sent to a journal by people into something
usable/compilable/good-looking, I can say that one of the first things
I usually do is to delete /all \usepackage's/ from the preamble, and
see if it compiles correctly.  In more than 50% cases, it does...

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University



Re: [O] Status fix for Regression in fill-paragraph behavior?

2013-05-24 Thread Wagemans, Peter

Nicolas Goaziou wrote:

 Then try editing your text in a block like:
 
   #+BEGIN_SRC message
...
   #+END_SRC

Or with fundamental or text mode. Possible but more cumbersome. Normal
text paragraph fill used to just work.

 I wouldn't call it a regression since this behaviour never was defined
 as a feature in the first place.

Maybe it wasn't defined, but it used to work up to 7.8.11 (at least).
For me it is very useful and often used functionality and even
fundamental and text mode offer it. So why break that? Could org-mode
perhaps delegate text paragraph fill to the functions used by those
modes (from Emacs fill.el I presume), so that the standard Emacs
Adaptive Fill functionality remains available?

Regards,

Peter Wagemans




Re: [O] Error with \usepackage{amsmath} due to \iint already being defined

2013-05-24 Thread Nicolas Goaziou
Hello,

Marcin Borkowski mb...@wmi.amu.edu.pl writes:

 Also, taking into account the number of problems with wasysym's
 conflicts, I'd suggest dropping it (and maybe several other packages)
 from it.

That would break, among other things, previewing of LaTeX snippets. On
the other hand, it's probably safe to remove longtable package since
we don't provide other table packages supported by the latex export
back-end.

Also, we may pass the nointegrals option by default to wasysym.

 Further, this seems to be a bit of work - I can't promise
 anything /now/ - but I'll try to look into it and check which package
 is needed for which entity; loading a big package for a few commands
 might be an overkill.

IIRC it has been done already. The document is somewhere in Worg.

 Would it be possible for the LaTeX exporter to include some packages
 only if they are really needed, i.e., if some entity is actually used
 in the document? This would both speed up compilation time and (maybe
 more importantly) reduce the risk of such conflicts. (Not to mention
 the inelegance of a large preamble consisting of loading unnecessary
 packages - as a person responsible for converting LaTeX files sent to
 a journal by people into something usable/compilable/good-looking,
 I can say that one of the first things I usually do is to delete /all
 \usepackage's/ from the preamble, and see if it compiles correctly. In
 more than 50% cases, it does...

It has been suggested on this list already. Aaron Ecay even provided
a patch. I think this is calling for problems as it cannot be totally
reliable (and the time necessary to do this would probably defeat the
compilation gain).

On the other hand, you can define your own optimized preamble with
`org-latex-classes' while the default setup still provides a (somewhat)
smooth experience for the casual LaTeX user.


Regards,

-- 
Nicolas Goaziou



Re: [O] Status fix for Regression in fill-paragraph behavior?

2013-05-24 Thread Nicolas Goaziou
Wagemans, Peter peter.wagem...@kpn.com writes:

 Nicolas Goaziou wrote:

 Then try editing your text in a block like:
 
   #+BEGIN_SRC message
...
   #+END_SRC

 Or with fundamental or text mode. Possible but more cumbersome. Normal
 text paragraph fill used to just work.

No, it didn't just work. It mixed Org keywords, ignored line breaks...
which are part of Org syntax, unlike to mail citation markup. Fixing it
broke a side-effect you used. I understand this is annoying, but it is
all about priority.

 Maybe it wasn't defined, but it used to work up to 7.8.11 (at least).
 For me it is very useful and often used functionality and even
 fundamental and text mode offer it.

And rst mode doesn't. Some major modes have such a feature, some others
don't.

Also, you have to admit that Org is a bit more complex than Text mode
(or Fundamental mode), and may have different requirements.

 Could org-mode perhaps delegate text paragraph fill to the functions
 used by those modes (from Emacs fill.el I presume), so that the
 standard Emacs Adaptive Fill functionality remains available?

Again, what you call standard Adaptive Fill is not standard, since it
depends on the major mode.

I think external packages (filladapt.el?) might provide the
functionality you're after, assuming you configure them to play nicely
with Org.


Regards,

-- 
Nicolas Goaziou



Re: [O] Importing all files into .org document source blocks

2013-05-24 Thread Myles English

Hi Rainer,

Rainer M. Krug writes:
 Is there a way of importing all files in a directory
 (/etc/apt/sources/list.d/) into an org document, with each being in a
 separate code block?

Maybe this?:

for i in `find . -maxdepth 1 -type f`; do
 echo #+BEGIN_SRC :tangle /this/dir/${i}  afile.org
 cat ${i}  afile.org
 echo #+END_SRC\n  afile.org
done

(this kind of reply is becoming a theme of mine)

Myles




Re: [O] Indentation of code blocks within lists

2013-05-24 Thread Sebastien Vauban
Hello Nicolas,

Nicolas Goaziou wrote:
 Sebastien Vauban sva-n...@mygooglest.com writes:

 That won't help you, but I've already sent questions on this problem, last
 year (Org  8). See my post on
 http://lists.gnu.org/archive/html/emacs-orgmode/2012-02/msg00247.html.

 Though, it's (for me) still unfixed as of today.

 The good news is that Nicolas seemed OK to look at it, and find a solution 
 for
 it...

 AFAICS, your problem was solved. Could you point to what is still wrong?

 I also cannot reproduce OP's problem. It may be related to
 `org-src-preserve-indentation' value.

Indeed. I have as well `org-src-preserve-indentation' set to `t', for the same
reason as pointed out: if I don't use it that way, then my code blocks which
have different relative depths are exported (in HTML) on the same level, as if
there was no indentation to respect.

So, yes, it does work if you don't need to preserve indentation, you're well
right. But, if not, the indentation is lost on export (and on source editing
with C-c ').

Best regards,
  Seb

-- 
Sebastien Vauban




Re: [O] Updated syntax for #+bind and no LaTeX \maketitle command?

2013-05-24 Thread Sebastien Vauban
Hi John,

John Hendy wrote:
 On Fri, May 24, 2013 at 1:36 AM, Nick Dokos ndo...@gmail.com wrote:
 Check the value of org-export-allow-bind-keywords. If nil, then
 BIND keywords seem to be ignored silently.

 Thanks all! Not knowing about the org-export-allow-bind-keywords was
 my issue, and setting it to =t= fixed it. Out of curiosity, what's the
 difference between org-export-allow-BIND and
 org-export-allow-bind-keywords? They M-x help on them sounds very
 similar.

One is used in Org  8, the other in Org 8 and future versions.

Best regards,
  Seb

-- 
Sebastien Vauban




[O] [OT] Gnus mail tutorial?

2013-05-24 Thread Marcin Borkowski
Hi list,

sorry for an off-topic question, but I'm sure someone here will be
able to help me with this: I'm thinking about using Emacs as my email
client, and I'm considering using Gnus for that.  The Gnus manual is a
bit intimidating; is there any newbie-friendly tutorial which might help
get me started, taking into account that I do /not/ want to use Gmail,
but another (IMAP-aware) mail service?

Regards,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University



Re: [O] [OT] Gnus mail tutorial?

2013-05-24 Thread John Hendy
On May 24, 2013 6:01 PM, Marcin Borkowski mb...@wmi.amu.edu.pl wrote:

 Hi list,

 sorry for an off-topic question, but I'm sure someone here will be
 able to help me with this: I'm thinking about using Emacs as my email
 client, and I'm considering using Gnus for that.  The Gnus manual is a
 bit intimidating; is there any newbie-friendly tutorial which might help
 get me started, taking into account that I do /not/ want to use Gmail,
 but another (IMAP-aware) mail service?


Seconded. I tried following the tutorials that *do* exist once and just
gave up. Something tried and known to work and be complete would be
awesome. and I know there's a lot of gnus users on the list :)

John

 Regards,

 --
 Marcin Borkowski
 http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
 Adam Mickiewicz University



Re: [O] [PATCH] ox-koma-letter.el: Reintroduce variables removed in commit 832c6fd with proper defaults (was Re: [patch] ox-koma-letter.el: clean-up/semantic bug [4/4])

2013-05-24 Thread Robert Klein
Hi,

FWIW, from a users view it would be nice if:

- Use Author/Email information from org file
- If not present use information from LCO file
- if neither org file nor LCO file has any information use
  user-full-name and user-email-address

Could this be solved by having several e.g. `setkomavar{fromname}'
and so on in the tex file, so is created as follows:


if no #+AUTHOR in org-file and user-full-name is set:
add user-full-name
if #+LCO(s) in org-file:
add LCO file(s)
if #+AUTHOR in org-file:
add \setkomavar{fromname}{#+AUTHOR}
  same for email
add \setkomavar{signature}{\usekomavar{fromname}}


so the result tex file may have:


\setkomavar{fromname}{Hans Wurst}
\setkomavar{fromemail}{hans_wu...@example.com}
...
\setkomavar{fromname}{Reiner Zufall}
\setkomavar{fromemail}{reiner_zuf...@example.com}
\setkomavar{signature}{\usekomavar{fromname}}


This probably isn't a `clean' solution, but should work without a need
to grep LCO files.

Best regards
Robert


On 05/23/2013 12:06 AM, Viktor Rosenfeld wrote:
 Hi Rasmus,
 
 Viktor Rosenfeld wrote:
 
 Hi Rasmus,

 Rasmus wrote:

 Viktor Rosenfeld listuse...@gmail.com writes:

 Or 5, keep the change from SENDER to AUTHOR but revert the default
 values to `org-koma-letter-*' variables. (Right now the AUTHOR and EMAIL
 lines could be removed because they duplicate the derived latex
 backend.)

 I once had a teacher who talked about the optimal degree of
 conservatism (as well speaking positively about being in the infamoues
 ivory tower).  5. is fine with me.  So I guess the deal is
   1. default value is the same as in ox-latex.
   2. . . . but it's kept in a seperete variable ox-kl variable.

 I think that switching from SENDER to AUTHOR, keeping the
 `org-koma-letter-{author,email}' variables in the KOMA backend, but
 setting them per default to `user-full-name' and `user-mail-address',
 would solve both your problems and let me keep LCO files. I would then
 simply set these `org-koma-letter-*' variables to `nil' and document
 this setup in the docstring. I'll see tomorrow if this is feasable.

 Does the attached patch work for you (also with ps tags?)

 It works, but I noticed the following problem: According to the Emacs
 documentation `user-mail-address' is only set by Emacs after the
 initialization process has completed and if it is not explicitly set
 during initialization [1]. So, the defcustom of org-koma-letter-email
 does not work as expected if the user has not set `user-mail-address'
 before. Instead it is set to the empty string, which according to the
 code setting `user-mail-address' means not set yet.

 This can be taking care of by using `after-init-hook' as in the example
 below. It has the added advantage that the value of `user-mail-address'
 will be picked up regardless of whether it is set before or after
 require'ing ox-koma-letter. 

 Note that this creates a slight inconsistency with regard to
 `user-full-name' which is only picked up correctly if it is set before
 require'ing ox-koma-letter. I've fixed this by a slightly complicated
 defcustom definition of `org-koma-letter-author' and another
 after-init-hook.

 I've also changed the docstring to indicate what are the default values
 and added the :group and :type flags again.
 
 I've put my changes into a patch against the current master (commit
 06cdb2d2). Could you check it with your setup?
 
 Cheers,
 Viktor