Re: [O] :noweb header argument
Hi Thomas, Eric(s) and all,
Thomas S. Dye wrote:
> Eric Schulte writes:
>> t...@tsdye.com (Thomas S. Dye) writes:
>>> "Sebastien Vauban" 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
Re: [O] inline src_R also in latex src block
Michael Bach writes:
> Andreas Leha 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}
>> <>
>> \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 <> 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}
<>
!=
<>
\end{equation}
#+end_src
Cheers,
Andreas
[O] [bug] alias for list-diary-entries-hook creates loop in emacs 24
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
Eric S Fraga 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
d.tchin writes: > Eric S Fraga 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
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?
-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
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/01/12 08:45, Eric Schulte wrote:
> Frozenlock 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 ?
Bastien 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 ?
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
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
"Sebastien Vauban" 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
Bastien writes: > Karl Voit 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
Giovanni Giorgi 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 ` 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
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
Leo Alekseyev 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
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
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) "") "\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 / 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?
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?
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
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
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
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
> | 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
Hi Phil On Tue, Jan 10, 2012 at 14:39, Phil (Philip) Mason 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
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
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
Aloha all,
Attached please find subject patch.
All the best,
Tom
>From bd3579cef735c2bb62c37a4d394597be384fe18d Mon Sep 17 00:00:00 2001
From: Thomas Dye
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
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
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
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
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 ?
Bastien writes: > Bastien 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
Eric S Fraga writes: > Leo Alekseyev 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 ?
> > 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 ?
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
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 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
András Major 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 ?
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 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
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
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
> Eric S Fraga 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
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 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/01/12 08:45, Eric Schulte wrote:
>> Frozenlock 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
> 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
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
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 writes:
>
>> Achim Gratz 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
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 writes: >> >>> Achim Gratz 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
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
Hi Eric, It's great to find :wrap in master. Thanks for augmenting the draft. All the best, Tom Eric Schulte 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 writes: >>> Achim Gratz 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
On Wed, Jan 11, 2012 at 7:40 PM, Leo Alekseyev wrote: >> Eric S Fraga 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
On Wed, Jan 11, 2012 at 12:50 AM, Jambunathan K 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
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 writes: > On Wed, Jan 11, 2012 at 12:50 AM, Jambunathan K > 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
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
t...@tsdye.com (Thomas S. Dye) writes: > This patch to the manual fixes a typo. Applied, thanks! -- Bastien
Re: [O] Capitalisation and good taste ?
Eric Schulte 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
