Re: [O] inline src_R also in latex src block
Hi Michael, Michael Bach wrote: > 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... 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
Re: [O] Capitalisation and good taste ?
Hi Bastien, François Pinard wrote: > Bastien writes: >> Eric Schulte 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] Minor org mode for achieve code folding effects
Leo Alekseyev 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
[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
On Tue, Jan 10, 2012 at 7:21 PM, David Rogoff wrote: > > > David Rogoff > January 10, 2012 4:34 PM > Carlos Russo 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))) <>
Re: [O] [Orgmode] Automatic screenshot insertion
Skip Collins writes: > 2012/1/10 François Pinard : >> 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 | to step out onto the log, no
[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] [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 wrote: > Jeff Horn 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 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 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 >> >> wrote: >> >>> On Thu, Dec 15, 2011 at 1:26 AM, Jeff Horn 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/
Re: [O] Minor org mode for achieve code folding effects
David Rogoff January 10, 2012 4:34 PM Carlos Russo 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] Minor org mode for achieve code folding effects
Carlos Russo 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] Capitalisation and good taste ?
2012/1/11 Eric S Fraga > 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] inline src_R also in latex src block
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...
Re: [O] Minor org mode for achieve code folding effects
On Tue, Jan 10, 2012 at 3:08 PM, Eric S Fraga wrote: > 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. > > 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] 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] 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: pre { background-color: #191919 } pre { color:#00FF00 } 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: > 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
David Rogoff 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] 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. 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)
[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] :noweb header argument
Eric Schulte 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)
Re: [O] Capitalisation and good taste ?
pin...@iro.umontreal.ca (François Pinard) writes: > Bastien writes: > >> Eric Schulte 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] [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] [org-babel] break when used with header in emacs 22.3
d.tchin 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] Capitalisation and good taste ?
Bastien writes: > Eric Schulte 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
Eric Schulte 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] [org-babel] break when used with header in emacs 22.3
d.tchin 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] Capitalisation and good taste ?
Eric Schulte 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] [Orgmode] Automatic screenshot insertion
2012/1/10 François Pinard : > 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 ?
Bastien 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] 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
[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] [Orgmode] Automatic screenshot insertion
Eric S Fraga 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
Re: [O] :noweb header argument
Hi Eric, Eric Schulte writes: > t...@tsdye.com (Thomas S. Dye) writes: > >> Hi Seb, >> >> "Sebastien Vauban" 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 en
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] [Orgmode] Automatic screenshot insertion
pin...@iro.umontreal.ca (François Pinard) writes: > Eric S Fraga 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)
[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] [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/
Re: [O] :noweb header argument
t...@tsdye.com (Thomas S. Dye) writes: > Hi Seb, > > "Sebastien Vauban" 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/
[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 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] Capitalisation and good taste ?
François Pinard wrote: > Nick Dokos writes: > > > François Pinard 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
Re: [O] :noweb header argument
Hi Seb, "Sebastien Vauban" 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 ?
Nick Dokos writes: > François Pinard 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] [Orgmode] Automatic screenshot insertion
Eric S Fraga 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
[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] inline src_R also in latex src block
Michael Bach writes: > Eric Schulte 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} <> \end{equation} #+end_src Cheers, Andreas
Re: [O] S-tab in source blocks
Bernt Hansen writes: > Andreas Leha 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] S-tab in source blocks
Bernt Hansen writes: > Andreas Leha 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
Andreas Leha 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] inline src_R also in latex src block
Eric Schulte 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] Symbol's function definition is void: org-write-agenda
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! -- Bastien
Re: [O] Symbol's function definition is void: org-write-agenda
* Bastien wrote: > Hi Karl, Hi! > Karl Voit 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
Hi Karl, Karl Voit 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] :noweb header argument
"Sebastien Vauban" 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)
[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] if both schedule and deadline, appear only once in agenda
On Fri, 12 Oct 2007 14:36:42 +0100 Bastien wrote: > Gijs Hillenius 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] 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] [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)
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 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] :noweb header argument
"Sebastien Vauban" 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