[O] problem with command-line call to emacsclient
I'm making a call to an emacsclient and trying to figure out how to get the buffer to unload at the end of the function I'm calling. I know kill-buffer isn't supposed to unload the buffer but I can't figure out what will. I've tried server-edit and server-kill-buffer in place of kill-buffer below and they also haven't worked. The buffer gets "pushed to the kill buffer", but remains loaded. The problem with having buffer remain loaded is when I redo the command-line call after editing the org file outside of emacs it prompts user for whether to reload changed file. One option would be to simply disable that prompt, I guess, but I'd rather be able to clear the buffer. Here's the function I'm calling: -- (defun vimorg-export-publish (fname exp-function) (find-file fname) (funcall exp-function nil) (kill-buffer) ) - And here's sample command line that calls it. Strange characters are because it's on Windows system, but it works fine other than that the buffer is not unloaded at end of vimorg-export-publish function: - c:\users\herbert\emacsclientw.exe --eval ^"(vimorg-export-publish \^"~/myorgfile.org\^" 'org-export-as-html-and-open )^" -- Thanks for any tips. -- Herb
Re: [O] [PATCH] Fix some #+ blocks fontification when there is no lang attribute
Julien Barnier writes: > Hi Bastien, > > Bastien altern.org> writes: > >> > * lisp/org.el (org-fontify-meta-lines-and-blocks-1): Fix test for src >> > blocks >> > lang attribute >> > >> > When there is no lang attribute to a block (for quote, verse or others), >> > the >> > lang variable is not nil, but an empty string. >> >> Applied, thanks! > > Maybe I'm mistaken, but I think there is a problem with the patch : in the > patch > file I sent the new line was the following : > > ((and lang (not (string= lang "")) org-src-fontify-natively) > > But it seems that the applied patch in the git repository is the following : > > ((and lang (not (string= lang "") org-src-fontify-natively)) > > http://repo.or.cz/w/org-mode.git/commitdiff/549a5212566e300023e038ec945cb9e8efe37e19 > > As you can see, the parenthesis is not at the right place, and this seems to > break completely src code blocks fontification... > > Thanks in advance, > Fixed. Thanks for reporting -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [PATCH] Fix some #+ blocks fontification when there is no lang attribute
Hi Bastien, Bastien altern.org> writes: > > * lisp/org.el (org-fontify-meta-lines-and-blocks-1): Fix test for src blocks > > lang attribute > > > > When there is no lang attribute to a block (for quote, verse or others), the > > lang variable is not nil, but an empty string. > > Applied, thanks! Maybe I'm mistaken, but I think there is a problem with the patch : in the patch file I sent the new line was the following : ((and lang (not (string= lang "")) org-src-fontify-natively) But it seems that the applied patch in the git repository is the following : ((and lang (not (string= lang "") org-src-fontify-natively)) http://repo.or.cz/w/org-mode.git/commitdiff/549a5212566e300023e038ec945cb9e8efe37e19 As you can see, the parenthesis is not at the right place, and this seems to break completely src code blocks fontification... Thanks in advance, Julien
Re: [O] Move to item to the bottom
Nicolas, Or are we talking about two different things? Not sure, maybe. What I mean is: gtd.org file: * TODO Blah * TODO Foo * TODO bar Instead of: gtd.org file: * Tasks ** TODO Blah ** TODO Foo ** TODO Bar So, the items in gtd.org files are all top-level, they don't belong to a list (unless org considers a virtual top level main list) Cheers, Marcelo. On Fri, Jul 1, 2011 at 2:25 PM, Nicolas Goaziou wrote: > Hello, > > Marcelo de Moraes Serpa writes: > > > Nicolas, what if all the items are top-level items? My gtd.org file is > > basically a flat list of projects and I don't have a main top list for > that > > wraps them. Any ideas? > > I'm not sure to understand. If all the items are at top level, the > function will move the current item at the bottom of the list. Every > item belongs to a list. > > Or are we talking about two different things? > > Regards, > > -- > Nicolas Goaziou >
Re: [O] Regression bug in tangle/weave
I normally keep `org-confirm-babel-evaluate' set to nil but to test the below I set it to t and was not prompted for evaluation. Do you have a code block named "file-version" in this file? If so then either that code block, or the results line will need to be renamed. When Org-mode finds both a code block _and_ a results line of the same name it defaults to evaluating the code block in case the results are stale. Cheers -- Eric MidLifeXis at PerlMonks writes: > I am still getting prompted with the 'Evaluate this text code block > (file-version) on your system?' message. > > What is your value of org-confirm-babel-evaluate set to? Mine is set > as the default, 't. According to the docs, this is the more secure > setting. > > > I updated no more than two weeks ago. I will refresh my org-mode setup over > the weekend and see if that takes care of it. > > Brian > > > > - Original Message - > From: Eric Schulte > To: MidLifeXis at PerlMonks > Cc: emacs-orgmode > Sent: Friday, July 1, 2011 2:14 PM > Subject: Re: [O] Regression bug in tangle/weave > > Yes, the second example I gave (shown immediately below) requires no > execution of code. > > #+begin_src text :tangle yes > <>. > #+end_src > > #+results: file-version > : 1.2.3.4 > > Best -- Eric > > MidLifeXis at PerlMonks writes: > >> Is there an example of this that does not use something like elisp, >> R, perl, python, shell, or some other process that requires either >> allowing all blocks to execute without prompting, or prompting for >> authority to run the block every time the file is tangled? >> >> Brian >> >> >> >> - Original Message - >> From: Eric Schulte >> To: MidLifeXis at PerlMonks >> Cc: emacs-orgmode >> Sent: Thursday, June 30, 2011 1:30 PM >> Subject: Re: [O] Regression bug in tangle/weave >> >> Hi, >> >> Indeed this example below no longer works, however I believe the new >> behavior is both desired and permanent. I'll explain and include an >> option for how your example could be restructured to work with the new >> code. >> >> We ran into problems automatically removing trailing newlines from code >> block bodies as in some languages (looking at you Python and Haskell) >> things like trailing newlines are of syntactic importance. In your >> example this behavior results in the insertion of newlines after >> file-name and file-version. Babel is careful to preserve line prefixes >> when expanding references in comments, so it then reproduces the >> >> # Generated from >> >> portion of that line for every line of the expanded noweb references. >> >> I would suggest the following alternatives, either using a data >> references in stead of a code block reference as in the file-version >> example below, or using an evaluated code block as in the file-name >> example below. Hope this helps. >> >> Best -- Eric >> >> >> >> MidLifeXis at PerlMonks writes: >> >>> It appears that there may be a regression problem with the current >>> tangle/weave process. I used to be able to have a noweb section for >>> the name of the file, another for the version of the file, and then >>> have an autogenerated header section that included those two pieces of >>> information on a single line. Following is an org file snippet of my >>> bug description. >>> >>> >>> * Bugs >>> ** SOMEDAY org-mode bug with tangle and newlines :BUG: >>> :PROPERTIES: >>> :created: [2011-06-30 Thu 10:00] >>> :ID: e4c992b5-4d35-443b-b34a-0fbda7c66aea >>> :END: >>> :LOGBOOK: >>> - Added on [2011-06-30 Thu 10:00] >>> :END: >>> [2011-06-30 Thu] >>> >>> A regression bug has surfaced in org-mode with the tangle/weave >>> process mangling the following setup: >>> >>> #+begin_src perl :noweb yes :tangle testoutput.pl :shebang #!perl >>> # <> >>> print "Hello world\n"; >>> #+end_src >>> >>> #+srcname: generated-from >>> #+begin_src text :noweb yes >>> Generated from <> version <>. >>> #+end_src >>> >>> #+srcname: file-name >>> #+begin_src text :noweb yes >>> ATestFile.org >>> #+end_src >>> >>> #+srcname: file-version >>> #+begin_src text :noweb yes >>> 1.2.3.4 >>> #+end_src >>> >>> The last it worked* was sometime in the early 7.4 timeframe. If I >>> get some time, I may do a bisect on it, although others are welcome >>> to do the work required. Timeframe is based on memory, not >>> actual checking, so first a bisect needs to be done to find where >>> it last worked. >>> >>> >>> *** Actual output >>> >>> #+begin_src perl >>> #!perl >>> >>> # Generated from ATestFile.org >>> # Generated from version 1.2.3.4 >>> # Generated from <> version . >>> # >>> print "Hello world\n"; >>> #+end_src >>> >>> *** Expected output (or at least similar) >>> >>> #+begin_src perl >>> #!perl >>> >>> # Generated from ATestFile.org version 1.2.3.4. >>> >>> print "Hello world\n"; >>> #+end_src >>> >>> * End of org file >>> >>> -- Eric Schulte http://cs.unm.edu
[O] foot note / enumeration question
Hi group, A file of #+begin_example * Title This is a text [fn:: the 1. footnote] with a footnote. #+end_example begins an enumeration inside the footenote and then forgets to close the footnote (which in LaTeX export gets closed at the next \section or so). I'm not sure what the expected behavior should be -- I'd obviously prefer no enumerations in footnotes :) Is there a way to specify this in the header, e.g. enum-in-footnotes: nil or similar? Just thinking when someone pute literary references in footnotes this could be useful (e.g.: [fn:: My fun. pp. 3-5, 12. edition, O'Really, 1996. London, New York...] ) Best regards and thanks for any comments Robert
Re: [O] Regression bug in tangle/weave
I am still getting prompted with the 'Evaluate this text code block (file-version) on your system?' message. What is your value of org-confirm-babel-evaluate set to? Mine is set as the default, 't. According to the docs, this is the more secure setting. I updated no more than two weeks ago. I will refresh my org-mode setup over the weekend and see if that takes care of it. Brian - Original Message - From: Eric Schulte To: MidLifeXis at PerlMonks Cc: emacs-orgmode Sent: Friday, July 1, 2011 2:14 PM Subject: Re: [O] Regression bug in tangle/weave Yes, the second example I gave (shown immediately below) requires no execution of code. #+begin_src text :tangle yes <>. #+end_src #+results: file-version : 1.2.3.4 Best -- Eric MidLifeXis at PerlMonks writes: > Is there an example of this that does not use something like elisp, R, perl, > python, shell, or some other process that requires either allowing all blocks > to execute without prompting, or prompting for authority to run the block > every time the file is tangled? > > Brian > > > > - Original Message - > From: Eric Schulte > To: MidLifeXis at PerlMonks > Cc: emacs-orgmode > Sent: Thursday, June 30, 2011 1:30 PM > Subject: Re: [O] Regression bug in tangle/weave > > Hi, > > Indeed this example below no longer works, however I believe the new > behavior is both desired and permanent. I'll explain and include an > option for how your example could be restructured to work with the new > code. > > We ran into problems automatically removing trailing newlines from code > block bodies as in some languages (looking at you Python and Haskell) > things like trailing newlines are of syntactic importance. In your > example this behavior results in the insertion of newlines after > file-name and file-version. Babel is careful to preserve line prefixes > when expanding references in comments, so it then reproduces the > > # Generated from > > portion of that line for every line of the expanded noweb references. > > I would suggest the following alternatives, either using a data > references in stead of a code block reference as in the file-version > example below, or using an evaluated code block as in the file-name > example below. Hope this helps. > > Best -- Eric > > > > MidLifeXis at PerlMonks writes: > >> It appears that there may be a regression problem with the current >> tangle/weave process. I used to be able to have a noweb section for >> the name of the file, another for the version of the file, and then >> have an autogenerated header section that included those two pieces of >> information on a single line. Following is an org file snippet of my >> bug description. >> >> >> * Bugs >> ** SOMEDAY org-mode bug with tangle and newlines :BUG: >> :PROPERTIES: >> :created: [2011-06-30 Thu 10:00] >> :ID: e4c992b5-4d35-443b-b34a-0fbda7c66aea >> :END: >> :LOGBOOK: >> - Added on [2011-06-30 Thu 10:00] >> :END: >> [2011-06-30 Thu] >> >> A regression bug has surfaced in org-mode with the tangle/weave >> process mangling the following setup: >> >> #+begin_src perl :noweb yes :tangle testoutput.pl :shebang #!perl >> # <> >> print "Hello world\n"; >> #+end_src >> >> #+srcname: generated-from >> #+begin_src text :noweb yes >> Generated from <> version <>. >> #+end_src >> >> #+srcname: file-name >> #+begin_src text :noweb yes >> ATestFile.org >> #+end_src >> >> #+srcname: file-version >> #+begin_src text :noweb yes >> 1.2.3.4 >> #+end_src >> >> The last it worked* was sometime in the early 7.4 timeframe. If I >> get some time, I may do a bisect on it, although others are welcome >> to do the work required. Timeframe is based on memory, not >> actual checking, so first a bisect needs to be done to find where >> it last worked. >> >> >> *** Actual output >> >> #+begin_src perl >> #!perl >> >> # Generated from ATestFile.org >> # Generated from version 1.2.3.4 >> # Generated from <> version . >> # >> print "Hello world\n"; >> #+end_src >> >> *** Expected output (or at least similar) >> >> #+begin_src perl >> #!perl >> >> # Generated from ATestFile.org version 1.2.3.4. >> >> print "Hello world\n"; >> #+end_src >> >> * End of org file >> >> -- Eric Schulte http://cs.unm.edu/~eschulte/
[O] [PATCH] Add org-lparse and org-odt as contrib modules
>From 9b97d19c1184d3cf2cc82831e3d29067cf91f014 Mon Sep 17 00:00:00 2001 From: Jambunathan K Date: Sat, 2 Jul 2011 01:56:01 +0530 Subject: [PATCH] Add org-lparse and org-odt as contrib modules * lisp/org.el (org-modules): Add org-lparse and org-odt as contrib modules. * contrib/README: Ditto --- contrib/README |2 ++ lisp/org.el|2 ++ 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/contrib/README b/contrib/README index c076c89..05a2635 100644 --- a/contrib/README +++ b/contrib/README @@ -33,12 +33,14 @@ org-interactive-query.el --- Interactive modification of tags query org-invoice.el --- Help manage client invoices in OrgMode org-jira.el --- Add a jira:ticket protocol to Org org-learn.el --- SuperMemo's incremental learning algorithm +org-lparse.el--- Library for building custom exporters org-mac-iCal.el --- Imports events from iCal.app to the Emacs diary org-mac-link-grabber.el --- Grab links and URLs from various Mac applications org-mairix.el --- Hook mairix search into Org for different MUAs org-man.el --- Support for links to manpages in Org-mode org-mime.el --- org html export for text/html MIME emails org-mtags.el --- Support for some Muse-like tags in Org-mode +org-odt.el --- OpenDocumentText exporter for Org-mode org-panel.el --- Simple routines for us with bad memory org-registry.el --- A registry for Org links org-screen.el--- Visit screen sessions through Org-mode links diff --git a/lisp/org.el b/lisp/org.el index 6824f38..0edeb9d 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -329,12 +329,14 @@ to add the symbol `xyz', and the package must have a call to (const :tag "C jira: Add a jira:ticket protocol to Org-mode" org-jira) (const :tag "C learn: SuperMemo's incremental learning algorithm" org-learn) + (const :tag "C lparse:Library for building custom exporters" org-lparse) (const :tag "C mairix:Hook mairix search into Org-mode for different MUAs" org-mairix) (const :tag "C notmuch: Provide org links to notmuch searches or messages" org-notmuch) (const :tag "C mac-iCal Imports events from iCal.app to the Emacs diary" org-mac-iCal) (const :tag "C mac-link-grabber Grab links and URLs from various Mac applications" org-mac-link-grabber) (const :tag "C man: Support for links to manpages in Org-mode" org-man) (const :tag "C mtags: Support for muse-like tags" org-mtags) + (const :tag "C odt: OpenDocumentText exporter for Org-mode" org-odt) (const :tag "C panel: Simple routines for us with bad memory" org-panel) (const :tag "C registry: A registry for Org-mode links" org-registry) (const :tag "C org2rem: Convert org appointments into reminders" org2rem) -- 1.7.2.3 --
Re: [O] caching and code execution on export
Ista Zahn writes: > Hi all, > I'm giving org-babel another go after a recent retreat back to Sweave. > I'm having problems with code being executed on export, even when > :cache yes is in force. Please see the following example. Thanks for pointing this out. There were some export-specific header arguments included in the cache calculation. I've just pushed up a fix which fixes this issue. Please let me know if you notice any further problems. > Also, a quick question that I can't seem to find the answer to: what > is the difference between "#+source " and "#+srcname "? > No difference, I believe that #+function is another valid alias. Thanks -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [babel] evaluating ledger source block now scans large number of org files
Hi Eric, Thanks for pointing this out. IDs can be used to resolve code block references, however it appears that the `org-id-goto' function is attempting to re-scan all ID locations when a reference is not found. I've just pushed up a patch which side-steps this rescanning behavior. Best -- Eric Eric S Fraga writes: > Hello, > > I don't know what has changed or when but, being the start of a new > month, I am doing my finances. I use ledger for this and, of course, > within org! > > Evaluating a ledger source code block now takes a significant amount of > time. Babel seems to search org files throughout my disk for IDs. I > get messages like this: > > , > | ... > | Finding ID locations (13/65 files): ~/git/notes/personal.org > | Finding ID locations (14/65 files): ~/git/notes/research.org > | Finding ID locations (15/65 files): ~/git/notes/tasks.org > | ... > ` > > I am using ":noweb yes" but otherwise I cannot see why org + babel need > to scan files throughout the disk? > > A minimal example that exhibits this behaviour is attached. Evaluating > the second code block generates the lines shown above. Evaluating the > first block does not which is why I think this may have something to do > with :noweb. > > Up to date org (see signature below). > > thanks, > eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [bug] [babel] fontification of source code blocks lost if using #+header(s)
Hi Eric, Thanks for pointing this out, I've just pushed up a patch which should fix this fontificaiton. Please let me know if something is not working. Best -- Eric Eric S Fraga writes: > Hello again, > > For source code blocks with long header lines, org allows the use of > the #+header: or #+headers: alternative for specifying these. Attached > is an example. > > The problem is that using these seems to cause fontification to stop > working and, unfortunately in a non-reproducible manner, also causes > some problems with C-c' working for allowing me to edit the code in a > code specific mode. Fontification works just fine if the header > arguments are on the #+begin_src line, however. > > > > thanks, > eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [RFC] testing the org exporters
Jambunathan K writes: > I have been using the attached test.org file as part of my org-odt > related work. > > The usual steps I follow for testing are quite simple: > 1. Visit the file > 2. Export it to xhtml or odt > 3. Visually make sure that everything is OK. > > I would like to add this file to the testing dir of the trunk. This file > would be a good starting point for not only validating but also > documenting (the quirks?) of various exporters. > > At the moment, I am not very inclined to have it integrated with > ert[1]. Based on my experience, the standalone test.org file has proven > it's worth multiple times over during the development phase. > > What do you think? I am happy to hear feedback on > > 1. what to put in that test.org > 2. where to put the test.org > 3. how to have it integrated with test framework. > > Footnotes: > [1] This is mostly because I don't know nothing about ert. Hi Jambunathan, I would very much like to see this test file [1] integrated into the testing repository of org-mode in (testing/examples) _and_ integrated into Org-mode's ert test framework. ERT is easy to use, and will more than repay any time spent applying it to your test file through the ability to quickly programmatically and reproducibly evaluate export results. There are many tests [2] which already implement a 1. visit example file 2. export to backend 3. confirm properties of backend (e.g., does or does not contain some string) Please try running the Org-mode test suite and look at the examples in testing/lisp. I see no reason not to take this final step and begin writing ERT tests which can serve as both documentation of issues and insurance against regression. Best -- Eric Footnotes: [1] I am not sure about including the org-mode unicorn png image in the repository as that could add alot of weight... perhaps .gitignore that file, point to a version of the file online, or generate an image on the fly with ditaa as part of the test suite [2] for example those in testing/lisp/test-ob-exp.el -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Regression bug in tangle/weave
Yes, the second example I gave (shown immediately below) requires no execution of code. #+begin_src text :tangle yes <>. #+end_src #+results: file-version : 1.2.3.4 Best -- Eric MidLifeXis at PerlMonks writes: > Is there an example of this that does not use something like elisp, R, perl, > python, shell, or some other process that requires either allowing all blocks > to execute without prompting, or prompting for authority to run the block > every time the file is tangled? > > Brian > > > > - Original Message - > From: Eric Schulte > To: MidLifeXis at PerlMonks > Cc: emacs-orgmode > Sent: Thursday, June 30, 2011 1:30 PM > Subject: Re: [O] Regression bug in tangle/weave > > Hi, > > Indeed this example below no longer works, however I believe the new > behavior is both desired and permanent. I'll explain and include an > option for how your example could be restructured to work with the new > code. > > We ran into problems automatically removing trailing newlines from code > block bodies as in some languages (looking at you Python and Haskell) > things like trailing newlines are of syntactic importance. In your > example this behavior results in the insertion of newlines after > file-name and file-version. Babel is careful to preserve line prefixes > when expanding references in comments, so it then reproduces the > > # Generated from > > portion of that line for every line of the expanded noweb references. > > I would suggest the following alternatives, either using a data > references in stead of a code block reference as in the file-version > example below, or using an evaluated code block as in the file-name > example below. Hope this helps. > > Best -- Eric > > > > MidLifeXis at PerlMonks writes: > >> It appears that there may be a regression problem with the current >> tangle/weave process. I used to be able to have a noweb section for >> the name of the file, another for the version of the file, and then >> have an autogenerated header section that included those two pieces of >> information on a single line. Following is an org file snippet of my >> bug description. >> >> >> * Bugs >> ** SOMEDAY org-mode bug with tangle and newlines :BUG: >> :PROPERTIES: >> :created: [2011-06-30 Thu 10:00] >> :ID: e4c992b5-4d35-443b-b34a-0fbda7c66aea >> :END: >> :LOGBOOK: >> - Added on [2011-06-30 Thu 10:00] >> :END: >> [2011-06-30 Thu] >> >> A regression bug has surfaced in org-mode with the tangle/weave >> process mangling the following setup: >> >> #+begin_src perl :noweb yes :tangle testoutput.pl :shebang #!perl >> # <> >> print "Hello world\n"; >> #+end_src >> >> #+srcname: generated-from >> #+begin_src text :noweb yes >> Generated from <> version <>. >> #+end_src >> >> #+srcname: file-name >> #+begin_src text :noweb yes >> ATestFile.org >> #+end_src >> >> #+srcname: file-version >> #+begin_src text :noweb yes >> 1.2.3.4 >> #+end_src >> >> The last it worked* was sometime in the early 7.4 timeframe. If I >> get some time, I may do a bisect on it, although others are welcome >> to do the work required. Timeframe is based on memory, not >> actual checking, so first a bisect needs to be done to find where >> it last worked. >> >> >> *** Actual output >> >> #+begin_src perl >> #!perl >> >> # Generated from ATestFile.org >> # Generated from version 1.2.3.4 >> # Generated from <> version . >> # >> print "Hello world\n"; >> #+end_src >> >> *** Expected output (or at least similar) >> >> #+begin_src perl >> #!perl >> >> # Generated from ATestFile.org version 1.2.3.4. >> >> print "Hello world\n"; >> #+end_src >> >> * End of org file >> >> -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] ob-lilypond
Martyn Jago writes: > Hi > >> >> That's good to hear. Are you up for trying to merge them into the rest >> of the Org-mode test suite? This should be as simple as placing any >> org-mode example files you have in >> >> org-mode/testing/examples/ >> >> placing the .el file defining your tests into >> >> org-mode/testing/lisp/ >> >> and renaming all of your tests so that they start with the prefix >> "ob-lilypond/" >> >> I fully understand if you don't have the time to do this, and I should >> be able to take a shot at it some time in the not-too-distant future. > > Hopefully this patch will work for you... > Yes, this patch applied without error, and the test suite passes all tests. Thanks for contributing and for greatly increasing the size of the Org-mode test suite. > > It looks like noweb parsing has very recently become very brittle, > since it broke the noweb in my lilypond example. > This does not appear to be restricted to lilypond blocks. > > The error is (wrong-type-argument consp nil) > > I fixed for my songs by changing... > > #+srcname: gen_arpeggio(key,root) > > to... > > #+srcname: gen_arpeggio (key,root) > > and... > > <> > > to... > > <> > > I believe #+call: is affected too. > > Unfortunately I won't be able to investigate further until next week. > I can't reproduce this problem, for example the following works for me on the latest version of Org-mode. I think perhaps you may not be on the latest git HEAD. Thanks again for this great contribution -- Eric ** define a block with a name for noweb expansion :PROPERTIES: :tangle: yes :noweb:yes :END: #+source: simple(something="something") #+begin_src emacs-lisp something #+end_src another block including the first block #+begin_src emacs-lisp <> #+end_src -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Move to item to the bottom
Hello, Marcelo de Moraes Serpa writes: > Nicolas, what if all the items are top-level items? My gtd.org file is > basically a flat list of projects and I don't have a main top list for that > wraps them. Any ideas? I'm not sure to understand. If all the items are at top level, the function will move the current item at the bottom of the list. Every item belongs to a list. Or are we talking about two different things? Regards, -- Nicolas Goaziou
Re: [O] Bug: Broken fontification of code blocks [7.5 (release_7.5.525.gd6fb5)]
Hi Oleksandr, [...] > > 2. Edit the following minimal example: > > #+begin_src > (defun id (x) x) > #+end_src > The behavior you describe below is the desired behavior, not a bug. A language is a desired property of a code block, if you want a simple example block please use the example syntax. #+begin_example #+end_example Best -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Org-mode is not able to manage complex calendar events
* Bastien wrote: > Hi Karl, Hi! > Karl Voit writes: > >> Yes, there is this sexp-workaround[1] for more complex things but >> quite frankly: this is not an option for the ordinary user like me >> (not having that much ELISP knowledge). > > FWIW: what would perhaps be useful is an interactive way to easily > produce such sexp diary timestamps. For example. Or an extended syntax of the existing timestamps as I suggested somewhere in this thread: <2011-07-01 Fri +1w> <-2011-07-08 Fri> ... or similar for an exception of a recurring event. I'd be glad to be of help in terms of brainstorming or «usability evaluation». -- Karl Voit
Re: [O] Calendar-like view of the org-agenda
Oh, I didn't know calender integrate with org! Living and learning. Thanks for that, Memnon. M> On Fri, Jul 1, 2011 at 5:06 AM, Michael Markert < markert.mich...@googlemail.com> wrote: > On 1 Jul 2011, Bastien wrote: > > > PS: there are definitely nice things in Taskwarrior I would love to > > see integrated in Org. Let's continue brainstorming about this. > > I don't know if Taskwarrior features that, but I'd like to see a > time-table like week-view with correct (maybe color coded) time > ranges. Since I'm a student I've got lots of recurring lectures and it > would be nice to have a nice overview. > > To give an example: The way Google Calendar displays it fulfills my > need, but I don't like feeding my appointments to Google. > > Pointers where I should look to implement it (or maybe Org already > features it and I just don't know it -- after all this is Org ;)) are > highly appreciated! > > Michael >
[O] caching and code execution on export
Hi all, I'm giving org-babel another go after a recent retreat back to Sweave. I'm having problems with code being executed on export, even when :cache yes is in force. Please see the following example. Also, a quick question that I can't seem to find the answer to: what is the difference between "#+source " and "#+srcname "? Thanks! Ista = 8< = example starts here <= 8< = #+BABEL: :session *R* * Org-babel cache test ** Instructions 1. Start emacs in quiet mode (to rule out personal setting changing the results). 2. Evaluate the buffer and save it. 3. Evaluate it again. 4. Now export (e.g., to html) the buffer. ** Setup *** load ess #+source start-ess #+begin_src emacs-lisp :results silent :exports none (require 'ess-site) #+end_src *** Setup bable for R #+source setup-r-babel #+begin_src emacs-lisp :results silent :exports none (org-babel-do-load-languages 'org-babel-load-languages '((R . t))) #+end_src ** Test *** First R code block #+source: obtest #+begin_src R :cache yes x <- rnorm(10) Sys.sleep(5) #+end_src *** Second R code block #+source obtest2 #+begin_src R :cache yes y <- 10 Sys.sleep(5) #+end_src ** What happens Cached code blocks are not re-exectued in step 3, as intented. However, they are exectued in step 4. After much pain I found that setting org-export-babel-evaluate to nil fixed the problem. But a) I don't think this is the intended behavior, and b) if it is I think it should be changed. I've seen the discussion at http://comments.gmane.org/gmane.emacs.orgmode/40685 which seems to indicate that this should not be happening. ** Version Info GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600) of 2011-04-11 Org-mode version 7.4 (same thing on 7.5 from ELPA) = 8< = example ends here <= 8< = -- Ista Zahn Graduate student University of Rochester Department of Clinical and Social Psychology http://yourpsyche.org
Re: [O] Move to item to the bottom
Nice discussion! Nicolas, what if all the items are top-level items? My gtd.org file is basically a flat list of projects and I don't have a main top list for that wraps them. Any ideas? Cheers, M> On Fri, Jul 1, 2011 at 11:07 AM, Bastien wrote: > Hi Carsten, > > Carsten Dominik writes: > > > I do not agree, if I move something up, I never want it to go down. > > A list is not a circle. Maybe C-M-down, or C-u M-down > > or so might be a possibility. > > Agreed, C-M-up will surely be less surprising. > > Let's wait for Nicolas's patch about this and give feedback against > real testing. > > There is no hurry to make this change, we can delay it after taking > the time to test/discuss. > > -- > Bastien >
Re: [O] Move to item to the bottom
Hi Carsten, Carsten Dominik writes: > I do not agree, if I move something up, I never want it to go down. > A list is not a circle. Maybe C-M-down, or C-u M-down > or so might be a possibility. Agreed, C-M-up will surely be less surprising. Let's wait for Nicolas's patch about this and give feedback against real testing. There is no hurry to make this change, we can delay it after taking the time to test/discuss. -- Bastien
Re: [O] Bug: inline images for filenames with spaces
Hi Manuel, Manuel Giraud writes: > AFAIU, now a link to an inline image inserted with org-insert-link will > expand into [[file name.jpg]] instead of [[file%20name.jpg][file > name.jpg]]. But the later form still doesn't work so it have to be > fixed into older org files. Yes, exactly. -- Bastien
Re: [O] [BUG] Ugly checkbox on HTML export
Manuel Giraud writes: > Nicolas' patch is already applied and far more complete than mine. So > I guess it's decided ;-) Great -- thanks for the update! -- Bastien
Re: [O] [BUG] Ugly checkbox on HTML export
Bastien writes: > Hi Manuel, > > Manuel Giraud writes: > >> Oops, the previous patch was applied on top on another one I have >> here. This one's better. > > I let Nicolas decide on this one. Nicolas' patch is already applied and far more complete than mine. So I guess it's decided ;-) -- Manuel Giraud
Re: [O] [PATCH] Fix some #+ blocks fontification when there is no lang attribute
Hi Julien, julien Barnier writes: > * lisp/org.el (org-fontify-meta-lines-and-blocks-1): Fix test for src blocks > lang attribute > > When there is no lang attribute to a block (for quote, verse or others), the > lang variable is not nil, but an empty string. Applied, thanks! -- Bastien
Re: [O] [BUG] Ugly checkbox on HTML export
Hi Manuel, Manuel Giraud writes: > Oops, the previous patch was applied on top on another one I have > here. This one's better. I let Nicolas decide on this one. -- Bastien
Re: [O] Org-mode is not able to manage complex calendar events
Hi Karl, Karl Voit writes: > Yes, there is this sexp-workaround[1] for more complex things but > quite frankly: this is not an option for the ordinary user like me > (not having that much ELISP knowledge). FWIW: what would perhaps be useful is an interactive way to easily produce such sexp diary timestamps. -- Bastien
[O] [PATCH] Fix some #+ blocks fontification when there is no lang attribute
* lisp/org.el (org-fontify-meta-lines-and-blocks-1): Fix test for src blocks lang attribute When there is no lang attribute to a block (for quote, verse or others), the lang variable is not nil, but an empty string. --- lisp/org.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 9fddf3f..fb1041d 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -5207,7 +5207,7 @@ will be prompted for." (add-text-properties end1 (+ end 1) '(face org-meta-line)) ; for end_src (cond - ((and lang org-src-fontify-natively) + ((and lang (not (string= lang "")) org-src-fontify-natively) (org-src-font-lock-fontify-block lang block-start block-end) ;; remove old background overlays (mapc (lambda (ov) -- 1.7.5.4
[O] [bug] [babel] fontification of source code blocks lost if using #+header(s)
Hello again, For source code blocks with long header lines, org allows the use of the #+header: or #+headers: alternative for specifying these. Attached is an example. The problem is that using these seems to cause fontification to stop working and, unfortunately in a non-reproducible manner, also causes some problems with C-c' working for allowing me to edit the code in a code specific mode. Fontification works just fine if the header arguments are on the #+begin_src line, however. # -*- coding: utf-8; -*- #+TITLE: examplebug.org #+AUTHOR:Eric S Fraga #+EMAIL: e.fr...@ucl.ac.uk #+OPTIONS: H:3 num:t toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t #+OPTIONS: TeX:t LaTeX:t skip:nil d:nil todo:t pri:nil tags:nil * finances #+srcname: transactions #+header: :noweb yes #+begin_src ledger 2011/06/01 * Income assets:bank £1000 income:pay 2011/06/30 * Rent expenses:rent £500 assets:bank #+end_src #+source: balance #+header: :cmdline bal :noweb yes #+begin_src ledger <> #+end_src thanks, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.533.gdffdb)
Re: [O] Collaborating with other people (was: Org-mode as a replacement for LaTeX)
Thanks for the information about VCS's. I agree CVS is outdated, but we use it mostly for legacy reasons --- all of our codebase is in CVS along with papers going back many years. For my other projects, I use git or mercurial as a VCS. My question was originally more oriented toward handling Org-mode files with collaborators who don't use Org-mode, regardless of the VCS. Those collaborators are only comfortable modifying the LaTeX document itself, and checking in changes to the LaTeX document won't update the Org-mode file. There have already been a few good suggestions, but if others have some system worked out, please chime in :). Chris On Fri, Jul 1, 2011 at 7:47 AM, Rainer M Krug wrote: > > > On Fri, Jul 1, 2011 at 1:10 PM, Karl Voit wrote: >> >> * chris.m.mal...@gmail.com wrote: >> > >> > I'm curious how you work on Org-mode papers for publication with >> > collaborators? In particular, do all of your collaborators know and use >> > Org-mode themselves? Our current method is just to use ordinary LaTeX >> > files >> > in a CVS repository for collaboration. >> >> CVS is very ... old if not ancient. >> >> For collaboration with LaTeX documents I am using SVN[1] as a >> centralized version control system (VCS) if my collaborators are not >> tech savvy. There are lots of handy tools available like [2] that >> made it possible to convince any ordinary user from using SVN. >> >> If I am working with tech savvy people, I tend to use git [3] >> instead. It is a *decentralized* VCS with much more possibilities >> and it is a bit harder to learn. But if you are familiar with git, >> you get advantages from offline commits, partial commits, and very >> good internal merging capabilities that solve most of the LaTeX >> integration process automatically. >> >> 1. https://secure.wikimedia.org/wikipedia/en/wiki/Subversion_(software) >> 2. https://secure.wikimedia.org/wikipedia/en/wiki/TortoiseSVN >> 3. https://secure.wikimedia.org/wikipedia/en/wiki/Git_(software) > > Just to add from the Linux side: > http://www.rabbitvcs.org/ > very similar to TortoiseSVN - also works for git. > Rainer >> >> -- >> Karl Voit >> >> > > > > -- > Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, > UCT), Dipl. Phys. (Germany) > > Centre of Excellence for Invasion Biology > Stellenbosch University > South Africa > > Tel : +33 - (0)9 53 10 27 44 > Cell: +33 - (0)6 85 62 59 98 > Fax (F): +33 - (0)9 58 10 27 44 > > Fax (D): +49 - (0)3 21 21 25 22 44 > > email: rai...@krugs.de > > Skype: RMkrug > >
Re: [O] latex short caption broken?
Hi Bastien and Suvayu, Hmm...somehow my cron job on my machine to checkout org-mode from git stopped working some time ago. I hadn't paid attention to the various releases, because I thought I was up-to-date! Thanks for figuring this out. Chris On Fri, Jul 1, 2011 at 4:28 AM, Bastien wrote: > suvayu ali writes: > >>> That thread says the patch has been applied, and as far as I can tell >>> it appears to be in the code. I'm using version =org-version= 7.3. >> >> I think the patch was applied after the 7.5 release. > > I confirm -- Chris, please upgrade, or wait one week if you want to > upgrade to 7.6. > > -- > Bastien >
Re: [O] ob-lilypond
Hi > > That's good to hear. Are you up for trying to merge them into the rest > of the Org-mode test suite? This should be as simple as placing any > org-mode example files you have in > > org-mode/testing/examples/ > > placing the .el file defining your tests into > > org-mode/testing/lisp/ > > and renaming all of your tests so that they start with the prefix > "ob-lilypond/" > > I fully understand if you don't have the time to do this, and I should > be able to take a shot at it some time in the not-too-distant future. Hopefully this patch will work for you... port-test-ob-lilypond.patch Description: Binary data It looks like noweb parsing has very recently become very brittle, since it broke the noweb in my lilypond example. This does not appear to be restricted to lilypond blocks. The error is (wrong-type-argument consp nil) I fixed for my songs by changing... #+srcname: gen_arpeggio(key,root) to... #+srcname: gen_arpeggio (key,root) and... <> to... <> I believe #+call: is affected too. Unfortunately I won't be able to investigate further until next week. Regards Martyn
Re: [O] HTML Postamble is inside Content DIV
Hi Pierre,
Pierre de Buyl wrote:
> Le 28 juin 11 à 23:45, Sebastien Vauban a écrit :
>> Here is thus my proposition for a better div-structured HTML.
>>
>> There are only four parts required in the HTML for all the magic to work
>> with the CSS:
>>
>> - The first part is a container div ("content", by default) that surrounds
>> everything.
>>
>> - Inside that are three more parts:
>> + a preamble (in a div, if the user wants it),
>> + a div "body" and
>> + a postamble (in a div, if the user wants it).
>
> I think my regular use of the html export would be broken.
We'll try to solve that, then.
> I add a in the preamble and a in the postamble.
> This allows me to make a "boxed" page (see
> http://homepages.ulb.ac.be/~pdebuyl/ ) which I like.
>
> If I cannot end my div in the postamble, I think it would break my setup.
>
> Here is my setup:
>:html-preamble "
>
>
>HERE, some static menu items.
>
> "
>:html-postamble "
>
> "
Why are you adding a `wrapper' div in the already existing `content' div (that
surrounds everything). I see no real difference between both.
> I tried without that extra div and I cannot reproduce my former layout.
Would you apply your CSS rule onto `content', would that make a diff?
Best regards,
Seb
--
Sebastien Vauban
Re: [O] Help with compilation warnings since Emacs 24
Hi Rainer, Rainer M Krug writes: > I am a little reluctant to use the latest from their vcs, as it > might be unstable? AFAICT, bleeding edge Emacs is really stable these days. You can either use bzr or git to get it: http://savannah.gnu.org/bzr/?group=emacs http://git.savannah.gnu.org/cgit/emacs.git HTH, -- Bastien
Re: [O] Help with compilation warnings since Emacs 24
On Fri, Jul 1, 2011 at 3:23 PM, Eric S Fraga wrote: > Rainer M Krug writes: > > > On Fri, Jul 1, 2011 at 11:48 AM, Bastien wrote: > > > >> Dear all, > >> > >> Emacs 24 introduces changes to some buffer/window/frames related > >> functions, and compiling Org with Emacs 24 results in a few warnings > >> about this. > >> > > > > If some of you are already using Emacs >24 and can help silencing > >> those warnings, that will boost the release process a lot. > >> > > > > I would like to try out emacs 24 - is there somwhere a download for > > it? I am > > What system are you wanting to use it on? There are pre-built packages > for Debian at the very least... > Sorry - Ubuntu Natty - thanks - they are referenced on the website. Rainer > : deb http://emacs.naquadah.org/ unstable/ > : deb-src http://emacs.naquadah.org/ unstable/ > > HTH. > > -- > : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 > : using Org-mode version 7.5 (release_7.5.533.gdffdb) > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: [O] Jambunathan's ODT exporter now in contrib/
Niels Giesen writes: Hi, Niels, > Using latest org-mode, with org-odt included. > > C-c C-e O complained about not finding OrgOdtAutomaticStyles.xml. > I patched org-odt.el to the following so that it could find it: it was applied 22 minutes ago by Bastien. a51c5637f9c9c8a20eaa063cd35427ffd211787d cheers Giovanni
Re: [O] Help with compilation warnings since Emacs 24
Rainer M Krug writes: > On Fri, Jul 1, 2011 at 11:48 AM, Bastien wrote: > >> Dear all, >> >> Emacs 24 introduces changes to some buffer/window/frames related >> functions, and compiling Org with Emacs 24 results in a few warnings >> about this. >> > > If some of you are already using Emacs >24 and can help silencing >> those warnings, that will boost the release process a lot. >> > > I would like to try out emacs 24 - is there somwhere a download for > it? I am What system are you wanting to use it on? There are pre-built packages for Debian at the very least... : deb http://emacs.naquadah.org/ unstable/ : deb-src http://emacs.naquadah.org/ unstable/ HTH. -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.533.gdffdb)
Re: [O] [PATCH] Make org-xhtml and org-odt usable
Jambunathan K writes: > The attached patch will make sure that the xhtml and odt exporter don't > crash when invoked. Could you please apply this patch? Done, thanks! -- Bastien
Re: [O] Jambunathan's ODT exporter now in contrib/
Using latest org-mode, with org-odt included. C-c C-e O complained about not finding OrgOdtAutomaticStyles.xml. I patched org-odt.el to the following so that it could find it: Could someone look into this? (e.g. I do not know whether this would break non-integrated org-odt (or whether that matters at all at this stage) diff --git a/contrib/lisp/org-odt.el b/contrib/lisp/org-odt.el index ad53204..2857bf9 100644 --- a/contrib/lisp/org-odt.el +++ b/contrib/lisp/org-odt.el @@ -70,7 +70,7 @@ (defconst org-odt-lib-dir (file-name-directory load-file-name)) (defconst org-odt-data-dir - (let ((dir1 (expand-file-name ".." org-odt-lib-dir)); git + (let ((dir1 (expand-file-name "../odt" org-odt-lib-dir)); git (dir2 (expand-file-name "./contrib/odt" org-odt-lib-dir))) ; elpa (cond ((file-directory-p dir1) dir1) On Fri, Jul 1, 2011 at 11:37 AM, Bastien wrote: > Dear all, > > I'm please to announce that Jambunathan's ODT exporter is now in the > contrib/ directory (in latest git repo) -- the files are here: > > contrib/odt/ > contrib/lisp/org-odt.el > contrib/lisp/org-lparse.el > contrib/lisp/org-xhtml.el > > Jambunathan and I are still actively tuning this major addition, please > bare with us while we are making sure everything works as expected. > > We still need to update the documentation and a few things. > > Again, thanks a lot to Jambunathan for this wonderful addition and for > his patience, and also thanks to Lennart who contributed to the initial > effort and helped make this come true. > > The ODT exporter will live in contrib/ for Org 7.6 -- then we will work > on integrating it to the core, so that it can safely move to Emacs one > day. > > Happy hacking and testing to everyone! > > -- > Bastien > > -- http://pft.github.com
Re: [O] Regression bug in tangle/weave
Is there an example of this that does not use something like elisp, R, perl, python, shell, or some other process that requires either allowing all blocks to execute without prompting, or prompting for authority to run the block every time the file is tangled? Brian - Original Message - From: Eric Schulte To: MidLifeXis at PerlMonks Cc: emacs-orgmode Sent: Thursday, June 30, 2011 1:30 PM Subject: Re: [O] Regression bug in tangle/weave Hi, Indeed this example below no longer works, however I believe the new behavior is both desired and permanent. I'll explain and include an option for how your example could be restructured to work with the new code. We ran into problems automatically removing trailing newlines from code block bodies as in some languages (looking at you Python and Haskell) things like trailing newlines are of syntactic importance. In your example this behavior results in the insertion of newlines after file-name and file-version. Babel is careful to preserve line prefixes when expanding references in comments, so it then reproduces the # Generated from portion of that line for every line of the expanded noweb references. I would suggest the following alternatives, either using a data references in stead of a code block reference as in the file-version example below, or using an evaluated code block as in the file-name example below. Hope this helps. Best -- Eric MidLifeXis at PerlMonks writes: > It appears that there may be a regression problem with the current > tangle/weave process. I used to be able to have a noweb section for > the name of the file, another for the version of the file, and then > have an autogenerated header section that included those two pieces of > information on a single line. Following is an org file snippet of my > bug description. > > > * Bugs > ** SOMEDAY org-mode bug with tangle and newlines :BUG: > :PROPERTIES: > :created: [2011-06-30 Thu 10:00] > :ID: e4c992b5-4d35-443b-b34a-0fbda7c66aea > :END: > :LOGBOOK: > - Added on [2011-06-30 Thu 10:00] > :END: > [2011-06-30 Thu] > > A regression bug has surfaced in org-mode with the tangle/weave > process mangling the following setup: > > #+begin_src perl :noweb yes :tangle testoutput.pl :shebang #!perl > # <> > print "Hello world\n"; > #+end_src > > #+srcname: generated-from > #+begin_src text :noweb yes > Generated from <> version <>. > #+end_src > > #+srcname: file-name > #+begin_src text :noweb yes > ATestFile.org > #+end_src > > #+srcname: file-version > #+begin_src text :noweb yes > 1.2.3.4 > #+end_src > > The last it worked* was sometime in the early 7.4 timeframe. If I > get some time, I may do a bisect on it, although others are welcome > to do the work required. Timeframe is based on memory, not > actual checking, so first a bisect needs to be done to find where > it last worked. > > > *** Actual output > > #+begin_src perl > #!perl > > # Generated from ATestFile.org > # Generated from version 1.2.3.4 > # Generated from <> version . > # > print "Hello world\n"; > #+end_src > > *** Expected output (or at least similar) > > #+begin_src perl > #!perl > > # Generated from ATestFile.org version 1.2.3.4. > > print "Hello world\n"; > #+end_src > > * End of org file > > -- Eric Schulte http://cs.unm.edu/~eschulte/
[O] [RFC] testing the org exporters
I have been using the attached test.org file as part of my org-odt related work. The usual steps I follow for testing are quite simple: 1. Visit the file 2. Export it to xhtml or odt 3. Visually make sure that everything is OK. I would like to add this file to the testing dir of the trunk. This file would be a good starting point for not only validating but also documenting (the quirks?) of various exporters. At the moment, I am not very inclined to have it integrated with ert[1]. Based on my experience, the standalone test.org file has proven it's worth multiple times over during the development phase. What do you think? I am happy to hear feedback on 1. what to put in that test.org 2. where to put the test.org 3. how to have it integrated with test framework. tests.tar Description: tests.tar Footnotes: [1] This is mostly because I don't know nothing about ert. --
Re: [O] Jambunathan's ODT exporter now in contrib/
Congratulations and thanks to Jambunathan! This is indeed a major addition, and great news for those of us with clients who expect *office formats. Yours, Christian On 7/1/11 11:37 AM, Bastien wrote: Dear all, I'm please to announce that Jambunathan's ODT exporter is now in the contrib/ directory (in latest git repo) -- the files are here: contrib/odt/ contrib/lisp/org-odt.el contrib/lisp/org-lparse.el contrib/lisp/org-xhtml.el Jambunathan and I are still actively tuning this major addition, please bare with us while we are making sure everything works as expected. We still need to update the documentation and a few things. Again, thanks a lot to Jambunathan for this wonderful addition and for his patience, and also thanks to Lennart who contributed to the initial effort and helped make this come true. The ODT exporter will live in contrib/ for Org 7.6 -- then we will work on integrating it to the core, so that it can safely move to Emacs one day. Happy hacking and testing to everyone!
[O] [PATCH] Make org-xhtml and org-odt usable
Bastien
> Dear all,
>
> I'm please to announce that Jambunathan's ODT exporter is now in the
> contrib/ directory (in latest git repo) -- the files are here:
>
> contrib/odt/
> contrib/lisp/org-odt.el
> contrib/lisp/org-lparse.el
> contrib/lisp/org-xhtml.el
>
Thanks for accepting my contribution. I am happy to see my files land in
the master repo. I am confident that these files will provide a good and
stable framework for external exporters to plug in.
> Jambunathan and I are still actively tuning this major addition, please
> bare with us while we are making sure everything works as expected.
The attached patch will make sure that the xhtml and odt exporter don't
crash when invoked. Could you please apply this patch?
>From d96a8f9e167abebe74cb23e5810f3556ed7a87e1 Mon Sep 17 00:00:00 2001
From: Jambunathan K
Date: Fri, 1 Jul 2011 17:11:45 +0530
Subject: [PATCH] Make org-xhtml and org-odt usable
* contrib/lisp/org-odt.el (org-odt-data-dir): Update to
reflect new directory layout.
* contrib/lisp/org-xhtml.el
(org-export-xhtml-special-string-regexps): Define it.
---
contrib/lisp/org-odt.el |2 +-
contrib/lisp/org-xhtml.el |7 +++
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/contrib/lisp/org-odt.el b/contrib/lisp/org-odt.el
index ad53204..c0b6491 100644
--- a/contrib/lisp/org-odt.el
+++ b/contrib/lisp/org-odt.el
@@ -70,7 +70,7 @@
(defconst org-odt-lib-dir (file-name-directory load-file-name))
(defconst org-odt-data-dir
- (let ((dir1 (expand-file-name ".." org-odt-lib-dir)) ; git
+ (let ((dir1 (expand-file-name "../odt" org-odt-lib-dir)) ; git
(dir2 (expand-file-name "./contrib/odt" org-odt-lib-dir))) ; elpa
(cond
((file-directory-p dir1) dir1)
diff --git a/contrib/lisp/org-xhtml.el b/contrib/lisp/org-xhtml.el
index 7cdb936..fcc782c 100644
--- a/contrib/lisp/org-xhtml.el
+++ b/contrib/lisp/org-xhtml.el
@@ -44,6 +44,13 @@
:tag "Org Export HTML"
:group 'org-export)
+(defconst org-export-xhtml-special-string-regexps
+ '(("-" . "")
+("---\\([^-]\\)" . "—\\1")
+("--\\([^-]\\)" . "–\\1")
+("\\.\\.\\." . "…"))
+ "Regular expressions for special string conversion.")
+
(defcustom org-export-xhtml-footnotes-section "
%s:
--
1.7.2.3
Jambunathan K.
--
Re: [O] ob-lilypond
On 6/30/11 8:10 PM, Eric Schulte wrote: Martyn Jago writes: (...) Great, I've just moved this into the Org-mode core and added it to the list of Babel languages. Great! One distinction that has occurred to me (especially following comments on the mailing list) is that of "babel language" and "babel language work-flow". In other words, I can visualise refactoring ob-lilypond to be no more than a specification of the Lilypond syntax, and working in parallel, on a work-flow implementation for Lilypond that is "opinionated" in terms of adjusting org-babel settings away from their defaults / removing work-flow noise etc. ( org-lilypond.el ) ? Would this make sense, and if so where would it live (aligned to org-babel / a native Emacs mode perhaps)? I hope that makes sense. That sounds like a good idea. Ideally ob-lilypond should include just those elements expected by the code block interface, namely functions for session/external evaluation, for expanding variables in code block bodies, and for returning results to Org-mode. I think that it would be a good idea to develop an external org-lilypond to support a more comprehensive workflow. I like this. I certainly see that the already complex task of making arrangements like those in Martyn's examples should be made as easy as possible. As for the comparatively simple use cases I brought up, once they're supported by ob-lilypond I'd be perfectly happy to throw header arguments at them. Yours, Christian
Re: [O] Collaborating with other people (was: Org-mode as a replacement for LaTeX)
On Fri, Jul 1, 2011 at 1:10 PM, Karl Voit wrote: > * chris.m.mal...@gmail.com wrote: > > > > I'm curious how you work on Org-mode papers for publication with > > collaborators? In particular, do all of your collaborators know and use > > Org-mode themselves? Our current method is just to use ordinary LaTeX > files > > in a CVS repository for collaboration. > > CVS is very ... old if not ancient. > > For collaboration with LaTeX documents I am using SVN[1] as a > centralized version control system (VCS) if my collaborators are not > tech savvy. There are lots of handy tools available like [2] that > made it possible to convince any ordinary user from using SVN. > > If I am working with tech savvy people, I tend to use git [3] > instead. It is a *decentralized* VCS with much more possibilities > and it is a bit harder to learn. But if you are familiar with git, > you get advantages from offline commits, partial commits, and very > good internal merging capabilities that solve most of the LaTeX > integration process automatically. > > 1. https://secure.wikimedia.org/wikipedia/en/wiki/Subversion_(software) > 2. https://secure.wikimedia.org/wikipedia/en/wiki/TortoiseSVN > 3. https://secure.wikimedia.org/wikipedia/en/wiki/Git_(software) Just to add from the Linux side: http://www.rabbitvcs.org/ very similar to TortoiseSVN - also works for git. Rainer > > -- > Karl Voit > > > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: [O] Help with compilation warnings since Emacs 24
On Fri, Jul 1, 2011 at 11:48 AM, Bastien wrote: > Dear all, > > Emacs 24 introduces changes to some buffer/window/frames related > functions, and compiling Org with Emacs 24 results in a few warnings > about this. > If some of you are already using Emacs >24 and can help silencing > those warnings, that will boost the release process a lot. > I would like to try out emacs 24 - is there somwhere a download for it? I am a little reluctant to use the latest from their vcs, as it might be unstable? Rainer > > Thanks in advance, > > -- > Bastien > > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
[O] Collaborating with other people (was: Org-mode as a replacement for LaTeX)
* chris.m.mal...@gmail.com wrote: > > I'm curious how you work on Org-mode papers for publication with > collaborators? In particular, do all of your collaborators know and use > Org-mode themselves? Our current method is just to use ordinary LaTeX files > in a CVS repository for collaboration. CVS is very ... old if not ancient. For collaboration with LaTeX documents I am using SVN[1] as a centralized version control system (VCS) if my collaborators are not tech savvy. There are lots of handy tools available like [2] that made it possible to convince any ordinary user from using SVN. If I am working with tech savvy people, I tend to use git [3] instead. It is a *decentralized* VCS with much more possibilities and it is a bit harder to learn. But if you are familiar with git, you get advantages from offline commits, partial commits, and very good internal merging capabilities that solve most of the LaTeX integration process automatically. 1. https://secure.wikimedia.org/wikipedia/en/wiki/Subversion_(software) 2. https://secure.wikimedia.org/wikipedia/en/wiki/TortoiseSVN 3. https://secure.wikimedia.org/wikipedia/en/wiki/Git_(software) -- Karl Voit
Re: [O] Move to item to the bottom
On Jul 1, 2011, at 12:14 PM, Eric S Fraga wrote: > Carsten Dominik writes: > >> On Jul 1, 2011, at 10:57 AM, Bastien wrote: >> >>> Hi Nicolas, >>> >>> Nicolas Goaziou writes: >>> Correcting myself, I paste here another try to the problem at hand. Indeed, moving an item to a list he doesn't directly belong to makes little sense. Thus, the item will be moved at the end of its list. >>> >>> Nice. Such a move could be bound to M- when the cursor is on the >>> first item, instead of throwing an error, as it does now. >>> >>> What do you think? >> >> This does sound counter-intuitive to me. >> >> - Carsten >> > > I agree but there *is* some precedence for this type of behaviour in > Emacs: e.g. the bs buffer display package where moving up () at the > top of the list of buffers takes you to the bottom of the list and vice > versa ()? I think this is different. You are talking about selecting an item. Moving list items feels different, at least for me. - Carsten
Re: [O] Bug: inline images for filenames with spaces
Bastien writes: > Hi Huy, > > Bastien writes: > >>> I'm not exporting. >>> I'm just doing C-c C-x C-v to display the inline images within emacs. >> >> I confirm there is a bug here, I'm on it. > > I've pushed the fix now, please test it! I've tested your patch. It works with org-toggle-inline-image, export to HTML and to LaTeX. AFAIU, now a link to an inline image inserted with org-insert-link will expand into [[file name.jpg]] instead of [[file%20name.jpg][file name.jpg]]. But the later form still doesn't work so it have to be fixed into older org files. Best, -- Manuel Giraud
Re: [O] org-install ?
On 1 Jul 2011, Giovanni Ridolfi wrote: > > So I have some questions and answers: > > - (Since we are aiming to release org 7.6) will the org-install.el be > generated during such process? > - and during the compilation of Emacs 24? The emacs-bundled org-mode org-install.el is empty (if it is there). It's purpose is to provide an easy way to hook it with emacs. > + I checked version 6.21b (2009-02-02), shipped with Emacs 23.1, > and it seems to me that there's no org-install file. > so probably it will be generated during the compilation of Emacs 24. > > - Is it possible that, after 20th october 2010, something changed and > the install file is generated *only* with the make command? Can't answer that, but it would be strange if it shipped before. > + well looking through the history of makefile it seems that > org-install has been generated at least since 2008-01-31 Carsten > Dominik Release 5.18 release_5.18. bah?! > > cheers, Giovanni /who have to find a way to create the org-install.el > without using make or using make, but without compiling org-mode. No > .elc file around, please! :-) Perhaps it is time to get Emacs 24 or > package manager ;-) Because of the autoload problems mentioned in another thread I built an elisp file to have something to play with. Put it in the base folder and run it with `emacs -Q -l gen-autoloads.el' or directly via emacs, but make sure that you are in the base-folder. Michael (setq org-lisp-files '(org.el org-agenda.el org-ascii.el org-attach.el org-archive.el org-bbdb.el org-beamer.el org-bibtex.el org-capture.el org-clock.el org-colview.el org-colview-xemacs.el org-compat.el org-pcomplete.el org-crypt.el org-ctags.el org-datetree.el org-docview.el org-entities.el org-exp.el org-exp-blocks.el org-docbook.el org-faces.el org-feed.el org-footnote.el org-freemind.el org-gnus.el org-habit.el org-html.el org-icalendar.el org-id.el org-indent.el org-info.el org-inlinetask.el org-jsinfo.el org-irc.el org-latex.el org-list.el org-mac-message.el org-macs.el org-mew.el org-mhe.el org-mks.el org-mobile.el org-mouse.el org-publish.el org-plot.el org-protocol.el org-remember.el org-rmail.el org-special-blocks.el org-src.el org-table.el org-taskjuggler.el org-timer.el org-vm.el org-w3m.el org-wl.el org-xoxo.el ob.el ob-table.el ob-lob.el ob-ref.el ob-exp.el ob-tangle.el ob-comint.el ob-eval.el ob-keys.el ob-awk.el ob-C.el ob-calc.el ob-ditaa.el ob-haskell.el ob-perl.el ob-sh.el ob-R.el ob-dot.el ob-mscgen.el ob-latex.el ob-lisp.el ob-ledger.el ob-python.el ob-sql.el ob-asymptote.el ob-emacs-lisp.el ob-matlab.el ob-ruby.el ob-sqlite.el ob-clojure.el ob-ocaml.el ob-sass.el ob-css.el ob-gnuplot.el ob-octave.el ob-screen.el ob-plantuml.el ob-org.el ob-js.el ob-scheme.
[O] Help with compilation warnings since Emacs 24
Dear all, Emacs 24 introduces changes to some buffer/window/frames related functions, and compiling Org with Emacs 24 results in a few warnings about this. If some of you are already using Emacs >24 and can help silencing those warnings, that will boost the release process a lot. Thanks in advance, -- Bastien
Re: [O] Calendar-like view of the org-agenda
On 1 Jul 2011, Bastien wrote: > PS: there are definitely nice things in Taskwarrior I would love to > see integrated in Org. Let's continue brainstorming about this. I don't know if Taskwarrior features that, but I'd like to see a time-table like week-view with correct (maybe color coded) time ranges. Since I'm a student I've got lots of recurring lectures and it would be nice to have a nice overview. To give an example: The way Google Calendar displays it fulfills my need, but I don't like feeding my appointments to Google. Pointers where I should look to implement it (or maybe Org already features it and I just don't know it -- after all this is Org ;)) are highly appreciated! Michael pgpoDjvMqdK8w.pgp Description: PGP signature
Re: [O] Move to item to the bottom
On Jul 1, 2011, at 11:46 AM, Bastien wrote: > Carsten Dominik writes: > >> This does sound counter-intuitive to me. > > Why? > > The idea is that someone who wants to move a first item to the top > really wants to cycle through items -- same for moving the bottom item > to the bottom, where the user really wants to move it to the top. I do not agree, if I move something up, I never want it to go down. A list is not a circle. Maybe C-M-down, or C-u M-down or so might be a possibility. > > Actually, it's important to have both feature to let the user navigate > back and forth. Yes, symmetry is always good. - Carsten
Re: [O] Move to item to the bottom
Carsten Dominik writes: > On Jul 1, 2011, at 10:57 AM, Bastien wrote: > >> Hi Nicolas, >> >> Nicolas Goaziou writes: >> >>> Correcting myself, I paste here another try to the problem at >>> hand. Indeed, moving an item to a list he doesn't directly belong to >>> makes little sense. Thus, the item will be moved at the end of its >>> list. >> >> Nice. Such a move could be bound to M- when the cursor is on the >> first item, instead of throwing an error, as it does now. >> >> What do you think? > > This does sound counter-intuitive to me. > > - Carsten > I agree but there *is* some precedence for this type of behaviour in Emacs: e.g. the bs buffer display package where moving up () at the top of the list of buffers takes you to the bottom of the list and vice versa ()? -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.533.gdffdb)
Re: [O] Move to item to the bottom
Hello, Bastien writes: >> Correcting myself, I paste here another try to the problem at >> hand. Indeed, moving an item to a list he doesn't directly belong to >> makes little sense. Thus, the item will be moved at the end of its >> list. > > Nice. Such a move could be bound to M- when the cursor is on the > first item, instead of throwing an error, as it does now. > > What do you think? Good idea, as long as M- also moves the last item to the top position. It needs a better optimization (my excuse for `org-list-delete-item'). I will work on it tonight. Regards, -- Nicolas Goaziou
[O] Jambunathan's ODT exporter now in contrib/
Dear all, I'm please to announce that Jambunathan's ODT exporter is now in the contrib/ directory (in latest git repo) -- the files are here: contrib/odt/ contrib/lisp/org-odt.el contrib/lisp/org-lparse.el contrib/lisp/org-xhtml.el Jambunathan and I are still actively tuning this major addition, please bare with us while we are making sure everything works as expected. We still need to update the documentation and a few things. Again, thanks a lot to Jambunathan for this wonderful addition and for his patience, and also thanks to Lennart who contributed to the initial effort and helped make this come true. The ODT exporter will live in contrib/ for Org 7.6 -- then we will work on integrating it to the core, so that it can safely move to Emacs one day. Happy hacking and testing to everyone! -- Bastien
Re: [O] Move to item to the bottom
Carsten Dominik writes: > This does sound counter-intuitive to me. Why? The idea is that someone who wants to move a first item to the top really wants to cycle through items -- same for moving the bottom item to the bottom, where the user really wants to move it to the top. Actually, it's important to have both feature to let the user navigate back and forth. -- Bastien
Re: [O] Move to item to the bottom
Nicolas Goaziou writes: > It needs a better optimization (my excuse for > `org-list-delete-item'). I will work on it tonight. Thanks! I'm really excited by all this activity/features/questions. I'm still focusing on our main goal, though, which is to release 7.6 ASAP so that it will be included in Emacs pretest. I plan to make the release by *sunday morning*. -- Bastien
[O] [Accepted] individual markups for active and inactive time stamps on export
Patch 816 (http://patchwork.newartisans.com/patch/816/) is now "Accepted".
Maintainer comment: none
This relates to the following submission:
http://mid.gmane.org/%3C874o373spj.fsf%40ucl.ac.uk%3E
Here is the original message containing the patch:
> Content-Type: text/plain; charset="utf-8"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Subject: [O] individual markups for active and inactive time stamps on export
> Date: Fri, 01 Jul 2011 02:38:48 -
> From: Eric S Fraga
> X-Patchwork-Id: 816
> Message-Id: <874o373spj@ucl.ac.uk>
> To: emacs-orgmode@gnu.org
>
> Hello again,
>
> okay, I will answer my own post with a possible solution to my feature
> request earlier today.
>
> Attached is a patch that does the job; whether it is elegant enough or
> not is another question. I've not addressed the documentation at all
> yet. I will wait to see what the response to this simple patch might
> be...
>
> Thanks,
> eric
>
>
> * Allow for a different markup for inactive time stamps on latex export
>
>
> diff --git a/lisp/org-latex.el b/lisp/org-latex.el
> index 1baa5f9..694f65b 100644
> --- a/lisp/org-latex.el
> +++ b/lisp/org-latex.el
> @@ -292,6 +292,11 @@ markup defined, the first one in the association list
> will be used."
>:group 'org-export-latex
>:type 'string)
>
> +(defcustom org-export-latex-timestamp-inactive-markup "\\textit{%s}"
> + "A printf format string to be applied to inactive time stamps."
> + :group 'org-export-latex
> + :type 'string)
> +
> (defcustom org-export-latex-timestamp-keyword-markup "\\texttt{%s}"
>"A printf format string to be applied to time stamps."
>:group 'org-export-latex
> @@ -1613,7 +1618,9 @@ links, keywords, lists, tables, fixed-width"
>(org-if-unprotected-at (1- (point))
> (replace-match
> (org-export-latex-protect-string
> - (format org-export-latex-timestamp-markup
> + (format (if (string= "<" (substring (match-string 0) 0 1))
> + org-export-latex-timestamp-markup
> +org-export-latex-timestamp-inactive-markup)
>(substring (org-translate-time (match-string 0)) 1 -1)))
> t t)
>
>
Re: [O] org-install ?
Memnon Anon writes: Memnon and Michael, thank you for your time, this is just for archival purpose. > Giovanni Ridolfi writes: > >> GNU Emacs 23.3.1 (i386-mingw-nt5.1.2600) of 2011-03-10 on 3249CTO >> Org-mode version 7.5 9c582ceed8c4ffc1b83f719f8bcabbc2e23027b2 >> >> I used to have a >> \lisp\org-install.el >> file in my load path. This file was there since >> 20th October 2010 and everythig has been fine untill today. >> >> I've just found that in the latest version of org-mode >> there's no "\lisp\org-install.el" anymore. > > ma@mymachine:~/tmp/bin/org-mode$ git pull [...] >4f3a31d..ffa016b master -> origin/master > [...] > ma@mymachine:~/tmp/bin/org-mode$ make clean > [...] > ma@mymachine:~/tmp/bin/org-mode$ make > [...] > ma@mymachine:~/tmp/bin/org-mode$ ls -alh lisp/org-install.* > -rw-r--r-- 1 ma ma 66K 30. Jun 20:07 lisp/org-install.el > > Its still there. I am on a windows machine where I cannot have git neither cygwin, since I have only user permission. This morning (in Italy, 8.00 UTC) I downloaded the tar.gz of Org-mode version 7.5 311b09d92644f39040087327d6a1dbeb09a9ab6e and the org-install.el file is not in the tar.gz file. I surfed the git repository with my browser and found that in the /org/lisp directory: http://orgmode.org/w/?p=org-mode.git;a=tree;f=lisp;h=5be11d857b3b180d058ad25b5a985d0ac798e41b;hb=311b09d92644f39040087327d6a1dbeb09a9ab6e there's no org-install.el. This is (now) obvious, since org-install.el is generated by make, as can be read in the makefile. --- # The following variables need to be defined by the maintainer LISPF = [snip] LISPFILES0 = $(LISPF:%=lisp/%) LISPFILES = $(LISPFILES0) lisp/org-install.el [...] mv org-install.el lisp # ! aha! :-/ However searching the history of makefile http://orgmode.org/w/?p=org-mode.git;a=history;f=Makefile;hb=912ca556015c745a035d481b18d3e3bf8e930955 I was not able to find when this procedure was introduced. Moreover the commits arount 20th October 2010 leave untouched such part of the makefile. Where does my org-install.el come from? Impossible to know. Even it is a complex file! this is its head: ;;;### (autoloads (org-customize org-reload org-require-autoloaded-modules ;; org-submit-bug-report org-cycle-agenda-files org-switchb ;; org-map-entries org-open-link-from-string org-open-at-point-global ;; org-insert-link-global org-store-link org-run-like-in-org-mode ;; turn-on-orgstruct++ turn-on-orgstruct orgstruct-mode org-global-cycle ;; org-mode org-babel-do-load-languages) "org" "lisp/org.el" ;; (19641 15028)) ;;; Generated autoloads from lisp/org.el So I have some questions and answers: - (Since we are aiming to release org 7.6) will the org-install.el be generated during such process? - and during the compilation of Emacs 24? + I checked version 6.21b (2009-02-02), shipped with Emacs 23.1, and it seems to me that there's no org-install file. so probably it will be generated during the compilation of Emacs 24. - Is it possible that, after 20th october 2010, something changed and the install file is generated *only* with the make command? + well looking through the history of makefile it seems that org-install has been generated at least since 2008-01-31 Carsten Dominik Release 5.18 release_5.18. bah?! cheers, Giovanni /who have to find a way to create the org-install.el without using make or using make, but without compiling org-mode. No .elc file around, please! :-) Perhaps it is time to get Emacs 24 or package manager ;-)
Re: [O] [Accepted] individual markups for active and inactive time stamps on export
Bastien Guerry writes: > Patch 816 (http://patchwork.newartisans.com/patch/816/) is now > "Accepted". Thanks! I'll have a go at updating the documentation. -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.530.g23bb.dirty)
Re: [O] Bug: inline images for filenames with spaces
Hi Huy, Bastien writes: >> I'm not exporting. >> I'm just doing C-c C-x C-v to display the inline images within emacs. > > I confirm there is a bug here, I'm on it. I've pushed the fix now, please test it! Thanks, -- Bastien
Re: [O] Move to item to the bottom
On Jul 1, 2011, at 10:57 AM, Bastien wrote: > Hi Nicolas, > > Nicolas Goaziou writes: > >> Correcting myself, I paste here another try to the problem at >> hand. Indeed, moving an item to a list he doesn't directly belong to >> makes little sense. Thus, the item will be moved at the end of its >> list. > > Nice. Such a move could be bound to M- when the cursor is on the > first item, instead of throwing an error, as it does now. > > What do you think? This does sound counter-intuitive to me. - Carsten
Re: [O] [PATCH] individual markups for active and inactive time stamps on export
Hi Eric, Eric S Fraga writes: > okay, I will answer my own post with a possible solution to my feature > request earlier today. > > Attached is a patch that does the job; whether it is elegant enough or > not is another question. I've not addressed the documentation at all > yet. I will wait to see what the response to this simple patch might > be... thanks, applied! -- Bastien
Re: [O] Move to item to the bottom
Hi Nicolas, Nicolas Goaziou writes: > Correcting myself, I paste here another try to the problem at > hand. Indeed, moving an item to a list he doesn't directly belong to > makes little sense. Thus, the item will be moved at the end of its > list. Nice. Such a move could be bound to M- when the cursor is on the first item, instead of throwing an error, as it does now. What do you think? -- Bastien
Re: [O] Calendar-like view of the org-agenda
Hi Marcelo, Marcelo de Moraes Serpa writes: > Is there a way to have a calendar-like overview of the agenda with > org? Not exactly what you want, but here is what I use. I have a separate rdv.org for appointments. Then a ~/.diary file including them into Emacs's calendar: %%(org-diary :scheduled) /home/guerry/org/rdv.org M-x calendar RET shows the calendar, then pressing `m' in the calendar highlights days with appointments. I found using a separate rdv.org speeds up things, .diary should better not include too many things, otherwise the M-x calendar RET command takes too long. HTH, -- Bastien
[O] [babel] evaluating ledger source block now scans large number of org files
Hello, I don't know what has changed or when but, being the start of a new month, I am doing my finances. I use ledger for this and, of course, within org! Evaluating a ledger source code block now takes a significant amount of time. Babel seems to search org files throughout my disk for IDs. I get messages like this: , | ... | Finding ID locations (13/65 files): ~/git/notes/personal.org | Finding ID locations (14/65 files): ~/git/notes/research.org | Finding ID locations (15/65 files): ~/git/notes/tasks.org | ... ` I am using ":noweb yes" but otherwise I cannot see why org + babel need to scan files throughout the disk? A minimal example that exhibits this behaviour is attached. Evaluating the second code block generates the lines shown above. Evaluating the first block does not which is why I think this may have something to do with :noweb. Up to date org (see signature below). thanks, eric # -*- coding: utf-8; -*- #+TITLE: examplebug.org #+AUTHOR:Eric S Fraga #+EMAIL: e.fr...@ucl.ac.uk #+OPTIONS: H:3 num:t toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t #+OPTIONS: TeX:t LaTeX:t skip:nil d:nil todo:t pri:nil tags:nil * finances #+srcname: transactions #+begin_src ledger :noweb yes 2011/06/01 * Income assets:bank £1000 income:pay 2011/06/30 * Rent expenses:rent £500 assets:bank #+end_src #+srcname: balance #+begin_src ledger :cmdline bal :noweb yes <> #+end_src #+results: balance : £500 assets:bank : £500 expenses:rent : £-1000 income:pay : :0 -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.530.g23bb.dirty)
Re: [O] Subtly hightling task backgrounds
Hi John, John Wiegley writes: > To achieve this, I have the following in my todo file: Nice -- maybe a more general implementation would be to let users assign a color to a category, which is really one defcustom away from your code. Would you be willing to submit a patch in that direction? Thanks! -- Bastien
Re: [O] Replaced obsolete interactive-p function
Hi Eric, Eric Schulte writes: > This extra argument supplies more information to the macro (e.g., an > idea of /how/ interactive is considered /interactive/) through taking on > the value of 'any or 'interactive. This information is thrown out in > older versions of Emacs but is passed on to the called-interactively-p > function in Emacs24 and should influence its behavior. Thanks for the explanations. -- Bastien
Re: [O] Calendar-like view of the org-agenda
PS: there are definitely nice things in Taskwarrior I would love to see integrated in Org. Let's continue brainstorming about this. -- Bastien
Re: [O] latex short caption broken?
suvayu ali writes: >> That thread says the patch has been applied, and as far as I can tell >> it appears to be in the code. I'm using version =org-version= 7.3. > > I think the patch was applied after the 7.5 release. I confirm -- Chris, please upgrade, or wait one week if you want to upgrade to 7.6. -- Bastien
Re: [O] [PATCH] Allow to disable the agenda block separator per block
Hi Michael, Michael Brand writes: > * org-agenda.el (org-agenda-compact-blocks): Improve docstring. > (org-agenda-block-separator): Add nil to docstring and customization. > (org-prepare-agenda): Skip agenda block separator additionally if > org-agenda-block-separator is nil. > (org-agenda-overriding-header): Improve docstring. Applied, thanks! -- Bastien
Re: [O] LaTeX Formulas and Publishing to HTML Error
Hello, Did you try putting some text before the first formula ? It is not recognized as latex (there is only one img included in the html). Anyway, your version of org-mode may be outdated, it works fine on my computer (org-mode version 7.5). http://orgmode.org/manual/Installation.html#Installation will give you the steps required to install. On the mac, you need to give the full path the the emacs binary in the Makefile. It should look similar to /Applications/Aquamacs.app/Contents/MacOS/ Emacs Do not forget to set up the load path so that emacs will pick the new version of emacs. Pierre Le 30 juin 11 à 21:50, Colin Grey a écrit : Hello, I'm having a weird problem trying to write formulas using latex in org mode. Here is a sample file with just two formulas: #+TITLE: Title #+OPTIONS: H:3 num:t toc:t #+OPTIONS: author:nil timestamp:nil creator:nil #+OPTIONS: ^:t skip:t LaTeX:t $A$ $B$ When I export to HTML, the result is where 'A' should be is a link to 'file' and where 'B' should be is rendered 'A'. The output HTML is below. Any ideas? (I'm using Aquamacs on OS X) http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> http://www.w3.org/1999/xhtml"; lang="en" xml:lang="en"> Title Title file:
Re: [O] LaTeX Formulas and Publishing to HTML Error
Colin Grey writes: > Hello, > > I'm having a weird problem trying to write formulas using latex in org > mode. Here is a sample file with just two formulas: > > #+TITLE: Title > #+OPTIONS: H:3 num:t toc:t > #+OPTIONS: author:nil timestamp:nil creator:nil > #+OPTIONS: ^:t skip:t LaTeX:t > > $A$ > > $B$ This didn't work for me either. Adding a top leaving heading, such as: --8<---cut here---start->8--- * Introduction --8<---cut here---end--->8--- before the first equation at least made latex export work. HTML export still doesn't do what I believe you wanted, however, but this I know less about... HTH. -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.526.g311b0.dirty)
