Re: [O] :noweb header argument

2012-01-11 Thread Sebastien Vauban
Hi Thomas, Eric(s) and all,

Thomas S. Dye wrote:
 Eric Schulte eric.schu...@gmx.com writes:
 t...@tsdye.com (Thomas S. Dye) writes:
 Sebastien Vauban wxhgmqzgw...@spammotel.com writes:
 Thomas S. Dye wrote:

 | tangle | -| +  | -  |
 |+--++|
 | need   | +| +  | -  |

 What should the name for such an option be?

 Andreas' suggestion, :noweb no-export, seems right to me.

Or all-but-export which would show that there is expansion going on in all
modes but for export?

Anyway, I don't really care, as long as it's rather intuitive and well
documented. And I'm sure both will be true very soon.

 I think it might be good to have a parameter that expands noweb
 references on evaluation and tangling, but leaves them alone during
 export. This way the code block would be fully functional, but wouldn't
 duplicate code during export (when the noweb references are to other
 code blocks in the same document).

 I'd find that interesting as well, but then the names of the code blocks
 must be visible again (in HTML and PDF exports), something that has
 disappeared over time.

 Alternatively for LaTeX, some way to wrap exported code blocks in
 a \begin{listing} ... \end{listing} environment, complete with caption and
 label. This way the code block name could appear in the caption, and with
 \listoflistings, in the document frontmatter as well.

Thanks for your sample. It shows we really lack key features to be as good in
HTML as Org is in LaTeX:

