[Orgmode] Re: Testing --- again...
Hi Sebastian, the lack of a testing suite for Org-mode is really frustrating, and even more frustrating is that we have had like seven attempts to start one, and each of these lead to nothing. So I would be perfectly happy to give a free hand, write access to the repo and a full directory in the distribution to implement one. Once there is a framework, I am sure many people would be willing to contribute tests. More comments below. On Oct 2, 2010, at 5:51 AM, Sebastian Rose wrote: Hi, I thought about testing again recently. This is something, that never really got started. For a reason: there's no framework for testing. I therefore wrote a very rough proposal, found on http://github.com/SebastianRose/org-test The idea is, to provide two simple commands: * org-test-test-current-defun will search for tests for the defun point is in or behind (`beginning-of-defun') and execute them surrounded by (let ((select (or selector ^org)) (deactivate-mark nil)) (save-excursion (save-match-data * org-test-test-buffer-file will search for tests for the entire file and execute them the same way. FIrst: I have *no* clue about testing. Second, I am surprised that you want to structure it by function. I would have thought that it could be structure by file at the most. And then there will be tests that involve code from many files. But I guess If you use one of these commands, all currently registered ERT tests are deleted, and files are reloaded (since you're likely to work on the tests, too). To repeat the tests without reloading, you will use the ERT commands like `ert-results-rerun-all-tests', bound to `r' in the ERT results buffer. I choose ERT (git clone http://github.com/ohler/ert.git) because that's likely to go into Emacs core (or elpa.gnu.org). The idea is to search the directory structure from the current source file upwards for a directory named tests/ if it exists. Else ask the user. Similar to what `add-change-log-entry' does. Below that directory, a tree like the source tree exists: project +-- lisp/ | +-- a.el | `-- b/ | +-- b.el | `-- tests/ +-- a.el/ | +-- tests.el | `-- a-defun.el `-- b/ +-- b.el/ +-- tests.el `-- b-defun.el If this setup exists, when editing defun-x in lisp/a.el, `M-x org-test-test-current-defun' will load tests/a.el/defun-x.el (fallback: tests.el there) and execute all tests with selector ^a-defun. Well, OK, this is fine. But under a.el and b.el there should also be general tests that are not function dependent, and there should be a place to put tests that you do not want to assign to a specific file. We do have a testing directory already, you can use that. I would prefer the tests to be in testing, not in lisp/testing if possible. I would like to have the lisp directory contain only code. If possible. It would be OK to have a lisp subdirectory in testing, just as it would be OK to have contrib/lisp in testing for the contributed packages. PLEASE, go ahead. I do not think you have write access yet on repo - give me your user name and I'll activate you. - Carsten `M-x org-test-test-buffer-file' in that same source file will load all *.el files in tests/a.el/ and execute all ERT tests for selector ^a. Thus tests for org-mode/lisp/org-protocol.el will be searched in the directory org-mode/tests/lisp/org-protocol.el/*.el Once the basic route of testing is clear, I'd like to translate the existing tests for org-html.el to work with ERT, which will involve writing more tools (create output buffers, compare output with control files using ediff etc.). I know Lennart Borgman has wrote that stuff for nXhtml already. I hope we can use his stuff and help here. The directory org-mode/lisp/tests/ would not need to be part of the official Org mode package. It could as well be checked out separately, if tests is part of org-mode/lisp/.gitignore (e.g.). Any thoughts? Sebastian ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Timestamps Agenda
I just noticed today that the agenda is now only showing the *first* timestamp in any headline, whether active or inactive. I'm not sure when this changed, I'm running 7.01e. I found that ability valuable, so I suspect a bug? Example: * Testing multiples 2010-10-02 Sat 05:31 2010-10-02 Sat 06:31 2010-10-02 Sat 07:31 [2010-10-02 Sat 08:31] [2010-10-02 Sat 09:31] [2010-10-02 Sat 10:31] When the example is loaded in agenda, and log mode turned on and then optionally inactive timestamps enabled, only the first timestamp is displayed. Thanks. -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3 ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Testing --- again...
Carsten Dominik carsten.domi...@gmail.com writes: Hi Sebastian, the lack of a testing suite for Org-mode is really frustrating, and even more frustrating is that we have had like seven attempts to start one, and each of these lead to nothing. So I would be perfectly happy to give a free hand, write access to the repo and a full directory in the distribution to implement one. Once there is a framework, I am sure many people would be willing to contribute tests. There was no support for testing in Emacs and I could not see something coming up. I guess that was one of the main reasons, that nothing happened. The existing tests use a undocumented framework wich consists of many source files itself, so that I was not able to get my head around that in half an hour (which is by far too long for most of us). I asked on emacs-devel and Stefan Monier told me that there was some consensus that ERT _should_ go into Emacs (24?) or at least to elpa.gnu.org. Christian Ohlert already sprang into action, so I'm optimistic that ERT is the right choice on the long run. So. The framework will be ERT. I'll just right a few commands and functions that make it _dead simple to right and execute tests_. More comments below. On Oct 2, 2010, at 5:51 AM, Sebastian Rose wrote: Hi, I thought about testing again recently. This is something, that never really got started. For a reason: there's no framework for testing. I therefore wrote a very rough proposal, found on http://github.com/SebastianRose/org-test The idea is, to provide two simple commands: * org-test-test-current-defun will search for tests for the defun point is in or behind (`beginning-of-defun') and execute them surrounded by (let ((select (or selector ^org)) (deactivate-mark nil)) (save-excursion (save-match-data * org-test-test-buffer-file will search for tests for the entire file and execute them the same way. FIrst: I have *no* clue about testing. Second, I am surprised that you want to structure it by function. I would have thought that it could be structure by file at the most. And then there will be tests that involve code from many files. It's both actually (see below). But a simple function could easily have 5 or more invariants. For each invariant a test should be written. That makes 5 tests. Having those (_optional_) per function test files will help finding certain test easily. Some functions will also need lot's of other test code, e.g. let bindings that emulate different setups or code that creates temporary directory structures (publishing) and the like. Naming (again: optionally) files like the functions they are written for and putting them into a directory named after the code file makes things easy to find --- even without docs. ... The idea is to search the directory structure from the current source file upwards for a directory named tests/ if it exists. Else ask the user. Similar to what `add-change-log-entry' does. Below that directory, a tree like the source tree exists: project +-- lisp/ | +-- a.el | `-- b/ | +-- b.el | `-- tests/ +-- a.el/ | +-- tests.el | `-- a-defun.el `-- b/ +-- b.el/ +-- tests.el `-- b-defun.el If this setup exists, when editing defun-x in lisp/a.el, `M-x org-test-test-current-defun' will load tests/a.el/defun-x.el (fallback: tests.el there) and execute all tests with selector ^a-defun. Well, OK, this is fine. But under a.el and b.el there should also be general tests that are not function dependent, and there should be a place to put tests that you do not want to assign to a specific file. That's what tests.el is for currently (besides that it is the fallback for function tests). `org-test-test-buffer-file' simply loads _all_ *.el files in a file's test directory. With prefix argument, it loads tests.el only. We do have a testing directory already, you can use that. I would prefer the tests to be in testing, not in lisp/testing if possible. I would like to have the lisp directory contain only code. If possible. That's already possible. The directory tests (will rename that to testing) is searched in the same directory as `buffer-file-name' and from there up the directory tree. It could be place entirely outside the project tree. It would be OK to have a lisp subdirectory in testing, just as it would be OK to have contrib/lisp in testing for the contributed packages. That's what it has to be like (it is). We couldn't use the autmatic test search otherwise. E.g. emacs/lisp/ has many sub-directories each of which could hold files with the same basename (in theory). The above graph was wrong, sorry. This is the current structure: ... `-- tests/ +-- lisp/ +-- a.el/ | +-- tests.el | `--
[Orgmode] Re: Testing --- again...
Carsten Dominik carsten.domi...@gmail.com writes: It would be OK to have a lisp subdirectory in testing, just as it would be OK to have contrib/lisp in testing for the contributed packages. That's what it is like. You probably did not notice, because org-test.el is supposed to live inside testing/, so it's not obvious. Sebastian ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] bug: babel: Export of temporary buffers fails
Hello, Export of temporary buffers with babel src blocks fails. Line 118 of ob-exp.el has (set-buffer (get-file-buffer org-current-export-file)) But the value of org-current-exp-file is nil for a temporary buffer. The following commit brought in that change. commit efdf78172d9f7c0070c781d136a9b49a2a56fcc4 Author: Eric Schulte schulte.e...@gmail.com Date: Sat Sep 18 19:01:49 2010 -0600 ob-exp: resolving code block parameters in the original file on export * lisp/ob-exp.el (org-babel-exp-src-blocks): now switching back to the original file before resolving code block parameters to ensure headline and buffer wide parameters are taken into consideration when only a narrowed portion of the file is exported HTH, Puneeth ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Testing --- again...
On Oct 2, 2010, at 5:01 PM, Sebastian Rose wrote: Carsten Dominik carsten.domi...@gmail.com writes: It would be OK to have a lisp subdirectory in testing, just as it would be OK to have contrib/lisp in testing for the contributed packages. That's what it is like. You probably did not notice, because org-test.el is supposed to live inside testing/, so it's not obvious. OK. You can also rename testing to tests or whatever is convenient. I have given you push access. - Carsten ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] bug: babel: Export of temporary buffers fails
Hi Puneeth, I believe that export is only allowed from buffers visiting files, when I tried to reproduce your problem exporting from a buffer without a file name I get the following error message (error Need a file name to be able to export) which is thrown by org-latex, org-docbook, or org-html on attempted export. Unless I'm missing something, it is not a problem that Babel expects org-current-export-file to have a value. Best -- Eric Puneeth puncha...@gmail.com writes: Hello, Export of temporary buffers with babel src blocks fails. Line 118 of ob-exp.el has (set-buffer (get-file-buffer org-current-export-file)) But the value of org-current-exp-file is nil for a temporary buffer. The following commit brought in that change. commit efdf78172d9f7c0070c781d136a9b49a2a56fcc4 Author: Eric Schulte schulte.e...@gmail.com Date: Sat Sep 18 19:01:49 2010 -0600 ob-exp: resolving code block parameters in the original file on export * lisp/ob-exp.el (org-babel-exp-src-blocks): now switching back to the original file before resolving code block parameters to ensure headline and buffer wide parameters are taken into consideration when only a narrowed portion of the file is exported HTH, Puneeth ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Testing --- again...
Hi, This is exciting. Rather than impose a complete directory/layout schema before-hand I'd lean towards starting with a little more chaos and then letting the structure of the test directory develop /naturally/. From the discussion below it sounds like an initial structure of testing/lisp/ testing/contrib/lisp/ may make sense, reserving the top level for meta testing stuff, like functions for running tests, common fixtures, example files, etc... I have two questions. 1) while waiting for ert to be included into Emacs, should we include an ert distribution as part of the Org-mode repository (maybe using git sub-modules) or should we just agree that users should have a certain version of ert installed locally? I'm honestly not sure which of these options sounds preferable. 2) should the initial population of the testing/ directory take place in a separate branch of the repository or in the master branch? Again I don't know which I would prefer, branches add complication but could result in cleaner commit histories. Best -- Eric Carsten Dominik carsten.domi...@gmail.com writes: Hi Sebastian, the lack of a testing suite for Org-mode is really frustrating, and even more frustrating is that we have had like seven attempts to start one, and each of these lead to nothing. So I would be perfectly happy to give a free hand, write access to the repo and a full directory in the distribution to implement one. Once there is a framework, I am sure many people would be willing to contribute tests. More comments below. On Oct 2, 2010, at 5:51 AM, Sebastian Rose wrote: Hi, I thought about testing again recently. This is something, that never really got started. For a reason: there's no framework for testing. I therefore wrote a very rough proposal, found on http://github.com/SebastianRose/org-test The idea is, to provide two simple commands: * org-test-test-current-defun will search for tests for the defun point is in or behind (`beginning-of-defun') and execute them surrounded by (let ((select (or selector ^org)) (deactivate-mark nil)) (save-excursion (save-match-data * org-test-test-buffer-file will search for tests for the entire file and execute them the same way. FIrst: I have *no* clue about testing. Second, I am surprised that you want to structure it by function. I would have thought that it could be structure by file at the most. And then there will be tests that involve code from many files. But I guess If you use one of these commands, all currently registered ERT tests are deleted, and files are reloaded (since you're likely to work on the tests, too). To repeat the tests without reloading, you will use the ERT commands like `ert-results-rerun-all-tests', bound to `r' in the ERT results buffer. I choose ERT (git clone http://github.com/ohler/ert.git) because that's likely to go into Emacs core (or elpa.gnu.org). The idea is to search the directory structure from the current source file upwards for a directory named tests/ if it exists. Else ask the user. Similar to what `add-change-log-entry' does. Below that directory, a tree like the source tree exists: project +-- lisp/ | +-- a.el | `-- b/ | +-- b.el | `-- tests/ +-- a.el/ | +-- tests.el | `-- a-defun.el `-- b/ +-- b.el/ +-- tests.el `-- b-defun.el If this setup exists, when editing defun-x in lisp/a.el, `M-x org-test-test-current-defun' will load tests/a.el/defun-x.el (fallback: tests.el there) and execute all tests with selector ^a-defun. Well, OK, this is fine. But under a.el and b.el there should also be general tests that are not function dependent, and there should be a place to put tests that you do not want to assign to a specific file. We do have a testing directory already, you can use that. I would prefer the tests to be in testing, not in lisp/testing if possible. I would like to have the lisp directory contain only code. If possible. It would be OK to have a lisp subdirectory in testing, just as it would be OK to have contrib/lisp in testing for the contributed packages. PLEASE, go ahead. I do not think you have write access yet on repo - give me your user name and I'll activate you. - Carsten `M-x org-test-test-buffer-file' in that same source file will load all *.el files in tests/a.el/ and execute all ERT tests for selector ^a. Thus tests for org-mode/lisp/org-protocol.el will be searched in the directory org-mode/tests/lisp/org-protocol.el/*.el Once the basic route of testing is clear, I'd like to translate the existing tests for org-html.el to work with ERT, which will involve writing more tools (create output buffers, compare output with control files using ediff etc.). I know Lennart Borgman has wrote that
Re: [Orgmode] ELPA Howto
Jambunathan K kjambunat...@gmail.com writes:
I managed to create an elpa compatible tar for orgmode. Recording here
what I did in the hope that it will be useful.
Creating ELPA-compatible tar:
1. Add the enclosed changes to Makefile.
2. Create an ELPA-compatible tarfile with
$ make TAG=20100930 elpa
3. Copy the generated org-20100930.tar to the package server
That's great,
and it looks like your Makefile patch even automates the process. I'd
vote that this to be included into the core and that we begin supporting
an elpa-installable version of org-mode tracking the latest named
release. If possible I think it'd be great to add a git post-commit
hook which could maintain a second elpa org-mode package tracking the
latest git HEAD, although I'm not sure if this is possible and it may
place overmuch burden on the repo.or.cz and the elpa servers.
ELPA Server-side setup:
I think we can ignore the server-side setup, since that should be
handled by the elpa server at tromney or gnu.org. Is this correct?
[...]
An Observation:
package.el generates an 'org-autoloads.el' as part of compilation and
loads the same as part of activation. This means that autoloads such as
'org-agenda' gets served from the newly installed package while
non-autoloads like 'org-overview' still point to the old installation.
This means that a restart of Emacs is necessary for the new changes to
take effect. I am not sure whether it is intended. But this behaviour
could surprise the user.
Noted, perhaps the user could somehow be instructed to run org-reload as
part of the ELPA update process, although I believe even org-reload
leaves some items un-re-initialized.
Cheers -- Eric
Jambunathan K.
Attachments:
X diff --git a/Makefile b/Makefile
X old mode 100644
X new mode 100755
X index 1c1f317..a84b62f
X --- a/Makefile
X +++ b/Makefile
X @@ -53,6 +53,9 @@ CP = cp -p
X # Name of the program to install info files
X INSTALL_INFO=install-info
X
X +
X +DOCSTRING = Outline-based notes management and organizer
X +
X ##--
X ## BELOW THIS LINE ON YOUR OWN RISK!
X ##--
X @@ -325,6 +328,14 @@ distfile:
X zip -r org-$(TAG).zip org-$(TAG)
X gtar zcvf org-$(TAG).tar.gz org-$(TAG)
X
X +elpa: install-info
X + $(MKDIR) org-$(TAG)
X + cp -r $(LISPFILES0) org-$(TAG)/
X + cp $(infodir)/dir org-$(TAG)
X + cp $(INFOFILES) org-$(TAG)
X + echo (define-package \org\ \$(TAG)\ \$(DOCSTRING)\)
org-$(TAG)/org-pkg.el
X + tar cf org-$(TAG).tar org-$(TAG) --remove-files
X +
X makerelease:
X @if [ X$(TAG) = X ]; then echo *** No tag ***; exit 1; fi
X ${MAKE} distfile
X
Jambunathan K.
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] publishing orgmode to a CMS
Read worg: http://orgmode.org/worg/org-blog-wiki.php On 1 October 2010 22:43, Erik Iverson er...@ccbr.umn.edu wrote: Does anyone have any general advice or comments regarding the publishing of org-mode documents to a CMS? I'm thinking of the case where I have HTML files generated by Org-mode, and want to publish it Worg-style, but would prefer to publish to a system with comments/RSS/etc. If anyone has done that, I'd love to hear your experience, which CMS software you chose, and how it is working for you. Thanks, Erik ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Tips for writing lecture notes in org-beamer?
On Fri, 1 Oct 2010 15:35:00 -0500, John Hendy jw.he...@gmail.com wrote: Eric, Per Bastien, you put the file wherever, but you link to the file at http://orgmode.org/worg/sources/path/to/file/file.org. For example: [...] Hope that helps, John It does. Thanks. I've updated the tutorial on Worg to use a direct http: link for the footnote entry. -- Eric S Fraga GnuPG: 8F5C 279D 3907 E14A 5C29 570D C891 93D8 FFFC F67D ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Testing --- again...
Eric Schulte schulte.e...@gmail.com writes: Hi, This is exciting. Rather than impose a complete directory/layout schema before-hand I'd lean towards starting with a little more chaos and then letting the structure of the test directory develop /naturally/. From the discussion below it sounds like an initial structure of testing/lisp/ testing/contrib/lisp/ I believe it makes sense enforcing rules. Many developers plus power users will want to be able to use the test system. No system is what we had in the past. The idea is, to have a system to automate the laoding of tests. How should a function like `org-test-test-current-defun' find the tests otherwise? sh$ cd org-mode sh$ find . -name '*.el' | wc -l 146 Also, we could provide services like setup temporary directories, buffers and files for tests. This cannot be automated in a save way, if there is no structure. The tests are written in elisp. Hence one could do whatever he likes ;) It's like Perl. You don't need to follow the conventions, but it will make your live easier (hopefully). Just what I think. may make sense, reserving the top level for meta testing stuff, like functions for running tests, common fixtures, example files, etc... I have two questions. 1) while waiting for ert to be included into Emacs, should we include an ert distribution as part of the Org-mode repository (maybe using git sub-modules) or should we just agree that users should have a certain version of ert installed locally? I'm honestly not sure which of these options sounds preferable. I thought about this, too. I guess not. Developers and users that want to test will be able to follow the current ERT git repo. But ERT is just 7 *.el files plus 1 texinfo file. An what I don't know is: How would git submodules work? 2) should the initial population of the testing/ directory take place in a separate branch of the repository or in the master branch? Again I don't know which I would prefer, branches add complication but could result in cleaner commit histories. I'll start on a branch first and constantly rebase as long as the structure evolves. The first simple commit will be what you can see on github, with some doc strings adjusted. Sebastian Best -- Eric Carsten Dominik carsten.domi...@gmail.com writes: Hi Sebastian, the lack of a testing suite for Org-mode is really frustrating, and even more frustrating is that we have had like seven attempts to start one, and each of these lead to nothing. So I would be perfectly happy to give a free hand, write access to the repo and a full directory in the distribution to implement one. Once there is a framework, I am sure many people would be willing to contribute tests. More comments below. On Oct 2, 2010, at 5:51 AM, Sebastian Rose wrote: Hi, I thought about testing again recently. This is something, that never really got started. For a reason: there's no framework for testing. I therefore wrote a very rough proposal, found on http://github.com/SebastianRose/org-test The idea is, to provide two simple commands: * org-test-test-current-defun will search for tests for the defun point is in or behind (`beginning-of-defun') and execute them surrounded by (let ((select (or selector ^org)) (deactivate-mark nil)) (save-excursion (save-match-data * org-test-test-buffer-file will search for tests for the entire file and execute them the same way. FIrst: I have *no* clue about testing. Second, I am surprised that you want to structure it by function. I would have thought that it could be structure by file at the most. And then there will be tests that involve code from many files. But I guess If you use one of these commands, all currently registered ERT tests are deleted, and files are reloaded (since you're likely to work on the tests, too). To repeat the tests without reloading, you will use the ERT commands like `ert-results-rerun-all-tests', bound to `r' in the ERT results buffer. I choose ERT (git clone http://github.com/ohler/ert.git) because that's likely to go into Emacs core (or elpa.gnu.org). The idea is to search the directory structure from the current source file upwards for a directory named tests/ if it exists. Else ask the user. Similar to what `add-change-log-entry' does. Below that directory, a tree like the source tree exists: project +-- lisp/ | +-- a.el | `-- b/ | +-- b.el | `-- tests/ +-- a.el/ | +-- tests.el | `-- a-defun.el `-- b/ +-- b.el/ +-- tests.el `-- b-defun.el If this setup exists, when editing defun-x in lisp/a.el, `M-x org-test-test-current-defun' will load tests/a.el/defun-x.el (fallback: tests.el there) and execute all tests with selector ^a-defun.
Re: [Orgmode] bug: babel: Export of temporary buffers fails
Eric Schulte schulte.e...@gmail.com writes: Hi Puneeth, I believe that export is only allowed from buffers visiting files, when I tried to reproduce your problem exporting from a buffer without a file name I get the following error message (error Need a file name to be able to export) which is thrown by org-latex, org-docbook, or org-html on attempted export. Unless I'm missing something, it is not a problem that Babel expects org-current-export-file to have a value. Best -- Eric Puneeth puncha...@gmail.com writes: Hello, Export of temporary buffers with babel src blocks fails. Line 118 of ob-exp.el has (set-buffer (get-file-buffer org-current-export-file)) But the value of org-current-exp-file is nil for a temporary buffer. The following commit brought in that change. commit efdf78172d9f7c0070c781d136a9b49a2a56fcc4 Author: Eric Schulte schulte.e...@gmail.com Date: Sat Sep 18 19:01:49 2010 -0600 ob-exp: resolving code block parameters in the original file on export * lisp/ob-exp.el (org-babel-exp-src-blocks): now switching back to the original file before resolving code block parameters to ensure headline and buffer wide parameters are taken into consideration when only a narrowed portion of the file is exported Usually an Org file NAME.org is exported to NAME.html, NAME.txt and so forth. You can still export to a temporary buffer (`A' instead of `a', `H' instead of `h') ... HTH Sebastian ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Testing --- again...
Hi Sebastian, Sebastian Rose sebastian_r...@gmx.de writes: Eric Schulte schulte.e...@gmail.com writes: Hi, This is exciting. Rather than impose a complete directory/layout schema before-hand I'd lean towards starting with a little more chaos and then letting the structure of the test directory develop /naturally/. From the discussion below it sounds like an initial structure of testing/lisp/ testing/contrib/lisp/ I believe it makes sense enforcing rules. Many developers plus power users will want to be able to use the test system. No system is what we had in the past. The idea is, to have a system to automate the laoding of tests. How should a function like `org-test-test-current-defun' find the tests otherwise? sh$ cd org-mode sh$ find . -name '*.el' | wc -l 146 Also, we could provide services like setup temporary directories, buffers and files for tests. This cannot be automated in a save way, if there is no structure. The tests are written in elisp. Hence one could do whatever he likes ;) It's like Perl. You don't need to follow the conventions, but it will make your live easier (hopefully). Just what I think. Point well taken, I suppose my point is more a matter of personal taste, and I fully understand if we disagree and would yield to your judgment as you've put more thought into this. But having said that here's my thoughts and opinions :) Could we just load every test in tests/lisp by default, and then use the existing `ert' selection method to select and run tests. For example if we enforce our conventions on the level of test function name rather than on file name, we could (I believe) do something like the following. Say every test for a particular function (say org-export) includes that name of that function in the test name (say test-org-export), then we could use something simple like the following to run the tests for the current function (i.e. function around the point) --8---cut here---start-8--- (defun org-test-current-function () Test the current function. (ert (format %S (which-function --8---cut here---end---8--- This way we could maintain a much simpler directory structure inside of tests/ (or testing/) in which we don't need a separate file name for every function, but rather maybe one test file per elisp file (e.g. test-ob.el for ob.el), and possibly other files for tests organized around concepts that span multiple files (e.g. test-blocks.el or somesuch). I may well be misunderstanding the framework you are proposing, so maybe the best thing to do is to just get started and then see how things develop. BTW: back when I worked on ruby-on-rails projects I developed jump.el [1] for jumping between functions and their tests, I could probably fairly easily apply this to the org-mode repo if that's desirable. may make sense, reserving the top level for meta testing stuff, like functions for running tests, common fixtures, example files, etc... I have two questions. 1) while waiting for ert to be included into Emacs, should we include an ert distribution as part of the Org-mode repository (maybe using git sub-modules) or should we just agree that users should have a certain version of ert installed locally? I'm honestly not sure which of these options sounds preferable. I thought about this, too. I guess not. Developers and users that want to test will be able to follow the current ERT git repo. But ERT is just 7 *.el files plus 1 texinfo file. An what I don't know is: How would git submodules work? using git submodules we could specify a location (e.g. tests/ert) and a version (some particular git commit) for the org-mode repository. Then running git submodule init git submodule update would checkout the appropriate version of ert to that location. Users who don't want to run tests could just never run the two above commands and shouldn't notice any difference aside from a .gitmodules file in the base of their org-mode repo. 2) should the initial population of the testing/ directory take place in a separate branch of the repository or in the master branch? Again I don't know which I would prefer, branches add complication but could result in cleaner commit histories. I'll start on a branch first and constantly rebase as long as the structure evolves. The first simple commit will be what you can see on github, with some doc strings adjusted. Great, when I get a chance I'll check it out and try to write a couple of simple Babel tests. Cheers -- Eric Sebastian Best -- Eric Carsten Dominik carsten.domi...@gmail.com writes: Hi Sebastian, the lack of a testing suite for Org-mode is really frustrating, and even more frustrating is that we have had like seven attempts to start one, and each of these lead to nothing. So I would be perfectly happy to give a
Re: [Orgmode] Re: Testing --- again...
Eric Schulte schulte.e...@gmail.com writes: [...] Could we just load every test in tests/lisp by default, and then use the existing `ert' selection method to select and run tests. For example if we enforce our conventions on the level of test function name rather than on file name, we could (I believe) do something like the following. Say every test for a particular function (say org-export) includes that name of that function in the test name (say test-org-export), then we could use something simple like the following to run the tests for the current function (i.e. function around the point) (defun org-test-current-function () Test the current function. (ert (format %S (which-function This way we could maintain a much simpler directory structure inside of tests/ (or testing/) in which we don't need a separate file name for every function, but rather maybe one test file per elisp file (e.g. test-ob.el for ob.el), and possibly other files for tests organized around concepts that span multiple files (e.g. test-blocks.el or somesuch). To illustrate my suggestions, I've thrown together a couple simple Babel tests roughly following this outline, currently up in the `schulte-testing' branch of the Org-mode repo. To try it out 1) load the testing/org-test.el file 2) run `org-load-tests' to load up the entire org-mode test suite 3) run `ert' to run the test suite. 4) or jump to the definition of `org-babel-get-src-block-info' and run `org-test-current-function' to just run the tests for that function Best -- Eric ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Testing --- again...
Eric Schulte schulte.e...@gmail.com writes: Hi Sebastian, Sebastian Rose sebastian_r...@gmx.de writes: Eric Schulte schulte.e...@gmail.com writes: Hi, This is exciting. Rather than impose a complete directory/layout schema before-hand I'd lean towards starting with a little more chaos and then letting the structure of the test directory develop /naturally/. From the discussion below it sounds like an initial structure of testing/lisp/ testing/contrib/lisp/ I believe it makes sense enforcing rules. Many developers plus power users will want to be able to use the test system. No system is what we had in the past. The idea is, to have a system to automate the laoding of tests. How should a function like `org-test-test-current-defun' find the tests otherwise? sh$ cd org-mode sh$ find . -name '*.el' | wc -l 146 Also, we could provide services like setup temporary directories, buffers and files for tests. This cannot be automated in a save way, if there is no structure. The tests are written in elisp. Hence one could do whatever he likes ;) It's like Perl. You don't need to follow the conventions, but it will make your live easier (hopefully). Just what I think. Point well taken, I suppose my point is more a matter of personal taste, and I fully understand if we disagree and would yield to your judgment as you've put more thought into this. But having said that here's my thoughts and opinions :) Could we just load every test in tests/lisp by default, and then use the existing `ert' selection method to select and run tests. For example if we enforce our conventions on the level of test function name rather than on file name, we could (I believe) do something like the following. Say every test for a particular function (say org-export) includes that name of that function in the test name (say test-org-export), then we could use something simple like the following to run the tests for the current function (i.e. function around the point) (defun org-test-current-function () Test the current function. (ert (format %S (which-function I have no function called `which-function' !? But yes, those prefixes are (and have to be) part of our standard. The entire Emacs elisp structure is build on that way of namespacing. It's basically working like that (but I used more lines to get to the function name...). All this is _not_ meant to get in the way of ERT. I just hope a) to add some support to get people started and b) provide some help and maintainance of that testing stuff. E.g. `org-test-run-tests (optional selector)' runs tests enclosed in (let ((deactivate-mark nil)) (save-excursion (save-match-data ;; ... run tests here ))) But yes, I guess the art is to do not too much. This way we could maintain a much simpler directory structure inside of tests/ (or testing/) in which we don't need a separate file name for every function, but rather maybe one test file per elisp file (e.g. test-ob.el for ob.el), and possibly other files for tests organized around concepts that span multiple files (e.g. test-blocks.el or somesuch). H - I see. But you'd still test single units of code, and a single unit of code lives in one source file, not in many source files. Even though many source files are involved, which is always the case when you execute code. I may well be misunderstanding the framework you are proposing, so maybe the best thing to do is to just get started and then see how things develop. OK. Same here :) I just pushed my little starter to a new branch ert-testing. Pooha, git always a little challenging in such rare situations :) BTW: back when I worked on ruby-on-rails projects I developed jump.el [1] for jumping between functions and their tests, I could probably fairly easily apply this to the org-mode repo if that's desirable. That's such a helpful little tool I think of! I'll check that, too :) I just created the branch ert-testing and pushed my little starter. may make sense, reserving the top level for meta testing stuff, like functions for running tests, common fixtures, example files, etc... I have two questions. 1) while waiting for ert to be included into Emacs, should we include an ert distribution as part of the Org-mode repository (maybe using git sub-modules) or should we just agree that users should have a certain version of ert installed locally? I'm honestly not sure which of these options sounds preferable. I thought about this, too. I guess not. Developers and users that want to test will be able to follow the current ERT git repo. But ERT is just 7 *.el files plus 1 texinfo file. An what I don't know is: How would git submodules work? using git submodules we could specify a location (e.g. tests/ert) and a version (some particular git commit) for the org-mode repository. Then running git submodule init
[Orgmode] arranging and publishing music with Org-mode and lilypond
Dear all, I believe that many members of this list with an interest in music (notation/composition) might find the http://lilypond.org project addictive (in the nicest possible manner): the concept is rather similar to writing TeX, there is very good Emacs support (if you know where to look), it is all OpenSource, there is extensive documentation (in LaTeX format with embedded lilypond snippets), the print quality is excellent. I mention this because while arranging some piece of music recently, I noticed that Org-mode might be helpful in this context - it is probably already possible by tweaking org-babel a bit: lilypond encourages the user to structure music in a way that lends itself rather naturally to processing with Org-mode - you can assign a theme, a few bar with notes or even whole voices to variables and use them repeatedly. And imagine using Org-mode's outline capabilities to structure a piece of music. Exporting an org-file with lilypond-snippets in it to PDF or HTML might also be an interesting option. I have not yet put any effort into it and just wanted to find out if anybody apart from me finds the combination of Org-mode and lilypond (potentially) exciting. Warm regards, Stefan -- Dr. Stefan Vollmar, Dipl.-Phys. Head of IT group Max-Planck-Institut für neurologische Forschung Gleuelerstr. 50, 50931 Köln, Germany Tel.: +49-221-4726-213 FAX +49-221-4726-298 Tel.: +49-221-478-5713 Mobile: 0160-93874279 Email: voll...@nf.mpg.de http://www.nf.mpg.de smime.p7s Description: S/MIME cryptographic signature ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: arranging and publishing music with Org-mode and lilypond
Hi Stefan Maybe a bit OT but I find nted useful for my musical needs: http://vsr.informatik.tu-chemnitz.de/~jan/nted/nted.xhtml because it both plays and shows music quite well. [I use it to teach singing] Does lilypond play also? One small gripe with nted is that it exports but does not import lilypond. Rustom ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] bug: babel: Export of temporary buffers fails
Hi Eric, You can still export to a temporary buffer (`A' instead of `a', `H' instead of `h') ... Yes. And this fails when there is an org-babel src block in the buffer. -- Puneeth ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: arranging and publishing music with Org-mode and lilypond
Rustom Mody rustompm...@gmail.com wrote: Hi Stefan Maybe a bit OT but I find nted useful for my musical needs: http://vsr.informatik.tu-chemnitz.de/~jan/nted/nted.xhtml because it both plays and shows music quite well. [I use it to teach singing] Does lilypond play also? One small gripe with nted is that it exports but does not import lilypond. lilypond is a batch processor: it can produce MIDI files but it does not play them. Nick ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] org-capture: file to top level with prepend
Hi!
I'm trying to capture and file an entry as an top-level entry as first entry
in an org file without config at the beginning (no #+).
This leads to filing the entry as _second_ headline in the org file.
The template is:
(z test entry (file ~/Data/z.org) * %^{Note} %t :NOTE:\n %?
:prepend t)
I think this is due to jumping over lines starting with #+ at the
beginning of the org file
(line 715 in org-capture.el (org-capture-place-entry)).
My file has no config header and starts with the first headline. Calling
outline-next-heading
in this situation leads to jumping to the second headline in the file.
The appended patch fixes this problem by checking if we are on a headline
and then skips jumping to next headline.
Regards
Thomas
patch
Description: Binary data
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] ELPA Howto
Hello Eric
Eric Schulte schulte.e...@gmail.com writes:
Jambunathan K kjambunat...@gmail.com writes:
I managed to create an elpa compatible tar for orgmode. Recording here
what I did in the hope that it will be useful.
Creating ELPA-compatible tar:
1. Add the enclosed changes to Makefile.
2. Create an ELPA-compatible tarfile with
$ make TAG=20100930 elpa
3. Copy the generated org-20100930.tar to the package server
That's great,
and it looks like your Makefile patch even automates the process. I'd
vote that this to be included into the core and that we begin supporting
an elpa-installable version of org-mode tracking the latest named
release. If possible I think it'd be great to add a git post-commit
hook which could maintain a second elpa org-mode package tracking the
latest git HEAD, although I'm not sure if this is possible and it may
place overmuch burden on the repo.or.cz and the elpa servers.
One could host N latest snapshots and expunge the rest. The snapshots
could be published either daily or weekly etc etc. This could be hooked
to existing cron job.
Just publishing the snapshot itself would help problems surface
faster. The submitter of the problem could temporarily revert to an
earlier stable snapshot and wait till the next snapshot arrives (hoping
that his problem is addressed).
If a snapshot is 'truly' unstable maintainers could intervene and hand
publish the archive.
ELPA Server-side setup:
I think we can ignore the server-side setup, since that should be
handled by the elpa server at tromney or gnu.org. Is this correct?
[...]
One could host packages on http://orgmode.org, In that case my notes
will serve as a good starting point.
Btw hosting the packages (also) on orgmode would give better control and
distribution.
An Observation:
package.el generates an 'org-autoloads.el' as part of compilation and
loads the same as part of activation. This means that autoloads such as
'org-agenda' gets served from the newly installed package while
non-autoloads like 'org-overview' still point to the old installation.
This means that a restart of Emacs is necessary for the new changes to
take effect. I am not sure whether it is intended. But this behaviour
could surprise the user.
Noted, perhaps the user could somehow be instructed to run org-reload as
part of the ELPA update process, although I believe even org-reload
leaves some items un-re-initialized.
Cheers -- Eric
Jambunathan K.
Attachments:
X diff --git a/Makefile b/Makefile
X old mode 100644
X new mode 100755
X index 1c1f317..a84b62f
X --- a/Makefile
X +++ b/Makefile
X @@ -53,6 +53,9 @@ CP = cp -p
X # Name of the program to install info files
X INSTALL_INFO=install-info
X
X +
X +DOCSTRING = Outline-based notes management and organizer
X +
X ##--
X ## BELOW THIS LINE ON YOUR OWN RISK!
X ##--
X @@ -325,6 +328,14 @@ distfile:
Xzip -r org-$(TAG).zip org-$(TAG)
Xgtar zcvf org-$(TAG).tar.gz org-$(TAG)
X
X +elpa: install-info
X + $(MKDIR) org-$(TAG)
X + cp -r $(LISPFILES0) org-$(TAG)/
X + cp $(infodir)/dir org-$(TAG)
X + cp $(INFOFILES) org-$(TAG)
X + echo (define-package \org\ \$(TAG)\ \$(DOCSTRING)\)
org-$(TAG)/org-pkg.el
X + tar cf org-$(TAG).tar org-$(TAG) --remove-files
X +
X makerelease:
X@if [ X$(TAG) = X ]; then echo *** No tag ***; exit 1; fi
X${MAKE} distfile
X
Jambunathan K.
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
