Re: [O] :noweb header argument
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: [...] 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. +1 for both 1) the :noweb no-export or similar 2) and the possibility to include source block names in export - Andreas
Re: [O] Unable to unfold a folded block having point directly after the folded block
Am 04.01.2012 11:27, schrieb Bastien: Hi Rainer, Rainer Stengele rainer.steng...@online.de writes: I just pulled and checked but cannot see a change. Did you check in the fix already? Yes I did. Try with (setq org-special-ctrl-a/e nil) C-e goes *after* the end of the invisible region and TAB will do nothing here, either in a folded subtree or in a folded drawer. With (setq org-special-ctrl-a/e 'reversed) C-e goes *right before* the end of the invisible region and TAB will unfold as expected, both in a folded subtree or in a folded drawer. This behavior is more consistent than the previous one. But you need to set `org-special-ctrl-a/e' according to your needs. HTH, Hi Bastien and Carsten, I do have (setq org-special-ctrl-a/e 'reversed) and it works as expected when jumping to the end of line with C-e. But I do use cursor keys to move one line down. Point at end of line and moving down one line with cursor down I cannot unfold the block by pressing TAB. Is there a chance to get this done when using the cursor movement? Thanks, Rainer
Re: [O] [Orgmode] Automatic screenshot insertion
pin...@iro.umontreal.ca (François Pinard) writes: [...] Hi, Eric. Sorry. Here is a quick correction for that problem. This is only this week that I plan to use that function for actual work; last week was rather an exploration of the capability of various tools. Of course, do not hesitate if you see that I goofed elsewhere! :-). Thanks. This correction did not work for me out of the box. I had to add a call to expand-file-name for getting a file name which worked on my system for some reason. I also re-arranged your second (unless ...) to an (if ...): #+begin_src emacs-lisp (defun fp-org-image (name) Insert a link to an already existing image, or else to a screenshot. The screenshot is either taken to the given non-existing file name, or added into the given directory, defaulting to the current one. ;; FIXME: Should limit to '(pdf jpeg jpg png ps eps) ;; which is org-export-latex-inline-image-extensions. (interactive GImage name? ) (when (file-directory-p name) (setq name (concat (make-temp-name (expand-file-name (concat (file-name-as-directory name) (subst-char-in-string . - (file-name-sans-extension (file-name-nondirectory (buffer-file-name))) .png))) (unless (file-exists-p name) (if (file-writable-p name) (progn (message Taking screenshot into %s name) (call-process import nil nil nil name) (message Taking screenshot...done)) (error Cannot create image file))) (insert (concat [[ name ]])) (org-display-inline-images)) #+end_src This now appears to work (for me). 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.67.g56c73)
[O] S-tab in source blocks
Hi all, is it possible to make S-tab call the global org-cycle when the point is in a source block? Best, Andreas
Re: [O] if both schedule and deadline, appear only once in agenda
On Fri, 12 Oct 2007 14:36:42 +0100 Bastien b...@altern.org wrote: Gijs Hillenius g...@hillenius.net writes: But maybe I should not :-). But here goes: I plan to start working on an item by date X - schedule stamp. The item has a deadline, so - deadline. For that I use `org-deadline-warning-days'. I start the deadline when it shows up in my agenda. The default value for this is 14, but you can set a value for each deadline like this: I'm all on Gijs' side in using SCHEDULED and DEADLINE just the way he does. A deadline warning for me describes some different kind of animal. Nevertheless: If both SCHEDULED and DEADLINE passed by and no work was done either there was no real deadline or there is a new deadline or now you're allowed to remove the task silently. :-) Detlef DEADLINE: 2004-02-29 Sun -10d Meaning that you should start the deadline 10 days before the deadline. ,[ (info (org)Deadlines and scheduling) ] | You can specify a different lead time for warnings for a specific | deadlines using the following syntax. Here is an example with a | warning period of 5 days `DEADLINE: 2004-02-29 Sun -5d'. ` HTH, -- Bastien ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[O] Symbol's function definition is void: org-write-agenda
Hi! I am using Org-mode from git and do face a problem when using a function that previously worked for a couple of weeks without any problem: Error-Message: #+begin_verse vk-export-agenda: Symbol's function definition is void: org-write-agenda #+end_verse #+begin_src emacs-lisp (defun vk-export-agenda() Exports monthly Org-mode agenda to agenda.ics file (interactive) (org-agenda-list nil nil 60) (org-write-agenda ~/share/all/org-mode/agenda.ics) ) #+end_src Do you have an idea, what might have changed? Thanks! -- Karl Voit
Re: [O] :noweb header argument
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: [...] Some time after that, we had block names in the HTML/PDF output, but not anymore. I've been wondering about this for some time. The appearance of source code block names in exported latex output comes and goes in what appears to me as a random process! Personally, I don't want these names exported *ever* as they cause problems with latex, my usual target, especially because the # sign is interpreted by latex as an argument to a macro which typically doesn't make sense. My most recent use of exporting code blocks has not included the names, so I'm happy. However, only a couple of weeks ago, the names were exported. That was for a different file so maybe my settings were different? It would be nice to have some clarity on when names will appear or not and how this can be controlled. I've looked at the manual but have not found any reference to how code block names are treated on export. Any pointers would be most welcome! Thanks, eric PS - apologies for possibly hijacking this thread. -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.92.1 : using Org-mode version 7.8.03 (release_7.8.03.67.g56c73)
Re: [O] Symbol's function definition is void: org-write-agenda
Hi Karl, Karl Voit devn...@karl-voit.at writes: I am using Org-mode from git and do face a problem when using a function that previously worked for a couple of weeks without any problem: Error-Message: #+begin_verse vk-export-agenda: Symbol's function definition is void: org-write-agenda #+end_verse #+begin_src emacs-lisp (defun vk-export-agenda() Exports monthly Org-mode agenda to agenda.ics file (interactive) (org-agenda-list nil nil 60) (org-write-agenda ~/share/all/org-mode/agenda.ics) ) #+end_src Do you have an idea, what might have changed? `org-write-agenda' has been renamed to `org-agenda-write', please update your code. Thanks, -- Bastien
Re: [O] Symbol's function definition is void: org-write-agenda
* Bastien b...@altern.org wrote: Hi Karl, Hi! Karl Voit devn...@karl-voit.at writes: vk-export-agenda: Symbol's function definition is void: org-write-agenda `org-write-agenda' has been renamed to `org-agenda-write', please update your code. Thanks for the hint! Missed in in the change notes ... -- Karl Voit
Re: [O] Symbol's function definition is void: org-write-agenda
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! -- Bastien
Re: [O] inline src_R also in latex src block
Eric Schulte eric.schu...@gmx.com writes: I don't know of a way to evaluate inline code blocks which are already inside of regular code blocks. Thanks for your thoughts on this, Eric. This would be *really* convenient for me. Too bad the christmas wishlist was processed already. You could try direct begin_latex code blocks, but in-buffer font lock support may simply not be possible in this situation. Sadly, direct begin_latex code blocks get fontified with `org-block' and also export the inline `src_R' snippets literally. What I was looking for is latex code fontified as AUCTeX and inline `src_R' snippets evaluated prior to exporting. The only working combination I got right now is inline `src_R' evaluation and no AUCTeX font-lock. This is only a minor itch and not too bad considering what org-mode already does for me. Best Regards, Michael
Re: [O] S-tab in source blocks
Andreas Leha andreas.l...@med.uni-goettingen.de writes: is it possible to make S-tab call the global org-cycle when the point is in a source block? Yes, (setq org-src-tab-acts-natively nil) Regards, Bernt
Re: [O] S-tab in source blocks
Bernt Hansen be...@norang.ca writes: Andreas Leha andreas.l...@med.uni-goettingen.de writes: is it possible to make S-tab call the global org-cycle when the point is in a source block? Yes, (setq org-src-tab-acts-natively nil) Regards, Bernt Hi Bernt, thanks. But that disables tab as well. So to clarify: I am looking for native tab and S-tab calling the globel org-cycle. Cheers, Andreas
Re: [O] S-tab in source blocks
Bernt Hansen be...@norang.ca writes: Andreas Leha andreas.l...@med.uni-goettingen.de writes: is it possible to make S-tab call the global org-cycle when the point is in a source block? Yes, (setq org-src-tab-acts-natively nil) Still, we could have TAB indent code in source blocks, and S-TAB do the global cycling. I'll look into it. -- Bastien
Re: [O] inline src_R also in latex src block
Michael Bach pha...@gmail.com writes:
Eric Schulte eric.schu...@gmx.com writes:
I don't know of a way to evaluate inline code blocks which are already
inside of regular code blocks.
Thanks for your thoughts on this, Eric. This would be *really*
convenient for me. Too bad the christmas wishlist was processed
already.
You could try direct begin_latex code blocks, but in-buffer font lock
support may simply not be possible in this situation.
Sadly, direct begin_latex code blocks get fontified with `org-block' and
also export the inline `src_R' snippets literally.
What I was looking for is latex code fontified as AUCTeX and inline
`src_R' snippets evaluated prior to exporting. The only working
combination I got right now is inline `src_R' evaluation and no AUCTeX
font-lock. This is only a minor itch and not too bad considering what
org-mode already does for me.
Best Regards,
Michael
Hi Michael,
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
Cheers,
Andreas
[O] org-preview-latex-fragment does not include #+LaTeX_CLASS definition
Hello everyone, org-mode version 7.8.02 When doing `org-preview-latex-fragment' on a buffer with custom set #+LaTeX_CLASS and some #+LATEX_HEADER lines, the pdflatex process to create the ltxpng/*.png images fails e.g. with: Failed to create dvi file from /tmp/orgtex1650tNa.tex Now when I check the temporary .tex file under e.g. /tmp/orgtex1650tNa.tex, I see that the #+LATEX_HEADER: parts of my file got put in, but the preamble does not include the #+LaTeX_CLASS \usepackage definitions. The #+LATEX_HEADER lines depend on the packages loaded in my #+LaTeX_CLASS definition, so there is no wonder pdflatex fails. My actual question: Why is the tmp tex file generated without the custom #+LaTeX_CLASS preamble? Best Regards, Michael
Re: [O] [Orgmode] Automatic screenshot insertion
Eric S Fraga e.fr...@ucl.ac.uk writes: Hi again, Eric. I'll be using your corrections on the code, thanks! I had to add a call to expand-file-name for getting a file name which worked on my system for some reason. (make-temp-name (expand-file-name (concat (file-name-as-directory name) (subst-char-in-string . - (file-name-sans-extension (file-name-nondirectory (buffer-file-name))) .png))) Not a big deal, but I wonder if it should not rather be: (make-temp-name (concat (expand-file-name (file-name-as-directory name)) (subst-char-in-string . - (file-name-sans-extension (file-name-nondirectory (buffer-file-name)) as there is nothing to expand in the base part of the file name? I also re-arranged your second (unless ...) to an (if ...): (if (file-writable-p name) (progn (message Taking screenshot into %s name) (call-process import nil nil nil name) (message Taking screenshot...done)) (error Cannot create image file)) I kept it, but I might likely revert it back routinely to the earlier state, if I later happen to revisit that code. Just to show you how maniacal I may be, let me explain. I just do not like (progn ...), and make stunts to avoid it. I would rather write: (if (not (file-writable-p name)) (error Cannot create image file) (message Taking screenshot into %s name) (call-process import nil nil nil name) (message Taking screenshot...done)) Then, besides a few exceptions, I generally do not like else clauses after returning or other escaping statements, so the above becomes: (if (not (file-writable-p name)) (error Cannot create image file)) (message Taking screenshot into %s name) (call-process import nil nil nil name) (message Taking screenshot...done) Finally, I avoid (not ...) when this is easily done. I will always exchange the two branches of an if to get rid of one (unless it would imply re-introducing (progn ...), as progn is uglier than not :-). Easier here, as (if (not ...)) may be rewritten (unless ...). By the way, (when ...) is always nicer than a single-branched if. Scheme is especially irritating. They said it is minimalist, and yet, they have many ways to write conditional code, forcing me to choose constantly. I will turn (if ...) into (cond ...) if a (begin ...) becomes necessary on either branch. And a (cond ...) back to an (if ...) if while simplifying a cond, I see it could written to an if without begin. And there is always this stretch towards tail recursion, and so many ways to reuse or not local variables as arguments, doing so. Irritating I say. And yet, I love this language. Maniacal I am, really! François P.S. If you happen to grok French, you might have fun reading me (or making fun of me reading...): http://icule.blogspot.com/1997/02/dieu-la-douleur-et-l.html
Re: [O] Capitalisation and good taste ?
Nick Dokos nicholas.do...@hp.com writes: François Pinard pin...@iro.umontreal.ca wrote: P.P.S. How about amending the manual for consistent capitalization? Knock yourself out! ;-) I've absolutely nothing against doing that little work myself (that one is easy enough!), besides the idea that I might be working against the crowd. If nobody objects that I normalize everything (every #+ thing) to lower case, I'll happily do it. If the only result of a patch would be to start a flame war (or just loosing my time), I'd better stay quiet... Always easier to formally ask permission once you informally got it! François
Re: [O] :noweb header argument
Hi Seb,
Sebastien Vauban wxhgmqzgw...@spammotel.com writes:
Hi Thomas,
Thomas S. Dye wrote:
Is there a difference between :noweb tangle and :noweb no?
Yes: :noweb no is the default, and must *not expand* anything.
Based on the documentation and some limited testing, I made the following
table.
*** :noweb parameters
| param | eval | tangle | export |
|+--++|
| yes| +| + | + |
| no | -| + | - |
It should be -, -, - here, if - means no expansion.
Hmm, the manual entry for :noweb no says However, noweb references will
still be expanded during tangling. You're right, though, :noweb no
doesn't expand noweb references during tangling. I'll work up a manual
patch.
| tangle | -| + | - |
|+--++|
| need | +| + | - |
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.
Find attached the 2 PDF I had written (in 2009) for comparing NoWeb's
rendering of blocks and Babel's rendering. See
http://lists.gnu.org/archive/html/emacs-orgmode/2009-12/msg00170.html.
Some time after that, we had block names in the HTML/PDF output, but not
anymore.
Best regards,
Seb
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] Capitalisation and good taste ?
François Pinard pin...@iro.umontreal.ca wrote: Nick Dokos nicholas.do...@hp.com writes: François Pinard pin...@iro.umontreal.ca wrote: P.P.S. How about amending the manual for consistent capitalization? Knock yourself out! ;-) I've absolutely nothing against doing that little work myself (that one is easy enough!), besides the idea that I might be working against the crowd. If nobody objects that I normalize everything (every #+ thing) to lower case, I'll happily do it. If the only result of a patch would be to start a flame war (or just loosing my time), I'd better stay quiet... Always easier to formally ask permission once you informally got it! OK - I'm not the one to ask permission from, but I doubt very much that a flame war will erupt because of a patch to make things in the manual more uniform (of course, there will have to be a notation somewhere, if one is not there already, that capitalization does not matter in these cases: it's easy to infer that when all the examples are in various forms of capitalization, but harder when everything is uniform - as you can see, uniformity is not an unmitigated blessing :-) ). Nick
[O] [PATCH] Revise manual entry for :noweb no
Aloha all,
The attached patch to the manual is intended to make the description of
:noweb no conform to its behavior.
All the best,
Tom
From 7207cdec84daecd31d4e53117c477abaad91bbd1 Mon Sep 17 00:00:00 2001
From: Thomas Dye dk@poto.local
Date: Tue, 10 Jan 2012 06:06:49 -1000
Subject: [PATCH] * doc/org.texi: Edit :noweb no header argument for
correctness
---
doc/org.texi |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index c4031d7..c3405f1 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -13583,9 +13583,8 @@ argument can have one of three values: @code{yes}, @code{no}, or @code{tangle}.
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 on evaluating
-code blocks, However, noweb references will still be expanded during
-tangling.
+The default. No ``noweb'' syntax specific action is taken when 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
--
1.7.5.4
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] :noweb header argument
t...@tsdye.com (Thomas S. Dye) writes:
Hi Seb,
Sebastien Vauban wxhgmqzgw...@spammotel.com writes:
Hi Thomas,
Thomas S. Dye wrote:
Is there a difference between :noweb tangle and :noweb no?
Yes: :noweb no is the default, and must *not expand* anything.
Based on the documentation and some limited testing, I made the following
table.
*** :noweb parameters
| param | eval | tangle | export |
|+--++|
| yes| +| + | + |
| no | -| + | - |
It should be -, -, - here, if - means no expansion.
Hmm, the manual entry for :noweb no says However, noweb references will
still be expanded during tangling. You're right, though, :noweb no
doesn't expand noweb references during tangling. I'll work up a manual
patch.
Great, I'll apply your documentation patch.
| tangle | -| + | - |
|+--++|
| need | +| + | - |
What should the name for such an option be?
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.
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.
Cheers,
Find attached the 2 PDF I had written (in 2009) for comparing NoWeb's
rendering of blocks and Babel's rendering. See
http://lists.gnu.org/archive/html/emacs-orgmode/2009-12/msg00170.html.
Some time after that, we had block names in the HTML/PDF output, but not
anymore.
Best regards,
Seb
All the best,
Tom
--
Eric Schulte
http://cs.unm.edu/~eschulte/
Re: [O] [PATCH] Revise manual entry for :noweb no
Applied, Thanks, t...@tsdye.com (Thomas S. Dye) writes: Aloha all, The attached patch to the manual is intended to make the description of :noweb no conform to its behavior. All the best, Tom -- Eric Schulte http://cs.unm.edu/~eschulte/
[O] Diacritics in image file names
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
Re: [O] [Orgmode] Automatic screenshot insertion
pin...@iro.umontreal.ca (François Pinard) writes: Eric S Fraga e.fr...@ucl.ac.uk writes: Hi again, Eric. I'll be using your corrections on the code, thanks! You're welcome! I had to add a call to expand-file-name for getting a file name which worked on my system for some reason. (make-temp-name (expand-file-name (concat (file-name-as-directory name) (subst-char-in-string . - (file-name-sans-extension (file-name-nondirectory (buffer-file-name))) .png))) Not a big deal, but I wonder if it should not rather be: (make-temp-name (concat (expand-file-name (file-name-as-directory name)) (subst-char-in-string . - (file-name-sans-extension (file-name-nondirectory (buffer-file-name)) as there is nothing to expand in the base part of the file name? Yes, this would be equivalent in this case. I guess I prefer the former but only for reasons of style! I also re-arranged your second (unless ...) to an (if ...): (if (file-writable-p name) (progn (message Taking screenshot into %s name) (call-process import nil nil nil name) (message Taking screenshot...done)) (error Cannot create image file)) I kept it, but I might likely revert it back routinely to the earlier state, if I later happen to revisit that code. Just to show you how maniacal I may be, let me explain. I just do not like (progn ...), and make stunts to avoid it. I would rather write: Well, the progn is only there because of the debugging messages I needed to see what was happening... I should probably get to grips with the debugger instead :( [...] Maniacal I am, really! No, simply differing styles! I appreciate your reasoning in each case I've elided but, in the end, the different versions or approaches you mention are all essentially equivalent (computationally)... :-) François P.S. If you happen to grok French, you might have fun reading me (or making fun of me reading...): http://icule.blogspot.com/1997/02/dieu-la-douleur-et-l.html I grok French a little (as a Canadian, albeit one from the west...) so will have a look at this when I am back online! 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.69.gfadca)
Re: [O] Capitalisation and good taste ?
Hey François, bh I wouldn't spend too much time agonizing over the 'right' way fp Truth is that I've been so agonizing for the whole of my computer fp life! Each one his sickness, I guess... :-) I understand your pain. Have you read The Paradox of Choice by Bary Schwartz? Sounds as if you (like me) are a Maximizer on this kind of thing :-). As a fellow sufferer, let me put you out of your misery and choose for you: First, let's acknowledge the primary raison d'etre of capitals is to enhance ease of reading by making one class of word stand out in an environment where -- crucially -- more than one class of word may be present (e.g. starts of sentences in block of prose, or constants (say) in code). So here, it doesn't really matter. Therefore, let's make ease of writing be the deciding factor. #+latex_header: Best (it would be even better if that underscore was a hyphen but we can't have everything). #+LATEX_HEADER: Next best #+Latex_Header: Worse. #+LaTeX_HEADER: Worst. Yeah, yeah, it's correct but I'm not hitting Shift three times when I can hit it no times :-) toMmY
Re: [O] :noweb header argument
Hi Eric,
Eric Schulte eric.schu...@gmx.com writes:
t...@tsdye.com (Thomas S. Dye) writes:
Hi Seb,
Sebastien Vauban wxhgmqzgw...@spammotel.com writes:
Hi Thomas,
Thomas S. Dye wrote:
Is there a difference between :noweb tangle and :noweb no?
Yes: :noweb no is the default, and must *not expand* anything.
Based on the documentation and some limited testing, I made the following
table.
*** :noweb parameters
| param | eval | tangle | export |
|+--++|
| yes| +| + | + |
| no | -| + | - |
It should be -, -, - here, if - means no expansion.
Hmm, the manual entry for :noweb no says However, noweb references will
still be expanded during tangling. You're right, though, :noweb no
doesn't expand noweb references during tangling. I'll work up a manual
patch.
Great, I'll apply your documentation patch.
| tangle | -| + | - |
|+--++|
| need | +| + | - |
What should the name for such an option be?
Andreas' suggestion, :noweb no-export, seems right to me.
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.
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.
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 to go on and on. I do much of my writing in Org mode now,
somewhat unexpectedly. There are still some rough spots, where I can't
seem to get the control I exercise in LaTeX (though these often enough
turn out to be my own ignorance). On the other hand, I'm way more
productive than I've ever been, and am able to accomplish new and
interesting
Re: [O] [Orgmode] Automatic screenshot insertion
Eric S Fraga e.fr...@ucl.ac.uk writes: I appreciate your reasoning in each case I've elided but, in the end, the different versions or approaches you mention are all essentially equivalent (computationally)... :-) Who cares about computation! :-) Some sad people think of me as a programmer. While deep down, I am fundamentally an artist. Programming is mere mean of expression :-). Thanks again, I'm the one thanking you! François
[O] [org-babel] break when used with header in emacs 22.3
Hi, I would like to report a problem of evalation when org-babel is used with emacs 22.3 on windows and recent org-mode 7.8.03. I use the following code : #+begin_src sh :results silent ls #+end_src It breaks when a header is used. When evaluated with C-c C-c, the following message appears : matched: Wrong type argument: listp, 58 The configuration is the following : Org-mode version 7.8.03 GNU Emacs 22.3.1 (i386-mingw-nt5.1.2600) of 2008-09-06 on SOFT-MJASON Mark set With the following version of emacs, it works : GNU Emacs 23.3.1 (i386-mingw-nt5.1.2600) of 2011-03-10 on 3249CTO Regards
Re: [O] Capitalisation and good taste ?
Hi François, pin...@iro.umontreal.ca (François Pinard) writes: P.P.S. How about amending the manual for consistent capitalization? I've pushed a fix for this. The manual used mostly uppercase so I fixed the few lowercase instances of option/environment keywords. I made an exception for #+results, which is dynamically used with lowercase. For the historical note: Carsten used uppercase most of the time, and Eric introduced lowercase. To me, uppercase looks better in the manual, and also means this is a predefined keyword (see the other rules for TODO, tags and properties.) Thanks for raising this, -- Bastien
Re: [O] Capitalisation and good taste ?
Bastien b...@altern.org writes: Hi François, pin...@iro.umontreal.ca (François Pinard) writes: P.P.S. How about amending the manual for consistent capitalization? I've pushed a fix for this. The manual used mostly uppercase so I fixed the few lowercase instances of option/environment keywords. I made an exception for #+results, which is dynamically used with lowercase. For the historical note: Carsten used uppercase most of the time, and Eric introduced lowercase. To me, uppercase looks better in the manual, and also means this is a predefined keyword (see the other rules for TODO, tags and properties.) Thanks for raising this, Ah! I don't mean to introduce inconsistencies. I would be happy to change the dynamic #+results: generation so that it instead inserts #+RESULTS: into the buffer. I believe the gain in consistency out-weights any aesthetic concerns. That said I'm happy that Org-mode is forgiving enough to allow me to lowercase most of my keywords locally. Best, -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [Orgmode] Automatic screenshot insertion
2012/1/10 François Pinard pin...@iro.umontreal.ca: Some sad people think of me as a programmer. While deep down, I am fundamentally an artist. Programming is mere mean of expression :-). You and Jambunathan K. should form a club.
Re: [O] Capitalisation and good taste ?
Eric Schulte eric.schu...@gmx.com writes: That said I'm happy that Org-mode is forgiving enough to allow me to lowercase most of my keywords locally. 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. Eric, what do you think? -- Bastien
Re: [O] [org-babel] break when used with header in emacs 22.3
d.tchin d.tc...@voila.fr writes: Hi, I would like to report a problem of evalation when org-babel is used with emacs 22.3 on windows and recent org-mode 7.8.03. I use the following code : #+begin_src sh :results silent ls #+end_src It breaks when a header is used. When evaluated with C-c C-c, the following message appears : matched: Wrong type argument: listp, 58 The configuration is the following : Org-mode version 7.8.03 GNU Emacs 22.3.1 (i386-mingw-nt5.1.2600) of 2008-09-06 on SOFT-MJASON Mark set With the following version of emacs, it works : GNU Emacs 23.3.1 (i386-mingw-nt5.1.2600) of 2011-03-10 on 3249CTO Regards This same issue was raised recently on the mailing list and (I believe) a patch has been pushed to the git repository. Would you mind checking if the problem persists in the git head? Thanks, -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [org-babel] break when used with header in emacs 22.3
Eric Schulte eric.schulte at gmx.com writes: This same issue was raised recently on the mailing list and (I believe) a patch has been pushed to the git repository. Would you mind checking if the problem persists in the git head? I download org-latest.zip archive and test it. This version solves this problem. I have a side effect : the agenda display doesn't work anymore. I have the following message when I stroke C-c a a. Press key for agenda command: let*: Symbol's value as variable is void: diary-list-entries-hook Thanks, Thanks
Re: [O] Capitalisation and good taste ?
Bastien b...@altern.org writes: Eric Schulte eric.schu...@gmx.com writes: That said I'm happy that Org-mode is forgiving enough to allow me to lowercase most of my keywords locally. 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 surely like this! :-). 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). François
Re: [O] [org-babel] break when used with header in emacs 22.3
d.tchin d.tc...@voila.fr writes: I have the following message when I stroke C-c a a. Press key for agenda command: let*: Symbol's value as variable is void: diary-list-entries-hook Fixed in the git HEAD. Please download org-latest.zip in 24 hours or use the git repo. PS: the problem was that list-diary-entries-hook is obsolete in recent version of Emacs and I did not create an alias from this name to the new name `diary-list-entries-hook' because I thought Emacs would take care of this. -- Bastien
Re: [O] [Orgmode] Automatic screenshot insertion
pin...@iro.umontreal.ca (François Pinard) writes: Some sad people think of me as a programmer. While deep down, I am fundamentally an artist. Programming is mere mean of expression :-). Hence: D Knuth: The Art of computer programming https://en.wikipedia.org/wiki/The_Art_of_Computer_Programming or programming for expression (well, a form of art) instead: Prusinkiewicz Lindenmayer (1990), The algorithmic beauty of plants [[http://algorithmicbotany.org/papers/#abop]] You can download the latter from the site! Anyway, totally and utterly OT! :-) I'm done! -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.92.1 : using Org-mode version 7.8.03 (release_7.8.03.73.gd2b3d)
Re: [O] Capitalisation and good taste ?
pin...@iro.umontreal.ca (François Pinard) writes: Bastien b...@altern.org writes: Eric Schulte eric.schu...@gmx.com writes: That said I'm happy that Org-mode is forgiving enough to allow me to lowercase most of my keywords locally. Actually, I'm thinking of another solution: - keep one-line option/environment keywords uppercase #+NAME #+HTML #+TITLE #+... [...] Personally, I would like to be able to do: ** Some code ~~~ emacs-lisp (some-code goes-here) ~~~ ... which compands to: ** Some code ~~~ el... Personally I dislike capitalized labels immensely! [...] Best, Martyn
Re: [O] :noweb header argument
Eric Schulte eric.schu...@gmx.com writes:
t...@tsdye.com (Thomas S. Dye) writes:
[...]
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.
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.
There is some precedence for having target specific customisations, even
if that is not a pretty approach. As an example that has come up
recently, and one that I was just using a few minutes ago (!), we have
,[ C-h v org-export-latex-timestamp-markup RET ]
| org-export-latex-timestamp-markup is a variable defined in `org-latex.el'.
| Its value is \\hfill Action created or updated: %s
| Original value was \\textit{%s}
|
| Documentation:
| A printf format string to be applied to time stamps.
|
| You can customize this variable.
|
| [back]
`
Although I can see the benefit of a generic intermediate step, I am of
the belief that target specific markups are going to be more powerful
and likely more useful...
Just my two ¢.
--
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.92.1
: using Org-mode version 7.8.03 (release_7.8.03.73.gd2b3d)
[O] org-property-accumulation tests broken
Just a testing head's up... commit f1043a53cc46d2ce2e578d3cb498f895dc65f1ff breaks the tests. FAILED test-org-property-accumulation-append-use FAILED test-org-property-accumulation-append-val FAILED test-org-property-accumulation-top-use FAILED test-org-property-accumulation-top-val Best, Martyn
Re: [O] Minor org mode for achieve code folding effects
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. Carsten has already given you one possible solution; another is to use org + babel with tangling to have each function or method within a separate headline in an org document. Check out the manual: (org) Working With Source Code or, within that section, the subsection (org) Extracting source code -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.92.1 : using Org-mode version 7.8.03 (release_7.8.03.73.gd2b3d)
Re: [O] text background when exporting as HTML
David Rogoff da...@therogoffs.com writes: Hi all. I'm using orgmode for outlines and documentation. Since no one else I work with does this, I export to HTML which generally works fine. However, I've got a problem with embedded code samples using #+BEGIN_SRC / #+END_SRC. The faces for the source code are set up for a black background. The exported HTML picked up the face colors, but the background is white, so they're mostly unreadable. Is there a (hopefully simple) way to tell the HTML export to specify a black background for these blocks? FYI, emacs 23.3.1, REH Linux, orgmode 7.5 Thanks, David Check out the info manual: (org) CSS support This might be the easiest way. -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.92.1 : using Org-mode version 7.8.03 (release_7.8.03.73.gd2b3d)
Re: [O] Capitalisation and good taste ?
pin...@iro.umontreal.ca (François Pinard) writes: Hi, Org people. I really have mixed feelings about capitalisation of #+WORDS, and wonder if some consensus and good taste has developed over time among Org mode users. What is the collective wisdom saying as being nicer among: [...] Maybe this has already been debated to death? I do not know for Org mode files, yet I know that style issues are usually flame-prone. I'm surely not trying to start any kind of war. Nevertheless, I would like if the manual and the Wiki select and document a preferred convention, and were amended to be very consistent on it. So, I'll have a clear model to follow. :-) François I have problems with RSI so try to minimise any key-chording, including capital letters, as much as possible (hence my use of evil-mode in emacs and extensive use of both completion and abbreviations for acronyms...). But I am happy for everybody to use what they prefer and I am just happy that org is case insensitive in general! -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.92.1 : using Org-mode version 7.8.03 (release_7.8.03.73.gd2b3d)
Re: [O] text background when exporting as HTML
Hi all.
I'm using orgmode for outlines and documentation. Since no one else I
work with does this, I export to HTML which generally works
fine. However, I've got a problem with embedded code samples using
#+BEGIN_SRC / #+END_SRC. The faces for the source code are set up
for a black background. The exported HTML picked up the face colors,
but the background is white, so they're mostly unreadable. Is there a
(hopefully simple) way to tell the HTML export to specify a black
background for these blocks?
FYI, emacs 23.3.1, REH Linux, orgmode 7.5
Thanks,
David
Check out the info manual: (org) CSS support
This might be the easiest way.
-- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.92.1
Thanks Eric. I searched around the mailing list archives and found this:
http://thread.gmane.org/gmane.emacs.orgmode/19605/focus=19633
I just added this to the beginning of my org file and it works great:
#+STYLE: style pre { background-color: #191919 } pre { color:#00FF00 }
/style
This matches the colors I use for the default font in emacs.
David
Re: [O] Capitalisation and good taste ?
pin...@iro.umontreal.ca (François Pinard) writes: [...] Should I say, I notice a strong correlation between rotten software and the lack of attention to such details. I'm not saying that avoiding trailing white space is a guarantee of good software. But I'm saying that people unwilling to pay attention to details are not prone to pay attention for a lot of other things, which is not good for software. What is interesting, to me, is that some of these details come down to style preferences *and* that these preferences can change dramatically over time. I have been programming for 35+ years and it's scary to see how my preferences have changed, sometimes cycling several times with a period of 5 or more years! I am thinking especially about things like indentation rules, blank lines, multi-line versus single line comments, variable names, case (cf. this thread), etc. Of course, the language in use affects the choices available but there are always choices, none of which is automatically and permanently correct. cheers, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.92.1 : using Org-mode version 7.8.03 (release_7.8.03.73.gd2b3d)
Re: [O] Minor org mode for achieve code folding effects
On Tue, Jan 10, 2012 at 3:08 PM, Eric S Fraga e.fr...@ucl.ac.uk wrote: 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. Carsten has already given you one possible solution; another is to use org + babel with tangling to have each function or method within a separate headline in an org document. Check out the manual I have used both Carsten's and Eric's solution, as well as hideshow-org (https://github.com/secelis/hideshow-org), which works rather well and deserves a mention. Expanding a bit on Carsten's post: Tassilo Horn wrote some convenience functions to set the outline minor mode regexps to correspond to the current comment syntax. Thus, if I'm (for instance) in shell-script mode, # * and # ** become the outline level 1 and 2 markers. One issue with this approach is that you might prefer finer control over what sections appear folded and what sections appear visible by default. To deal with this, I hacked org.el watch for special visibility-control markers in the heading line, so that e.g. * A heading ending with tilde-tilde like so ~~ would appear always visible. I hope to come up with a better solution for this in the future. The other issue is that Tassilo's code is currently broken for c-mode (possibly due to conflating *'s in /* comment syntax with *'s in the outline header level syntax). If you can fix it, that would be useful :) The code: (require 'outline) (add-hook 'outline-minor-mode-hook '(lambda () (define-key outline-minor-mode-map (kbd TAB) 'org-cycle) (define-key outline-minor-mode-map [(tab)] 'org-cycle) (define-key outline-minor-mode-map [(shift tab)] 'org-global-cycle) (define-key outline-minor-mode-map [backtab] 'org-global-cycle))) ;; Tassilo Horn's outline-minor-mode enhancement: derive regex from comment syntax (defvar th-outline-minor-mode-font-lock-keywords '((eval . (list (concat ^\\(?: outline-regexp \\).*) 0 '(outline-font-lock-face) t t))) Additional expressions to highlight in Orgstruct Mode and Outline minor mode. The difference to `outline-font-lock-keywords' is that this will overwrite other highlighting.) (defun th-outline-regexp () Calculate the outline regexp for the current mode. (let ((comment-starter (replace-regexp-in-string [[:space:]]+ comment-start))) (when (string= comment-starter ;) (setq comment-starter ;;)) (when (string= comment-starter #) (setq comment-starter ##)) (concat comment-starter [*]+ ))) (defun th-outline-minor-mode-init () (interactive) (unless (eq major-mode 'latex-mode) (setq outline-regexp (th-outline-regexp)) (font-lock-add-keywords nil th-outline-minor-mode-font-lock-keywords) (font-lock-fontify-buffer))) (add-hook 'outline-minor-mode-hook 'th-outline-minor-mode-init)
Re: [O] inline src_R also in latex src block
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...
Re: [O] Capitalisation and good taste ?
2012/1/11 Eric S Fraga e.fr...@ucl.ac.uk pin...@iro.umontreal.ca (François Pinard) writes: [...] Should I say, I notice a strong correlation between rotten software and the lack of attention to such details. I'm not saying that avoiding trailing white space is a guarantee of good software. But I'm saying that people unwilling to pay attention to details are not prone to pay attention for a lot of other things, which is not good for software. What is interesting, to me, is that some of these details come down to style preferences *and* that these preferences can change dramatically over time. I have been programming for 35+ years and it's scary to see how my preferences have changed, sometimes cycling several times with a period of 5 or more years! I am thinking especially about things like indentation rules, blank lines, multi-line versus single line comments, variable names, case (cf. this thread), etc. Of course, the language in use affects the choices available but there are always choices, none of which is automatically and permanently correct. cheers, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.92.1 : using Org-mode version 7.8.03 (release_7.8.03.73.gd2b3d) Thanks for the awesome Donald Knuth Video François, a must watch for folks who love TeX and its wrappers. Don't have much to say for the Caps convention, except that the criterion suggested by Bastien seems fair enough. Regards, Sankalp
Re: [O] Minor org mode for achieve code folding effects
Carlos Russo mestre.adamastor at gmail.com writes: I have used both Carsten's and Eric's solution, as well as hideshow-org (https://github.com/secelis/hideshow-org), which works rather well and deserves a mention. Expanding a bit on Carsten's post: Tassilo Horn wrote some convenience functions to set the outline minor mode regexps to correspond to the current comment syntax. Thus, if I'm (for instance) in shell-script mode, # * and # ** become the outline level 1 and 2 markers. This is great info! I was just looking for this in the last couple of days and appreciate everyone's code since it's way beyond my elisp abilities. I like this a lot more than the folding.el I had been using since I already use orgmode. However, I've got a question: I'm using this with verilog-mode which uses // to start comments. The problem is that when I indent my file, the comments indent too and it seems that output-minor-mode (and, I assume, orgmode) only recognize headings that start in column 0. How/where can I change this so it will recognize any line that is whitepace followed by the comment-start? Thanks! David
Re: [O] Minor org mode for achieve code folding effects
David Rogoff January 10, 2012 4:34 PM Carlos Russo mestre.adamastor at gmail.com writes: I have used both Carsten's and Eric's solution, as well as hideshow-org (https://github.com/secelis/hideshow-org), which works rather well and deserves a mention. Expanding a bit on Carsten's post: Tassilo Horn wrote some convenience functions to set the outline minor mode regexps to correspond to the current comment syntax. Thus, if I'm (for instance) in shell-script mode, # * and # ** become the outline level 1 and 2 markers. This is great info! I was just looking for this in the last couple of days and appreciate everyone's code since it's way beyond my elisp abilities. I like this a lot more than the folding.el I had been using since I already use orgmode. However, I've got a question: I'm using this with verilog-mode which uses "// " to start comments. The problem is that when I indent my file, the comments indent too and it seems that output-minor-mode (and, I assume, orgmode) only recognize headings that start in column 0. How/where can I change this so it will recognize any line that is whitepace followed by the comment-start? This works, but is probably not the best way to do it: (defun th-outline-regexp () "Calculate the outline regexp for the current mode." (let ((comment-starter (replace-regexp-in-string "[[:space:]]+" "" comment-start))) (when (string= comment-starter ";") (setq comment-starter ";;")) (when (string= comment-starter "#") (setq comment-starter "##")) (when (eq major-mode 'verilog-mode) (setq comment-starter "\\s-*//")) ;; for verilog-mode, define comment-starter as any amount of whitespace followed by "//". This allows indented comments as outline levels (concat comment-starter " [*]+ ")))
Re: [O] [BUG] org-agenda-switch-to fails with void function org-pop-to-buffer-same-window
Daniel's solution didn't end up working for some reason. After spending over an hour on it this evening, I couldn't get git-cloned org to work. I was running into an odd problem with 'cyclic variable indirection' or something like that. In a trouble-shooting step, I moved the git-cloned org out of the way, and site org took over. Turns out, site org in Aquamacs Dev is the current stable version of org. I suppose I might run into an issue here or there, but for now all seems to be working. Since I've never really actively participated in development and I ran smoothly over a year without needing to report a bug, I don't seem to be losing much. Cheers, all, and thanks for your suggestions. On Sat, Dec 31, 2011 at 11:46, Nick Dokos nicholas.do...@hp.com wrote: Jeff Horn jrhorn...@gmail.com wrote: Manually loading `org-mode/lisp/org-compat.el` loads the missing function. Is it weird to have so much functionality depend on a compatibility library? (I don't do software for a living, this is an innocent question.) Also, does anyone have a clue as to why org-compat.el isn't being loaded automatically? This is (most probably) a red herring: the problem is probably a frankenstein org mode install (bits and pieces loaded from various places). Daniel Doherty posted an answer (in another thread - see http://thread.gmane.org/gmane.emacs.orgmode/50526/focus=50574 for details). I added that proposed solution to the FAQ on worg but I don't use starter-kit, so feel free to correct and clarify appropriately. In particular, if you (Jeff) can verify that it solves your problem, that would go a long way towards putting this problem to bed - permanently, I hope. Thanks, Nick On Fri, Dec 30, 2011 at 16:14, Jeff Horn jrhorn...@gmail.com wrote: It looks like git org-mode is at the front of my load-path already. I'm assuming that emacs' load-path works similar to a shell load-path, with lower-indexed directories being searched (and used) before higher-indexed ones. This bug is really messing with my workflow. Anything else I should try? ,[ load-path ] | (~/.emacs.d/elpa/color-theme-6.6.1/themes ~/completion ~/test | /Users/jrhorn424/.emacs.d/src | /Users/jrhorn424/.emacs.d/src/ado-mode | /Users/jrhorn424/.emacs.d/src/deft | /Users/jrhorn424/.emacs.d/src/markdown-mode | /Users/jrhorn424/.emacs.d/src/org-mode | /Users/jrhorn424/.emacs.d/src/w3m | /Users/jrhorn424/.emacs.d/src/ado-mode/info | /Users/jrhorn424/.emacs.d/src/ado-mode/lisp | /Users/jrhorn424/.emacs.d/src/ado-mode/plan for highlighting.oo3 | /Users/jrhorn424/.emacs.d/src/ado-mode/scripts | /Users/jrhorn424/.emacs.d/src/ado-mode/templates | /Users/jrhorn424/.emacs.d/src/org-mode/BUGFIXING | /Users/jrhorn424/.emacs.d/src/org-mode/EXPERIMENTAL | /Users/jrhorn424/.emacs.d/src/org-mode/UTILITIES | /Users/jrhorn424/.emacs.d/src/org-mode/contrib | /Users/jrhorn424/.emacs.d/src/org-mode/etc | /Users/jrhorn424/.emacs.d/src/org-mode/lisp | /Users/jrhorn424/.emacs.d/src/org-mode/testing ` On Sun, Dec 18, 2011 at 13:55, Jeff Horn jrhorn...@gmail.com wrote: I'll have to look into that. I'm using Eric Schulte's starter kit, so I doubt initialization is a problem. I haven't changed anything in my initialization other than a color theme in quite some time. On Thu, Dec 15, 2011 at 11:58, Sean O'Halpin sean.ohal...@gmail.com wrote: On Thu, Dec 15, 2011 at 1:26 AM, Jeff Horn jrhorn...@gmail.com wrote: Recently did a fresh pull, which seems to have broken org-agenda-switch-to. To reproduce, open an agenda buffer, navigate to a line you want to inspect, press [RET]. On my machine, this calls autopair, then falls back to org-agenda-switch-to. Autopair doesn't seem to be causing the problem, since it persists even if I call =M-x org-agenda-switch-to= instead of pressing [RET]. Org-mode version 7.8.02 (release_7.8.02.3.gfb8c) GNU Emacs 24.0.90.3 (i386-apple-darwin9.8.0, NS apple-appkit-949.54) of 2011-12-14 on braeburn.aquamacs.org - Aquamacs Distribution 3.xdev Can anyone reproduce? I recently had a similar problem with =org-pop-to-buffer-same-window= . It turned out that after switching to using =org-babel-load-file= to load my init file, emacs was then using the org-mode installed in site-lisp rather than my local git copy. I fixed this by setting =load-path= to point to my local git copy of org-mode before calling =org-babel-load-file=. HTH. Regards, Sean -- Jeffrey Horn http://www.failuretorefrain.com/jeff/ -- Jeffrey Horn http://www.failuretorefrain.com/jeff/ -- Jeffrey Horn http://www.failuretorefrain.com/jeff/ -- Jeffrey Horn http://www.failuretorefrain.com/jeff/
[O] Org exports leaking into each other?
I'm trying to do simultaneous exports of an org document by doing the following: #+begin_src emacs-lisp (org-export-as-ascii org-export-headline-levels) (org-export-as-html org-export-headline-levels) #+end_src Each export done manually is fine, but when done like my code, the .txt file seems to be leaking into the .html file. Any suggestion to fix this? Also, when I export a babel latex code, it asks me if I want to evaluate. When I I export a babel /emasc-lisp/ code however, it doesn't ask me for anything and goes straight by. I would like it to be executed at each export, if it's possible. Thank you in advance!
Re: [O] [Orgmode] Automatic screenshot insertion
Skip Collins skip.coll...@gmail.com writes:
2012/1/10 François Pinard pin...@iro.umontreal.ca:
Some sad people think of me as a programmer. While deep down, I am
fundamentally an artist. Programming is mere mean of expression :-).
You and Jambunathan K. should form a club.
Since I am being dragged in to the conversaion, I am digging out a
reddit post that resonated with me (in a totally different setting).
The clincher is actually the last paragraph and you need to read the
first few paragraphs to enjoy the last one.
There is also a story at the end of this post for everyone to ponder
about.
, From
http://www.reddit.com/r/Buddhism/comments/if08k/when_did_you_first_discover_the_illusory_nature/
| At some point in my teens I'd started doing C programming. If you
| don't know, computer code is usually formatted in a systematic way to
| make it easier to read. Most languages give you a lot of freedom in
| this, so every project has its own coding conventions.
|
| I was really into Linux and assumed Linus Torvalds was probably the
| most wonderful genius hacker of all time. He's got his own write-up
| about the Linux kernel coding style, which you can read here if you
| happen to be interested. Some quotes:
|
| First off, I'd suggest printing out a copy of the GNU coding
| standards, and NOT read it. Burn them, it's a great symbolic
| gesture.
|
| [...]
|
| Tabs are 8 characters, and thus indentations are also 8
| characters. There are heretic movements that try to make
| indentations 4 (or even 2! [this is the GNU standard]) characters
| deep, and that is akin to trying to define the value of PI to be
| 3.
|
| [...]
|
| You've probably been told by your long-time Unix user helper that
| GNU emacs automatically formats the C sources for you, and
| you've noticed that yes, it does do that, but the defaults it uses
| are less than desirable (in fact, they are worse than random
| typing - an infinite number of monkeys typing into GNU emacs would
| never make a good program).
|
| So I read this at an impressionable age and it all seemed very obvious
| and plainly true. Linux kernel source code, you could tell by just the
| aesthetic impression of the code style, was fast, clean, and smart. It
| looked good. On the other hand, the source code for GNU projects had a
| weird ugly style.
|
| Here's some Linux-style code:
|
| static char *concat(char *s1, char *s2)
| {
| while (x == y) {
| something();
| somethingelse();
| }
| finalthing();
| }
|
| Here's the corresponding GNU-style code:
|
| static char *
| concat (char *s1, char *s2)
| {
| while (x == y)
| {
| something ();
| somethingelse ();
| }
| finalthing ();
| }
|
| But then I started using GNU Emacs and became fascinated by the
| founder of GNU, Richard Stallman, who wrote Emacs and popularized this
| coding convention. I gradually began to think Linus was kind of
| annoying and not as profoundly creative as rms (as Mr. Stallman is
| known).
|
| Then one day I noticed that Linux kernel code looked weird ugly and
| GNU code looked fast, clean, and smart. This was now the obvious and
| plain truth. When I noticed myself feeling like this, it was obvious
| that something was seriously weird with the aesthetic sense.
|
| And that's when I realized that subconscious judgments filter
| experience in a very strange way. So I couldn't really trust myself
| anymore. It was like glimpsing some uncanny fluttering in the veils of
| my ego delusion... dun dun dun!
|
| How weird is this story?
`
My own opinion on the matter is:
Great hackers have *a* style and stick religiously to it. But they
remain steady and productive (even) when working with a dump (pun
intended) from a different school.
, From http://users.rider.edu/~suler/zenstory/concentrate.html
| After winning several archery contests, the young and rather boastful
| champion challenged a Zen master who was renowned for his skill as an
| archer. The young man demonstrated remarkable technical proficiency
| when he hit a distant bull's eye on his first try, and then split that
| arrow with his second shot. There, he said to the old man, see if
| you can match that! Undisturbed, the master did not draw his bow, but
| rather motioned for the young archer to follow him up the
| mountain. Curious about the old fellow's intentions, the champion
| followed him high into the mountain until they reached a deep chasm
| spanned by a rather flimsy and shaky log. Calmly stepping out onto the
| middle of the unsteady and certainly perilous bridge, the old master
| picked a far away tree as a target, drew his bow, and fired a clean,
| direct hit. Now it is your turn, he said as he gracefully stepped
| back onto the safe ground. Staring with terror into the seemingly
| bottomless and beckoning abyss, the young man could not force himself
|
Re: [O] Minor org mode for achieve code folding effects
On Tue, Jan 10, 2012 at 7:21 PM, David Rogoff da...@therogoffs.com wrote: David Rogoff da...@therogoffs.com January 10, 2012 4:34 PM Carlos Russo mestre.adamastor at gmail.com writes: I have used both Carsten's and Eric's solution, as well as hideshow-org (https://github.com/secelis/hideshow-org), which works rather well and deserves a mention. Expanding a bit on Carsten's post: Tassilo Horn wrote some convenience functions to set the outline minor mode regexps to correspond to the current comment syntax. Thus, if I'm (for instance) in shell-script mode, # * and # ** become the outline level 1 and 2 markers. This is great info! I was just looking for this in the last couple of days and appreciate everyone's code since it's way beyond my elisp abilities. I like this a lot more than the folding.el I had been using since I already use orgmode. However, I've got a question: I'm using this with verilog-mode which uses // to start comments. The problem is that when I indent my file, the comments indent too and it seems that output-minor-mode (and, I assume, orgmode) only recognize headings that start in column 0. How/where can I change this so it will recognize any line that is whitepace followed by the comment-start? I've done a little bit of digging into how Tassilo's code works, and realized that it's somewhat broken in the following way: if a mode provides its own outline-level function, chances are, his code will break (this is why c-mode doesn't work). Even if default outline-level is used, it will determine the level incorrectly since it just counts characters in the current outline regex. Thus, with the ouline regexp set to something like ## * this function will say that you are on outline level 5. This might lead to some unexpected behavior. Long story short, here is the fixed code that provides and sets proper outline level: (defun th-outline-regexp () Calculate the outline regexp for the current mode. (let ((comment-starter (replace-regexp-in-string [[:space:]]+ comment-start))) (setq comment-starter (replace-regexp-in-string * [*] comment-starter)) (when (string= comment-starter ;) (setq comment-starter ;;)) (when (string= comment-starter #) (setq comment-starter ##)) (concat \\( comment-starter \\) \\( [*]+ \\ (defun th-lva-outline-level () Calculates appropriate outline level by counting the stars in the regex (let ((stars-regex [*]+) (outline-start-string (match-string 2))) ;; ideally, second group obtained by (match-string 2) will be just the stars (if (string-match stars-regex outline-start-string) (- (match-end 0) (match-beginning 0)) 0))) (defun th-outline-minor-mode-init () (interactive) (unless (eq major-mode 'latex-mode) (setq outline-regexp (th-outline-regexp)) (setq outline-level 'th-lva-outline-level) (font-lock-add-keywords nil th-outline-minor-mode-font-lock-keywords) (font-lock-fontify-buffer))) postbox-contact.jpg
[O] Org-edit-special and C-x C-s strange behavior
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 splitting disappears, and if I go back to the original org buffer, find the relevant code block and try to edit again via C-', I'm faced with a rather cryptic message Return to existing edit buffer? [n] will revert changes: (y or n) . Since C-x C-s is such a basic operation, I think it should do something more sensible in an edit buffer (for instance, it should save the original org document and not screw with the window configuration). Alternatively, it could be configured to save, and exit the edit buffer (i.e. simulate the effect of pressing C-' and then C-x C-s in the original org buffer). This would go a long way to making working with code blocks more pleasant. From my viewpoint / usage patterns it makes a lot of sense for an edit buffer to behave like a version of the original org buffer narrowed to the source code block. If there's a particular reason for the current behavior, I'd be very curious to know it. --Leo
Re: [O] Minor org mode for achieve code folding effects
Leo Alekseyev dnqu...@gmail.com writes: I've done a little bit of digging into how Tassilo's code works, and realized that it's somewhat broken in the following way: if a mode provides its own outline-level function, chances are, his code will break (this is why c-mode doesn't work). Even if default outline-level is used, it will determine the level incorrectly since it just counts characters in the current outline regex. Yes, I was satisfied with having different colors. But thanks a lot for the improved version! Bye, Tassilo
Re: [O] Capitalisation and good taste ?
Hi Bastien, François Pinard wrote: Bastien b...@altern.org writes: Eric Schulte eric.schu...@gmx.com writes: That said I'm happy that Org-mode is forgiving enough to allow me to lowercase most of my keywords locally. 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 surely like this! :-). So do I. 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). François, Are you talking of a dark theme or light theme? Did you take a look at Emacs color themes, and their customization for Org? See, for example, mine at http://orgmode.org/worg/color-themes-screenshot.html#sec-1-4 [1]. In that page, you'll find: - 6 dark themes - 1 gray theme - 1 light theme Best regards, Seb Footnotes: [1] I should update my color-theme code and screenshot on Worg, as my color theme has varied over the last months. -- Sebastien Vauban
Re: [O] inline src_R also in latex src block
Hi Michael,
Michael Bach wrote:
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...
That's perfectly correct: as long as your input code block does not change
(options on the meta line and/or contents), your results will be taken as
is, instead of being recomputed every time.
Best regards,
Seb
--
Sebastien Vauban