- bibliography
- acronyms
- listing of images, code, etc.

 As I recall this was originally implemented and then later removed because
 it was causing more confusion and problems than it was worth. I hope it
 hasn't crossed the line of existence more than once. At some point it
 should be placed behind a user-customizable variable, preferably something
 like `org-babel-export-code-format' which defaults to something like
 %code but could be augmented to something like Block Name: *%name*\n
 %code. It is not immediately clear if such a variable should have
 different values for different export backends or (likely preferable)
 should expand into Org-mode text *before* export.

 I think you're right about getting this done early in the process. I've been
 thinking only about LaTeX export because that is my immediate goal--not a
 good design perspective.

 Perhaps I could help by specifying what I'm trying to do? I'd like to write
 an article or book about particular statistical analyses. I want this also
 to be a piece of reproducible research so readers of the book can follow
 along and perhaps analyze data of their own. I'd like to write a code block
 once and then use it in the following ways: 1) evaluate and return the
 results of analyses; 2) export as a floating listing so I can refer to it in
 discussions of implementation; and 3) tangle to a source code file that can
 be used as the basis for a package that can be used outside of Org mode.

 1) is easy with #+call: With the :wrap header argument that we've
 partially implemented, I can mark the results off in whatever environment I
 like, which is a wonderful bit of flexibility. Different kinds of results
 can be presented distinctively.

 2) is partially there--the code itself is handled nicely by minted and
 I'm able to make it look as good as I want. What I'm lacking now is an easy
 way to identify the code block. Seb's suggestion that the header lines be
 included is one way, though Eric F.'s point about the special characters
 tripping up LaTeX is well taken. It might be some work to get an
 intermediate representation that can be exported to all the targets. My
 alternate idea, which is to wrap the code block in an environment to which I
 can attach a caption and a label, is the LaTeX approach and might not work
 as well for other export targets.

I use HTML export more and more, and would be sad if the solution wasn't
targeted at all to HTML as well.

I see rare cases where I wouldn't want to see the code name: if they have a
name, most of the time, it's because they are referenced one or multiple times
from elsewhere and you'd better be able to display that information to the
reader of your LP/RR document.

Without knowing what it implies, I'd find an extra option rather sexy,
something such as:

#+OPTIONS:   H:4 num:nil noweb-names:t

The real question is: should we be able to turn that off for some code blocks?
Not sure, but difficult to answer that it's totally unwanted.

 3) I don't have much experience with this but I believe the tangling
 apparatus does everything I might want. I remember some discussion on the
 list a while back about using Org mode for writing R packages. I'll need to
 follow up on that to see how far that effort got. Ideally, I'd tangle the
 full R package, but it might prove easier to tangle the source code and then
 use R tools to work out documentation (although that sounds like duplicated
 effort, now that I write it out).

 Sorry 

Re: [O] inline src_R also in latex src block

2012-01-11 Thread Andreas Leha
Michael Bach pha...@gmail.com writes:

 Andreas Leha andreas.l...@med.uni-goettingen.de writes:

 would this noweb-based approach work for you:

 #+name: inner_test
 #+begin_src R
   4 + 4
 #+end_src

 #+name: test
 #+begin_src latex :noweb yes
   \begin{equation}
 inner_test()
   \end{equation}
 #+end_src


 Yes, that works.  Thanks for your thoughts on this, Andreas.

 I am just thinking of another benefit:  Is it correct that I can use
 caching with this approach?  So that the call to inner_test() does
 not evaluate the `inner_test' block but instead takes its results
 directly from the cached `#+results[6099...]: inner_test' block?  This
 would be speedier than src_R usage...

yes, that should work.  Try to export the following several times.  The
first number should not change.
(note: maybe you'd have to execute the inner_test_cached once on your
system)

#+name: inner_test_cached
#+begin_src R :cache yes :exports none
  rnorm(1)
#+end_src

#+results[dbeb7280be41fdc949815808cf601a6d01a400bb]: inner_test_cached
: 1.12399967834262

#+name: inner_test_not_cached
#+begin_src R :exports none
  rnorm(1)
#+end_src

#+results: inner_test_not_cached
: -0.562660468468834

#+name: test
#+begin_src latex :noweb yes
  \begin{equation}
inner_test_cached()
!=
inner_test_not_cached()
  \end{equation}
#+end_src

Cheers,
Andreas




[O] [bug] alias for list-diary-entries-hook creates loop in emacs 24

2012-01-11 Thread Eric S Fraga
Hello,

one of the recent updates

  commit d6e40fb3472761ed51795f54491b969976167116
  
to org has caused a problem with the latest emacs snapshot (version from
5 January I believe).  Specifically, the alias for
list-diary-entries-hook would appear to create an alias loop as
diary-lib.el in emacs already has an alias.

Removing two lines from org-agenda.el (patch attached) fixes the problem
(for me).  I am not suggesting this as a patch as it would appear that
an emacs version specific check should probably be made?  I don't know
enough about this to suggest a proper solution unfortunately.

thanks,
eric

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 28f5429..bdf6881 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -4378,8 +4378,6 @@ of what a project is and how to check if it stuck, customize the variable
 
 (defvar org-disable-agenda-to-diary nil)  ;Dynamically-scoped param.
 (defvar diary-list-entries-hook)
-(if (fboundp 'defvaralias)
-(defvaralias 'diary-list-entries-hook 'list-diary-entries-hook))
 (defvar diary-time-regexp)
 (defun org-get-entries-from-diary (date)
   Get the (Emacs Calendar) diary entries for DATE.

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1
: using Org-mode version 7.8.03 (release_7.8.03.75.g7e08.dirty)


Re: [O] [bug] alias for list-diary-entries-hook creates loop in emacs 24

2012-01-11 Thread d . tchin
Eric S Fraga e.fraga at ucl.ac.uk writes:

 
 Hello,
 
 one of the recent updates
 
   commit d6e40fb3472761ed51795f54491b969976167116
 
 to org has caused a problem with the latest emacs snapshot (version from
 5 January I believe).  Specifically, the alias for
 list-diary-entries-hook would appear to create an alias loop as
 diary-lib.el in emacs already has an alias.


 Removing two lines from org-agenda.el (patch attached) fixes the problem
 (for me).  I am not suggesting this as a patch as it would appear that
 an emacs version specific check should probably be made?  I don't know
 enough about this to suggest a proper solution unfortunately.
 
 thanks,
 eric
 

I think this bug is related to the correction of a bug I recently
submitted related to emacs 22.3. Please follow the link below :

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

Hope that can make help.



Regards






Re: [O] [bug] alias for list-diary-entries-hook creates loop in emacs 24

2012-01-11 Thread Eric S Fraga
d.tchin d.tc...@voila.fr writes:

 Eric S Fraga e.fraga at ucl.ac.uk writes:

 
 Hello,
 
 one of the recent updates
 
   commit d6e40fb3472761ed51795f54491b969976167116
 
 to org has caused a problem with the latest emacs snapshot (version from
 5 January I believe).  Specifically, the alias for
 list-diary-entries-hook would appear to create an alias loop as
 diary-lib.el in emacs already has an alias.


 Removing two lines from org-agenda.el (patch attached) fixes the problem
 (for me).  I am not suggesting this as a patch as it would appear that
 an emacs version specific check should probably be made?  I don't know
 enough about this to suggest a proper solution unfortunately.
 
 thanks,
 eric
 

 I think this bug is related to the correction of a bug I recently
 submitted related to emacs 22.3. Please follow the link below :

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

 Hope that can make help.



 Regards

Indeed!  I wrote my email on the train (off-line).  By the time I got to
my office, the problem had been fixed!  That's what I love about org.

Thanks,
eric
-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.92.1
: using Org-mode version 7.8.03 (release_7.8.03.76.ga9c15)



[O] automatic tangle

2012-01-11 Thread András Major
Hi fellows,

I've just discovered that I'm missing a feature in org-mode.  These
days I write much of my code in an Org buffer and tangle it into a set
of source files.  Currently, I follow a rather cumbersome procedure
when making changes to the code:

1. I change the Org file using the C-cC-c keystroke within the code
   block I want to edit.

2. After editing, I press C-cc-c again to return to the main buffer.

3. I save the buffer.

4. I tangle the buffer using C-cC-vt.

5. For further editing, I press C-cC-c again.

I know that 3. is optional, but this still leaves me with four steps
instead of (ideally) just one.

What I would like to have is a way of reducing all this to just one
key command.  Would it make sense to introduce such a command that
simply tangles the entire buffer, including the changes made in the
language-specific buffer, but leaving that buffer open for editing?
If it's a reasonably small change, could anyone introduce it?  (I
don't have time to delve into the depths of org-mode.)

Cheers,

  András



[O] [babel]org-mode-tangle-jump-to-org and line number?

2012-01-11 Thread Rainer M Krug
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi

I am using org-mode-tangle-jump-to-org to jump from tangled code to
the source in the org file. This works nice, but if I remember
correctly, there was talk about implementing that the jump is to the
line of code - has this been implemented yet, because for me, it is
not working. I use

#+PROPERTIES: :comments link

Thanks,

Rainer
- -- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8NnpgACgkQoYgNqgF2egqdAQCggIasR/2Ti/W07Gs//gZvU2qL
ejoAoIOWC38mDqi+2MpqZCa0iG6AfCvP
=i9J6
-END PGP SIGNATURE-



[O] Using last row in remote table references

2012-01-11 Thread Phil (Philip) Mason
Hello all,

Should I be able to use @ in references to remote tables? 

For example in the tables below I would expect the results table to show cde 
as the result of both formulas. 

#+TBLNAME: TEST1
|---+---|
| a | f |
| b | g |
| c | h |
| d | i |
| e | j |
|---+---|
 
#+TBLNAME: RESULTS
|--|
| Formula test |
|--|
| cde  |
| abc  |
|--|
#+TBLFM: @2$1='(concat remote(TEST1, @3$1..@5$1))::@3$1='(concat remote(TEST1, 
@3$1..@$1))

Is there a syntax I should be using if I want to get all the entries in a table 
below a certain row without explicitly entering the number of the last row?

Thanks in advance

Phil Mason







Re: [O] automatic tangle

2012-01-11 Thread Sebastien Vauban
Hi András,

András Major wrote:
 I've just discovered that I'm missing a feature in org-mode.  These
 days I write much of my code in an Org buffer and tangle it into a set
 of source files.  Currently, I follow a rather cumbersome procedure
 when making changes to the code:

 1. I change the Org file using the C-cC-c keystroke within the code
block I want to edit.

 2. After editing, I press C-cc-c again to return to the main buffer.

 3. I save the buffer.

 4. I tangle the buffer using C-cC-vt.

 5. For further editing, I press C-cC-c again.

 I know that 3. is optional, but this still leaves me with four steps
 instead of (ideally) just one.

 What I would like to have is a way of reducing all this to just one
 key command.  Would it make sense to introduce such a command that
 simply tangles the entire buffer, including the changes made in the
 language-specific buffer, but leaving that buffer open for editing?
 If it's a reasonably small change, could anyone introduce it?  (I
 don't have time to delve into the depths of org-mode.)

I have the impression it's already there: if you edit your code directly in
the Org buffer, without opening an indirect buffer, the only thing you have to
do is:

1. save (optional, as you say)
2. tangle via C-c C-v (C-)t.

You can even advice the tangle function to do the save for you...

Another option is the opposite: edit in your tangled file, and untangle when
you feel it's the right time.

Best regards,
  Seb

-- 
Sebastien Vauban




Re: [O] Including source when exporting in PDF

2012-01-11 Thread Rainer M Krug
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/01/12 08:45, Eric Schulte wrote:
 Frozenlock frozenl...@gmail.com writes:
 
 I am a strong advocate in keeping the source of everything.
 
 However,  a source can easily be lost if it doesn't follow the
 document. In LaTeX, there's a package to attach a file to a PDF
 (like when you attach a file to an email). By doing so, the
 source will follow the PDF even if the common reader have no clue
 what it's for, or even how to use it.
 
 
 This sounds like a great Reproducible Research practice.
 
 
 Here is how I attach my org source to every document I export to
 PDF:
 
 ;; Include the source file for every exported PDF (org-mode) 
 (eval-after-load org-exp '(defadvice org-export-as-latex
 (around org-export-add-source-pdf activate) Add the source (org
 file) to the resulting pdf file (let ((filename (buffer-name))) 
 ad-do-it ;do the function (let ((latex-buffer ad-return-value)) 
 (set-buffer latex-buffer) (while (re-search-forward
 usepackage{.+} nil t)); go to the end of packages (insert
 \n\\usepackage{attachfile2}); the package needed to attach
 files (when (re-search-forward end{document} nil t) 
 (forward-line -1) (insert (concat \\vfill\n \\footnotesize\n 
 The source of this document is an Org-Mode file attached here: 
 \n\\attachfile { filename }))) (save-buffer)
 
 
 This is by no mean a patch, but rather a quick hack. Perhaps
 someone with a working knowledge of the org-export could find a
 way to add a source option?
 
 
 I think this practice may not actually require any changes to the 
 Org-mode core.  The attached small Org-mode file will attach itself
 to pdf exports using only features already present in Org-mode.

Following this idea - how can I easily attach all files created by
tangling? Is there a programmatic way, without having to specify them
manually?

Thanks,

Rainer


 
 
 
 
 
 Thanks for sharing this idea!
 
 
 
 Cheers!
 
 


- -- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8NqqwACgkQoYgNqgF2egro/wCfTlVxaVNR1/5395UC8wWrL9Ku
jhIAn3f3Lud1aFrHz1uzo7SlFH+CsmFi
=wU4r
-END PGP SIGNATURE-



Re: [O] Capitalisation and good taste ?

2012-01-11 Thread Bastien
Bastien b...@altern.org writes:

 Actually, I'm thinking of another solution:

 - keep one-line option/environment keywords uppercase
   #+NAME
   #+HTML
   #+TITLE
   #+...

 - use lowercase for multi-lines environments keywords
   #+begin_ascii
   #+begin_html
   #+results

 This is the only good criterium I can think of, and that
 way people using easy templates will not be surprised to
 see #+begin_xxx in the manual.

I tried this and I find the lowercase #+begin_xxx really
not readable enough in the manual.   So I use #+RESULTS:
and explained this convention in the manual.

-- 
 Bastien



Re: [O] Capitalisation and good taste ?

2012-01-11 Thread Bastien
Hi François,

pin...@iro.umontreal.ca (François Pinard) writes:

 Could the highlighting be made consistent as well?  I would suggest that
 gray is uniformly kept for all one-line option/environment keywords.
 Currently, #+TITLE is gray, #+OPTIONS is red, so #+OPTION would be
 rendered the same as #+TITLE.  The gray would counter-balance the
 shouting of the capitals, making it more bearable.

 For lowercase multi-line environments keywords, red is just fine, and I
 did not see exceptions so far (which does not mean there are not any).

As Sébastien suggested, please contribute to this page:
http://orgmode.org/worg/color-themes-screenshot.html

Thanks,

-- 
 Bastien



Re: [O] C-k in visual line mode

2012-01-11 Thread Bastien
Hi François,

pin...@iro.umontreal.ca (François Pinard) writes:

 Let me suggest this tiny patch, so C-k does the proper thing in visual
 line mode.

Applied, thanks.  

-- 
 Bastien



Re: [O] :noweb header argument

2012-01-11 Thread Eric S Fraga
Sebastien Vauban wxhgmqzgw...@spammotel.com writes:

 Hi Thomas, Eric(s) and all,

Hi Sebastien,

[...]

 I use HTML export more and more, and would be sad if the solution wasn't
 targeted at all to HTML as well.

I agree although this doesn't preclude target specific customisation
variables; it just means that each target would have to have its own
variable.  Maybe less aesthetically pleasing than a single org
intermediary but possibly easier to use...


 I see rare cases where I wouldn't want to see the code name: if they have a
 name, most of the time, it's because they are referenced one or multiple times
 from elsewhere and you'd better be able to display that information to the
 reader of your LP/RR document.

Well, my case is the opposite!  I seldom want the names in the exported
output.  That's partly because I tend to name *every* code
block.  First, I use yasnippet to insert code blocks and it prompts for
the name; second, I find it good practice as I never know if or when I
might actually want to refer to the code block so naming as I go along
is most convenient; third, most importantly, it makes it possible to
jump to code blocks quickly in a large file!

 Without knowing what it implies, I'd find an extra option rather sexy,
 something such as:

 #+OPTIONS:   H:4 num:nil noweb-names:t

I would be happy with this!

 The real question is: should we be able to turn that off for some code blocks?
 Not sure, but difficult to answer that it's totally unwanted.

It would be nice but, at least for my use case, not necessary.

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1
: using Org-mode version 7.8.03 (release_7.8.03.76.ga9c15)



Re: [O] Symbol's function definition is void: org-write-agenda

2012-01-11 Thread Eric S Fraga
Bastien b...@altern.org writes:

 Karl Voit devn...@karl-voit.at writes:

 `org-write-agenda' has been renamed to `org-agenda-write', 
 please update your code.

 Thanks for the hint! Missed in in the change notes ...

 You didn't miss anything -- this change is in current git HEAD,
 which used not to be advertised in http://orgmode.org/Changes.html

 I'm now publishing a new section in this page called Current HEAD of
 the git repository, it will expose such incompatible changes earlier.

 Thanks!

