Nicolas Goaziou writes:
> So, indeed, the second failing test appears. It should pass now (at
> least it does even on my compiled Org installation).
I confirm the fix, thank you very much.
> I think the others come from a file-error ("Opening output file").
I can see now why this happens: the
Achim Gratz writes:
> Well, that is likely because you run the test on uncompiled source,
> while I am running it on compiled orgmode... maybe one of these pesky
> byte-compiler warnings shouldn't have been ignored. I can't reproduce
> the 24 unexpected results, but they probably have a similar
Nicolas Goaziou writes:
>> [...]
>> 2 unexpected results:
>>FAILED test-org-export/export-scope
>>FAILED test-org-footnote/normalize-outside-org
>
> With your command, I was able to reproduce the first one (along with 24
> unexpected results), for which I have pushed a fix. I still don't
Hello,
Achim Gratz writes:
> Nicolas Goaziou writes:
>> I cannot reproduce any of them, interactively or in batch mode[1].
>
> This is the invocation (to be run in bash, like make would do):
>
> TMPDIR=/tmp/tmp-orgtest /usr/local/bin/emacs -batch -Q \
> -L lisp/ -L testing/ -L contrib/lisp \
>
Nicolas Goaziou writes:
> I cannot reproduce any of them, interactively or in batch mode[1].
This is the invocation (to be run in bash, like make would do):
TMPDIR=/tmp/tmp-orgtest /usr/local/bin/emacs -batch -Q \
-L lisp/ -L testing/ -L contrib/lisp \
--eval '(defconst org-release "7.8.03-Test"
"Sebastien Vauban"
writes:
> I don't understand why once there are 192 tests, once 130. I thought that the
> second figure was the total number of tests, hence should be stable over the
> test runs?
The number of available tests depend on the Babel languages that are
activated. One of those fail
Hello Achim,
Achim Gratz wrote:
> Two test failures in current HEAD:
>
> Test test-org-footnote/normalize-outside-org backtrace:
> org-footnote-in-valid-context-p()
> [...]
> normal-top-level()
> Test test-org-footnote/normalize-outside-org condition:
> (void-variable message-cite-prefix
Hello,
Achim Gratz writes:
> Two test failures in current HEAD:
I cannot reproduce any of them, interactively or in batch mode[1].
I'm not sure where they could come from.
Regards,
[1] Though, I have 8 unexpected failures there, but not related to
those described here.
--
Nicolas Goaziou
Two test failures in current HEAD:
--8<---cut here---start->8---
Test test-org-footnote/normalize-outside-org backtrace:
org-footnote-in-valid-context-p()
org-footnote-at-reference-p()
byte-code(\20\304\202 \305\n\306#\204\307\310\311\"\21\20
org-foo
Achim Gratz writes:
> It all works now when adding "testing/" to the load path. I'll add
> this to the default configuration in my Makefile fork.
I've improved the test invocation in my Makefile fork. It now starts
from a clean Emacs invocation withoutsite startup and loads the
configured Babe
Nicolas Goaziou writes:
> This should be fixed now. Thank you for reporting it.
I confirm the fix, testing is clean again, thank you very much.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Strome
Hello,
Achim Gratz writes:
> There's another patch by Nicolas that added a few test, one of which
> seems broken:
This should be fixed now. Thank you for reporting it.
Regards,
--
Nicolas Goaziou
Eric Schulte writes:
[...]
Thanks for your latest round of patches. It all works now when adding
"testing/" to the load path. I'll add this to the default configuration
in my Makefile fork. There's another patch by Nicolas that added a few
test, one of which seems broken:
OVERVIEW
Mark set
Te
Eric Schulte writes:
> My guess is that when I removed require statements for org-html and
> org-ascii from from test-org-html and test-org-exp, they removed some
> functionality not loaded by default in the test scripts. These should
> probably be added into the Makefile.
Unless someone can giv
Achim Gratz writes:
> Eric Schulte writes:
>> Moving forward on this point, many of the existing tests explicitly
>> `require' new Org-mode functionality (mainly language support for
>> testing code blocks execution). I do not think that tests should ever
>> be activating new packages changing
Eric Schulte writes:
> Moving forward on this point, many of the existing tests explicitly
> `require' new Org-mode functionality (mainly language support for
> testing code blocks execution). I do not think that tests should ever
> be activating new packages changing a users global environment.
Moving forward on this point, many of the existing tests explicitly
`require' new Org-mode functionality (mainly language support for
testing code blocks execution). I do not think that tests should ever
be activating new packages changing a users global environment.
For this reason I have just p
Tests for experimental org features (e.g. from contrib/ ) should expect
to fail when the user has not configured their inclusion into the
current setup. In other words, things like "(require org-element)"
should not break the test run, but instead just note that this test has
failed expectedly an
18 matches
Mail list logo
