[O] Exporting org-mode source
I want to export a block of org-mode source code in a tutorial I am writing. I have tried variations of the following. But nothing seems to give me org-mode code in the exported pdf. #+BEGIN_SRC org :results code replace org-mode code here #+END_SRC What is the right way to do it? Vikas
Re: [O] :mkdirp without path specifier
On Fri, May 2, 2014 at 11:43 PM, R. Michael Weylandt wrote: > Patch attached. Should apply cleanly against master and maint. Bah, botched the formatting. Attached should be fixed. 0001-Fix-tangle-with-mkdirp-yes-tangle-FILE.patch Description: Binary data
Re: [O] :mkdirp without path specifier
On Thu, May 1, 2014 at 3:47 PM, Michael Weylandt wrote: > If it intended that setting :mkdirp yes should break tangling with > 'directory-free' file names? > > I.e., should > # > #+TITLE: test > #+BEGIN_SRC python :mkdirp yes :tangle test.py > print 1+2 > #+END_SRC > ### > > tangle without error? > > It currently doesn't because (file-name-directory "test.py"), which is nil, > gets passed to make-directory, which throws an error. > > The manual is ambiguous, stating only that the arg to :tangle is interpreted > as a path. A strict reading says this shouldn't work, regardless of :mkdirp, > since we're not giving a path, but I think the "understood ./" of :mkdirp no > is reasonable. > Patch attached. Should apply cleanly against master and maint. Michael 0001-Fix-tangle-with-mkdirp-yes-tangle-FILE.patch Description: Binary data
[O] Color entries according to assigned priority
Hello, is it possible to color the different entries in an org file according to the priority assigned to them? I'd like to have #a items in black and #b, #c and non-prioritized items in gray tones. Uwe
Re: [O] (no subject)
Or, even better, just divide by the HMS form for 1 second (0@ 0' 1"): | - | - | - | 1@ 11' 37" | - | - | - | 4297 | #+TBLFM: $8=$4 \ 0@ 0' 1" Note that \ is integer division, so there is no need for a format conversion Will P.S. I highly recommend reading the [[info:calc#Basic Arithmetic]] section of the calc manual On Fri, May 2, 2014 at 10:01 PM, William Henney wrote: > Hi Ryan > > Convert to degrees, then multiply by 3600: > > | - | - | - | 1@ 11' 37" | - | - | - | 4297 | > #+TBLFM: $8=3600 deg($4); %d > > Cheers > > Will > > > > On Fri, May 2, 2014 at 8:52 PM, Ryan Moszynski > wrote: > >> If an org table cell contains the HMS 1@ 11' 37" >> >> is there an easy way to get the total (time)seconds? >> >> (1*3600 + 11*60 + 37 = 4297) >> >> >> if $4 = 1@ 11' 37" >> >> how do I get $8 = 4297? >> >> thanks >> >> ryan >> >> -- >> He felt that his whole life was some kind of dream and he sometimes >> wondered whose it was and whether they were enjoying it. - Douglas >> Adams >> >> > > > -- > > Dr William Henney, Centro de Radioastronomía y Astrofísica, > Universidad Nacional Autónoma de México, Campus Morelia > -- Dr William Henney, Centro de Radioastronomía y Astrofísica, Universidad Nacional Autónoma de México, Campus Morelia
Re: [O] (no subject)
Hi Ryan Convert to degrees, then multiply by 3600: | - | - | - | 1@ 11' 37" | - | - | - | 4297 | #+TBLFM: $8=3600 deg($4); %d Cheers Will On Fri, May 2, 2014 at 8:52 PM, Ryan Moszynski wrote: > If an org table cell contains the HMS 1@ 11' 37" > > is there an easy way to get the total (time)seconds? > > (1*3600 + 11*60 + 37 = 4297) > > > if $4 = 1@ 11' 37" > > how do I get $8 = 4297? > > thanks > > ryan > > -- > He felt that his whole life was some kind of dream and he sometimes > wondered whose it was and whether they were enjoying it. - Douglas > Adams > > -- Dr William Henney, Centro de Radioastronomía y Astrofísica, Universidad Nacional Autónoma de México, Campus Morelia
[O] (no subject)
If an org table cell contains the HMS 1@ 11' 37" is there an easy way to get the total (time)seconds? (1*3600 + 11*60 + 37 = 4297) if $4 = 1@ 11' 37" how do I get $8 = 4297? thanks ryan -- He felt that his whole life was some kind of dream and he sometimes wondered whose it was and whether they were enjoying it. - Douglas Adams
[O] using Org-player with Org-drill
I posted the following at gmane.emacs.help but afterwards realized this might be the more appropriate forum. Please excuse the double post: Hi all. I'm relatively new to emacs, and I don't have a computer programming background. For purposes of learning a language, I want to use Org-player within an Org-drill session. I believe I have both of those programs working fine independently. But, the problem arises that when in an Org-drill session the user is unable to control the cursor, preventing me in this case from accessing the audio file I'd like to play and checking my pronunciation of the given word. Clicking on the link with the mouse, which of course wouldn't be ideal anyway, has no effect. Please let me know if anyone has an idea of how to make a change, presumably with Org-drill, to enable this type of use. Thanks, todd
Re: [O] Redshank gets loaded when exporting ELisp code blocks to HTML!?
Hello Sacha and Nicolas, Answering after a (too) long time with very intermittent Internet access... Sacha Chua wrote: > Sebastien Vauban writes: > >> Why are Emacs Lisp minor modes loaded for exporting the Org document >> to HTML? If not necessary, this seems suboptimal (performance-wise). > > org-export-format-source-code-or-example loads the mode associated > with the language in org-src-lang-modes in order to fontify the > block. Only to fontify, not to indent, right? > You could check if org-export-current-backend is nil before > loading anything that you want to use only interactively. > > Maybe like so? > > (add-hook 'emacs-lisp-mode-hook (lambda () > (unless org-export-current-backend > (turn-on-redshank-mode This seems to be a solution (although I did not test it), but it seems as well impractical: I'd have to chase almost all minor modes of all languages... Can't we assume that the major modes have all the information to fontify the code blocks, and -- if yes -- have a manner to forbid loading all the minor modes at once (as, then, they'd be completely useless for the export process)? Best regards, Seb -- Sebastien Vauban
Re: [O] [bug] Org-verbatim and org-code not converted into HTML tags
Hi Bastien,
Bastien wrote:
> Sebastien Vauban writes:
>
>> Though, there are extra diffs in my HTML output, about the style of the
>> org-block delimiter lines: they've lost their "under/over-line" feature,
>> and colors are not the same anymore.
>
> Can you bisect to spot the first bad commit, and tell exactly
> what's bad here from an emacs -Q point of view?
It took me a while to understand what was going on. But I did.
See http://screencast.com/t/1peLgaZ7.
The "styling" bug is present in all latest Emacs versions, and relates
to the Emacs bug #16440 ("Some colors of the theme aren't respected in
latest Emacs"):
╭ From: Eli Zaretskii
│
│ This seems to be the consequence of the change described in NEWS like
│ this:
│
│ *** Face specs set via Custom themes now replace the `defface' spec
│ rather than inheriting from it (as do face specs set via Customize).
│
│ Org uses org-copy-face to define the faces that you show in your
│ screencast, and org-copy-face assumes the face it inherits from
│ already exists. But loading a theme now doesn't create the faces, it
│ only prepares the data for when the face will be created. So :inherit
│ in org-copy-face doesn't do what you expect.
│
│ I guess either some change is needed in how themes are handled, or
│ org-copy-face needs to change to follow suit. (CC to Bastien for
│ that.)
╰
See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16440 for the whole
thread.
Best regards,
Seb
--
Sebastien Vauban
Re: [O] [RFC] Rewrite indentation functions
Nicolas Goaziou writes: > Hello, > > Eric Abrahamsen writes: > >> Wish I was competent to actually review this, but... In lieu of that, >> I'd be happy to run it and report errors. If you think a separate >> testing branch is warranted, that might be an idea. Otherwise I'd say >> let it drop and we'll pick up the pieces :) > > You can create a local branch in your git repo and apply the patches > I sent (be sure to use the second version of the first patch) there. > > I can certainly wait for your feedback. If it turns out to be mostly > good and no one objects, I will then apply the patches and fix the > remnant issues on master branch. Done! I'll try to give it a little exercise over the next couple of days, though I guess I'm not expecting much breakage.
Re: [O] Title of org files in github not recognized
Hi Waldemar, Thanks, I'm looking forward to see all these improvements also in github. Best wishes Julian On 02.05.2014 07:44, Waldemar Quevedo wrote: Hi, yes this issue would be fixed once Github upgrades the Ruby implementation of the parser. To upgrade the version it takes making a pull request to the github/markup repository so that they bump the version and do the release, but it takes some time before the upgrade is validated (security checks, etc...) There another couple of issues that I would like it that they make it to Github, so once having those tackled I'll see if I can ask one of the maintainers to help out planning for an update soon. Cheers On Fri, May 2, 2014 at 12:21 AM, Sebastien Vauban mailto:sva-n...@mygooglest.com>> wrote: Julian Gehring wrote: > On 01.05.2014 14:17, Sebastien Vauban wrote: >> Julian Gehring wrote: >>> How I can convince github to recognize the '#+TITLE:' field of an >>> org-file? This should be a 'h1' heading, while it is currently >>> treated as normal text (for example, see >>> https://github.com/julian-gehring/vignettes/blob/master/README.org). >>> I know that this is a problem of the parsing on github's site, but >>> is anyone aware of a good solution? >> >> That was supposed to be solved. >> >> See https://github.com/wallyqs/org-ruby/issues/3 > > Nice. So it seems that github is using an older version of org-ruby. Is it > clear what the update policy/cycle of github for softwares like org-ruby is? Unfortunately, not to me... ;-) Best regards, Seb -- Sebastien Vauban
Re: [O] [RFC] Rewrite indentation functions
Hello, Eric Abrahamsen writes: > Wish I was competent to actually review this, but... In lieu of that, > I'd be happy to run it and report errors. If you think a separate > testing branch is warranted, that might be an idea. Otherwise I'd say > let it drop and we'll pick up the pieces :) You can create a local branch in your git repo and apply the patches I sent (be sure to use the second version of the first patch) there. I can certainly wait for your feedback. If it turns out to be mostly good and no one objects, I will then apply the patches and fix the remnant issues on master branch. Thank you. Regards, -- Nicolas Goaziou