Thanks Bastien.  This will be very useful!  I track org daily (via a
semi-automated synchronisation on my various computers) but don't
necessarily read the mailing list every day, as much as I would like to
;-)  Knowing that there is a reasonably up to date list of changes in
the development version would be very nice indeed.

Thanks again,
eric

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1
: using Org-mode version 7.8.03 (release_7.8.03.76.ga9c15)



Re: [O] Minor org mode for achieve code folding effects

2012-01-11 Thread Eric S Fraga
Giovanni Giorgi j...@gioorgi.com writes:

   

 Hi all,
  I'd like to edit some ruby/python/shell script using
 functions folding. 

 I'd like to get a way to fold functions or method.

Giovanni,

I wonder, having thought about this some more, whether using org mode is
the correct solution?  (as much as I like org!)  There are other
solutions that may work /out of the box/ as you want.  This is *emacs*
we are talking about after all!

For instance, when I was doing a lot of Java programming, I used
hideshow.el all the time to hide block and function bodies.  Works very
well (although the default key bindings are annoying to me).  Have a
look!  It's a standard package in emacs, at least in Emacs 24 but much
earlier than that I believe.

There's a small add-on called hideshow-org.el which may be useful as
well:

,
| ;;; hideshow-org.el - Provides org-mode like hide and show for hideshow.el
| ;;
| ;; Copyright (C) 2009 Shane Celis
| ;;
| ;; Author: Shane Celis shane (at) gnufoo (dot) org
`

Have a search for that; if you can't find it, I can send you my copy but
there may be a more up to date one on the web somewhere...

HTH,
eric

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1
: using Org-mode version 7.8.03 (release_7.8.03.76.ga9c15)



Re: [O] Diacritics in image file names

2012-01-11 Thread Eric S Fraga
pin...@iro.umontreal.ca (François Pinard) writes:

 Hi, Org people.

 It seems that if I use diacritics in file names for included images, and
 then asks for a PDF rendering of it (through LaTeX), the image does not
 get included.  If I remember correctly, I only get a big hollow square,
 with the textual name of the image file (rather than the image) included
 in the square and extending out to its right.

 The file name uses UTF-8, as well as the Org file referring to it.

 If I rename the file to pure ASCII, and adjust the reference
 accordingly, all goes well.  So did I, of course.  Yet, I think the
 problem is worth being reported, and then, either corrected or
 documented (so other people do not spend time scratching their head).

 François

Is the problem with org or with latex?  I.e. have you looked at the
latex code generated to see if the translation was correct?  Latex has
traditionally had more problems with the ASCII to UTF-8/Unicode move than
org or Emacs, in my experience.

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1
: using Org-mode version 7.8.03 (release_7.8.03.76.ga9c15)



Re: [O] Org-edit-special and C-x C-s strange behavior

2012-01-11 Thread Eric S Fraga
Leo Alekseyev dnqu...@gmail.com writes:

 I often edit my org-babel code blocks via org-edit-special (C-'), in
 part because I find the tabbing behavior within the code blocks to be
 somewhat flaky. Inevitably, when editing the code block I will press
 C-x C-s (muscle memory). This causes all sorts of annoying
 consequences: the buffer with the code block gets buried, window

[...]

What version of org are you using?  I ask because I used to experience
the annoyance you describe a while back; more recently (since at least a
few months ago), hitting C-x C-s no longer has any negative impact: it
saves the file, or at least appears to.

You still have to C-c ' to get back to the full buffer, mind you, but
that's better, IMO, than changing the behaviour of such a fundamental
key binding as C-x C-s.
-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1
: using Org-mode version 7.8.03 (release_7.8.03.76.ga9c15)



[O] [PATCH] Show human-readable link descriptions first when inserting links

2012-01-11 Thread Dave Abrahams

This patch makes it easy to select links from among a forest of
similar-looking machine-readable forms.  Without it, the human-readable
descriptions tend to fall off the right side of the window.

From fa9522e8dd1ef602574d0fb58f8f610ef82b15d7 Mon Sep 17 00:00:00 2001
From: Dave Abrahams d...@boostpro.com
Date: Thu, 22 Sep 2011 15:11:27 -0400
Subject: [PATCH] Show human-readable link descriptions first when inserting
 links

---
 lisp/org.el |   12 
 1 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 3953890..34ae6c4 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -9016,6 +9016,12 @@ Note: this function also decodes single byte encodings like
 (setq s (replace-match %40 t t s)))
   s)
 
+(defun org-pretty-link (link)
+  Return a human-digestible representation of a given LINK,
+whose car must be a raw link and whose cadr must be either a link
+description or nil.
+  (concat (or (cadr link) no description) \t[[ (car link) ]]))
+
 ;;;###autoload
 (defun org-insert-link-global ()
   Insert a link like Org-mode does.
@@ -9098,9 +9104,7 @@ be used as the default description.
 Use TAB to complete link prefixes, then RET for type-specific completion support\n)
 	(when org-stored-links
 	  (princ \nStored links are available with up/down or M-p/n (most recent with RET):\n\n)
-	  (princ (mapconcat
-		  (lambda (x)
-		(if (nth 1 x) (concat (car x)  ( (nth 1 x) )) (car x)))
+	  (princ (mapconcat 'org-pretty-link
 		  (reverse org-stored-links) \n
   (let ((cw (selected-window)))
 	(select-window (get-buffer-window *Org Links* 'visible))
@@ -9109,7 +9113,7 @@ Use TAB to complete link prefixes, then RET for type-specific completion support
 	  (org-fit-window-to-buffer))
 	(and (window-live-p cw) (select-window cw)))
   ;; Fake a link history, containing the stored links.
-  (setq tmphist (append (mapcar 'car org-stored-links)
+  (setq tmphist (append (mapcar 'org-pretty-link org-stored-links)
 			org-insert-link-history))
   (setq all-prefixes (append (mapcar 'car org-link-abbrev-alist-local)
  (mapcar 'car org-link-abbrev-alist)
-- 
1.7.5.4


-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com



[O] Maybe a typo in the manual?

2012-01-11 Thread François Pinard
Hi, Org people.

I'm not familiar with referencing in documents, so I'm not sure.  The
section 11.2 Images and Tables in the manual says:


You can use the following lines somewhere before the table to assign a
caption and a label for cross references, and in the text you can refer
to the object with `\ref{tab:basic-data}':

 #+CAPTION: This is the caption for the next table (or link)
 #+LABEL:   tbl:basic-data
