Re: [O] org-babel -- Improper syntax error in session mode?
Aloha Herbert, I think you're right about the potential to improve the documentation. That's an on-going process. Could you suggest some specific changes? All the best, Tom Herbert Sitz writes: > Eric Schulte gmail.com> writes: > >> >> Babel sessions explicitly are thin wrappers around the interactive mode >> of the language in question (whatever that may be). That is why Babel >> happily doesn't implement sessions for all languages, the contract >> simply is that if a language supports interactive evaluation, Babel will >> try to allow access to that functionality. >> > > That the Babel session is only a "thin" wrapper is not clear at all from the > docs. The docs do mention 'interactive session'--and even that the output may > be slightly different from the non-session mode. The docs don't mention > anything about the user needing to do extra preparation to avoid syntax errors > in evaluation of already valid code. If I take an existing Org block of > non-session code and stick a :session on I don't expect to get syntax errors. > If that's the expected behavior then it needs to be emphasized more in the > docs, otherwise most users will think something is broken in Org. > >> If the contract was rather simply "Babel provides session based >> evaluation", then we'd be on the hook for implementing session >> evaluation where it doesn't already exist and may not make sense (e.g., >> C, ditaa), and normalizing everywhere else as you're suggesting here. >> Which would in turn requires us to spell out Babel-specific semantics of >> session based evaluation -- something we have thus-far avoided. > > Again, the docs reference 'Session based evaluation' in big bold letters and > don't indicate the thinness of the wrapper. > >> >> Some positive points *for* the "thin wrapper" approach include; >> >> 1. It is the simplest to implement >>- easier to implement support for new language >>- easier to maintain -- especially if interactive tools change >>- easier to reason about -- thinking about bug fixing here >>- works with alternate back-ends e.g., ipython >> > > I think I have a solution for Python that gives full "session-based > evaluation" > and which is better than the current "thin wrapper" for all four concerns > above > (See bottom of my message for an example.) This same approach, I think, would > work for Ruby, but I would need to do a little digging to find exact method. > Let me know if you want me to do that digging. > >> 2. It is the least surprising. I'd maintain that for users familiar >>with using Python sessions this behavior is the easiest to quickly >>understand and use. As opposed to if we did something fancy (even if >>it was an improvement) it would be another environment for language >>users to have to familiarize themselves with -- they'd have both >>normal session rules and babel session rules > > As a sometimes Python user it had me totally confused. I don't think of > "session-based" as having any essential tie to "interactive shell" at all. > Why > would I worry about state being maintained between statements in an org > block? > State is already maintained between statements in non-session Org blocks. The > only difference with session-based blocks is the starting state may not be > "fresh". > > When I look at Org and think of "session-based" blocks, I see a potential big > benefit in having multiple source-blocks throughout my document share the same > session. That way I don't need to use Org's (clever and useful but) somewhat > clunky and inflexible method of passing data explicitly. In statistics-based > docs, for example, I can imagine that the sheer amount of data would make > using > Org's explicit variable-passing method unfeasible. Using > session-based-evaluation is at the same time both simpler and more heavy-duty. > > I never thought the use of session-based code blocks as something like a > scratchpad was much more than toy. If you're typing in code that's not > intended > to be an integral part of an Org doc then you could just as well jump to the > shell and enter it there. > > Here's an example of how to run a block of Python code of any length in the > interactive session and save its output in a file. Note that this is _not_ > interactive, even though the command runs in the interactive shell's session: > > Start with this block of code: > - > #+begin_src python :results output :session mypy > x = 1 > y = 1 > z = 1 > for i in range(1,2): > x = x + i > print x > > for y in range(10,11): > print y > # comment here > for z in range(5,6): > print z > while y > 0: > print y > y=y-1 > > print "Did it work?" > #+end_src > > > Strip out the block of empty space at the left side and save in a file in > current d
Re: [O] [Bug] Doc string for org-clock-into-drawer truncated?
On Jun 20, 2011, at 9:32 PM, Achim Gratz wrote: > > In org-clock.el, the following definition is found: > > (defcustom org-clock-into-drawer org-log-into-drawer > "Should clocking info be wrapped into a drawer? > When t, clocking info will always be inserted into a :LOGBOOK: drawer. > If necessary, the drawer will be created. > When nil, the drawer will not be created, but used when present. > When an integer and the number of clocking entries in an item > reaches or exceeds this number, a drawer will be created. > When a string, it names the drawer to be used. > > The default for this variable is the value of `org-log-into-drawer', > which see." > … > > I can't make much sense of the last sentence which looks truncated. It means, please look at the variable org-log-into-drawer for more information. I have seen this idiom in Emacs in a number of places, so I assumed it is OK. > > As an aside, while the value for org-log-into-drawer can be changed for > a subtree by setting a property, this setting is not honored for > clocking in the same subtree, which will still use the value of > org-log-into-drawer in global or local scope or the LOGBOOK drawer, if > present. In org-clock.el: > > (if org-clock-into-drawer > (let ((logbook >(if (stringp org-clock-into-drawer) >(concat ":" org-clock-into-drawer ":") > ":LOGBOOK:"))) > > But no defun to check a property like that used for logging in org.el: > > (defun org-log-into-drawer () > "Return the value of `org-log-into-drawer', but let properties overrule. > If the current entry has or inherits a LOG_INTO_DRAWER property, it will be > used instead of the default value." > (let ((p (org-entry-get nil "LOG_INTO_DRAWER" 'inherit))) >(cond > ((or (not p) (equal p "nil")) org-log-into-drawer) > ((equal p "t") "LOGBOOK") > (t p > > For symmetry it seems that one should be able to specify a property > CLOCK_INTO_DRAWER specifically for clocking or fall back onto LOG_INTO > DRAWER, just like the customization variables allow one to do. This does make sense, can you make a patch? - Carsten
Re: [O] org-capture does not fully clean up after C-c C-k
Hi Jason,
On Jun 16, 2011, at 8:44 PM, Jason Dunsmore wrote:
> Carsten Dominik writes:
>
>> On 4.5.2011, at 14:30, Leo wrote:
>>
>>> Hello,
>>>
>>> I have one template as follows
>>>
>>> ("n" "Notes" entry (file "Notes.org") "* %?\n %i" :prepend t)
>>>
>>> Every time I `C-c C-k' to abort the capture, a blank line is inserted at
>>> the front of file Notes.org.
>>
>> Hi Leo,
>>
>> I am unable to reproduce this. I do get an empty line the first time,
>> but when the empty line is already there, then there is no problem.
>>
>> Do you find the insertion of this one empty line a problem?
>
> It's a significant problem for me. I still use org-remember because 1)
> org-capture inserts an extra blank line
Do you also mean at the beginning of the file, or elsewhere?
> and 2) canceling a capture
> doesn't work for some reason - I get the following message:
>
> "org-capture-finalize: Capture process aborted, but target buffer could not
> be cleaned up correctly"
can you make a minimal example to demonstrate this issue?
I would like to fix it.
>
> Both of these issues cause me to do manual clean up following every
> capture.
>
> Please let me know if there are fixes/workarounds for these issues. I'd
> like to finally make the switch to org-capture.
>
> Regards,
> Jason
- Carsten
Re: [O] Subtasks are blocked in todo-items of ordered projects. Bug?
On ma 20-jun-2011 19:37 Bernt Hansen wrote: >> Should the first task in a subproject of a project >> having the ':ORDERED:' property set to true be blocked from marking >> 'DONE'? If so, why? > > I think the answer is yes it should be blocked because the entire tree > is blocked - the previous task needs to be DONE first. When the > subtree is unblocked you can then complete the first task in the > subtree. Ok, to get the behaviour I want, I could remove the 'TODO' keyword from the subproject. That will allow me to work on the subitems in parallel. Obvious disadvantage is that the subproject as such can only have a 'count' or 'percentage' but not a 'state' and thus cannot be tracked anymore. Any other suggestions for a way to work on subitems in parallel with the 'main tasks'? I'll spent some time digging if the wanted behaviour could be formulated as an option to set without disturbing the default behaviour. marcel -- Marcel van der Boom -- http://hsdev.com/mvdb.vcf HS-Development BV-- http://www.hsdev.com We use bitcoin! -- http://bitcoin.org smime.p7s Description: S/MIME cryptographic signature
Re: [O] [Bug] Doc string for org-clock-into-drawer truncated?
On 21/06/11 08:49, Carsten Dominik wrote: On Jun 20, 2011, at 9:32 PM, Achim Gratz wrote: In org-clock.el, the following definition is found: (defcustom org-clock-into-drawer org-log-into-drawer "Should clocking info be wrapped into a drawer? When t, clocking info will always be inserted into a :LOGBOOK: drawer. If necessary, the drawer will be created. When nil, the drawer will not be created, but used when present. When an integer and the number of clocking entries in an item reaches or exceeds this number, a drawer will be created. When a string, it names the drawer to be used. The default for this variable is the value of `org-log-into-drawer', which see." … I can't make much sense of the last sentence which looks truncated. It means, please look at the variable org-log-into-drawer for more information. I have seen this idiom in Emacs in a number of places, so I assumed it is OK. I agree with Achim, that idiom makes no sense to a native English speaker. To make sense it should say something like " for which see the doc string for `org-log-into-drawer', or even better the way Achim's patch is worded. Having just been picky, I must say that I am astounded by the general high standard of English both on this list and in the org documentation, from many people for whom it must be a second language. If only many of our native English writers could communicate so clearly and with correct grammar! Ian.
Re: [O] Subtasks are blocked in todo-items of ordered projects. Bug?
Marcel van der Boom writes: [...] > That will allow me to work on the subitems in parallel. Obvious > disadvantage is that the subproject as such can only have a > 'count' or 'percentage' but not a 'state' and thus cannot be tracked > anymore. > > Any other suggestions for a way to work on subitems in parallel with the > 'main tasks'? Strictly speaking, there is no "parallel" working on subitems or tasks in an ordered Tree; thats why I only use it for situations where there is really no alternative order than the way it is laid out in front of me. Did you try org-depend.el in contrib/ ? It offers a much more flexibel way of handling dependencies. OTOH, this flexibility naturally needs more manual intervention to set things up than `C-c C-x o'. Memnon
Re: [O] Subtasks are blocked in todo-items of ordered projects. Bug?
Marcel van der Boom writes: > On ma 20-jun-2011 19:37 > Bernt Hansen wrote: > >>> Should the first task in a subproject of a project >>> having the ':ORDERED:' property set to true be blocked from marking >>> 'DONE'? If so, why? >> >> I think the answer is yes it should be blocked because the entire tree >> is blocked - the previous task needs to be DONE first. When the >> subtree is unblocked you can then complete the first task in the >> subtree. > > Ok, to get the behaviour I want, I could remove the 'TODO' keyword > from the subproject. > > That will allow me to work on the subitems in parallel. Obvious > disadvantage is that the subproject as such can only have a > 'count' or 'percentage' but not a 'state' and thus cannot be tracked > anymore. > > Any other suggestions for a way to work on subitems in parallel with the > 'main tasks'? I'll spent some time digging if the wanted > behaviour could be formulated as an option to set without disturbing > the default behaviour. You can work on things in parallel - you just can't mark them as completed. I clock in time on tasks I work on which changes TODO to STARTED and there is no restriction (that I'm aware of) on doing this. You can also force the task state to DONE with a triple prefix (C-u C-u C-u C-c C-t d) which will ignore the blocking rules for this state change. HTH, -- Bernt
Re: [O] Subtasks are blocked in todo-items of ordered projects. Bug?
On di 21-jun-2011 07:30 Bernt Hansen wrote: > You can also force the task state to DONE with a triple prefix (C-u > C-u C-u C-c C-t d) which will ignore the blocking rules for this state > change. I think I'll use this, sounds the simplest for my usecase. Thanks, marcel -- Marcel van der Boom -- http://hsdev.com/mvdb.vcf HS-Development BV-- http://www.hsdev.com We use bitcoin! -- http://bitcoin.org smime.p7s Description: S/MIME cryptographic signature
Re: [O] Subtasks are blocked in todo-items of ordered projects. Bug?
On Jun 21, 2011, at 1:40 PM, Marcel van der Boom wrote: > > On di 21-jun-2011 07:30 > Bernt Hansen wrote: > >> You can also force the task state to DONE with a triple prefix (C-u >> C-u C-u C-c C-t d) which will ignore the blocking rules for this state >> change. And one more alternative: If `org-treat-insert-todo-heading-as-state-change' is nil (which is the default), S-right on a TODO keyword will change states and bypass both logging and blocking. Cheers - Carsten > I think I'll use this, sounds the simplest for my usecase. > > Thanks, > > marcel > > -- > Marcel van der Boom -- http://hsdev.com/mvdb.vcf > HS-Development BV-- http://www.hsdev.com > We use bitcoin! -- http://bitcoin.org - Carsten
Re: [O] Subtasks are blocked in todo-items of ordered projects. Bug?
On Jun 21, 2011, at 1:54 PM, Carsten Dominik wrote: > > On Jun 21, 2011, at 1:40 PM, Marcel van der Boom wrote: > >> >> On di 21-jun-2011 07:30 >> Bernt Hansen wrote: >> >>> You can also force the task state to DONE with a triple prefix (C-u >>> C-u C-u C-c C-t d) which will ignore the blocking rules for this state >>> change. > > And one more alternative: > > If `org-treat-insert-todo-heading-as-state-change' is nil (which is the > default), > S-right on a TODO keyword will change states and bypass both logging and > blocking. this was a typo. I meant the variable `org-treat-S-cursor-todo-selection-as-state-change', and its default is t, so you have to set it to zero to get the behavior I was describing - Carsten
Re: [O] Org-mode is not able to manage complex calendar events
* Eric S Fraga wrote: > Karl Voit writes: > >> * Eric S Fraga wrote: >>> you can clone with time shift whole trees, etc. >> >> Oh, I have to look up that clone thing. This is new to me. Do you >> happen to have an URL for this feature by instance? > > ,[ org-clone-subtree-with-time-shift ] >| ... > ` Wow, this is *great* news to me, thanks! Although this is mentioned in chapter 2 of the Org-mode manual, I strongly urge to mention this in section 8.3.2 «Repeated tasks»[1] too! Where can I place this wish? > Sure; elisp is non-trivial. Point taken! Thanks :-) The resulting problem is that things I can only express using sexp is non-trivial too. I'd be glad to see something like this: * Event <2011-06-21 Tue +1w> <-2011-06-28 Tue> ... which lets me express an exception (each tuesday starting with today but not next week) in an easy to use way. > If there's any complaint one might have about org, is that it can > be used for so many different tasks (calendar, task management, > document preparation, etc.) that it can be overwhelming. Agree. But I'd consider the calendar use-case as the worst supported usecase in this list. I have seen the talks of Carsten Dominik and AFAIR he clearly says that Org-mode's focus is task oriented and not calendar oriented. > Think of one of those very large swiss army knives where > you can spend minutes just trying to find the right "blade" ;-). But > I'm not complaining! :-> :-) Me too *g* > In any case, the org manual, the org web site and Worg, not to mention > this mailing list, provide a wealth of information and use cases. I love the documentation of Org-mode - it's pretty good! >> For ELISP-hackers out there: is this hard to do? A method which >> can be called «generate a series of Org-mode time stamps starting >> with $THIS_TIMESTAMP_CONTAINING_REPEATS up to $THIS date». >> >> I could think of generating such a series of <2011-06-22 Wed> >> <2011-06-29 Wed> ... just to be able to see all occurrences of an >> event and delete one specific event in between if necessary. This >> would ease exceptions for «ordinary» users like me. > > See above; I use org-clone-subtree-with-time-shift for setting up, for > instance, the lectures I have to give in a teaching term. I set up the > initial lectures for each relevant day in the week and then clone the > subtrees, removing any exceptions (reading/study weeks, say) afterwards. Sure, org-clone-subtree-with-time-shift is very cool indeed. But it goes in this direction: * Event <2011-06-21 Tue> * Event <2011-06-28 Tue> * Event <2011-07-05 Tue> * Event <2011-07-12 Tue +1w> But I aim in a slightly different direction: * Event <2011-06-21 Tue> <2011-06-28 Tue>: additional note <2011-07-05 Tue> <2011-07-12 Tue +1w> The latter one works pretty well and keeps my Org-file more clear. So org-clone-subtree-with-time-shift is helping a lot for the upper method but my personal preference would be the second example. Is there already any solution to this too? 1. http://orgmode.org/org.html#Repeated-tasks -- Karl Voit
Re: [O] Org-mode is not able to manage complex calendar events
Karl Voit writes: [...] > Sure, org-clone-subtree-with-time-shift is very cool indeed. But it > goes in this direction: > > * Event <2011-06-21 Tue> > * Event <2011-06-28 Tue> > * Event <2011-07-05 Tue> > * Event <2011-07-12 Tue +1w> > > But I aim in a slightly different direction: > > * Event > <2011-06-21 Tue> > <2011-06-28 Tue>: additional note > <2011-07-05 Tue> > <2011-07-12 Tue +1w> > > The latter one works pretty well and keeps my Org-file more clear. > > So org-clone-subtree-with-time-shift is helping a lot for the upper > method but my personal preference would be the second example. I would use standard Emacs edit command to go from the first form to the second one: a keyboard macro or rectangle edit. -- Rémi Vanicat
[O] Double Quotation not translated in sections for LaTeX
Hello,
I'm using the org-mode 7.5 in Emacs 23.3.
I noticed this lines in org:
** ``Internal'' and "External" Example
``Internal'' and "External" Examples in paragraph
will result in tex:
\section{``Internal'' and "External" Example}
\label{sec-1_1}
``Internal'' and ``External'' Examples in paragraph
One can see that the " quotation in the heading line is not translated
properly into TeX.
Is this a bug?
Thanks!
Xin
Re: [O] org-babel -- Improper syntax error in session mode?
On Mon, Jun 20, 2011 at 5:08 PM, Nick Dokos wrote: > Herbert Sitz wrote: > >> ... (and, it turns out, _avoid_ blank lines in other cases) > > What are those cases? > > Nick > _Every_ spot where a blank line occurs that is followed by "unindented" line of (uncommented) code. By design, the blank line in interactive shell terminates a "highest-level" block and triggers its output. So you _can't_ have blank lines within a level-1 block, all lines in the block must have text. I just noticed, though, that you can include comments and that the indent of comments is irrelevant, so these blank lines could merely have a '# sign prepended to them to transform them into comments. (Existence of "unindented" comments needs to be taken into account for the regex that adds blank lines, though, since they're to be ignored for that purpose.) So this works fine in interactive shell with Eric's patch: -- #+begin_src python :results output :session mypy x = 1 y = 1 z = 1 for i in range(1,2): x = x + i print x # comment here for y in range(10,11): print y # comment here for z in range(5,6): print z while y > 0: print y y=y-1 print "Did it work?" #+end_src - but this doesn't - #+begin_src python :results output :session mypy x = 1 y = 1 z = 1 for i in range(1,2): x = x + i print x for y in range(10,11): print y for z in range(5,6): print z while y > 0: print y y=y-1 print "Did it work?" #+end_src --
[O] [WISH] Latex WYSIWYG
Hi, my first post here: So big shout outs to all org-mode hackers. Great Stuff! There is one feature I'd really like to have, but i couldn't find anything that does what i want. I guess it's just a small hack, but with my retarded elisp skills it would take me days to implement it. WYSIWYG Latex is probably not the correct term for this. What i have in mind is more like seeing the formula, while editing the ASCII/Unicode representation. I'll try to explain the idea more detailed. * Reason of Request: ** Finding Errors There is no avoiding mistakes for me when writing latex formulas and i just take note of them after recognizing that the image can't be rendered. For longer formulas it can be quite annoying and time consuming finding the errors and I sometimes end up splitting to the math-environment to several parts when trying to locate. ** Importance of seeing the equations while writing Hey, latex formulas are much more pleasant to the eye and striking in the brain than their ASCII representation, that's why we're using em. When developing a train of thought in formulas, I always need to see what I've written so far. So I feel forced to to split the math-environments into many small parts, and putting them together after wards. Or even worse when i loose track: I need to copy the line I'm writing on and push org-preview-latex-fragment before i can go on. ** Summarizing I write a bit, hit preview-latex-fragment and copy it to keep it in mind while writing on. Surely everyone using org-mode for heavily formula dependent text has the same problem. I would be glad for every hint to avoid this, probably there are already good solutions for this. In the following the one i imagine: * Description of the feature wished - Keep all latex-fragments in image representation - Only the one at cursor position is in ASCII representation (as in preview-latex) but still showing the corresponding image above it - editing the latex code segment updates the image Rephrased: When the caret enters a latex environment (usually shown as a picture) it's code shows up (maybe in a different color) with the caret at the position as if there would have never been an image. Maybe the code should be should be shown aboveHi, my first post here: So big shoutouts to all org-mode hackers. Great Stuff! There is one feature i'd really like to have, but i couldn't find anything that does what i want. I guess it's just a small hack, but with my retarded elisp skills it would take me days to implement it. WYSIWYG Latex is probably not the correct term for this. What i have in mind is more like seeing the formula, while editing the ASCII/Unicode representation. I'll try to explain the idea more detailed below. * Reason of Request: ** Finding Errors There is no avoding mistakes for me when writing latex formulas and i just take note of them after recognizing that the image can't be rendered. For longer formulas it can be quite annoying and time consuming finding the errors and I sometimes end up splitting to the math-environment to several parts when trying to locate. ** Importance of seeing the equations while writing Hey, latex formulas are much more pleasant to the eye and striking in the brain than their ASCII represenation, that's why we're using em. When devoloping a train of thought in formulas, I always need need to see what I've written so far. So I feel forced to to split the math-environments into many small parts, and putting them together afterwards. Or even worse when i loose track: I need to copy the line I'm writing on and push org-preview-latex-fragment before i can go on. ** Summarizing I write a bit, hit preview-latex-fragment and copy it to keep it in mind while writing on. Surley everyone using org-mode for heavly formula dependent text has the same problem. I would be glad for every hint to avoid this, probably there are already good solutions for this. In the following the one i imagine: * Description of the feature wished - Keep all latex-fragments in image represenation - Only the one at cursor position is in ASCII representation (as in preview-latex) but still showing the corresponding image above it - editing the latex code segment updates the image Rephrased: When the caret enters a latex environment (usually shown as a picture) it's code shows up (maybe in a diffrent color) with the caret at the position as if there would have never been an image. Maybe the code should be should be shown below/above the the corresponding image wheather the carret enters from the top/bottom to avoid jumping of the image at focus (if this doesn't lead to more confusion than it helps) It shouldn't be to hard to do? Just auto evaluate the latex snippets and showing it's code when the cursor is above it. Could any elisp crack who's already into the org-latex code hack this? Or are there already better solutions? Thank you for any response, JonnyB. Another questio
Re: [O] [PATCH] Subtasks are blocked in todo-items of ordered projects. Bug?
On di 21-jun-2011 13:40 Marcel van der Boom wrote: >> You can also force the task state to DONE with a triple prefix (C-u >> C-u C-u C-c C-t d) which will ignore the blocking rules for this >> state change. > I think I'll use this, sounds the simplest for my usecase. On second thought, the patch is quite minimal, I've applied the attached patch in my branch which seems to do what I want. I'd obviously welcome this being applied in the main tree, but I can understand if it won't. What would be nice in general if the message that is produced contained a hint on why the entry was blocked by the system (children incomplete, sibling blocked etc.) Thanks everyone for the help. marcel -- Marcel van der Boom -- http://hsdev.com/mvdb.vcf HS-Development BV-- http://www.hsdev.com We use bitcoin! -- http://bitcoin.org diff --git a/lisp/org.el b/lisp/org.el index fee3174..c28d355 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -2181,6 +2181,17 @@ to change is while Emacs is running is through the customize interface." :group 'org-todo :type 'boolean) +(defcustom org-blocker-ignore-ancestor-siblings nil + "Non-nil means that when determining if a TODO entry is blocked, +siblings of entries which are higher up the hierarchy are not +considered. This allows to register state changes for item in +subprojects of ordered projects which enforce ordering. The +subproject itself is not affected. See +`org-block-todo-from-children-or-siblings-or-parent' for the +implementation." + :group 'org-todo + :type 'boolean) + (defcustom org-enforce-todo-checkbox-dependencies nil "Non-nil means unchecked boxes will block switching the parent to DONE. When this is nil, checkboxes have no influence on switching TODO states. @@ -11151,7 +11162,8 @@ changes. Such blocking occurs when: (when (and (org-not-nil (org-entry-get (point) "ORDERED")) (forward-line 1) (re-search-forward org-not-done-heading-regexp pos t)) - (throw 'dont-block nil ; block, older sibling not done. + ; block, older sibling not done, unless configured to ignore. + (throw 'dont-block org-blocker-ignore-ancestor-siblings (defcustom org-track-ordered-property-with-tag nil "Should the ORDERED property also be shown as a tag? smime.p7s Description: S/MIME cryptographic signature
Re: [O] Bug: org-reset-checkbox-state-subtree doesn't update checkbox cookies [7.5 (release_7.5.280.ga6e9)]
Nicolas Goaziou gmail.com> writes: > > Indeed, I noticed that when working on Paul's report. Issues should be > fixed now. > > Regards, > All working fine now, thanks! Paul
[O] [PATCH] org-latex: Convert quote marks in section headers
* lisp/org-latex.el (org-export-latex-fontify-headline): Convert
quotes to their LaTeX equivalents using
org-export-latex-quotation-marks.
---
Xin Shi wrote:
> Hello,
> I'm using the org-mode 7.5 in Emacs 23.3.
> I noticed this lines in org:
> ** ``Internal'' and "External" Example
>``Internal'' and "External" Examples in paragraph
> will result in tex:
> \section{``Internal'' and "External" Example}
> \label{sec-1_1}
>``Internal'' and ``External'' Examples in paragraph
> One can see that the " quotation in the heading line is not translated
> properly into TeX.
> Is this a bug?
It would appear to be so, though I'm not sure if the decision not
to convert quotation marks is a deliberate one. Although looking
at the commit logs, it would appear that it's probably an oversight.
lisp/org-latex.el |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/lisp/org-latex.el b/lisp/org-latex.el
index 8abe1d2..bc7644a 100644
--- a/lisp/org-latex.el
+++ b/lisp/org-latex.el
@@ -1589,6 +1589,7 @@ links, keywords, lists, tables, fixed-width"
(when (plist-get org-export-latex-options-plist :emphasize)
(org-export-latex-fontify))
(org-export-latex-time-stamps)
+(org-export-latex-quotation-marks)
(org-export-latex-keywords-maybe)
(org-export-latex-special-chars
(plist-get org-export-latex-options-plist :sub-superscript))
--
1.7.4.1
Re: [O] exporting emphasised text (bold, italics etc.) in ORGTBL
Benjamin Slade wrote:
> When I'm using orgtbl in the midst of a LaTeX document, is there a way to
> tell it to export *bold*
> as \textbf{bold}, /italics/ as \textit{italics} etc.?
Yes, just like that. For example, the following works fine for me:
--8<---cut here---start->8---
* foo
Here's a table:
| foo | bar |
|---+-|
| 1 | 2 |
| 3 | 4 |
| \textbf{bold} | \textit{italic} |
| | |
--8<---cut here---end--->8---
Not sure if you are talking about radio tables in a LaTeX file,
but that too seems to work fine (see appendix A.5.1 of the Org manual
for more details on this:
--8<---cut here---start->8---
\documentclass{article}
\begin{document}
Here's a table of stuff:
% BEGIN RECEIVE ORGTBL to-buy
\begin{tabular}{rr}
foo & bar \\
\hline
1 & 2 \\
3 & 4 \\
\textbf{bold} & \textit{italic} \\
& \\
\end{tabular}
% END RECEIVE ORGTBL to-buy
%The Org table is inside a LaTeX comment.
% #+ORGTBL: SEND to-buy orgtbl-to-latex
% | foo | bar |
% |---+-|
% | 1 | 2 |
% | 3 | 4 |
% | \textbf{bold} | \textit{italic} |
% | | |
\end{document}
%%% Local Variables:
%%% mode: latex
%%% TeX-master: t
%%% End:
--8<---cut here---end--->8---
Nick
Re: [O] org-babel -- Improper syntax error in session mode?
Thomas S. Dye tsdye.com> writes: > > Aloha Herbert, > > I think you're right about the potential to improve the documentation. > That's an on-going process. Could you suggest some specific changes? > > All the best, > Tom Tom -- I would suggest just adding specific warnings that session-based evaluation may throw syntax errors with valid code. Here's what Org manual says regarding :session evaluation with :results output': "The code is passed to the interpreter running as an interactive Emacs inferior process. The result returned is the concaOrg tenation of the sequence of (text) output from the interactive interpreter. Notice that this is not necessarily the same as what would be sent to STDOUT if the same code were passed to a non-interactive interpreter running as an external process. . . ." [http://orgmode.org/manual/Results-of-evaluation.html#Results-of-evaluation] All that needs to be added is a warning: "IMPORTANT: Note that Org provides only a thin wrapper around a language's interactive shell, so valid code that executes properly in non-session mode may fail in :session mode. This is because Org feeds the lines in a :session block to the interactive interpreter exactly as written. In come cases the lines may require special formatting in the source block to be executed properly in the interactive shell. For example: . . . " I think the above issue should be moot for some of the main interpreted languages (viz., Python, Perl, Ruby) where there are various ways to execute a block of code non-interactively despite being in the interactive shell. (One of those methods is the example I gave in previous message.) In that case identical code will run the same whether it's in an interactive-interpreter session or not. It seems to me that switching to that approach for languages that support it should both (1) simplify the Org Babel code, and (2) provide Org users with more flexibility and power. Also, it seems the real power of :session evaluation is to share state between Org/Babel source code blocks, not merely to act as a kind of Org-internal scratchpad. As a user trying to take advantage of that state-sharing power I would generally want my Org document exports to start from fresh sessions. That is, I would write my :session blocks so that they depended on results of code run in previous :session blocks, BUT I would want the first :session block to start with a fresh session,with a known state. So on export I would generally want any existing named session to be closed and restarted anew for an Org export. I hope that all makes sense. I should say I'm not a big Babel user, and I could easily be misunderstanding something. But it seems this is the way the :session-based stuff should work, when possible. -- Herb
Re: [O] exporting emphasised text (bold, italics etc.) in ORGTBL
Thanks, Nick. Yes, I understand what you're saying.
But what I was wondering is this: orgmode generally interprets *word* as
bolding of "word" and /word/ as italicising of "word". So is there a way to
make it export *word* as \textbf{word} and /word/ as \textit{word}, when
using orgtbl.
cheers,
--Ben
On 21 June 2011 10:28, Nick Dokos wrote:
> Benjamin Slade wrote:
>
> > When I'm using orgtbl in the midst of a LaTeX document, is there a way to
> tell it to export *bold*
> > as \textbf{bold}, /italics/ as \textit{italics} etc.?
>
> Yes, just like that. For example, the following works fine for me:
>
> --8<---cut here---start->8---
>
> * foo
>
> Here's a table:
>
>
> | foo | bar |
> |---+-|
> | 1 | 2 |
> | 3 | 4 |
> | \textbf{bold} | \textit{italic} |
> | | |
> --8<---cut here---end--->8---
>
>
> Not sure if you are talking about radio tables in a LaTeX file,
> but that too seems to work fine (see appendix A.5.1 of the Org manual
> for more details on this:
>
> --8<---cut here---start->8---
> \documentclass{article}
>
> \begin{document}
> Here's a table of stuff:
>
> % BEGIN RECEIVE ORGTBL to-buy
> \begin{tabular}{rr}
> foo & bar \\
> \hline
> 1 & 2 \\
> 3 & 4 \\
> \textbf{bold} & \textit{italic} \\
> & \\
> \end{tabular}
> % END RECEIVE ORGTBL to-buy
>
>
> %The Org table is inside a LaTeX comment.
>
> % #+ORGTBL: SEND to-buy orgtbl-to-latex
> % | foo | bar |
> % |---+-|
> % | 1 | 2 |
> % | 3 | 4 |
> % | \textbf{bold} | \textit{italic} |
> % | | |
>
>
> \end{document}
>
> %%% Local Variables:
> %%% mode: latex
> %%% TeX-master: t
> %%% End:
> --8<---cut here---end--->8---
>
> Nick
>
--
-
Benjamin Slade
Dept. of Linguistics
University of Illinois at Urbana-Champaign
[ http://www.jnanam.net/slade/ ]
Stæfcræft & Vyākaraṇa (lingblog) - http://staefcraeft.blogspot.com
The Babbage Files (techblog) - http://babbagefiles.blogspot.com
-
*प*रो ऽक्ष॑का*मा* हि *दे*वाः
'The gods love the obscure.' (Śatapathabrāmaṇa 6.1.1.2)
Re: [O] Org-mode is not able to manage complex calendar events
Karl Voit writes: > * Eric S Fraga wrote: >> Karl Voit writes: >> > >>> * Eric S Fraga wrote: you can clone with time shift whole trees, etc. >>> >>> Oh, I have to look up that clone thing. This is new to me. Do you >>> happen to have an URL for this feature by instance? >> >> ,[ org-clone-subtree-with-time-shift ] >>| ... >> ` > > Wow, this is *great* news to me, thanks! You're very welcome! > Although this is mentioned in chapter 2 of the Org-mode manual, I > strongly urge to mention this in section 8.3.2 «Repeated tasks»[1] > too! > > Where can I place this wish? You've done so, to some degree, by expressing this on the mailing list. Better yet, however, is to update the documentation yourself and submit a patch! Instructions on how to contribute to org are on the web site (I'm offline at the moment so cannot give you a direct link; sorry). Patches to the documentation, in particular, are very welcome and generally straightforward to generate! >> Sure; elisp is non-trivial. Point taken! > > Thanks :-) The resulting problem is that things I can only express > using sexp is non-trivial too. > > I'd be glad to see something like this: > >* Event <2011-06-21 Tue +1w> <-2011-06-28 Tue> > > ... which lets me express an exception (each tuesday starting with > today but not next week) in an easy to use way. Not possible without use of sexp entries, as far as I know. >> If there's any complaint one might have about org, is that it can >> be used for so many different tasks (calendar, task management, >> document preparation, etc.) that it can be overwhelming. > > Agree. But I'd consider the calendar use-case as the worst supported > usecase in this list. I have seen the talks of Carsten Dominik and > AFAIR he clearly says that Org-mode's focus is task oriented and not > calendar oriented. Yes, I think that's a fair assessment. The trick to using org is to realise that everything in life is really oriented around tasks; calendaring then comes automatically from this! The problem is that most people have gotten used to separating tasks from calendar views (cf. separation between tasks lists and appointments) and so moving to org can be a bit of a culture shock. If you start thinking from the tasks first, the rest follows. For instance, I'm working on a project; call it A. I create a headline for this project (or a file, or a sub-headline, whatever). Under this headline, I will create entries for finances, meetings, notes, actions, etc. Everything in one place. Org then provides a number of "views" to look at different aspects of this project: agenda view (akin to a calendar), column view, sparse tree view, tags view, ... All of these allow you to see, easily, the particular aspects of a project, or collection of projects, that are important at any point. [...] > Sure, org-clone-subtree-with-time-shift is very cool indeed. But it > goes in this direction: > > * Event <2011-06-21 Tue> > * Event <2011-06-28 Tue> > * Event <2011-07-05 Tue> > * Event <2011-07-12 Tue +1w> > > But I aim in a slightly different direction: > > * Event > <2011-06-21 Tue> > <2011-06-28 Tue>: additional note > <2011-07-05 Tue> > <2011-07-12 Tue +1w> > > The latter one works pretty well and keeps my Org-file more clear. I would argue that this is a more limiting view as it is difficult to add notes to each individual event, something I would often (always?) want to do! If each event (meeting?) is a sub-headline of its own, adding notes, actions that arise, etc is very easy. Again, you can use org to "view" the information you have in different ways so I would suggest you explore these views. For the above, maybe a Log view in the agenda might give you what you want. HTH. -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.414.g56de5)
Re: [O] org-babel -- Improper syntax error in session mode?
Aloha Herb, I think a note to that effect belongs here: http://orgmode.org/manual/session.html#session Perhaps the behavior related to session persistence could be described there, as well. Examples are probably best left to the language-specific documentation, such as it is, at http://orgmode.org/worg/org-contrib/babel/languages/ Note that there is no language-specific documentation for Python yet. Is it the case that the Ruby and Perl interpreters won't run code that does run in non-session mode? All the best, Tom Herbert Sitz writes: > Thomas S. Dye tsdye.com> writes: >> >> Aloha Herbert, >> >> I think you're right about the potential to improve the documentation. >> That's an on-going process. Could you suggest some specific changes? >> >> All the best, >> Tom > > Tom -- > > I would suggest just adding specific warnings that session-based evaluation > may > throw syntax errors with valid code. > > Here's what Org manual says regarding :session evaluation with :results > output': > > "The code is passed to the interpreter running as an interactive Emacs > inferior > process. The result returned is the concaOrg tenation of the sequence of > (text) > output from the interactive interpreter. Notice that this is not necessarily > the > same as what would be sent to STDOUT if the same code were passed to a > non-interactive interpreter running as an external process. . . ." > [http://orgmode.org/manual/Results-of-evaluation.html#Results-of-evaluation] > > All that needs to be added is a warning: > > "IMPORTANT: Note that Org provides only a thin wrapper around a language's > interactive shell, so valid code that executes properly in non-session mode > may > fail in :session mode. This is because Org feeds the lines in a :session > block > to the interactive interpreter exactly as written. In come cases the lines > may > require special formatting in the source block to be executed properly in the > interactive shell. For example: . . . " > > I think the above issue should be moot for some of the main interpreted > languages (viz., Python, Perl, Ruby) where there are various ways to execute a > block of code non-interactively despite being in the interactive shell. (One > of > those methods is the example I gave in previous message.) In that case > identical code will run the same whether it's in an interactive-interpreter > session or not. It seems to me that switching to that approach for languages > that support it should both (1) simplify the Org Babel code, and (2) provide > Org > users with more flexibility and power. > > Also, it seems the real power of :session evaluation is to share state between > Org/Babel source code blocks, not merely to act as a kind of Org-internal > scratchpad. As a user trying to take advantage of that state-sharing power I > would generally want my Org document exports to start from fresh sessions. > That > is, I would write my :session blocks so that they depended on results of code > run in previous :session blocks, BUT I would want the first :session block to > start with a fresh session,with a known state. So on export I would > generally > want any existing named session to be closed and restarted anew for an > Org export. > > I hope that all makes sense. I should say I'm not a big Babel user, and I > could > easily be misunderstanding something. But it seems this is the way the > :session-based stuff should work, when possible. > > -- Herb > > > -- Thomas S. Dye http://www.tsdye.com
[O] [bug] Latex export of lists (was Re: Problem with BEGIN_SRC export-as-latex and FORTRAN code)
Nick Papior Andersen writes:
> Hi all
>
> I have attached a sample which produces a wrong output in my org-mode
> installation. Both the output TeX file and the org file are attached.
>
> The wrong doing happens when i do "org-export-as-latex". The output tex file
> has removed a certain string length (i counted 23) and inserted some from
> the code below as a description in the item field (which it shouldn't do as
> we are in an enumerate environment).
The problem you describe does not exist in the current git head so I
recommend you try upgrading again. Maybe explain what problems you had
with 7.5?
In any case, using the same example file you posted, I see a different
problem when I export to latex. Here is a snippet of the resulting
latex:
,
| \section{Test}
| \label{sec-1}
|
|
| \begin{enumerate}
| \item Try and use \verb=org-export-as-latex=, it will produce error segment.
| \end{enumerate}
| \lstset{language=C}
| \begin{lstlisting}
|MODULE m_global_precision
| IMPLICIT NONE
| INTEGER, PARAMETER :: SP = SELECTED_REAL_KIND(6,30)
|END MODULE m_global_precision
| \end{lstlisting}
|
| ORG-LIST-END-MARKER
| \section{Test2}
`
*Note* the =ORG-LIST-END-MARKER=.
Finally, why not specify language=Fortran?
--
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.5 (release_7.5.414.g56de5)
Re: [O] [WISH] Latex WYSIWYG
Sebastian Berchtold writes:
> Hi, my first post here: So big shout outs to all org-mode hackers. Great
> Stuff!
>
> There is one feature I'd really like to have, but i couldn't find
> anything that does what i want. I guess it's just a small hack, but
> with my retarded elisp skills it would take me days to implement it.
>
> WYSIWYG Latex is probably not the correct term for this. What i have
> in mind is more like seeing the formula, while editing the
> ASCII/Unicode representation.
> I'll try to explain the idea more detailed.
You might prefer to use LyX instead of org if you really need this! It
has a very good latex math mode. Just a thought but sorry I'm not
really answering your question. :(
[...]
> Another question: Is there a simple way to activate latex syntax
> highlighting in org-mode?)
Put your latex code within a babel src block:
,
| #+begin_src latex
| \begin{something}
| and so on
| \end{something}
| #+end_src
`
HTH.
--
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.5 (release_7.5.414.g56de5)
Re: [O] [bug] Latex export of lists (was Re: Problem with BEGIN_SRC export-as-latex and FORTRAN code)
Hi Eric
Thanks.
I can see why the new thing would work as it utilizes the listing
environment. If the bug is fully removed then great.
It shows when the verbatim environment is used in my version. If a newer
version of org-mode will ever be used with only the verbatim environment,
then what happens?
No actual reason for not writing fortran besides it is shorter... However it
will produce the same error nonetheless.
Another error in your above shown result, is that the listing should have
been exported inside the enumerate environment. I have speculated whether
the error is due to fortran is not in language list.
http://orgmode.org/worg/org-contrib/babel/languages.html
As to my installation of org-mode, i downloaded and make, make install..
Have installed correctly, i just couldn't figure out to setup the new
installation of org (i.e. it still uses the old which is shipped by
standard!).
I think i can overcome this issue if i spend some more time on it. :)
Kind regards Nick
2011/6/21 Eric S Fraga
> Nick Papior Andersen writes:
>
> > Hi all
> >
> > I have attached a sample which produces a wrong output in my org-mode
> > installation. Both the output TeX file and the org file are attached.
> >
> > The wrong doing happens when i do "org-export-as-latex". The output tex
> file
> > has removed a certain string length (i counted 23) and inserted some from
> > the code below as a description in the item field (which it shouldn't do
> as
> > we are in an enumerate environment).
>
> The problem you describe does not exist in the current git head so I
> recommend you try upgrading again. Maybe explain what problems you had
> with 7.5?
>
> In any case, using the same example file you posted, I see a different
> problem when I export to latex. Here is a snippet of the resulting
> latex:
>
> ,
> | \section{Test}
> | \label{sec-1}
> |
> |
> | \begin{enumerate}
> | \item Try and use \verb=org-export-as-latex=, it will produce error
> segment.
> | \end{enumerate}
> | \lstset{language=C}
> | \begin{lstlisting}
> |MODULE m_global_precision
> | IMPLICIT NONE
> | INTEGER, PARAMETER :: SP = SELECTED_REAL_KIND(6,30)
> |END MODULE m_global_precision
> | \end{lstlisting}
> |
> | ORG-LIST-END-MARKER
> | \section{Test2}
> `
>
> *Note* the =ORG-LIST-END-MARKER=.
>
> Finally, why not specify language=Fortran?
>
> --
> : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
> : using Org-mode version 7.5 (release_7.5.414.g56de5)
>
Re: [O] Org-mode is not able to manage complex calendar events
* Rémi Vanicat wrote: > Karl Voit writes: > > >> Sure, org-clone-subtree-with-time-shift is very cool indeed. But it >> goes in this direction: >> >> * Event <2011-06-21 Tue> >> * Event <2011-06-28 Tue> >> * Event <2011-07-05 Tue> >> * Event <2011-07-12 Tue +1w> >> >> But I aim in a slightly different direction: >> >> * Event >> <2011-06-21 Tue> >> <2011-06-28 Tue>: additional note >> <2011-07-05 Tue> >> <2011-07-12 Tue +1w> > > I would use standard Emacs edit command to go from the first form to the > second one: a keyboard macro or rectangle edit. This is my current workaround, yes. But it's a bit annoying because usually I do not start with: * Event <2011-07-12 Tue +1w>" ... but rather with something like: * Event <2011-06-21 Tue +1w> :PROPERTIES: :CREATED: <2011-06-21 Tue 18:40> :END: And then the whole properties-drawer followed by the empty line gets cloned too which is not so easy to be modified by a simple rectangle operation alone. I'll have to look into Emacs keyboard macros (since I did not use them for nearly a decade). But if this is something a lot of people are aiming to, it might be a cool idea to provide a not-so-workaround solution :-) If not, I'll go for a works-for-me solution. -- Karl Voit
Re: [O] Org-mode is not able to manage complex calendar events
* Eric S Fraga wrote: > Karl Voit writes: > > Better yet, however, is to update the documentation yourself and submit > a patch! Pulled the current Org-mode files, read the contribution instructions[1], found the spot where the information should go and ... boom: ,[ http://orgmode.org/org.html#Repeated-tasks ] | An alternative to using a repeater is to create a number of copies | of a task subtree, with dates shifted in each copy. The command C-c | C-x c was created for this purpose, it is described in Structure | editing. ` Shame on me - I must have overlooked this important thing :-( >> I'd be glad to see something like this: >> >>* Event <2011-06-21 Tue +1w> <-2011-06-28 Tue> >> >> ... which lets me express an exception (each tuesday starting with >> today but not next week) in an easy to use way. > > Not possible without use of sexp entries, as far as I know. I know. I was dreaming of a future functionality which is easy to use (and easy to implement?) for the masses that are not yet enlightened with the knowledge of ELISP :-) > The trick to using org is to realise that everything in life is > really oriented around tasks; I will remember this statement and think of it the next days ... > calendaring then comes automatically from this! The problem is > that most people have gotten used to separating tasks from > calendar views (cf. separation between tasks lists and > appointments) and so moving to org can be a bit of a culture > shock. If you start thinking from the tasks first, the rest > follows. Hehe. Funny you mention that. Because I am using DateBk6[2] for PalmOS which integrates tasks into the calendar (very well!). So this is kina reverse thinking for me now. (Maybe you can think of «adding a different point of view to Org-mode» if you want.) > For instance, I'm working on a project; call it A. I create a > headline for this project (or a file, or a sub-headline, > whatever). Under this headline, I will create entries for > finances, meetings, notes, actions, etc. Everything in one place. I am currently adopting and developing my workflows for this, yes. > Org then provides a number of "views" to look at different aspects > of this project: agenda view (akin to a calendar), column view, > sparse tree view, tags view, ... All of these allow you to see, > easily, the particular aspects of a project, or collection of > projects, that are important at any point. I consider this the most important «feature» of Org-mode. I am dedicating my PhD (not only but mainly) to the notion that information visualization should not be depending on the structure the information is *stored* but only depending on the way I need to have while *accessing* it. [3] if you're interested. It's a research software that cleverly organizes your local files using tags and not within those usual (and not working) hierarchies of folders. It intgrates with *any* application you are currently using on Windows, OS X, and Linux as well. Current users are very happy with the method provided by tagstore. >> * Event <2011-06-21 Tue> >> * Event <2011-06-28 Tue> >> * Event <2011-07-05 Tue> >> * Event <2011-07-12 Tue +1w> >> >> But I aim in a slightly different direction: >> >> * Event >> <2011-06-21 Tue> >> <2011-06-28 Tue>: additional note >> <2011-07-05 Tue> >> <2011-07-12 Tue +1w> > > I would argue that this is a more limiting view as it is difficult to > add notes to each individual event, something I would often (always?) > want to do! If each event (meeting?) is a sub-headline of its own, > adding notes, actions that arise, etc is very easy. > > Again, you can use org to "view" the information you have in different > ways so I would suggest you explore these views. For the above, maybe a > Log view in the agenda might give you what you want. True. I'll give it a try. PS: Thanks for the help so far and I appreciate the community and discussion here very much. 1. http://orgmode.org/worg/org-contribute.html 2. http://www.pimlicosoftware.com/datebk6.htm 3. http://tagstore.org -- Karl Voit
Re: [O] org-babel -- Improper syntax error in session mode?
Thomas S. Dye tsdye.com> writes: > > Aloha Herb, > > [ . . . ] > > Is it the case that the Ruby and Perl interpreters won't run code that > does run in non-session mode? > > All the best, > Tom > Tom -- I don't know about Ruby and Perl, have only done some basic testing in Ruby and it works fine. My guess would be that generic Ruby and Perl code in :session mode is more likely to run without error than Python, because of Python's special reliance on and indentation as syntax items, and the way that affected design of the Python interactive shell. -- Herb
Re: [O] question about :results scalar
Excellent --- I'm glad that the interaction with emacs-lisp is straightened out! I've been continuing working with source blocks and the same problem seems to be present with clojure interaction. #+begin_src clojure :exports both :results scalar (ns whatever) (defn works? [] true) #+end_src #+results: | function | whatever/works? | The clojure repl would normally output the text "#'whatever/works?" but this is being converted into an org-mode table, ignoring the :results scalar declaration. futrhermore, the same test with emacs-lisp also fails as in this example #+begin_src clojure :results scalar '(1 2 3) #+end_src #+results: | 1 | 2 | 3 | --- also, although :results scalar still works, :results verbatim does not work quite yet for emacs-lisp #+begin_src emacs-lisp :results scalar ;;(debug t nil) '(1 2 3) #+end_src #+results: : (1 2 3) #+begin_src emacs-lisp :results verbatim ;;(debug t nil) '(1 2 3) #+end_src #+results: | 1 | 2 | 3 | M-x org-version returns: Org-mode version 7.5 (release_7.5.414.g56de5.dirty) Thank you so much for your prompt attention to my last comments! sincerely, --Robert McIntyre On Sun, Jun 19, 2011 at 6:08 PM, Eric Schulte wrote: > Hi Rob, > > Thanks for pointing this out. The emacs-lisp interaction is so simple > we apparently never implemented checks which are routine in other > languages. I just pushed up a fix to the git repository so the > ":results scalar" header argument combination should now be respected > for emacs-lisp. > > Thanks -- Eric > > Robert McIntyre writes: > > > hi --- I'm working through the org manual and have run into a strange > > problem with ":results scalar" > > > > M-x org-version gives "Org-mode version 7.5 > (release_7.5.288.gcec8.dirty)". > > > > I've made a code block using #+begin_src emacs-lisp :results scalar, > > with the source just being '(1 2 3), but I get back an org-table > > instead of the expected : (1 2 3). what am I doing wrong? > > > > a minimal example file can be found here: > > https://gist.github.com/1034648 > > > > I also get the same thing when trying the stable Org-mode version 7.5. > > > > sincerely, > > --Robert McIntyre > > > > -- > Eric Schulte > http://cs.unm.edu/~eschulte/ >
Re: [O] Problem with BEGIN_SRC export-as-latex and FORTRAN code
Hi Nick,
I think the solution to your problem may be simply to update to the
latest version of Org-mode, I get the following output when exporting
your example to LaTeX.
--8<---cut here---start->8---
\section{Test}
\label{sec-1}
\begin{enumerate}
\item Try and use \texttt{org-export-as-latex}, it will produce error segment.
\begin{verbatim}
MODULE m_global_precision
IMPLICIT NONE
INTEGER, PARAMETER :: SP = SELECTED_REAL_KIND(6,30)
END MODULE m_global_precision
\end{verbatim}
\end{enumerate}
\section{Test2}
\label{sec-2}
\begin{enumerate}
\item This will not fail as it is not in an enumerate environment.
\end{enumerate}
\begin{verbatim}
MODULE m_global_precision
IMPLICIT NONE
INTEGER, PARAMETER :: SP = SELECTED_REAL_KIND(6,30)
END MODULE m_global_precision
\end{verbatim}
--8<---cut here---end--->8---
I'm using
Org-mode version 7.5 (release_7.5.414.g56de5)
Best -- Eric
Nick Papior Andersen writes:
> Hi all
>
> I have attached a sample which produces a wrong output in my org-mode
> installation. Both the output TeX file and the org file are attached.
>
> The wrong doing happens when i do "org-export-as-latex". The output tex file
> has removed a certain string length (i counted 23) and inserted some from
> the code below as a description in the item field (which it shouldn't do as
> we are in an enumerate environment).
>
> I have version 7.01g, i have had troubles to install the newest 7.5 org-mode
> version so i cant say if it does the same there. But i have searched the
> changes list for export on latex source. It didn't seem to have had any
> changes as far as this bug.
>
> I know that i probably shouldn't denote FORTRAN code as C code, but is that
> internally differentiated?
>
> Kind regards Nick
>
--
Eric Schulte
http://cs.unm.edu/~eschulte/
Re: [O] org-babel -- Improper syntax error in session mode?
Herbert Sitz writes: > Thomas S. Dye tsdye.com> writes: >> >> Aloha Herbert, >> >> I think you're right about the potential to improve the documentation. >> That's an on-going process. Could you suggest some specific changes? >> >> All the best, >> Tom > > Tom -- > > I would suggest just adding specific warnings that session-based evaluation > may > throw syntax errors with valid code. > Done. I've added such a warning -- although not as strongly stated as your suggestion > [...] > > Also, it seems the real power of :session evaluation is to share state between > Org/Babel source code blocks, not merely to act as a kind of Org-internal > scratchpad. As a user trying to take advantage of that state-sharing power I > would generally want my Org document exports to start from fresh sessions. > That > is, I would write my :session blocks so that they depended on results of code > run in previous :session blocks, BUT I would want the first :session block to > start with a fresh session,with a known state. So on export I would > generally > want any existing named session to be closed and restarted anew for an > Org export. > There are times when I explicitly do not want a session to start fresh. Generally this is related to caching, for example if I have some value which is expensive (say a couple of minutes of computation) to compute, and it is currently alive in the session, then I'd probably rather keep my session active across multiple exports as I'm working on other (say visual/prose tweaks) to the exported document. Does that make sense? If the user did want to refresh the session on _every_ export I believe they could add such a function to the `org-export-preprocess-hook'. Cheers -- Eric > > I hope that all makes sense. I should say I'm not a big Babel user, and I > could > easily be misunderstanding something. But it seems this is the way the > :session-based stuff should work, when possible. > > -- Herb > > > -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] question about :results scalar
Hi Robert, I've added "verbatim" to the Emacs-lisp support. The attached patch should fix the Clojure behavior as well, however since I no longer have a working clojure install on my system, would you mind confirming it's behavior before I push it to the git repository? Thanks -- Eric >From 3d8136837979a6cd8e7a3b74be2d5652b81d1e16 Mon Sep 17 00:00:00 2001 From: Eric Schulte Date: Tue, 21 Jun 2011 10:35:58 -0700 Subject: [PATCH] ob-clojure: respect the ":results scalar" header argument * lisp/ob-clojure.el (org-babel-expand-body:clojure): Move pretty printing out of body expansion. (org-babel-execute:clojure): Now holds pretty printing logic, and respects the ":results scalar" header argument --- lisp/ob-clojure.el | 63 1 files changed, 34 insertions(+), 29 deletions(-) diff --git a/lisp/ob-clojure.el b/lisp/ob-clojure.el index cc6c2de..35e3bd7 100644 --- a/lisp/ob-clojure.el +++ b/lisp/ob-clojure.el @@ -49,39 +49,44 @@ (defun org-babel-expand-body:clojure (body params) "Expand BODY according to PARAMS, return the expanded body." - (let* ((vars (mapcar #'cdr (org-babel-get-header params :var))) - (result-params (cdr (assoc :result-params params))) - (print-level nil) (print-length nil) - (body (org-babel-trim - (if (> (length vars) 0) - (concat "(let [" - (mapconcat - (lambda (var) - (format "%S (quote %S)" (car var) (cdr var))) - vars "\n ") - "]\n" body ")") - body -(if (or (member "code" result-params) - (member "pp" result-params)) - (format - (concat - "(let [org-mode-print-catcher (java.io.StringWriter.)] " - "(clojure.pprint/with-pprint-dispatch clojure.pprint/%s-dispatch " - "(clojure.pprint/pprint (do %s) org-mode-print-catcher) " - "(str org-mode-print-catcher)))") - (if (member "code" result-params) "code" "simple") body) - body))) + (let ((vars (mapcar #'cdr (org-babel-get-header params :var))) + (print-level nil) (print-length nil)) +(org-babel-trim + (if (> (length vars) 0) + (concat "(let [" + (mapconcat + (lambda (var) + (format "%S (quote %S)" (car var) (cdr var))) + vars "\n ") + "]\n" body ")") + body (defun org-babel-execute:clojure (body params) "Execute a block of Clojure code with Babel." (require 'slime) (require 'swank-clojure) - (with-temp-buffer -(insert (org-babel-expand-body:clojure body params)) -((lambda (result) (condition-case nil (read result) (error result))) - (slime-eval - `(swank:interactive-eval-region - ,(buffer-substring-no-properties (point-min) (point-max))) - (cdr (assoc :package params)) + (let ((result-params (cdr (assoc :result-params params))) + (body (org-babel-expand-body:clojure body params))) +(with-temp-buffer + (insert + (if (or (member "code" result-params) + (member "pp" result-params)) + (format + (concat + "(let [org-mode-print-catcher (java.io.StringWriter.)] " + "(clojure.pprint/with-pprint-dispatch clojure.pprint/%s-dispatch " + "(clojure.pprint/pprint (do %s) org-mode-print-catcher) " + "(str org-mode-print-catcher)))") + (if (member "code" result-params) "code" "simple") body) + body)) + ((lambda (result) + (if (or (member "scalar" result-params) + (member "verbatim" result-params)) + result + (condition-case nil (read result) (error result + (slime-eval + `(swank:interactive-eval-region + ,(buffer-substring-no-properties (point-min) (point-max))) + (cdr (assoc :package params))) (provide 'ob-clojure) -- 1.7.4.1 Robert McIntyre writes: > Excellent --- I'm glad that the interaction with emacs-lisp is straightened > out! > > I've been continuing working with source blocks and the same problem seems > to be present with clojure interaction. > > #+begin_src clojure :exports both :results scalar > (ns whatever) > (defn works? [] true) > #+end_src > > #+results: > | function | whatever/works? | > > > The clojure repl would normally output the text > > "#'whatever/works?" > > but this is being converted into an org-mode table, ignoring the :results > scalar declaration. > > futrhermore, the same test with emacs-lisp also fails as in this example > > > #+begin_src clojure :results scalar > '(1 2 3) > #+end_src > > #+results: > | 1 | 2 | 3 | > > --- > > > also, although :results scalar still works, :results verbatim does not work > quite yet for emacs-lisp > > #+begin_src emacs-lisp :results scalar > ;;(debug t nil) > '(1 2 3) > #+end_src > > #+results: > : (1 2 3) > > > #+begin_src emacs-lisp :results verbatim > ;;(debug t nil) > '(1 2 3) > #+end_src > > #+results: > | 1 | 2 | 3 | > > > > M-x org-version returns: > Org-mode version 7.5 (release_7.5.414.g56de5.dirty) > > > Thank you so much for your prompt attention to my last comm
Re: [O] org-babel -- Improper syntax error in session mode?
Hi Herb,
I think we're agreed that the documentation should be updated, which
I've just done. As for your proposed solution.
You are suggesting that code to be run "interactively" should be written
to an external file then loaded into the interactive session. This
would certainly work around the syntax limitation of the current setup.
My two concerns here are that
1. users who use interactive babel blocks side-by-side with the session
may be used jumping into the session to play with code interactively
and debug, in such cases rather than seeing their code in the session
history they would only see execfile('/tmp/blahblah'). Note I do
recall discussion on list related to user's reading their session
code in the inferior session buffer.
2. similarly error messages would now point into this temporary file,
rather than back into the session history
Basically you would prefer more decoupling from the interpreter and I'm
not sure for the average user if this would be a worthwhile exchange
simply to be able to avoid syntax errors like your originally mentioned
example (which was the first such post I've seen on this list).
I'm disinclined to make such a change without a wider base of support
for the request from the Babel/Python user community -- or at least
without more complaints about the existing behavior.
Best -- Eric
Herbert Sitz writes:
> Eric Schulte gmail.com> writes:
>
>>
>> Babel sessions explicitly are thin wrappers around the interactive mode
>> of the language in question (whatever that may be). That is why Babel
>> happily doesn't implement sessions for all languages, the contract
>> simply is that if a language supports interactive evaluation, Babel will
>> try to allow access to that functionality.
>>
>
> That the Babel session is only a "thin" wrapper is not clear at all from the
> docs. The docs do mention 'interactive session'--and even that the output may
> be slightly different from the non-session mode. The docs don't mention
> anything about the user needing to do extra preparation to avoid syntax errors
> in evaluation of already valid code. If I take an existing Org block of
> non-session code and stick a :session on I don't expect to get syntax errors.
> If that's the expected behavior then it needs to be emphasized more in the
> docs, otherwise most users will think something is broken in Org.
>
>> If the contract was rather simply "Babel provides session based
>> evaluation", then we'd be on the hook for implementing session
>> evaluation where it doesn't already exist and may not make sense (e.g.,
>> C, ditaa), and normalizing everywhere else as you're suggesting here.
>> Which would in turn requires us to spell out Babel-specific semantics of
>> session based evaluation -- something we have thus-far avoided.
>
> Again, the docs reference 'Session based evaluation' in big bold letters and
> don't indicate the thinness of the wrapper.
>
>>
>> Some positive points *for* the "thin wrapper" approach include;
>>
>> 1. It is the simplest to implement
>>- easier to implement support for new language
>>- easier to maintain -- especially if interactive tools change
>>- easier to reason about -- thinking about bug fixing here
>>- works with alternate back-ends e.g., ipython
>>
>
> I think I have a solution for Python that gives full "session-based
> evaluation"
> and which is better than the current "thin wrapper" for all four concerns
> above
> (See bottom of my message for an example.) This same approach, I think, would
> work for Ruby, but I would need to do a little digging to find exact method.
> Let me know if you want me to do that digging.
>
>> 2. It is the least surprising. I'd maintain that for users familiar
>>with using Python sessions this behavior is the easiest to quickly
>>understand and use. As opposed to if we did something fancy (even if
>>it was an improvement) it would be another environment for language
>>users to have to familiarize themselves with -- they'd have both
>>normal session rules and babel session rules
>
> As a sometimes Python user it had me totally confused. I don't think of
> "session-based" as having any essential tie to "interactive shell" at all.
> Why
> would I worry about state being maintained between statements in an org
> block?
> State is already maintained between statements in non-session Org blocks. The
> only difference with session-based blocks is the starting state may not be
> "fresh".
>
> When I look at Org and think of "session-based" blocks, I see a potential big
> benefit in having multiple source-blocks throughout my document share the same
> session. That way I don't need to use Org's (clever and useful but) somewhat
> clunky and inflexible method of passing data explicitly. In statistics-based
> docs, for example, I can imagine that the sheer amount of data would make
> using
> Org's explicit variable-passing method unfeasible. Using
> sessi
Re: [O] [bug] Latex export of lists (was Re: Problem with BEGIN_SRC export-as-latex and FORTRAN code)
I puzzled with it... And finally got it working... Wasn't a pretty work around! Well it all works now! Thanks for this! I can see your point on the babel stuff.. :) Kind regards Nick 2011/6/21 Eric S Fraga > Nick Papior Andersen writes: > > > Hi Eric > > > > Thanks. > > > > I can see why the new thing would work as it utilizes the listing > > environment. If the bug is fully removed then great. > > > > It shows when the verbatim environment is used in my version. If a newer > > version of org-mode will ever be used with only the verbatim environment, > > then what happens? > > > > No actual reason for not writing fortran besides it is shorter... However > it > > will produce the same error nonetheless. > > > > Another error in your above shown result, is that the listing should have > > been exported inside the enumerate environment. > > Very true. I missed this. Given the indentation, the listing should > indeed belong to the enumeration item. > > Nicolas? > > > I have speculated whether > > the error is due to fortran is not in language list. > > http://orgmode.org/worg/org-contrib/babel/languages.html > > I doubt it. #+begin_src ... #+end_src is somewhat generic; it's only > when you want babel to interpret the code that the language has to be > recognised. I believe... > > > As to my installation of org-mode, i downloaded and make, make install.. > > Have installed correctly, i just couldn't figure out to setup the new > > installation of org (i.e. it still uses the old which is shipped by > > standard!). > > I think i can overcome this issue if i spend some more time on it. :) > > You need to add the location of where you have installed the new version > to the load-path variable very early in the emacs initialisation file > which is ~/.emacs in my case; what system are you using? Something > along the lines of > > (add-to-list 'load-path "~/path/to/new/org") > > should do the job. Typing > > M-x org-version RET > > once emacs has started should show you the version that has actually > been loaded. > > -- > : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 > : using Org-mode version 7.5 (release_7.5.415.g3f3fc.dirty) >
Re: [O] [bug] Latex export of lists (was Re: Problem with BEGIN_SRC export-as-latex and FORTRAN code)
Nick Papior Andersen writes: > Hi Eric > > Thanks. > > I can see why the new thing would work as it utilizes the listing > environment. If the bug is fully removed then great. > > It shows when the verbatim environment is used in my version. If a newer > version of org-mode will ever be used with only the verbatim environment, > then what happens? > > No actual reason for not writing fortran besides it is shorter... However it > will produce the same error nonetheless. > > Another error in your above shown result, is that the listing should have > been exported inside the enumerate environment. Very true. I missed this. Given the indentation, the listing should indeed belong to the enumeration item. Nicolas? > I have speculated whether > the error is due to fortran is not in language list. > http://orgmode.org/worg/org-contrib/babel/languages.html I doubt it. #+begin_src ... #+end_src is somewhat generic; it's only when you want babel to interpret the code that the language has to be recognised. I believe... > As to my installation of org-mode, i downloaded and make, make install.. > Have installed correctly, i just couldn't figure out to setup the new > installation of org (i.e. it still uses the old which is shipped by > standard!). > I think i can overcome this issue if i spend some more time on it. :) You need to add the location of where you have installed the new version to the load-path variable very early in the emacs initialisation file which is ~/.emacs in my case; what system are you using? Something along the lines of (add-to-list 'load-path "~/path/to/new/org") should do the job. Typing M-x org-version RET once emacs has started should show you the version that has actually been loaded. -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.415.g3f3fc.dirty)
[O] How to highlight the LaTeX fragments inside orgmode
Hello,
I'm looking for a way to highlight the syntax of the LaTeX fragments inside
orgmode.
I have tried to put the LaTeX parts into:
#+BEGIN_SRC LaTeX
#+END_SRC
But the output tex file will have the
\begin{verbatim}
\end{verbatim}
surrounding the parts. I'm wondering if it's possible to #+BEGIN_LaTeX: also
highlight the syntax inside the block?
Thanks!
Xin
Re: [O] org-babel -- Improper syntax error in session mode?
t...@tsdye.com (Thomas S. Dye) writes: > Aloha Herb, > > I think a note to that effect belongs here: > http://orgmode.org/manual/session.html#session > > Perhaps the behavior related to session persistence could be described > there, as well. > > Examples are probably best left to the language-specific documentation, > such as it is, at http://orgmode.org/worg/org-contrib/babel/languages/ > > Note that there is no language-specific documentation for Python yet. > Yes, these pages would benefit greatly from more documentation. > > Is it the case that the Ruby and Perl interpreters won't run code that > does run in non-session mode? > No, Python and Haskell are the only two languages of which I am aware of any difference between interactive and normal evaluation. Best -- Eric > > All the best, > Tom > > Herbert Sitz writes: > >> Thomas S. Dye tsdye.com> writes: >>> >>> Aloha Herbert, >>> >>> I think you're right about the potential to improve the documentation. >>> That's an on-going process. Could you suggest some specific changes? >>> >>> All the best, >>> Tom >> >> Tom -- >> >> I would suggest just adding specific warnings that session-based evaluation >> may >> throw syntax errors with valid code. >> >> Here's what Org manual says regarding :session evaluation with :results >> output': >> >> "The code is passed to the interpreter running as an interactive Emacs >> inferior >> process. The result returned is the concaOrg tenation of the sequence of >> (text) >> output from the interactive interpreter. Notice that this is not necessarily >> the >> same as what would be sent to STDOUT if the same code were passed to a >> non-interactive interpreter running as an external process. . . ." >> [http://orgmode.org/manual/Results-of-evaluation.html#Results-of-evaluation] >> >> All that needs to be added is a warning: >> >> "IMPORTANT: Note that Org provides only a thin wrapper around a language's >> interactive shell, so valid code that executes properly in non-session mode >> may >> fail in :session mode. This is because Org feeds the lines in a :session >> block >> to the interactive interpreter exactly as written. In come cases the lines >> may >> require special formatting in the source block to be executed properly in the >> interactive shell. For example: . . . " >> >> I think the above issue should be moot for some of the main interpreted >> languages (viz., Python, Perl, Ruby) where there are various ways to execute >> a >> block of code non-interactively despite being in the interactive shell. >> (One of >> those methods is the example I gave in previous message.) In that case >> identical code will run the same whether it's in an interactive-interpreter >> session or not. It seems to me that switching to that approach for languages >> that support it should both (1) simplify the Org Babel code, and (2) provide >> Org >> users with more flexibility and power. >> >> Also, it seems the real power of :session evaluation is to share state >> between >> Org/Babel source code blocks, not merely to act as a kind of Org-internal >> scratchpad. As a user trying to take advantage of that state-sharing power I >> would generally want my Org document exports to start from fresh sessions. >> That >> is, I would write my :session blocks so that they depended on results of code >> run in previous :session blocks, BUT I would want the first :session block to >> start with a fresh session,with a known state. So on export I would >> generally >> want any existing named session to be closed and restarted anew for an >> Org export. >> >> I hope that all makes sense. I should say I'm not a big Babel user, and I >> could >> easily be misunderstanding something. But it seems this is the way the >> :session-based stuff should work, when possible. >> >> -- Herb >> >> >> -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [bug] Latex export of lists (was Re: Problem with BEGIN_SRC export-as-latex and FORTRAN code)
> >> I have speculated whether the error is due to fortran is not in >> language list. >> http://orgmode.org/worg/org-contrib/babel/languages.html > > I doubt it. #+begin_src ... #+end_src is somewhat generic; it's only > when you want babel to interpret the code that the language has to be > recognised. I believe... > This is true. Unless you want to execute the code, the language does not have to be known to Babel. Although if you try to export to html with syntax highlighting for language "foo", the syntax highlighting will only work if emacs has a "foo-mode" defined. -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] How to highlight the LaTeX fragments inside orgmode
Xin Shi writes:
> Hello,
>
> I'm looking for a way to highlight the syntax of the LaTeX fragments inside
> orgmode.
>
> I have tried to put the LaTeX parts into:
>
> #+BEGIN_SRC LaTeX
> #+END_SRC
>
> But the output tex file will have the
> \begin{verbatim}
> \end{verbatim}
>
> surrounding the parts. I'm wondering if it's possible to #+BEGIN_LaTeX: also
> highlight the syntax inside the block?
>
> Thanks!
>
> Xin
Hi Xin,
Try the following syntax
#+begin_src latex :exports results :results code
...
#+end_src
Making sure that you have the ob-latex.el loaded.
Note that you can set the two header arguments on the subtree or the
file level so that you don't have to continually re-type them. See the
header arguments portion of the manual for information on how to do
this.
Best -- Eric
--
Eric Schulte
http://cs.unm.edu/~eschulte/
[O] [babel] How to set multiple variables with properties
I'm using org-babel to automate a few tasks and I'd like to define a few variables that are common to several code blocks as sub-tree properties. It works when I have only one variable, where I can use --8<---cut here---start->8--- * Heading :PROPERTY: :var: variable1="value1" :END: #+begin_src python :results output print variable1 #+end_src #+results: : value1 --8<---cut here---end--->8--- Is it possible to set multiples variables in this way? I tried things like --8<---cut here---start->8--- :PROPERTY: :var: variable1="value1" variable2="value2" :END: :PROPERTY: :var: variable1="value1",variable2="value2" :END: :PROPERTY: :variable1: "value1" :variable2: "value2" :END: --8<---cut here---end--->8--- but none of them worked. -- Darlan Cavalcante
Re: [O] [babel] How to set multiple variables with properties
Unfortunately org-mode properties only allow a single entry for any given key, so you can only specify one variable using properties. However the following workaround does exist. *** alternative :PROPERTIES: :var: vars=variables :END: #+tblname: variables | var1 | 1 | | var2 | 2 | #+begin_src python print vars[0][1] print vars[1][1] #+end_src Best -- Eric Darlan Cavalcante Moreira writes: > I'm using org-babel to automate a few tasks and I'd like to define a few > variables that are common to several code blocks as sub-tree properties. > > It works when I have only one variable, where I can use > * Heading > :PROPERTY: > :var: variable1="value1" > :END: > #+begin_src python :results output > print variable1 > #+end_src > > #+results: > : value1 > > Is it possible to set multiples variables in this way? > I tried things like > :PROPERTY: > :var: variable1="value1" variable2="value2" > :END: > > :PROPERTY: > :var: variable1="value1",variable2="value2" > :END: > > :PROPERTY: > :variable1: "value1" > :variable2: "value2" > :END: > but none of them worked. > > > -- > Darlan Cavalcante > -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] How to highlight the LaTeX fragments inside orgmode
Hi Eric,
Thanks for your reply!
I added these two lines into .emacs and it worked!
(require 'ob-latex)
(setq org-src-fontify-natively t)
However, I noticed something else is broken with the ob-latex:
The C-c C-e d (export to PDF and open the PDF file) is no longer working.
Maybe a bug in 7.5?
Best,
Xin
On Tue, Jun 21, 2011 at 3:35 PM, Eric Schulte wrote:
> Xin Shi writes:
>
> > Hello,
> >
> > I'm looking for a way to highlight the syntax of the LaTeX fragments
> inside
> > orgmode.
> >
> > I have tried to put the LaTeX parts into:
> >
> > #+BEGIN_SRC LaTeX
> > #+END_SRC
> >
> > But the output tex file will have the
> > \begin{verbatim}
> > \end{verbatim}
> >
> > surrounding the parts. I'm wondering if it's possible to #+BEGIN_LaTeX:
> also
> > highlight the syntax inside the block?
> >
> > Thanks!
> >
> > Xin
>
> Hi Xin,
>
> Try the following syntax
>
> #+begin_src latex :exports results :results code
> ...
> #+end_src
>
> Making sure that you have the ob-latex.el loaded.
>
> Note that you can set the two header arguments on the subtree or the
> file level so that you don't have to continually re-type them. See the
> header arguments portion of the manual for information on how to do
> this.
>
> Best -- Eric
>
> --
> Eric Schulte
> http://cs.unm.edu/~eschulte/
>
Re: [O] How to highlight the LaTeX fragments inside orgmode
Xin Shi wrote: > > However, I noticed something else is broken with the ob-latex: > > The C-c C-e d (export to PDF and open the PDF file) is no longer working. > Maybe a bug in 7.5? > Works fine here: Org-mode version 7.5 (baseline.324.ga0bc.dirty) Nick
Re: [O] How to highlight the LaTeX fragments inside orgmode
Thanks. Maybe it's just not working here. Also, I got this question every time: Evaluate this latex code block on your system? (y or n) Are there anyway to turn accept all? Xin On Tue, Jun 21, 2011 at 4:49 PM, Nick Dokos wrote: > Xin Shi wrote: > > > > > However, I noticed something else is broken with the ob-latex: > > > > The C-c C-e d (export to PDF and open the PDF file) is no longer working. > Maybe a bug in 7.5? > > > > Works fine here: Org-mode version 7.5 (baseline.324.ga0bc.dirty) > > Nick >
Re: [O] [babel] How to set multiple variables with properties
Hi Christian, That's the first I've heard of that variable? If you do get something working with multivalued properties please do share. Cheers -- Eric Christian Moe writes: > Hi, Eric, > > Just curious: What about the org-entry--multivalued-property functions > mentioned in "Using the properties API"? > > Is anybody using multivalued properties for anything? > > Yours, > Christian > > > On 6/21/11 10:17 PM, Eric Schulte wrote: >> Unfortunately org-mode properties only allow a single entry for any >> given key, so you can only specify one variable using properties. >> >> However the following workaround does exist. >> >> *** alternative >> :PROPERTIES: >> :var: vars=variables >> :END: >> >> #+tblname: variables >> | var1 | 1 | >> | var2 | 2 | >> >> #+begin_src python >>print vars[0][1] >>print vars[1][1] >> #+end_src >> >> Best -- Eric >> >> Darlan Cavalcante Moreira writes: >> >>> I'm using org-babel to automate a few tasks and I'd like to define a few >>> variables that are common to several code blocks as sub-tree properties. >>> >>> It works when I have only one variable, where I can use >>> * Heading >>>:PROPERTY: >>>:var: variable1="value1" >>>:END: >>>#+begin_src python :results output >>> print variable1 >>>#+end_src >>> >>>#+results: >>>: value1 >>> >>> Is it possible to set multiples variables in this way? >>> I tried things like >>> :PROPERTY: >>> :var: variable1="value1" variable2="value2" >>> :END: >>> >>> :PROPERTY: >>> :var: variable1="value1",variable2="value2" >>> :END: >>> >>> :PROPERTY: >>> :variable1: "value1" >>> :variable2: "value2" >>> :END: >>> but none of them worked. >>> >>> >>> -- >>> Darlan Cavalcante >>> >> > -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] How to highlight the LaTeX fragments inside orgmode
Hi Xin, I have the following line in my .emacs file: (setq org-confirm-babel-evaluate nil) This, I think, turns off asking for evaluation for all languages. Not sure if it can be done on a language specific basis or not. Chris On Jun 21, 2011 4:56pm, Xin Shi wrote: Thanks. Maybe it's just not working here. Also, I got this question every time: Evaluate this latex code block on your system? (y or n) Are there anyway to turn accept all? Xin On Tue, Jun 21, 2011 at 4:49 PM, Nick Dokos nicholas.do...@hp.com> wrote: Xin Shi shixin...@gmail.com> wrote: > > However, I noticed something else is broken with the ob-latex: > > The Cc Ce d (export to PDF and open the PDF file) is no longer working. Maybe a bug in 7.5? > Works fine here: Org-mode version 7.5 (baseline.324.ga0bc.dirty) Nick
Re: [O] [bug] Latex export of lists (was Re: Problem with BEGIN_SRC export-as-latex and FORTRAN code)
Hello,
Eric S Fraga writes:
> Very true. I missed this. Given the indentation, the listing should
> indeed belong to the enumeration item.
>
> Nicolas?
If I export this:
-
* Test
1. Try and use =org-export-as-latex=, it will produce error segment.
#+BEGIN_SRC C
MODULE m_global_precision
IMPLICIT NONE
INTEGER, PARAMETER :: SP = SELECTED_REAL_KIND(6,30)
END MODULE m_global_precision
#+END_SRC
-
I get this:
#+begin_src latex
\section{Test}
\label{sec-1}
\begin{enumerate}
\item Try and use \texttt{org-export-as-latex}, it will produce error segment.
\lstset{language=C}
\begin{lstlisting}
MODULE m_global_precision
IMPLICIT NONE
INTEGER, PARAMETER :: SP = SELECTED_REAL_KIND(6,30)
END MODULE m_global_precision
\end{lstlisting}
\end{enumerate}
#+end_src
It looks ok, or am I missing something?
Regards,
--
Nicolas Goaziou
Re: [O] [babel] How to set multiple variables with properties
Hi, Eric, Just curious: What about the org-entry--multivalued-property functions mentioned in "Using the properties API"? Is anybody using multivalued properties for anything? Yours, Christian On 6/21/11 10:17 PM, Eric Schulte wrote: Unfortunately org-mode properties only allow a single entry for any given key, so you can only specify one variable using properties. However the following workaround does exist. *** alternative :PROPERTIES: :var: vars=variables :END: #+tblname: variables | var1 | 1 | | var2 | 2 | #+begin_src python print vars[0][1] print vars[1][1] #+end_src Best -- Eric Darlan Cavalcante Moreira writes: I'm using org-babel to automate a few tasks and I'd like to define a few variables that are common to several code blocks as sub-tree properties. It works when I have only one variable, where I can use * Heading :PROPERTY: :var: variable1="value1" :END: #+begin_src python :results output print variable1 #+end_src #+results: : value1 Is it possible to set multiples variables in this way? I tried things like :PROPERTY: :var: variable1="value1" variable2="value2" :END: :PROPERTY: :var: variable1="value1",variable2="value2" :END: :PROPERTY: :variable1: "value1" :variable2: "value2" :END: but none of them worked. -- Darlan Cavalcante
Re: [O] How to highlight the LaTeX fragments inside orgmode
Thank you! P.S. Although this works, I still think for my purpose of just want to see the syntax of the LaTeX highlight, this "begin_src latex" might be a bit overkill. It would be nice the begin_latex have the option to do this job. Xin On Tue, Jun 21, 2011 at 5:05 PM, Eric Schulte wrote: > Xin Shi writes: > > > Thanks. Maybe it's just not working here. > > > > Also, I got this question every time: > > > > Evaluate this latex code block on your system? (y or n) > > > > Are there anyway to turn accept all? > > > > the following will disable this prompt > > (setq org-confirm-babel-evaluate nil) > > Best -- Eric > > > > > Xin > > > > > > > > On Tue, Jun 21, 2011 at 4:49 PM, Nick Dokos > wrote: > > > >> Xin Shi wrote: > >> > >> > > >> > However, I noticed something else is broken with the ob-latex: > >> > > >> > The C-c C-e d (export to PDF and open the PDF file) is no longer > working. > >> Maybe a bug in 7.5? > >> > > >> > >> Works fine here: Org-mode version 7.5 (baseline.324.ga0bc.dirty) > >> > >> Nick > >> > > -- > Eric Schulte > http://cs.unm.edu/~eschulte/ >
Re: [O] How to highlight the LaTeX fragments inside orgmode
Xin Shi writes: > Thanks. Maybe it's just not working here. > > Also, I got this question every time: > > Evaluate this latex code block on your system? (y or n) > > Are there anyway to turn accept all? > the following will disable this prompt (setq org-confirm-babel-evaluate nil) Best -- Eric > > Xin > > > > On Tue, Jun 21, 2011 at 4:49 PM, Nick Dokos wrote: > >> Xin Shi wrote: >> >> > >> > However, I noticed something else is broken with the ob-latex: >> > >> > The C-c C-e d (export to PDF and open the PDF file) is no longer working. >> Maybe a bug in 7.5? >> > >> >> Works fine here: Org-mode version 7.5 (baseline.324.ga0bc.dirty) >> >> Nick >> -- Eric Schulte http://cs.unm.edu/~eschulte/
[O] Make M-up and M-down transpose paragraphs in org buffers
By default, if used within ordinary paragraphs in org mode, M-up and M-down transpose *lines* (not sentences). This was not useful to me. The following code makes these keys transpose paragraphs, keeping the point at the start of the moved paragraph. Behaviour in tables and headings is unaffected. It would be easy to modify this to transpose sentences. (defun org-transpose-paragraphs (arg) (interactive) (when (and (not (or (org-at-table-p) (org-on-heading-p) (org-at-item-p))) (thing-at-point 'sentence)) (transpose-paragraphs arg) (backward-paragraph) (re-search-forward "[[:graph:]]") (goto-char (match-beginning 0)) t)) (add-to-list 'org-metaup-hook (lambda () (interactive) (org-transpose-paragraphs -1))) (add-to-list 'org-metadown-hook (lambda () (interactive) (org-transpose-paragraphs 1)))
Re: [O] [babel] How to set multiple variables with properties
Thanks Eric, I'll minimize the need of this by using "#+babel: var=something" for variables that are common to many blocks. The tip with the table is a good one also. -- Darlan Cavalcante At Tue, 21 Jun 2011 13:17:17 -0700, Eric Schulte wrote: > > Unfortunately org-mode properties only allow a single entry for any > given key, so you can only specify one variable using properties. > > However the following workaround does exist. > > *** alternative > :PROPERTIES: > :var: vars=variables > :END: > > #+tblname: variables > | var1 | 1 | > | var2 | 2 | > > #+begin_src python > print vars[0][1] > print vars[1][1] > #+end_src > > Best -- Eric > > Darlan Cavalcante Moreira writes: > > > I'm using org-babel to automate a few tasks and I'd like to define a few > > variables that are common to several code blocks as sub-tree properties. > > > > It works when I have only one variable, where I can use > > * Heading > > :PROPERTY: > > :var: variable1="value1" > > :END: > > #+begin_src python :results output > > print variable1 > > #+end_src > > > > #+results: > > : value1 > > > > Is it possible to set multiples variables in this way? > > I tried things like > > :PROPERTY: > > :var: variable1="value1" variable2="value2" > > :END: > > > > :PROPERTY: > > :var: variable1="value1",variable2="value2" > > :END: > > > > :PROPERTY: > > :variable1: "value1" > > :variable2: "value2" > > :END: > > but none of them worked. > > > > > > -- > > Darlan Cavalcante > > > > -- > Eric Schulte > http://cs.unm.edu/~eschulte/
