[O] Bug: org-element-parse-buffer doesn't work in 8.2.5h [8.2.5h (8.2.5h-30-gdd810b-elpa @ /home/sindikat/.emacs.d/elpa/org-20140303/)]
Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See http://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org-mode mailing list. How to reproduce: Create an org-mode buffer that contains at least one headline. Example: --- text * headline --- Run `(org-element-parse-buffer)'. The following error will pop up: Debugger entered--Lisp error: (invalid-function org-with-silent-modifications) org-with-silent-modifications(nil) org-refresh-category-properties() org-get-category() org-entry-properties(nil standard) org-element-headline-parser(17 nil) org-element--current-element(17 nil first-section nil) org-element--parse-elements(1 17 first-section nil nil nil (org-data nil (section (:begin 1 :end 6 :contents-begin 1 :contents-end 6 :post-blank 0 :parent #0) (paragraph (:begin 1 :end 6 :contents-begin 1 :contents-end 6 :post-blank 0 :post-affiliated 1 :parent #1) #(text\n 0 5 (:parent #2)) org-element-parse-buffer() eval((org-element-parse-buffer) nil) eval-expression((org-element-parse-buffer) nil) call-interactively(eval-expression nil nil) It was reproduced on clean Emacs by running `emacs -Q' and issuing: (let ((package-load-list '((org t (package-initialize)) On org-version 7.9.3f the command works. Emacs : GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.8.6) of 2013-12-23 on brahms, modified by Debian Package: Org-mode version 8.2.5h (8.2.5h-30-gdd810b-elpa @ /home/sindikat/.emacs.d/elpa/org-20140303/)
[O] Exporter and src blocks
I'm trying to fix this issue:
https://github.com/yoshinari-nomura/org-octopress/issues/14
Here's a copy of that message
Per:
justin808@27357cahttps://github.com/justin808/org-octopress/commit/27357caf41bb82d78059015c3d6048d11444f62b
I would like this to work:
#+BEGIN_SRC css sass/custom/_fonts.scss
b { font-weight: bold; }
i { font-style: italic; }
#+END_SRC
And have that generate
{% codeblock lang:css sass/custom/_fonts.scss %}
b { font-weight: bold; }
i { font-style: italic; }
{% endcodeblock %}
The lang goes in fine. I'd like the ability to have the other parameters
picked up.
Any chance you can give me a tip on the right change to the ox-jekyll.el?
Here's an example of header arguments:
http://orgmode.org/manual/Code-block-specific-header-arguments.html#Code-block-specific-header-arguments
I'm guessing that it's not necessary to use this syntax (prepend :title
before the title)
#+BEGIN_SRC css :title sass/custom/_fonts.scss
b { font-weight: bold; }
i { font-style: italic; }
#+END_SRC
In the method of ox-jekyll, if I print out the value of src-block, i get
this:
src-block is (src-block (:language css :switches nil :parameters nil :begin
1 :end 78 :number-lines nil :preserve-indent nil :retain-labels t
:use-labels t :label-fmt nil :value b { font-weight: bold; }
i { font-style: italic; }
:post-blank 0 :post-affiliated 1 :parent (section (:begin 1 :end 78
:contents-begin 1 :contents-end 78 :post-blank 0 :parent (org-data nil #2))
#0)))
I never can see the title.
Here's the method to fix:
(defun org-jekyll-src-block (src-block contents info)
Transcode SRC-BLOCK element into jekyll code template format
if `org-jekyll-use-src-plugin` is t. Otherwise, perform as
`org-html-src-block`. CONTENTS holds the contents of the item.
INFO is a plist used as a communication channel.
(if org-jekyll-use-src-plugin
(let ((language (org-element-property :language src-block))
(value (org-remove-indentation
(org-element-property :value src-block
(message src-block is %s src-block)
(format {%% codeblock lang:%s %%}\n%s{%% endcodeblock %%}
language value))
(org-export-with-backend 'html src-block contents info)))
--
Justin Gordon | 808-877-6461 | m: 808-281-7272
www.railsonmaui.com | twitter: @railsonmauihttps://twitter.com/railsonmaui
| sugarranchmaui.com http://www.sugarranchmaui.com/ | Sugar Ranch
Bloghttps://www.facebook.com/SugarRanch
Re: [O] Org-link-escape-chars (was Incorrect hexification in URLs in LaTeX Export)
R. Michael Weylandt michael.weyla...@gmail.com writes: On Tue, Mar 4, 2014 at 3:45 PM, Simon Thum simon.t...@gmx.de wrote: This seems to be a question of objective. Do you want to encode, i.e. maintain some reversible original in an url no matter what, or do you want to fix url's which wouldn't otherwise be legal? In the latter case, the question mark should probably be retained. I am not sure, that I understand what you say here. But in case you want to convince me, that exporting non-working links when the user supplies working links is a feature and not a bug, you will have a hard time ;-) - Andreas I believe the former. If the user types in a working link, the exporter shouldn't break it. This could be fixed by sprinkling org-url-decode through various backends, but that suggests to me that the problem may be upstream. Michael
[O] preview and default class [8.2.5h (release_8.2.5h-677-g55b0a3 @ /home/youngfrog/sourcetrees/org-mode/lisp/)]
Hello,
I was a little bit surprised that previewing latex fragments doesn't use
the same class as latex export. That's contrary to my expectation but I
don't know how to fix it. The reason I expected that is : I set a
default (personnal) latex class which defines many commands that I use
everyday when writing latex, and thus also when writing latex in org
documents.
Also, it took me a lot of time to find out that org-format-latex-header
was used for previewing latex fragments. I suggest that we mention it in
the manual in (info (org) Previewing LaTeX fragments). It's already
mentionned in (info (org) LaTeX fragments) in a footnote, but I think
the variable must be found in the Previewing section too.
Here's a patch to do it, but maybe the whole footnote should be moved to
the Previewing section instead ?
From: Nicolas Richard theonewiththeevill...@yahoo.fr
Date: Thu, 6 Mar 2014 13:21:41 +0100
Subject: [PATCH] * doc/org.texi: mention org-format-latex-header near
org-format-latex-options
---
doc/org.texi | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index 7e66034..b85f8c0 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -10228,10 +10228,11 @@ Remove the overlay preview images.
@end table
@vindex org-format-latex-options
-You can customize the variable @code{org-format-latex-options} to influence
-some aspects of the preview. In particular, the @code{:scale} (and for HTML
-export, @code{:html-scale}) property can be used to adjust the size of the
-preview images.
+@vindex org-format-latex-header
+You can customize the variables @code{org-format-latex-options} and
+@code{org-format-latex-header} to influence some aspects of the preview. In
+particular, the @code{:scale} (and for HTML export, @code{:html-scale})
+property of the former can be used to adjust the size of the preview images.
@vindex org-startup-with-latex-preview
You can turn on the previewing of all @LaTeX{} fragments in a file with
--
1.8.5.2
Re: [O] automatic scheduling of next task in project
* Peter Rayner peter.julien.ray...@gmail.com wrote: I would like org-mode to remind me automatically of the next task in a project. Perhaps an example will help. I'll use outline headings to show the levels of tasks Auto-scheduling might be difficult. In my workflows I am using dependencies with :BLOCKER: and settings SCHEDULED dates roughly but on the aggressive side. With (setq org-agenda-dim-blocked-tasks t) I get them all on my agenda. You just have to learn to visually ignore the dimmed tasks. From time to time I re-check dimmed tasks for the reason why they are dimmed/blocked to find dead-ends. An additional/other approach would be the use of :TRIGGER: chain-siblings(NEXT) in order to move the NEXT state from a finished task to the next one. -- mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode: get Memacs from https://github.com/novoid/Memacs https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github
Re: [O] automatic scheduling of next task in project
Karl Voit devn...@karl-voit.at writes: * Peter Rayner peter.julien.ray...@gmail.com wrote: I would like org-mode to remind me automatically of the next task in a project. Perhaps an example will help. I'll use outline headings to show the levels of tasks Auto-scheduling might be difficult. In my workflows I am using dependencies with :BLOCKER: and settings SCHEDULED dates roughly but on the aggressive side. With (setq org-agenda-dim-blocked-tasks t) I get them all on my agenda. You just have to learn to visually ignore the dimmed tasks. From time to time I re-check dimmed tasks for the reason why they are dimmed/blocked to find dead-ends. You can also set org-agenda-dim-blocked-tasks to 'invisible, which will remove blocked tasks entirely from the agenda. Then, you could add the property :ORDERED: t to the heading and schedule them (for the diary agenda) or mark them NEXT/TODO (for the todo list). This would cause each event to appear on the agenda after the blocking task is marked done. An additional/other approach would be the use of :TRIGGER: chain-siblings(NEXT) in order to move the NEXT state from a finished task to the next one. Or, since the OP is using org-depend.el (in contrib), he could also use :TRIGGER: chain-siblings-scheduled(NEXT). Best, Matt
[O] Agenda with blocked tasks
Hi! Is it possible to define an agenda that contains only items which are blocked by :BLOCKER:-conditions or similar? Thanks! -- mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode: get Memacs from https://github.com/novoid/Memacs https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github
Re: [O] Bug:
Yes, it's fixed now, thanks.
[O] Bug: org-catch-invisible-edits [8.2.5h (8.2.5h-30-gdd810b-elpa @ ~/.emacs.d/elpa/org/)]
Hi, Today I came across org-catch-invisible-edits, but I'm struggling to get it to work. Since I've never had it working it's possible that I'm misunderstanding it or doing something wrong, or maybe it's broken. In my .emacs file I put (setq org-catch-invisible-edits 'show) but both 'M-x query-replace' and 'M-x replace-string' still replace hidden strings in folded sections of an org file. Thanks, Paul current state: == (setq org-tab-first-hook '(org-hide-block-toggle-maybe org-src-native-tab-command-maybe org-babel-hide-result-toggle-maybe org-babel-header-arg-expand) org-speed-command-hook '(org-speed-command-default-hook org-babel-speed-command-hook) org-occur-hook '(org-first-headline-recenter) org-metaup-hook '(org-babel-load-in-session-maybe) org-confirm-shell-link-function 'yes-or-no-p org-after-todo-state-change-hook '(org-clock-out-if-current) org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-configure-edit-buffer) org-agenda-before-write-hook '(org-agenda-add-entry-text) org-babel-pre-tangle-hook '(save-buffer) org-mode-hook '(#[nil \300\301\302\303\304$\207 [org-add-hook change-major-mode-hook org-show-block-all append local] 5] #[nil \300\301\302\303\304$\207 [org-add-hook change-major-mode-hook org-babel-show-result-all append local] 5] org-babel-result-hide-spec org-babel-hide-all-hashes) org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point org-babel-execute-safely-maybe) org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers org-cycle-hide-inline-tasks org-cycle-show-empty-lines org-optimize-window-after-visibility-change) org-catch-invisible-edits 'show org-confirm-elisp-link-function 'yes-or-no-p org-metadown-hook '(org-babel-pop-to-session-maybe) org-clock-out-hook '(org-clock-remove-empty-clock-drawer) )
[O] Links in tables: could the plain text also look good?
Hi all, I don't know if this issue has been raised before (it's a bit difficult to google it). I was just committing a single line change to an org-mode table into git, and the diff isn't good at all: the whole table appears to have changed. Well, not really - just a few spaces were added on each table line because the single new line caused a need to re-align the whole table. So I'm thinking: if org-mode uses overlays for links to make some of the real text invisible, why not keep the plain text aligned and use the overlays to align the fontified text? Having a good-looking plain text is an achievement in itself, but using an smart allocation strategy (like std::vector growth) to add more spaces than needed each time a column grows, would alleviate the diff problem, i.e. the diff would show only a single line change most of the time a line is added or removed. I'd like some feedback on whether: - it's done already and I just haven't enabled this behavior - it can't be done because of some complex issue - it can be done, but just isn't a priority In the third case maybe some pointers on where to start implementing would help. regards, Oleh
[O] Publish project alist in org-mode 8 - confusing documentation
Can someone give me some hints for how to set up a publishing project in org-mode 8? Am I right in thinking that I can't use easy customization to set up a publish project alist? I've been reading various links such as http://orgmode.org/worg/exporters/ox-overview.html http://orgmode.org/worg/org-8.0.html and even http://orgmode.org/worg/exporters/ox-docstrings.html and http://orgmode.org/worg/exporters/org-element-docstrings.html but since I'm not at all a power user I find myself rather lost. I generally rely on the customization browsers to do most of my configuration. I do sometimes edit .emacs manually but normally closely following an example. I'd really like to set up a project based on the worg tutorial at http://orgmode.org/worg/org-tutorials/org-publish-html-tutorial.html but I don't know where to begin adapting it to the new export framework. For example, I'd be very grateful if someone could translate the following (or something more simple) into org-mode 8 version, so I can start evaluating and playing with it. (require 'org-publish) (setq org-publish-project-alist '( (org-notes :base-directory ~/org/ :base-extension org :publishing-directory ~/public_html/ :recursive t :publishing-function org-publish-org-to-html :headline-levels 7 :auto-preamble t ) (org-static :base-directory ~/org/ :base-extension css\\|js\\|png\\|jpg\\|gif\\|pdf\\|mp3\\|ogg\\|swf :publishing-directory ~/public_html/ :recursive t :publishing-function org-publish-attachment ) (org :components (org-notes org-static)) )) Many thanks! Gez Org-mode version 8.2.5h (8.2.5h-30-gdd810b-elpa GNU Emacs 24.3.1 (i386-mingw-nt6.2.9200)
[O] \344 in org agenda date string only
All since a few days I see \344 instead of German ä, but only in the date string part of the agenda. The collected headlines from my org files show German Umlaute ä,ö,ü correctly. Also all Org files look good. I wonder if someone has an idea how this can be removec. I run org 8.2.5h and Emacs 24.3.1 on Windows and Linux Thank you, Rainer
Re: [O] Publish project alist in org-mode 8 - confusing documentation
Hi Gez, Gez sule...@gmail.com writes: but I don't know where to begin adapting it to the new export framework. For example, I'd be very grateful if someone could translate the following (or something more simple) into org-mode 8 version, so I can start evaluating and playing with it. (require 'org-publish) (setq org-publish-project-alist '( (org-notes :base-directory ~/org/ :base-extension org :publishing-directory ~/public_html/ :recursive t :publishing-function org-publish-org-to-html It's been a while since I converted my publishing setup to the new exporter, but I *think* the only change you need to make here is to the :publishing-function option. The function you want here is now called org-html-publish-to-html. There are other similar functions in the other export backends -- e.g., the function to publish to PDF is org-latex-publish-to-pdf. Thus, if you need to find an appropriate publishing function, start by looking for a function named like: org-BACKEND-publish-to-FORMAT. I don't remember how I figured this out, but hopefully it is documented in the manual... (I am not sure about the :recursive or :auto-preamble options, which don't appear in the variable documentation for org-publish-project-alist; if changing :publishing-function on its own does not get this setup working, try removing those options.) :headline-levels 7 :auto-preamble t ) (org-static :base-directory ~/org/ :base-extension css\\|js\\|png\\|jpg\\|gif\\|pdf\\|mp3\\|ogg\\|swf :publishing-directory ~/public_html/ :recursive t :publishing-function org-publish-attachment ) (org :components (org-notes org-static)) )) Again, I think this should work as-is, with the possible exception of the :recursive option. org-publish-attachment is still around. Hope that helps! Best, Richard
Re: [O] [babel] cannot comment out noweb references
I think you may have to use the slower and more correct version of noweb expansion to avoid these sorts of problems. Best, Samuel Wales samolog...@gmail.com writes: By which I mean, the bug should be reproducible if you do so. On 2/11/14, Samuel Wales samolog...@gmail.com wrote: Try with: (setq org-babel-use-quick-and-dirty-noweb-expansion t) This setting is much, much faster, by the way. On 2/5/14, Eric Schulte schulte.e...@gmail.com wrote: Samuel Wales samolog...@gmail.com writes: hi eric, #+BEGIN_SRC org :results verbatim output :noweb yes :noweb-ref whatever a #+END_SRC # #+BEGIN_SRC org :results verbatim output :noweb yes :noweb-ref whatever # b # #+END_SRC #+BEGIN_SRC sh :results output :noweb yes echo whatever #+END_SRC it is a bug that babel tries to use b. babel tries to use COMMENT comments also. samuel When executing the last code block I get the expected output, namely a. #+BEGIN_SRC org :results verbatim output :noweb yes :noweb-ref whatever a #+END_SRC # #+BEGIN_SRC org :results verbatim output :noweb yes :noweb-ref whatever # b # #+END_SRC #+BEGIN_SRC sh :results output :noweb yes echo whatever #+END_SRC #+RESULTS: : a Best, -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. Denmark: free Karina Hansen NOW. -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] Org release 8.2.5g (minor release from maint)
Nick Dokos ndo...@gmail.com writes: Eric Abrahamsen e...@ericabrahamsen.net writes: I have the impression that cl-lib is (was?) frowned upon by upstream for packages that are included in the emacs distribution. But it's only a vague recollection at this point: am I wrong? am I thinking of something else common-lispish? I thought that the point of cl-lib was so that packages like Org-mode and gnus would stop re-implementing pieces of the cl package. I could easily be wrong. I remembered seeing something on emacs-devel about this, and just found this statement from Stefan Monnier from a few days ago: Note that the main motivation behind the move to cl-lib is so that it's perfectly acceptable to use cl-lib functions (since they don't pollute the global namespace any more). So if you prefer to avoid cl-lib functions, that's fine, but if you want to use them, that's perfectly fine as well. Stefan Interpret as you will! Thanks for putting me right! Great, so should Org-mode require cl-lib and stop supporting the following functions? - org-block - org-count - org-every - org-find-if - org-reduce - org-remove-if - org-remove-if-not - org-return - org-some - org-sort - org-sublist -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] Issue using [:exports both] for inline R code?
Inline code blocks were provided to allow results of code block
execution to be placed /inline/ within textual elements such as
paragraphs or lists. They are not designed to support code export.
The manual should be updated to make this limitation clear.
Best,
John Hendy jw.he...@gmail.com writes:
Here is a minimal example:
#+begin_src example
* Heading
Here is some R code:
src_R[:exports both]{1 + 2 + 3}.
#+end_src
Here is the minimal config I used with `emacs -Q`:
#+begin_src min-config
;; change as needed
(add-to-list 'load-path ~/.elisp/org.git/lisp/)
(add-to-list 'load-path ~/.elisp/org.git/contrib/lisp)
(add-to-list 'load-path ~/.elisp/site-lisp/ess/lisp/)
(require 'ox-latex)
;; setup babel languages
(org-babel-do-load-languages
'org-babel-load-languages
'((R . t)))
#+end_src
Org version (just pulled):
Org-mode version 8.2.5h (release_8.2.5h-676-gfb8a04 @
/home/jwhendy/.elisp/org.git/lisp/)
Upon exporting to latex, I get the attached.
I thought I ran into this some time back, but was able to use a
:session argument as a workaround in the header args. For some reason,
I can't seem to get that to play along at the moment. When I try
adding `:session r`, I get this in the *Messages* buffer:
Warning: defvar ignored because ess-ask-for-ess-directory is let-bound
org-babel-R-initiate-session: Symbol's function definition is void: R
Any suggestions on what's going on? In a non-minimal setup, I get
similar results except that `:session R` doesn't complain on export...
but I get my code bookended by verbatim #+begin/end_src text in the
PDF.
Thanks,
John
--
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D
Re: [O] how to force org-mode to interpret number as string
Stefan Huchler stefan.huch...@mail.de writes: Bastien b...@gnu.org writes: Hi Stefan, Stefan Huchler stefan.huch...@mail.de writes: The Problem is that that org-mode seems to auto-format the salary column as a number. That a problem here, but I guess this is handy in many circumstances. Why don't use just turn the number into a string in your code? if I could do that, without loosing the numbers behind the point I would be ok with that, but I dont want a fixed system for 1 table, but for a random table. I think that for this to work you may have to abandon using . as your numerical thousands separator. Or customize string-to-number and org-babel-number-p to fit your number syntax. Best, -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] Bug: add elisp to org-babel-tangle-lang-exts to support elisp source blocks [8.2.5h (release_8.2.5h-680-g12df70 @ /home/youngfrog/sources/org-mode/lisp/)]
Applied, Thanks. Nicolas Richard theonewiththeevill...@yahoo.fr writes: Hello, elisp (vs emacs-lisp) code blocks are supported via an entry org-src-lang-modes but not in org-babel-tangle-lang-exts. The patch below is to fix that. From: Nicolas Richard theonewiththeevill...@yahoo.fr Date: Wed, 5 Mar 2014 16:49:30 +0100 Subject: [PATCH] lisp/ob-tangle.el: elisp should get tangled to .el files. --- lisp/ob-tangle.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el index 5797ea4..8923e16 100644 --- a/lisp/ob-tangle.el +++ b/lisp/ob-tangle.el @@ -41,7 +41,8 @@ (declare-function org-before-first-heading-p org ()) (defcustom org-babel-tangle-lang-exts - '((emacs-lisp . el)) + '((emacs-lisp . el) +(elisp . el)) Alist mapping languages to their file extensions. The key is the language name, the value is the string that should be inserted as the extension commonly used to identify files -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] BUG org-babel-goto-named-src-block with indented block
Hi Andreas, The problem is with your example. You can not put a header line between a #+name and it's source block. Best, Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi all, there seems to be a bug, where org-babel-goto-named-src-block does not find an indented source block. Here is an example: --8---cut here---start-8--- * Test org-babel-goto-named-src-block Try org-babel-goto-named-src-block (C-c C-v g) with point on the following line. (This works for me.) #+call: block1(20) Try org-babel-goto-named-src-block (C-c C-v g) with point on the following line. (This does not work for me.) #+call: block2(20) ** The first block *without* indentation #+name: block1 #+header: :var end=10 #+begin_src R 1:end #+end_src ** The second block *with* indentation #+name: block2 #+header: :var end=11 #+begin_src R 2:end #+end_src --8---cut here---end---8--- Regards, Andreas -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] words starting with call_ confuse C-c C-c and export
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
Eric Schulte schulte.e...@gmail.com writes:
Nicolas Goaziou n.goaz...@gmail.com writes:
It would solve the current problem, but there are still many problematic
characters allowed (e.g., commas, curly brackets). I think there's no
point in allowing call_{i=1}() as a valid inline Babel call.
Furthermore, I don't think it's a real limitation to use alphanumeric
characters (and hyphen) only for a function name. I would even require
an alphabetic character as the first char, to avoid calls like:
call_1().
I often use / in function names, and in general I'd prefer not to
remove characters (e.g., {) unless there is a specific reason.
I think there's a specific reason to disallow naming a function {i=1}:
it is too close to underline syntax. We should make syntax less prone to
ambiguity (see recent thread about underline and subscript) ; this
doesn't help. Think also about call_~my-verbatim-function-name~(),
call_@@latex:my-export-snippet@@()...
We're talking about function names, not free-form text, so limitations
are understandable. For example, macro names only allow alphanumeric
characters or hyphens and have to start with an alphabetic character.
Having considered this, unless there are user objections I'd be happy
limiting function names to the same restricted alphabet as macro names.
This would be a breaking change though, and should be mentioned as such
in the notes.
Best,
I suggest to select a few symbols allowed in names (e.g., /) as
a starter. It is always possible to discuss on a case by case basis if
other symbols should be added.
Regards,
--
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D
Re: [O] inline source code blocks
Ilya Shlyakhter ilya_...@alum.mit.edu writes: Some questions about inline source code blocks: - They're not fontified even when org-src-fontify-natively is true -- correct? Correct. - They're not included in tangled code; is that intended behavior? The manual does not seem to say they're different from normal code blocks, except for syntax. They were originally added for the sole purpose of including results inline in textual elements. They are not meant to export code. There is currently no support (to my knowledge) for inline fontified code. There are also mailing list messages that suggest they're not meant to be exported. What is the correct understanding? I can submit a patch to the manual once I understand this myself. That would be much appreciated. - For very short code snippets (1-2 lines), it would be good to allow specifying (via properties) a default language for code blocks (say C) and a prefix character (say ''), after which one could write int i; I think code blocks work well for non-inline code. Although I think that an inline fontification solution may be nice. I use the following to make code block syntax less intrusive... Pretty code blocks #+begin_src emacs-lisp (defun prettier-org-code-blocks () (interactive) (font-lock-add-keywords nil '((\\(\+begin_src\\) (0 (progn (compose-region (match-beginning 1) (match-end 1) ?¦) nil))) (\\(\+end_src\\) (0 (progn (compose-region (match-beginning 1) (match-end 1) ?¦) nil)) (add-hook 'org-mode-hook 'prettier-org-code-blocks) #+end_src and code blocks may easily by typed with s TAB. Beyond that you could add personal customization to further reduce either the visual or typing burden. and have this be the equivalent of +BEGIN_SRC c int i; +END_SRC by analogy with short literal examples : such as this Would this break any Org invariants? (Context: trying to use Org for literate programming in C++; interested in others' experience in this area). Hope these suggestions help, Thanks, Ilya -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] Odd interaction with Python sessions and Org 8.2.5
Hi Michael, I believe this is a limitation of the current Python session support. The relevant code is in lisp/ob-python.el and any fix would probably end up modifying the `org-babel-python-evaluate-session' function. Best, R. Michael Weylandt michael.weyla...@gmail.com writes: Hi, I'm having trouble getting clean output from org 8.2.5 when I combine session based evaluation and capturing results from standard out. (See first example below) This is on Emacs 24.3 with the default python mode settings and nothing relevant in my init.el except for activating python support. Is this expected behavior or is there someway I can fix the first example? Michael -8---8 #+TITLE: Hello World * Standard Out + Session (Problem) #+BEGIN_SRC python :results output :session *Python* def test(): print Hello World test() #+END_SRC #+RESULTS: : : ... Hello World * Standard Out + No Session (Fine) #+BEGIN_SRC python :results output def test(): print Hello World test() #+END_SRC #+RESULTS: : Hello World * Value + Session #+BEGIN_SRC python :session *Python* def test(): print Hello World test() #+END_SRC #+RESULTS: * Value + No Session #+BEGIN_SRC python def test(): print Hello World test() #+END_SRC #+RESULTS: : None -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] Links in tables: could the plain text also look good?
Hi Oleh On Thu, Mar 6, 2014 at 8:00 PM, Oleh ohwoeo...@gmail.com wrote: I was just committing a single line change to an org-mode table into git, and the diff isn't good at all: the whole table appears to have changed. Well, not really - just a few spaces were added on each table line because the single new line caused a need to re-align the whole table. Did you try the git diff options -b and/or --color-words to not list the table lines and/or color the columns that were only realigned? There are many other (also color-less) word variants which might come closer to your need. With a regexp it should be possible to omit even realigned horizontal separator lines in tables. Or instrument git to use an external tool like, well, Emacs ediff. To find a solution to your need search the web for the words git difftool ediff-files. Emacs 24.3 changed coloring of the diffs to what I find much more convenient. See also the git command difftool and Worg hacks How to ediff folded Org files and the entire mailing list thread linked there, currently in this section http://orgmode.org/worg/org-hacks.html#sec-2-1 A discussion that I didn't read yet about the git diff format -a rb/r c +a gx/g c which is what I would prefer can be found here http://git.661346.n2.nabble.com/Understanding-and-improving-word-diff-td5717239.html So I'm thinking: if org-mode uses overlays for links to make some of the real text invisible, why not keep the plain text aligned and use the overlays to align the fontified text? Having a good-looking plain text is an achievement in itself, but using an smart allocation strategy (like std::vector growth) to add more spaces than needed each time a column grows, would alleviate the diff problem, i.e. the diff would show only a single line change most of the time a line is added or removed. I'd like some feedback on whether: - it's done already and I just haven't enabled this behavior This time no ;-) - it can't be done because of some complex issue - it can be done, but just isn't a priority At least it would have to be optional because it would make reading and editing Org files outside of Org mode or in Org mode with Visible mode less fun. For this I find the current behaviour, also with narrowed columns, a perfect solution. (Disclaimer: I hacked and use hidestarsfile, see http://orgmode.org/worg/org-hacks.html#fileconversion ) Michael
Re: [O] Issue using [:exports both] for inline R code?:
On Mar 6, 2014 4:18 PM, Eric Schulte schulte.e...@gmail.com wrote:
Inline code blocks were provided to allow results of code block
execution to be placed /inline/ within textual elements such as
paragraphs or lists. They are not designed to support code export.
The manual should be updated to make this limitation clear.
Thanks for clarifying. I'll give a shot at it as I have another manual
change to do anyway :)
John
Best,
John Hendy jw.he...@gmail.com writes:
Here is a minimal example:
#+begin_src example
* Heading
Here is some R code:
src_R[:exports both]{1 + 2 + 3}.
#+end_src
Here is the minimal config I used with `emacs -Q`:
#+begin_src min-config
;; change as needed
(add-to-list 'load-path ~/.elisp/org.git/lisp/)
(add-to-list 'load-path ~/.elisp/org.git/contrib/lisp)
(add-to-list 'load-path ~/.elisp/site-lisp/ess/lisp/)
(require 'ox-latex)
;; setup babel languages
(org-babel-do-load-languages
'org-babel-load-languages
'((R . t)))
#+end_src
Org version (just pulled):
Org-mode version 8.2.5h (release_8.2.5h-676-gfb8a04 @
/home/jwhendy/.elisp/org.git/lisp/)
Upon exporting to latex, I get the attached.
I thought I ran into this some time back, but was able to use a
:session argument as a workaround in the header args. For some reason,
I can't seem to get that to play along at the moment. When I try
adding `:session r`, I get this in the *Messages* buffer:
Warning: defvar ignored because ess-ask-for-ess-directory is let-bound
org-babel-R-initiate-session: Symbol's function definition is void: R
Any suggestions on what's going on? In a non-minimal setup, I get
similar results except that `:session R` doesn't complain on export...
but I get my code bookended by verbatim #+begin/end_src text in the
PDF.
Thanks,
John
--
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D
Re: [O] Links in tables: could the plain text also look good?
On 3/6/14 2:00 PM, Oleh wrote: I was just committing a single line change to an org-mode table into git, and the diff isn't good at all: the whole table appears to have changed. Well, not really - just a few spaces were added on each table line because the single new line caused a need to re-align the whole table. You can tell diff to ignore whitespace-only changes by using the -w option: https://www.kernel.org/pub/software/scm/git/docs/git-diff.html -w --ignore-all-space Ignore whitespace when comparing lines. This ignores differences even if one line has whitespace where the other line has none.
Re: [O] [ob-calc] bug when given table data as a variable
Org-mode's calc support is very limited. I think someone with a working knowledge of how calc uses vectors would need to add table support. Unfortunately calc experts seem to be few and far between. Best, Daniel Hackney d...@haxney.org writes: I am trying to use data from a table in a calc source block, but I get the following error when trying to eval the block: #+BEGIN_EXAMPLE math-format-stack-value: Wrong type argument: symbolp, 10 #+END_EXAMPLE Here is an example file which demonstrates the problem: #+BEGIN_EXAMPLE Org version: 8.2.5h (org-20140224 from package) Emacs version: 24.3.1 Run after starting Emacs with =emacs -Q= #+BEGIN_SRC elisp (add-to-list 'org-babel-load-languages '(calc . t)) (require 'ob-calc) #+END_SRC #+NAME: the-table | a | b | c | |---++-| | 1 | 10 | 100 | | 2 | 20 | 200 | | 3 | 30 | 300 | | 4 | 40 | 400 | #+BEGIN_SRC calc :var data=the-table[,1] 1 #+END_SRC #+BEGIN_SRC elisp :var data=the-table[,1] (format %s data) #+END_SRC #+END_EXAMPLE I'm not familiar with the workings of calc, but is there a workaround? P.S. Please CC me in replies since I'm not subscribed to the list. -- Daniel Hackney -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] inline source code blocks
I think code blocks work well for non-inline code.
For a series of one-liners interspersed with comments, code block
boundaries triple the number of lines. E.g. the example in the manual
at http://orgmode.org/org.html#noweb_002dref
+BEGIN_SRC sh :tangle yes :noweb yes :shebang #!/bin/sh
fullest-disk
#+END_SRC
* the mount point of the fullest disk
:PROPERTIES:
:noweb-ref: fullest-disk
:END:
** query all mounted disks
#+BEGIN_SRC sh
df \
#+END_SRC
** strip the header row
#+BEGIN_SRC sh
|sed '1d' \
#+END_SRC
** sort by the percent full
#+BEGIN_SRC sh
awk '{print $5 $6}'|sort -n |tail -1 \
#+END_SRC
** extract the mount point
#+BEGIN_SRC sh
|awk '{print $2}'
#+END_SRC
could be shortened to
#+PROPERTY: ob-default-lang sh
#+HEADER: :tangle yes :noweb yes :shebang #!/bin/sh
: fullest-disk
* the mount point of the fullest disk
:PROPERTIES:
:noweb-ref: fullest-disk
:END:
** query all mounted disks
: df \
** strip the header row
: |sed '1d' \
** sort by the percent full
: |awk '{print $5 $6}'|sort -n |tail -1 \
** extract the mount point
: |awk '{print $2}'
i.e. where the (inherited) property ob-default-lang exists, literal
examples become code blocks in that language.
Or in a list of C++ declarations:
#+PROPERTY: ob-default-lang c++
...
* class MyClass
Does X, Y and Z.
: class MyClass: public MyParent {
** Private fields
*** Field a: stores thing one
: int a;
*** Field b: stores thing two
: char *b;
** Public methods
: public:
*** Method getA: Returns the value of a.
: int getA() const { return a; }
** end class MyClass
: }
I'm finding that Org would work well as a literate programming system
for C++, if the code block starts and ends didn't get in the way so much
during frequent switching between code and prose.
I use the following to make code block syntax less intrusive
Thanks, that was helpful, didn't know about compose-region.
Still, it does not reduce the number of lines used, so a short list of
declarations interspersed with comments quickly ends up taking a lot of
vertical space. When coding it helps to be able to see many things at
once, and having many extra lines (even mostly-blank ones) makes that
difficult.
ilya
Re: [O] inline source code blocks
On 3/6/14 5:04 PM, Eric Schulte wrote:
I think code blocks work well for non-inline code.
For a series of one-liners interspersed with comments, code block
boundaries triple the number of lines. E.g. the example in the manual
at http://orgmode.org/org.html#noweb_002dref
+BEGIN_SRC sh :tangle yes :noweb yes :shebang #!/bin/sh
fullest-disk
#+END_SRC
* the mount point of the fullest disk
:PROPERTIES:
:noweb-ref: fullest-disk
:END:
** query all mounted disks
#+BEGIN_SRC sh
df \
#+END_SRC
** strip the header row
#+BEGIN_SRC sh
|sed '1d' \
#+END_SRC
** sort by the percent full
#+BEGIN_SRC sh
|awk '{print $5 $6}'|sort -n |tail -1 \
#+END_SRC
** extract the mount point
#+BEGIN_SRC sh
|awk '{print $2}'
#+END_SRC
could be shortened to
#+PROPERTY: ob-default-lang sh
#+HEADER: :tangle yes :noweb yes :shebang #!/bin/sh
: fullest-disk
* the mount point of the fullest disk
:PROPERTIES:
:noweb-ref: fullest-disk
:END:
** query all mounted disks
: df \
** strip the header row
: |sed '1d' \
** sort by the percent full
: |awk '{print $5 $6}'|sort -n |tail -1 \
** extract the mount point
: |awk '{print $2}'
i.e. where the (inherited) property ob-default-lang exists, literal
examples become code blocks in that language.
Or in a list of C++ declarations:
#+PROPERTY: ob-default-lang c++
...
* class MyClass
Does X, Y and Z.
: class MyClass: public MyParent {
** Private fields
*** Field a: stores thing one
: int a;
*** Field b: stores thing two
: char *b;
** Public methods
: public:
*** Method getA: Returns the value of a.
: int getA() const { return a; }
** end class MyClass
:}
I'm finding that Org would work well as a literate programming system
for C++, if the code block starts and ends didn't get in the way so much
during frequent switching between code and prose.
I use the following to make code block syntax less intrusive
Thanks, that was helpful, didn't know about compose-region.
Still, it does not reduce the number of lines used, so a short list of
declarations interspersed with comments quickly ends up taking a lot of
vertical space. When coding it helps to be able to see many things at
once, and having many extra lines (even mostly-blank ones) makes that
difficult.
ilya
[O] tangle the code blocks in the regions
Hi all, is there function to extract all the code blocks in the selected region? For example, can I select the region of the following two blocks and extract them with just one command? Or I have to move cursor to each block and extract them one by one? #+BEGIN_SRC sh :tangle foo.sh echo 'hello' #+END_SRC #+BEGIN_SRC python :tangle foo.py print 'hello' #+END_SRC I doesn't find the extracting region command in manual. I would think this can be a convenient feature to have? Best, Zhenjiang
Re: [O] [ob-calc] bug when given table data as a variable
Eric Schulte schulte.e...@gmail.com wrote: Org-mode's calc support is very limited. I think someone with a working knowledge of how calc uses vectors would need to add table support. Unfortunately calc experts seem to be few and far between. Looking at the calc source code was not terribly helpful, since it is barely documented. The info page can help somewhat, though. Doing a little bit of digging, it looks like you can bind variables for =calc-eval= like so: #+BEGIN_SRC elisp (let ((var-a [1, 2, 3])) (calc-eval evalv(reduce(add, a #+END_SRC #+RESULTS: : 6 This pattern could be used for variable binding. It would mean wrapping the code to be evaluated in =evalv=. If I get some time, I might investigate writing a patch to do this. -- Daniel Hackney
[O] Bug in export of call lines
Aloha all,
I've been dusting off a draft paper written when the new export
framework was still in contrib. Now that I've brought the file
up-to-date so that it exports asynchronously again, I'm getting an error
that wasn't there before.
This Org mode input:
- B.01397 :: This is an unusual tool with a nearly constant thickness
along most of its length (fig. [[fig:axes]], /a/). Most of
the edge is missing, but one corner is intact. Too little
remains of the edge to describe its shape, but the obtuse
angle of the surviving corner suggests the edge was
convex in plan view. The opposite end at the poll is also
incomplete, so a complete longitudinal section is absent.
The tool is made from a dark grey volcanic rock that has
a pitted texture and feels light for its size. It is
call_axe-length(a=B.01397) cm long,
call_axe-x-section(a=B.01397) cm at mid-section, and
weighs call_axe-wt(a=B.01397) g. The cutting edge
measures call_axe-edge(a=B.01397) cm.
yields this LaTeX export:
\begin{description}
\item[{B.01397}] This is an unusual tool with a nearly constant thickness
along most of its length (fig.~\ref{fig:axes}, \emph{a}). Most of
the edge is missing, but one corner is intact. Too little
remains of the edge to describe its shape, but the obtuse
angle of the surviving corner suggests the edge was
convex in plan view. The opposite end at the poll is also
incomplete, so a complete longitudinal section is absent.
The tool is made from a dark grey volcanic rock that has
a pitted texture and feels light for its size. It is
18.4
\end{description}
~cm long,
4.8~\texttimes~1.3
~cm at mid-section, and
weighs 223
~g. The cutting edge
measures 5.1
~cm.
Note the new line after each call result and the premature termination
of the {description} environment.
I'm using the latest Org mode from master.
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] inline source code blocks
I'm finding that Org would work well as a literate programming system for C++, if the code block starts and ends didn't get in the way so much during frequent switching between code and prose. I use the following to make code block syntax less intrusive Thanks, that was helpful, didn't know about compose-region. Still, it does not reduce the number of lines used, so a short list of declarations interspersed with comments quickly ends up taking a lot of vertical space. When coding it helps to be able to see many things at once, and having many extra lines (even mostly-blank ones) makes that difficult. I agree that maximizing code per vertical space is important. However, keeping Org-mode parseable and editable is also important. How about the following alternative to my previous suggestion, which will eliminate the extra lines. (defun prettier-org-code-blocks () (interactive) (font-lock-add-keywords nil '((\\(^[[:space:]]*#\\+begin_src .*[\r\n]\\) (0 (progn (compose-region (match-beginning 1) (match-end 1) ) nil))) (\\(^[[:space:]]*#\\+end_src[\r\n]\\) (0 (progn (compose-region (match-beginning 1) (match-end 1) ) nil)) Best, ilya -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] inline source code blocks
On 3/6/14 9:22 PM, Eric Schulte wrote: How about the following alternative to my previous suggestion, which will eliminate the extra lines. Looks beautiful initially, but leads to some confusing behaviors due to invisible lines. But eliminating extra lines is only important for some sections of code; in others, the extra lines (though shortened) actually help. I'll use begin_src/end_src for the former and BEGIN_SRC/END_SRC for the latter, and have your prettier-org-code-blocks fontifier match just the lowercase version. Thanks a lot, ilya
Re: [O] tangle the code blocks in the regions
zhenjiang zech xu zhenjiang...@gmail.com writes: Hi all, is there function to extract all the code blocks in the selected region? For example, can I select the region of the following two blocks and extract them with just one command? Or I have to move cursor to each block and extract them one by one? #+BEGIN_SRC sh :tangle foo.sh echo 'hello' #+END_SRC #+BEGIN_SRC python :tangle foo.py print 'hello' #+END_SRC I doesn't find the extracting region command in manual. I would think this can be a convenient feature to have? Best, Zhenjiang Currently tangling does not support limiting to the active region. It shouldn't be too difficult to update org-babel-tangle to use region-active-p to perform such limiting, unfortunately I personally don't have the time to implement such an extension. Best, -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] how to force org-mode to interpret number as string
Eric Schulte schulte.e...@gmail.com writes: Stefan Huchler stefan.huch...@mail.de writes: Bastien b...@gnu.org writes: Hi Stefan, Stefan Huchler stefan.huch...@mail.de writes: The Problem is that that org-mode seems to auto-format the salary column as a number. That a problem here, but I guess this is handy in many circumstances. Why don't use just turn the number into a string in your code? if I could do that, without loosing the numbers behind the point I would be ok with that, but I dont want a fixed system for 1 table, but for a random table. I think that for this to work you may have to abandon using . as your numerical thousands separator. Or customize string-to-number and org-babel-number-p to fit your number syntax. Best, I think the way I have to go is to use export the table to csv then it looses some of its cleverness and does what it should do in the first place. Hmm I just thought a second, maybe it does also do that data-manipulation also before it exports it, but no org-table-export does export it like a string. So here you have one bug, its inconsistent. So yes the easiest workaround is most likely to export it to a csv in /tmp/... and then parse it back ^^. Again I am suprised that there is no serial-mail package for emacs, then I would not even have to write this code. Sorry that I am maybe not so constructive but it´s stuff that should work and now you say that I should fix that upstream with me having written 50 lines of lisp code in my life. And how big are the chances that it gets included, when you people do not even consider that as a bug / needed feature. But sorry I really flame to much, I just find some stuff really stupid, as example why did I need to make out of a table a dict in the first place to put it into a list with lists is really stupid, dicts are more confortable I know in elisp maybe it has another name, but its similar and even in python I get no list of dicts (lines). Is it because of monstroses big Tables and performance problems? Sorry I can´t stopp. Still there is much great stuff there. Else I would not try to migrate my life into emacs ^^ ;)
Re: [O] how to force org-mode to interpret number as string
I think that for this to work you may have to abandon using . as your numerical thousands separator. Or customize string-to-number and org-babel-number-p to fit your number syntax. Best, I think the way I have to go is to use export the table to csv then it looses some of its cleverness and does what it should do in the first place. Hmm I just thought a second, maybe it does also do that data-manipulation also before it exports it, but no org-table-export does export it like a string. So here you have one bug, its inconsistent. Automatically recognizing numbers in tables is useful when converting tables to code, but would make no sense for CSV export. I don't see a problem here. Sorry that I am maybe not so constructive but it´s stuff that should work and now you say that I should fix that upstream with me having written 50 lines of lisp code in my life. I suggested that you remove . from your numbers. You could also wrap your numbers in s. #+name: example | 100. | #+begin_src emacs-lisp :var example=example (caar example) #+end_src #+RESULTS: : 100. Furthermore, when I said customize I did not mean fix upstream, I meant re-define org-babel-number-p in your *personal* config file. I apologize if this was not clear. But sorry I really flame to much, I just find some stuff really stupid, as example why did I need to make out of a table a dict in the first place to put it into a list with lists is really stupid, dicts are more confortable I know in elisp maybe it has another name, but its similar and even in python I get no list of dicts (lines). Is it because of monstroses big Tables and performance problems? I would argue that the list of lists representation is indeed more commonly useful than converting a table to a list of dictionaries keyed by the header row. Maybe you will find the following helpful. #+TBLNAME: jobs | jobname | city | salary | email | | Taxi-driver | New York City | 500.000 | ma...@gotham-city.com | | Butcher | Peking| 5.000 | jinp...@china.cn | #+name: table-w-headers-to-list-of-key-value #+begin_src emacs-lisp :var data='() (let ((keys (car data)) (vals (cdr data))) (mapcar (lambda (row) (map 'list #'cons keys row)) vals)) #+end_src Example usage, pull the email from each value. #+begin_src emacs-lisp :var data=table-w-headers-to-list-of-key-value(jobs) (mapcar (lambda (row) (cdr (assoc email row))) data) #+end_src #+RESULTS: | ma...@gotham-city.com | jinp...@china.cn | -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
[O] [PATCH] Fixed bug in org-entry-get-with-inheritance
From bea0daf422e9ab8f27addb412aa03456c89d5844 Mon Sep 17 00:00:00 2001 From: Ilya Shlyakhter ilya_...@alum.mit.edu Date: Fri, 7 Mar 2014 01:09:13 -0500 Subject: [PATCH] Properties: Fix property-getting with inheritance * lisp/org.el (org-entry-get-with-inheritance): Temporarily clear org-file-properties, org-global-properties and org-global-properties-fixed before calling org-entry-get on entries up the hierarchy from the queried entry. Problem was that when org-entry-get-with-inheritance went up the hierarchy of entries from a given entry, checking whether the property has been set in any of the entries, it was calling org-entry-get, which always looks at file-scope and global-scope properties. So if our property was set file-wide or system-wide, and somewhere up the hierarchy there was an entry which set some properties _other_ than the one we're looking up but did not set ours, org-entry-get would fill in the global property value and report that our property was in fact set in that entry. The search would stop, and if the property was actually set further up the hierarchy (which should override file-wide or system-wide settings), we would never get to that up-the-hierarchy setting. Illustration of fixed problem: #+PROPERTY: myprop aaa * headline A :PROPERTIES: :myprop: bbb :END: *** headline B :PROPERTIES: :otherprop: ccc :END: #+BEGIN_SRC emacs-lisp (message (org-entry-get-with-inheritance myprop)) #+END_SRC #+RESULTS: : aaa Result should be bbb, which it is after the fix. --- lisp/org.el | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 6f4b853..cd2a1c6 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -15548,14 +15548,15 @@ However, if LITERAL-NIL is set, return the string value \nil\ instead. (save-restriction (widen) (catch 'ex - (while t - (when (setq tmp (org-entry-get nil property nil 'literal-nil)) - (or (ignore-errors (org-back-to-heading t)) - (goto-char (point-min))) - (move-marker org-entry-property-inherited-from (point)) - (throw 'ex tmp)) - (or (ignore-errors (org-up-heading-safe)) - (throw 'ex nil)) + (let (org-file-properties org-global-properties org-global-properties-fixed) + (while t + (when (setq tmp (org-entry-get nil property nil 'literal-nil)) + (or (ignore-errors (org-back-to-heading t)) + (goto-char (point-min))) + (move-marker org-entry-property-inherited-from (point)) + (throw 'ex tmp)) + (or (ignore-errors (org-up-heading-safe)) + (throw 'ex nil))) (setq tmp (or tmp (cdr (assoc property org-file-properties)) (cdr (assoc property org-global-properties)) -- 1.8.4
Re: [O] Org release 8.2.5g (minor release from maint)
Hi Eric and Nick, Eric Schulte schulte.e...@gmail.com writes: Great, so should Org-mode require cl-lib and stop supporting the following functions? I guess so. But I'm unclear yet whether this removes compatibility with older Emacsen. I'll check this. -- Bastien
Re: [O] BUG org-babel-goto-named-src-block with indented block
Hi Eric, thanks for looking into this! Eric Schulte schulte.e...@gmail.com writes: Hi Andreas, The problem is with your example. You can not put a header line between a #+name and it's source block. If that is the case, then the manual should be fixed. As the manual explicitly allows that: See the last example on here [fn:1]. Regards, Andreas Footnotes: [fn:1] http://orgmode.org/manual/Code-block-specific-header-arguments.html#Code-block-specific-header-arguments Best, Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi all, there seems to be a bug, where org-babel-goto-named-src-block does not find an indented source block. Here is an example: --8---cut here---start-8--- * Test org-babel-goto-named-src-block Try org-babel-goto-named-src-block (C-c C-v g) with point on the following line. (This works for me.) #+call: block1(20) Try org-babel-goto-named-src-block (C-c C-v g) with point on the following line. (This does not work for me.) #+call: block2(20) ** The first block *without* indentation #+name: block1 #+header: :var end=10 #+begin_src R 1:end #+end_src ** The second block *with* indentation #+name: block2 #+header: :var end=11 #+begin_src R 2:end #+end_src --8---cut here---end---8--- Regards, Andreas