| ... | ...|

\ref says tab:, while #+LABEL says tbl:.  Is that a typo?

I presume, without knowing, that these prefixes are conventional, and
they do not have a preset meaning.  I could have used zzz: if I felt
like it?

François



Re: [O] Maybe a typo in the manual?

2012-01-11 Thread Thomas S. Dye
pin...@iro.umontreal.ca (François Pinard) writes:

 Hi, Org people.

 I'm not familiar with referencing in documents, so I'm not sure.  The
 section 11.2 Images and Tables in the manual says:


 You can use the following lines somewhere before the table to assign a
 caption and a label for cross references, and in the text you can refer
 to the object with `\ref{tab:basic-data}':

  #+CAPTION: This is the caption for the next table (or link)
  #+LABEL:   tbl:basic-data
 | ... | ...|

 \ref says tab:, while #+LABEL says tbl:.  Is that a typo?

 I presume, without knowing, that these prefixes are conventional, and
 they do not have a preset meaning.  I could have used zzz: if I felt
 like it?

 François

Yes, you are correct.

Tom
-- 
Thomas S. Dye
http://www.tsdye.com



[O] [PATCH] Fix typo in manual

2012-01-11 Thread Thomas S. Dye
Aloha all,

This patch to the manual fixes a typo.

All the best,
Tom

From 96fc5de8a377b69678d5dd82f414d293dea709c6 Mon Sep 17 00:00:00 2001
From: Thomas Dye dk@poto.local
Date: Wed, 11 Jan 2012 06:41:02 -1000
Subject: [PATCH] Fix typo on manual pointed out by Francois Pinard

---
 doc/org.texi |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index c3405f1..f619c90 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -9027,7 +9027,7 @@ the object with @code{\ref@{tab:basic-data@}}:
 
 @example
 #+CAPTION: This is the caption for the next table (or link)
-#+LABEL:   tbl:basic-data
+#+LABEL:   tab:basic-data
| ... | ...|
|-||
 @end example
-- 
1.7.5.4


-- 
Thomas S. Dye
http://www.tsdye.com


[O] LOGBOOK opening

2012-01-11 Thread François Pinard
Hi, Org people.

When using SPC in the Agenda buffer (org-agenda-show-and-scrollup), the
LOGBOOK drawer is shown opened, which is not a big problem, yet a
slightly annoying one, as I'm rarely interested to see its contents at
this stage.  Moreover, the manual explains that one of the purposes of
drawers is keeping information out of sight, unless the user takes
specific action for opening it.

The above command leave the cursor on the SCHEDULED: line in the Org
buffer, which is above and outside the LOGBOOK drawer, so there is
likely no need to open it.

Is there some secret variable to prevent such opening?  (I begin to see
the pattern on the Org mode list -- someone presents a problem, another
gives the name of the variable that solves it!)

François




Re: [O] :noweb header argument

2012-01-11 Thread Eric Schulte
 | tangle | -| +  | -  |
 |+--++|
 | need   | +| +  | -  |


 What should the name for such an option be?


 Andreas' suggestion, :noweb no-export, seems right to me.


Me too,

I've just pushed up a patch adding a no-export option to the :noweb
header argument.  If I could be so bold as to impose on you for a
correlate documentation patch... :)

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



Re: [O] Using last row in remote table references

2012-01-11 Thread Michael Brand
Hi Phil

On Tue, Jan 10, 2012 at 14:39, Phil (Philip) Mason
phil.ma...@broadcom.com wrote:
 Should I be able to use @ in references to remote tables?

Yes, this issue has been resolved by Carsten with
release_7.7-420-g1432e4b

 Is there a syntax I should be using if I want to get all the entries
 in a table below a certain row without explicitly entering the
 number of the last row?

The general solution for a Calc formula is e. g. with subvec as I
described here:
http://lists.gnu.org/archive/html/emacs-orgmode/2011-11/msg00562.html
and in a similar sense as I described for subscr in the subsection
Dynamic variation of ranges here:
http://orgmode.org/worg/org-hacks.html#field-coordinates-in-formulas

The general solution for a Lisp formula is e. g. with calc-subvector I
guess.

The following simpler solution is only possible when the range is
relative to the field where the formula is evaluated in and when the
offset to the range border is static:

|---+-|
| a | abc |
| b | bcd |
| c | cde |
| d | |
| e | |
|---+-|
#+TBLFM: @$2..@$2 = '(concat @0$1..@+2$1)

With a remote table you can not use the simple solution.

Michael



Re: [O] LOGBOOK opening

2012-01-11 Thread Sebastien Vauban
Hi François,

François Pinard wrote:
 When using SPC in the Agenda buffer (org-agenda-show-and-scrollup), the
 LOGBOOK drawer is shown opened, which is not a big problem, yet a
 slightly annoying one, as I'm rarely interested to see its contents at
 this stage.  Moreover, the manual explains that one of the purposes of
 drawers is keeping information out of sight, unless the user takes
 specific action for opening it.

 The above command leave the cursor on the SCHEDULED: line in the Org
 buffer, which is above and outside the LOGBOOK drawer, so there is
 likely no need to open it.

 Is there some secret variable to prevent such opening?  (I begin to see
 the pattern on the Org mode list -- someone presents a problem, another
 gives the name of the variable that solves it!)

I don't _think_ this is customizable right now; though, please not that
RET'ing on en entry from the agenda jumps to the entry, without expanding the
drawer. Though, it reuses the agenda buffer to do so -- it's not the same
behavior as SPC'ing.

Best regards,
  Seb

-- 
Sebastien Vauban




[O] MobileOrg Push Issue: 'org-agenda-filter' is void

2012-01-11 Thread Joerg Picard
Everything has been working fine for month and since yesterday I get 
'org-agenda-filter' is void error message when trying to push my org files to 
dropbox. I've found a thread on the message board with the suggestion to 
install the latest git code, which I did, but I still have the same issue.

Anybody has a solution?

Thanks
Joerg



[O] [PATCH] Manual edit for :noweb no-export

2012-01-11 Thread Thomas S. Dye
Aloha all,

Attached please find subject patch.

All the best,
Tom

From bd3579cef735c2bb62c37a4d394597be384fe18d Mon Sep 17 00:00:00 2001
From: Thomas Dye d...@poto.myhome.westell.com
Date: Wed, 11 Jan 2012 08:46:27 -1000
Subject: [PATCH] * doc/org.texi: Documented :noweb no-export

---
 doc/org.texi |   28 +---
 1 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index d23d2ab..a9f0139 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -13581,21 +13581,27 @@ interpreted language.
 @node noweb, noweb-ref, session, Specific header arguments
 @subsubsection @code{:noweb}
 
-The @code{:noweb} header argument controls expansion of ``noweb'' style (see
-@ref{Noweb reference syntax}) references in a code block.  This header
-argument can have one of three values: @code{yes}, @code{no}, or @code{tangle}.
+The @code{:noweb} header argument controls expansion of ``noweb'' syntax
+references (see @ref{Noweb reference syntax}) when the code block is
+evaluated, tangled, or exported.  The @code{:noweb} header argument can have
+one of four values: @code{no}, @code{yes}, @code{tangle}, or
+@code{no-export}.
 
 @itemize @bullet
-@item @code{yes}
-All ``noweb'' syntax references in the body of the code block will be
-expanded before the block is evaluated, tangled or exported.
 @item @code{no}
-The default.  No ``noweb'' syntax specific action is taken when the code
-block is evaluated, tangled or exported.
+The default.  ``Noweb'' syntax references in the body of the code block will
+not be expanded before the code block is evaluated, tangled or exported.
+@item @code{yes}
+``Noweb'' syntax references in the body of the code block will be
+expanded before the code block is evaluated, tangled or exported.
 @item @code{tangle}
-All ``noweb'' syntax references in the body of the code block will be
-expanded before the block is tangled, however ``noweb'' references will not
-be expanded when the block is evaluated or exported.
+``Noweb'' syntax references in the body of the code block will be expanded
+before the code block is tangled. However, ``noweb'' syntax references will
+not be expanded when the code block is evaluated or exported.
+@item @code{no-export}
+``Noweb'' syntax references in the body of the code block will be expanded
+before the block is evaluated or tangled. However, ``noweb'' syntax
+references will not be expanded when the code block is exported.
 @end itemize
 
 @subsubheading Noweb prefix lines
-- 
1.7.5.4


-- 
T.S. Dye  Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com


Re: [O] [PATCH] Manual edit for :noweb no-export

2012-01-11 Thread Eric Schulte
Applied, Thanks,

t...@tsdye.com (Thomas S. Dye) writes:

 Aloha all,

 Attached please find subject patch.

 All the best,
 Tom

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



Re: [O] automatic tangle

2012-01-11 Thread András Major
Hi Sebastien,

 I have the impression it's already there: if you edit your code directly in
 the Org buffer, without opening an indirect buffer, the only thing you have to
 do is:

That's precisely what I want to avoid.  I'd like to use the
language-specific indentation and highlighting using the indirect
buffer.  Basically, what I'm after is a quick keyboard command that
tangles the entire file while I'm in the indirect buffer.

 Another option is the opposite: edit in your tangled file, and untangle when
 you feel it's the right time.

I don't think that's practical, since each file can be built up from
several code blocks.  In any case, it would be too easy to lose code
that way by accidentally tangling while there are changes in the
source code file.

  András



[O] capture inside org-edit-src-code buffer

2012-01-11 Thread Andreas Leha
Hi all,

I'd like to be able to call capture such that the captured item is
stored under '* Notes' in the current org-file *from inside an
org-edit-src-code buffer*.

Preferably, I'd like a single capture template, that works
(1) on the current org file normally
(2) on the parent org file after doing C-' on a source block

A possible capture template for (1) looks like this:
(w currentfile entry (file+headline (buffer-file-name) Notes) )
How would I extend this to (2)?

Optimally, this template would record the #+name tag of the source
block under the point (if the point is in a source block) in (1) or the
source block being edited in (2), if such #name tag exists.

Thanks for hints,
Andreas




Re: [O] automatic tangle

2012-01-11 Thread Sebastien Vauban
Hi András,

András Major wrote:
 I have the impression it's already there: if you edit your code directly in
 the Org buffer, without opening an indirect buffer, the only thing you have 
 to
 do is:

 That's precisely what I want to avoid.  I'd like to use the
 language-specific indentation and highlighting using the indirect
 buffer.  Basically, what I'm after is a quick keyboard command that
 tangles the entire file while I'm in the indirect buffer.

I do have:
- language-specific indentation and
- highlighting
in the Org buffer itself...

Just put this in your .emacs file:

#+begin_src emacs-lisp
;; fontify code in code blocks
(setq org-src-fontify-natively t)

;; preserve spaces and `tab' characters in source code blocks
(setq org-src-preserve-indentation t)

;; same effect for `tab' as in the language major mode buffer
(setq org-src-tab-acts-natively t)
#+end_src

 Another option is the opposite: edit in your tangled file, and untangle when
 you feel it's the right time.

 I don't think that's practical, since each file can be built up from
 several code blocks.

That's not a problem: if you turn on the comments, you'll see every chunked
delimited in the tangled buffer.

 In any case, it would be too easy to lose code that way by accidentally
 tangling while there are changes in the source code file.

If you play within both files, yes, that's a real potential danger.

Best regards,
  Seb

-- 
Sebastien Vauban




Re: [O] Capitalisation and good taste ?

2012-01-11 Thread Eric Schulte
Bastien b...@altern.org writes:

 Bastien b...@altern.org writes:

 Actually, I'm thinking of another solution:

 - keep one-line option/environment keywords uppercase
   #+NAME
   #+HTML
   #+TITLE
   #+...

 - use lowercase for multi-lines environments keywords
   #+begin_ascii
   #+begin_html
   #+results

 This is the only good criterium I can think of, and that
 way people using easy templates will not be surprised to
 see #+begin_xxx in the manual.

 I tried this and I find the lowercase #+begin_xxx really
 not readable enough in the manual.   So I use #+RESULTS:
 and explained this convention in the manual.

Sounds good.

While I like the proposed distinction above, I'd just as soon have
Org-mode default to all caps in the manual and in practice.  As noted
before individual users can use lower case at the mercy of their (our)
potentially changing whims.

I'm going to push up a patch which will change to inserting #+RESULTS:
by default as well as a user-configurable variable which can be used to
customize this behavior.

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



Re: [O] Org-edit-special and C-x C-s strange behavior

2012-01-11 Thread Andreas Leha
Eric S Fraga e.fr...@ucl.ac.uk writes:

 Leo Alekseyev dnqu...@gmail.com writes:

 I often edit my org-babel code blocks via org-edit-special (C-'), in
 part because I find the tabbing behavior within the code blocks to be
 somewhat flaky. Inevitably, when editing the code block I will press
 C-x C-s (muscle memory). This causes all sorts of annoying
 consequences: the buffer with the code block gets buried, window

 [...]

 What version of org are you using?  I ask because I used to experience
 the annoyance you describe a while back; more recently (since at least a
 few months ago), hitting C-x C-s no longer has any negative impact: it
 saves the file, or at least appears to.

 You still have to C-c ' to get back to the full buffer, mind you, but
 that's better, IMO, than changing the behaviour of such a fundamental
 key binding as C-x C-s.

I am not sure, I understand this.

I do also experience the same behaviour as the OP since some time (weeks, I
guess).  Hitting C-x C-s in the org-edit-special buffer still saves the
org file, but the org-edit-special buffer gets buried.

Cheers,
Andreas




Re: [O] Capitalisation and good taste ?

2012-01-11 Thread Eric Schulte

 I'm going to push up a patch which will change to inserting #+RESULTS:
 by default as well as a user-configurable variable which can be used to
 customize this behavior.

Done.  This variable is named `org-babel-results-keyword'

,
| org-babel-results-keyword's value is RESULTS
| 
| Documentation:
| Keyword used to name results generated by code blocks.
| Should be either RESULTS or NAME however any capitalization may
| be used.
| 
| You can customize this variable.
| 
| [back]
`

Best,

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



[O] [PATCH] Re: Capitalisation and good taste ?

2012-01-11 Thread Thomas S. Dye
Aloha all,

The attached patch to the manual includes information on the RESULTS
keyword.

All the best,
Tom

From 7fbabd20ed1477e706633945c98400ee48fb0ab2 Mon Sep 17 00:00:00 2001
From: Thomas Dye d...@poto.myhome.westell.com
Date: Wed, 11 Jan 2012 11:23:19 -1000
Subject: [PATCH] * doc/org.texi: #+RESULTS now user-configurable

---
 doc/org.texi |   17 -
 1 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index a9f0139..2229358 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -12629,17 +12629,24 @@ of tangled code files.
 @section Evaluating code blocks
 @cindex code block, evaluating
 @cindex source code, evaluating
+@cindex #+RESULTS
 
 Code blocks can be evaluated@footnote{Whenever code is evaluated there is a
 potential for that code to do harm.  Org mode provides safeguards to ensure
 that code is only evaluated after explicit confirmation from the user.  For
 information on these safeguards (and on how to disable them) see @ref{Code
 evaluation security}.} and the results of evaluation optionally placed in the
-Org mode buffer.  By default, the evaluation facility is only enabled for
-Lisp code blocks specified as @code{emacs-lisp}. However, source code blocks
-in many languages can be evaluated within Org mode (see @ref{Languages} for a
-list of supported languages and @ref{Structure of code blocks} for
-information on the syntax used to define a code block).
+Org mode buffer.  The results of evaluation are placed following a line that
+begins by default with @code{#+RESULTS} and optionally a cache identifier
+and/or the name of the evaluated code block.  The default value of
+@code{#+RESULTS} can be changed with the customizable variable
+@code{org-babel-results-keyword}. 
+
+By default, the evaluation facility is only enabled for Lisp code blocks
+specified as @code{emacs-lisp}. However, source code blocks in many languages
+can be evaluated within Org mode (see @ref{Languages} for a list of supported
+languages and @ref{Structure of code blocks} for information on the syntax
+used to define a code block).
 
 @kindex C-c C-c
 There are a number of ways to evaluate code blocks.  The simplest is to press
-- 
1.7.5.4


Eric Schulte eric.schu...@gmx.com writes:


 I'm going to push up a patch which will change to inserting #+RESULTS:
 by default as well as a user-configurable variable which can be used to
 customize this behavior.

 Done.  This variable is named `org-babel-results-keyword'

 ,
 | org-babel-results-keyword's value is RESULTS
 | 
 | Documentation:
 | Keyword used to name results generated by code blocks.
 | Should be either RESULTS or NAME however any capitalization may
 | be used.
 | 
 | You can customize this variable.
 | 
 | [back]
 `

 Best,

-- 
Thomas S. Dye
http://www.tsdye.com


Re: [O] automatic tangle

2012-01-11 Thread Eric S Fraga
András Major andras.g.ma...@gmail.com writes:

 Hi fellows,

 I've just discovered that I'm missing a feature in org-mode.  These
 days I write much of my code in an Org buffer and tangle it into a set
 of source files.  Currently, I follow a rather cumbersome procedure
 when making changes to the code:

 1. I change the Org file using the C-cC-c keystroke within the code
block I want to edit.

 2. After editing, I press C-cc-c again to return to the main buffer.

 3. I save the buffer.

 4. I tangle the buffer using C-cC-vt.

 5. For further editing, I press C-cC-c again.

 I know that 3. is optional, but this still leaves me with four steps
 instead of (ideally) just one.

 What I would like to have is a way of reducing all this to just one
 key command.  Would it make sense to introduce such a command that
 simply tangles the entire buffer, including the changes made in the
 language-specific buffer, but leaving that buffer open for editing?
 If it's a reasonably small change, could anyone introduce it?  (I
 don't have time to delve into the depths of org-mode.)

 Cheers,

   András

Probably not what you want but, assuming that the keys you hit are
always the same, you could always define a keyboard macro, name it and
save it as emacs lisp code.

for example, the attached (because the insert-kbd-macro command creates
emacs lisp code with control characters) defines a new command which, if
starting from a code block special edit mode, exits that block, saves
the file, tangles the whole buffer and re-enters the code block:
You can then bind this new command to a key of your choice.  Untested...

* new function
  Allows one to exit a special code block editing mode, save the file,
  tangle all code blocks and then re-enter the code block editing
  mode.

#+begin_src emacs-lisp
(fset 'esf/org-save-tangle-reedit-macro
   (lambda (optional arg) 
 Keyboard macro. 
 (interactive p) 
 (kmacro-exec-ring-item (quote ('t' 0 %d)) arg)))
#+end_src



HTH,
eric
-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.92.1
: using Org-mode version 7.8.03 (release_7.8.03.99.gce5c5)


Re: [O] [PATCH] Re: Capitalisation and good taste ?

2012-01-11 Thread Eric Schulte
Fantastic, I've just applied this patch, Thanks

t...@tsdye.com (Thomas S. Dye) writes:

 Aloha all,

 The attached patch to the manual includes information on the RESULTS
 keyword.

 All the best,
 Tom



 Eric Schulte eric.schu...@gmx.com writes:


 I'm going to push up a patch which will change to inserting #+RESULTS:
 by default as well as a user-configurable variable which can be used to
 customize this behavior.

 Done.  This variable is named `org-babel-results-keyword'

 ,
 | org-babel-results-keyword's value is RESULTS
 | 
 | Documentation:
 | Keyword used to name results generated by code blocks.
 | Should be either RESULTS or NAME however any capitalization may
 | be used.
 | 
 | You can customize this variable.
 | 
 | [back]
 `

 Best,

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



[O] org-babel order of evaluation

2012-01-11 Thread Rick Frankel
There is a problem with the order of execution of interspersed source
and call blocks will not be executed in order because of the way
org-babel-execute-buffer is written (first all the source blocks, then
all the call blocks). 

Therefore, when executing an entire buffer, there is no way to have
the execution of a call block dependent on the prior execution of a
source block.

Given the following:

#+name: one(v=one)
#+begin_src elisp
v
#+end_src

#+call: one(two)

#+name: three(v=three)
#+begin_src elisp
v
#+end_src

The message buffer shows:

executing Elisp code block (one)...

(v (quote one))

Code block evaluation complete.
executing Elisp code block (three)...

(v (quote three))

Code block evaluation complete.
executing Elisp code block (one)...

(v (quote two))

two
executing Emacs-Lisp code block...

(results (quote two))




[O] source block variable expansion

2012-01-11 Thread Rick Frankel
Since org-mode v7.8, editing a code block in an indirect buffer causes
any referenced code blocks to be executed. While this behavior is
desired for viewing code in an indirect buffer (as the behavior has
always been) it is not for editing (esp. if the named block takes a
long time to run).

Given a referenced source block:

#+name: var
#+begin_src elisp
  you shouldn't see this in the mini-buffer
#+end_src

When editing the followiing code block (via =C-c '=), the above block
(=var=) will be executed. The message =executing Elisp code block
(var)...= will appear in the =*Message*= buffer and the message above
will appear in the mini-buffer.

#+name: edit-test(var=var)
#+begin_src perl
  $var;
#+end_src



Re: [O] Org-edit-special and C-x C-s strange behavior

2012-01-11 Thread Leo Alekseyev
 Eric S Fraga e.fr...@ucl.ac.uk writes:

 What version of org are you using?  I ask because I used to experience
 the annoyance you describe a while back; more recently (since at least a
 few months ago), hitting C-x C-s no longer has any negative impact: it
 saves the file, or at least appears to.

 You still have to C-c ' to get back to the full buffer, mind you, but
 that's better, IMO, than changing the behaviour of such a fundamental
 key binding as C-x C-s.

It appears that this bug is Emacs-version dependent: it functions as
you describe with 23.2, but the buffer gets buried (with an error
message basic-save-buffer: Wrong type argument: stringp, nil) in
24.0.92.  Org mode is the current git HEAD.  I tried to step through
basic-save-buffer in edebug, but I couldn't catch the error (I'm not
very experienced with edebug).  Can someone test this on Emacs 24 and
confirm what I'm seeing?



Re: [O] Including source when exporting in PDF

2012-01-11 Thread Frozenlock
To include multiple files, I export all of the required files before
the PDF creation and zip them. This way, I only need to include a
single zip file.

#+BEGIN_SRC emacs-lisp :exports none
;; various exports
 (save-window-excursion
  (org-export-as-ascii org-export-headline-levels))
(save-window-excursion
  (org-export-as-html org-export-headline-levels))

;;zip the required files
(let ((filename (file-name-sans-extension (file-name-nondirectory
(buffer-file-name)
  (shell-command
   (concat zip  filename .zip 
   (mapconcat '(lambda (arg) arg)
(remove-if
 '(lambda (filename)
(string-match \\.$\\|\\.pdf$\\|\\.atfi$\\|# filename))
 (directory-files (file-name-directory (buffer-file-name
 
#+END_SRC

(I've added this code in a babel block to evaluate just before the PDF export.)

As you can see, I make sure I don't include a previous PDF, or any
other useless file.

If you wish to add only a single type of file, simply replace
remove-if by remove-if-not and change the value in the
string-match function. For example, \\.$\\|\\.pdf$\\|\\.atfi$\\|#
would become \\.lisp$ to include all your exported lisp files.

Hope this helps!


By the way, I can't get the code block to be evaluated automatically
when I export to PDF, any clue on how to do that?



On Wed, Jan 11, 2012 at 10:28 AM, Rainer M Krug r.m.k...@gmail.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 06/01/12 08:45, Eric Schulte wrote:
 Frozenlock frozenl...@gmail.com writes:

 I am a strong advocate in keeping the source of everything.

 However,  a source can easily be lost if it doesn't follow the
 document. In LaTeX, there's a package to attach a file to a PDF
 (like when you attach a file to an email). By doing so, the
 source will follow the PDF even if the common reader have no clue
 what it's for, or even how to use it.


 This sounds like a great Reproducible Research practice.


 Here is how I attach my org source to every document I export to
 PDF:

 ;; Include the source file for every exported PDF (org-mode)
 (eval-after-load org-exp '(defadvice org-export-as-latex
 (around org-export-add-source-pdf activate) Add the source (org
 file) to the resulting pdf file (let ((filename (buffer-name)))
 ad-do-it ;do the function (let ((latex-buffer ad-return-value))
 (set-buffer latex-buffer) (while (re-search-forward
 usepackage{.+} nil t)); go to the end of packages (insert
 \n\\usepackage{attachfile2}); the package needed to attach
 files (when (re-search-forward end{document} nil t)
 (forward-line -1) (insert (concat \\vfill\n \\footnotesize\n
 The source of this document is an Org-Mode file attached here:
 \n\\attachfile { filename }))) (save-buffer)


 This is by no mean a patch, but rather a quick hack. Perhaps
 someone with a working knowledge of the org-export could find a
 way to add a source option?


 I think this practice may not actually require any changes to the
 Org-mode core.  The attached small Org-mode file will attach itself
 to pdf exports using only features already present in Org-mode.

 Following this idea - how can I easily attach all files created by
 tangling? Is there a programmatic way, without having to specify them
 manually?

 Thanks,

 Rainer







 Thanks for sharing this idea!



 Cheers!




 - --
 Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
 Biology, UCT), Dipl. Phys. (Germany)

 Centre of Excellence for Invasion Biology
 Stellenbosch University
 South Africa

 Tel :       +33 - (0)9 53 10 27 44
 Cell:       +33 - (0)6 85 62 59 98
 Fax :       +33 - (0)9 58 10 27 44

 Fax (D):    +49 - (0)3 21 21 25 22 44

 email:      rai...@krugs.de

 Skype:      RMkrug
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAk8NqqwACgkQoYgNqgF2egro/wCfTlVxaVNR1/5395UC8wWrL9Ku
 jhIAn3f3Lud1aFrHz1uzo7SlFH+CsmFi
 =wU4r
 -END PGP SIGNATURE-



Re: [O] Minor org mode for achieve code folding effects

2012-01-11 Thread Leo Alekseyev
 For instance, when I was doing a lot of Java programming, I used
 hideshow.el all the time to hide block and function bodies.  Works very
 well (although the default key bindings are annoying to me).  Have a
 look!  It's a standard package in emacs, at least in Emacs 24 but much
 earlier than that I believe.

 There's a small add-on called hideshow-org.el which may be useful as
 well:

Having read the OP, I'll second Eric's vote for hideshow-org.  It's a
better solution for folding functions.  However, the combination of
org/outline-minor-mode/Tassilo's code works well for splitting a file
into foldable sections.  Incidentally, you can use both of these
methods at the same time; they don't conflict too much.

--l



[O] [PATCH] :wrap header documentation

2012-01-11 Thread Thomas S. Dye
Hi Eric,

Attached please find a first draft of a patch for the manual entry
documenting a :wrap header argument.

All the best,
Tom

From 4e3a66a4fbfd8d6914fbfd3924981ae5c526aa4a Mon Sep 17 00:00:00 2001
From: Thomas Dye d...@poto.myhome.westell.com
Date: Wed, 11 Jan 2012 16:06:17 -1000
Subject: [PATCH] * doc/org.texi: added documentation for :wrap

---
 doc/org.texi |   12 +++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index f619c90..7ca797b 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -715,6 +715,7 @@ Specific header arguments
 * rownames::Handle row names in tables
 * shebang:: Make tangled files executable
 * eval::Limit evaluation of specific code blocks
+* wrap::Mark source block evaluation results
 
 Miscellaneous
 
@@ -13007,6 +13008,7 @@ argument in lowercase letters.  The following header arguments are defined:
 * rownames::Handle row names in tables
 * shebang:: Make tangled files executable
 * eval::Limit evaluation of specific code blocks
+* wrap::Mark source block evaluation results
 @end menu
 
 Additional header arguments are defined on a language-specific basis, see
@@ -13865,7 +13867,7 @@ Setting the @code{:shebang} header argument to a string value
 first line of any tangled file holding the code block, and the file
 permissions of the tangled file are set to make it executable.
 
-@node eval,  , shebang, Specific header arguments
+@node eval, wrap, shebang, Specific header arguments
 @subsubsection @code{:eval}
 The @code{:eval} header argument can be used to limit the evaluation of
 specific code blocks.  The @code{:eval} header argument can be useful for
@@ -13890,6 +13892,14 @@ If this header argument is not set then evaluation is determined by the value
 of the @code{org-confirm-babel-evaluate} variable see @ref{Code evaluation
 security}.
 
+@node wrap, , eval, Specific header arguments
+@subsubsection @code{:wrap}
+The @code{:wrap} header argument is used to mark the results of source block
+evaluation.  The header argument can be passed a string that typically will
+be appended to @code{#+BEGIN_} and @code{#+END_}, which will then be used to
+wrap the results.  An exception to this rule is the string @code{drawer},
+which instead wraps the results in an Org mode drawer.
+
 @node Results of evaluation, Noweb reference syntax, Header arguments, Working With Source Code
 @section Results of evaluation
 @cindex code block, results of evaluation
-- 
1.7.5.4


t...@tsdye.com (Thomas S. Dye) writes:

 Eric Schulte eric.schu...@gmx.com writes:

 Achim Gratz strom...@nexgo.de writes:

 t...@tsdye.com (Thomas S. Dye) writes:
 The attached patch defines a new header argument, :special, which wraps
 the results of Org babel source block execution in a #BEGIN_ ... #+END_
 block.  The block name is taken from a new variable
 org-babel-wrap-special, which is initialized as results.

 What is the rationale for feeding the block name via a configuration
 variable rather then a value to the header argument :special?


 Regards,
 Achim.

 Attached is an alternate patch and an example of its use.  This patch
 introduces a :wrap header argument which accepts an optional value
 used to specify the name of the block with which to wrap results.  If
 this looks workable we could push it up once it gets some documentation
 and tests.

 Cheers,


 #+Title: demonstrating the new :wrap header argument

 #+begin_src emacs-lisp :wrap schulte
   '((1 2)
 (3 4))
 #+end_src

 #+results:
 #+BEGIN_schulte
 | 1 | 2 |
 | 3 | 4 |
 #+END_schulte

 Hi Eric,

 Thanks for the :wrap header argument.  It works for me.

 The attached patch on top of your patch looks for :wrap drawer, and puts
 the result in a drawer, rather than wrapping the results in #+begin
 ... #+end.

 What I'm trying to do is make :results wrap obsolete.

 Also, note that with the :wrap header argument, :results org and
 :results latex are both redundant.  I'm not sure how you want to handle
 this--whether to leave them in place or remove them.

 I'll volunteer to work on the documentation.

 All the best,
 Tom

-- 
Thomas S. Dye
http://www.tsdye.com


Re: [O] [PATCH] :wrap header documentation

2012-01-11 Thread Eric Schulte
Hi Tom,

Thanks for this patch, I've just pushed up an augmented version which
more closely matches the current behavior.

t...@tsdye.com (Thomas S. Dye) writes:

 Hi Eric,

 Attached please find a first draft of a patch for the manual entry
 documenting a :wrap header argument.

 All the best,
 Tom



 t...@tsdye.com (Thomas S. Dye) writes:

 Eric Schulte eric.schu...@gmx.com writes:

 Achim Gratz strom...@nexgo.de writes:

 t...@tsdye.com (Thomas S. Dye) writes:
 The attached patch defines a new header argument, :special, which wraps
 the results of Org babel source block execution in a #BEGIN_ ... #+END_
 block.  The block name is taken from a new variable
 org-babel-wrap-special, which is initialized as results.

 What is the rationale for feeding the block name via a configuration
 variable rather then a value to the header argument :special?


 Regards,
 Achim.

 Attached is an alternate patch and an example of its use.  This patch
 introduces a :wrap header argument which accepts an optional value
 used to specify the name of the block with which to wrap results.  If
 this looks workable we could push it up once it gets some documentation
 and tests.

 Cheers,


 #+Title: demonstrating the new :wrap header argument

 #+begin_src emacs-lisp :wrap schulte
   '((1 2)
 (3 4))
 #+end_src

 #+results:
 #+BEGIN_schulte
 | 1 | 2 |
 | 3 | 4 |
 #+END_schulte

 Hi Eric,

 Thanks for the :wrap header argument.  It works for me.

 The attached patch on top of your patch looks for :wrap drawer, and puts
 the result in a drawer, rather than wrapping the results in #+begin
 ... #+end.

 What I'm trying to do is make :results wrap obsolete.

 Also, note that with the :wrap header argument, :results org and
 :results latex are both redundant.  I'm not sure how you want to handle
 this--whether to leave them in place or remove them.

 I'll volunteer to work on the documentation.

 All the best,
 Tom

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



[O] Typo on French web page

2012-01-11 Thread François Pinard
Hi!

A tiny typo on page http://orgmode.org/fr/org-mode-support.html:

3 deniers commits git should read 3 derniers commits git

François.



Re: [O] [PATCH] :wrap header documentation

2012-01-11 Thread Thomas S. Dye
Hi Eric,

It's great to find :wrap in master.  Thanks for augmenting the draft.

All the best,
Tom

Eric Schulte eric.schu...@gmx.com writes:

 Hi Tom,

 Thanks for this patch, I've just pushed up an augmented version which
 more closely matches the current behavior.

 t...@tsdye.com (Thomas S. Dye) writes:

 Hi Eric,

 Attached please find a first draft of a patch for the manual entry
 documenting a :wrap header argument.

 All the best,
 Tom



 t...@tsdye.com (Thomas S. Dye) writes:

 Eric Schulte eric.schu...@gmx.com writes:

 Achim Gratz strom...@nexgo.de writes:

 t...@tsdye.com (Thomas S. Dye) writes:
 The attached patch defines a new header argument, :special, which wraps
 the results of Org babel source block execution in a #BEGIN_ ... #+END_
 block.  The block name is taken from a new variable
 org-babel-wrap-special, which is initialized as results.

 What is the rationale for feeding the block name via a configuration
 variable rather then a value to the header argument :special?


 Regards,
 Achim.

 Attached is an alternate patch and an example of its use.  This patch
 introduces a :wrap header argument which accepts an optional value
 used to specify the name of the block with which to wrap results.  If
 this looks workable we could push it up once it gets some documentation
 and tests.

 Cheers,


 #+Title: demonstrating the new :wrap header argument

 #+begin_src emacs-lisp :wrap schulte
   '((1 2)
 (3 4))
 #+end_src

 #+results:
 #+BEGIN_schulte
 | 1 | 2 |
 | 3 | 4 |
 #+END_schulte

 Hi Eric,

 Thanks for the :wrap header argument.  It works for me.

 The attached patch on top of your patch looks for :wrap drawer, and puts
 the result in a drawer, rather than wrapping the results in #+begin
 ... #+end.

 What I'm trying to do is make :results wrap obsolete.

 Also, note that with the :wrap header argument, :results org and
 :results latex are both redundant.  I'm not sure how you want to handle
 this--whether to leave them in place or remove them.

 I'll volunteer to work on the documentation.

 All the best,
 Tom

-- 
Thomas S. Dye
http://www.tsdye.com



Re: [O] Org-edit-special and C-x C-s strange behavior

2012-01-11 Thread Leo Alekseyev
On Wed, Jan 11, 2012 at 7:40 PM, Leo Alekseyev dnqu...@gmail.com wrote:
 Eric S Fraga e.fr...@ucl.ac.uk writes:

 What version of org are you using?  I ask because I used to experience
 the annoyance you describe a while back; more recently (since at least a
 few months ago), hitting C-x C-s no longer has any negative impact: it
 saves the file, or at least appears to.

 You still have to C-c ' to get back to the full buffer, mind you, but
 that's better, IMO, than changing the behaviour of such a fundamental
 key binding as C-x C-s.

 It appears that this bug is Emacs-version dependent: it functions as
 you describe with 23.2, but the buffer gets buried (with an error
 message basic-save-buffer: Wrong type argument: stringp, nil) in
 24.0.92.  Org mode is the current git HEAD.  I tried to step through
 basic-save-buffer in edebug, but I couldn't catch the error (I'm not
 very experienced with edebug).  Can someone test this on Emacs 24 and
 confirm what I'm seeing?

I've done some more digging into why this is broken. I see a few
issues, but no clear indication of where the problem is.  This,
however, should be fixed: pressing C-x C-s should not break window
configuration.

On Emacs 24, with latest Org:

1. Somehow, (org-edit-src-save) screws up the window configuration and
buries the source edit buffer.  It appears that save-window-excursion
is not restoring windows correctly.  What's going on exactly is
unclear: in the process of getting saved, the source edit buffer is
killed and subsequently restored with   (org-src-switch-to-buffer
buffer 'edit).  Maybe this doesn't play well with
save-window-excursion in Emacs 24?

I stepped through the calls in Emacs 23 and 24, and it all looks
identical -- except for in 24, the call to save-window-excursion does
not in fact restore windows.

2. In file.el:4435 (basic-save-buffer)
(nthcdr 10 (file-attributes buffer-file-name)) often leads to
wrong-type-argument error.  The reason for this is that
buffer-file-name sometimes corresponds to the base .org buffer (no
error in this case), sometimes it corresponds to the name of the
src-edit buffer and sometimes it's nil (leads to wrong-type-argument
error).  By this point, the file should have been written using
'write-contents-functions that is set to (org-edit-src-save), so I
don't know if this error is important (nonetheless, buffer-file-name
should probably be valid).

3. Related, in the same function:
(if (or (buffer-modified-p)
;; handle the case when no modification has been made but
;; the file disappeared since visited
(and buffer-file-name
 (not (file-exists-p buffer-file-name

This if statement is always triggered, because buffer-file-name is not
nil, and because the buffer doesn't correspond to the file.  (Note
that in Emacs 23 this was just (if (buffer-modified-p)...).  This is
not be the appropriate behavior, but it persists because
buffer-file-name is not nil (which it probably should be).

--l



Re: [O] [Orgmode] Automatic screenshot insertion

2012-01-11 Thread Skip Collins
On Wed, Jan 11, 2012 at 12:50 AM, Jambunathan K kjambunat...@gmail.com wrote:
 You and Jambunathan K. should form a club.

 Since I am being dragged in to the conversaion,

Of course I intend no disrespect for you or François. I have noticed
that org, perhaps not surprisingly, attracts people with a certain
detail-oriented aesthetic, similar in some ways to Knuth's obsessive
perfectionism. While Francois fancies himself an artist who works in
the medium of code, I suspect that most of those afflicted with OCD
(Org Compulsive Disorder) are closer in spirit to the artisan or
craftsman than to the artist.



Re: [O] [Orgmode] Automatic screenshot insertion

2012-01-11 Thread Thomas S. Dye
Hi Skip,

I love OCD!  Thanks for that one.

And, thank goodness the Org mode community is big enough for artists,
artisans, and crafts people.  

I find it fascinating to use software created by such a diverse
community.  I've often thought I'm glimpsing the future.

All the best,
Tom


Skip Collins skip.coll...@gmail.com writes:

 On Wed, Jan 11, 2012 at 12:50 AM, Jambunathan K kjambunat...@gmail.com 
 wrote:
 You and Jambunathan K. should form a club.

 Since I am being dragged in to the conversaion,

 Of course I intend no disrespect for you or François. I have noticed
 that org, perhaps not surprisingly, attracts people with a certain
 detail-oriented aesthetic, similar in some ways to Knuth's obsessive
 perfectionism. While Francois fancies himself an artist who works in
 the medium of code, I suspect that most of those afflicted with OCD
 (Org Compulsive Disorder) are closer in spirit to the artisan or
 craftsman than to the artist.



-- 
Thomas S. Dye
http://www.tsdye.com



Re: [O] Typo on French web page

2012-01-11 Thread Bastien
pin...@iro.umontreal.ca (François Pinard) writes:

 A tiny typo on page http://orgmode.org/fr/org-mode-support.html:

 3 deniers commits git should read 3 derniers commits git

Fixed, thanks.

-- 
 Bastien



Re: [O] [PATCH] Fix typo in manual

2012-01-11 Thread Bastien
t...@tsdye.com (Thomas S. Dye) writes:

 This patch to the manual fixes a typo.

Applied, thanks!

-- 
 Bastien



Re: [O] Capitalisation and good taste ?

2012-01-11 Thread Bastien
Eric Schulte eric.schu...@gmx.com writes:

 I'm going to push up a patch which will change to inserting #+RESULTS:
 by default as well as a user-configurable variable which can be used to
 customize this behavior.

 Done.  This variable is named `org-babel-results-keyword'

Great, thanks.  I've also changed the default value of
`org-structure-template-alist' so that easy templates are 
using uppercase by default.  If people prefer lowercase,
please customize this option.

-- 
 Bastien