Hello, I just upgraded from 7.6 to 7.9.3. I went through the installation process as described in [1]. I dicovered two things, which I do not know how to solve on my own: (1) Clock in/out just by toggeling the task state does not work anymore. For starting and stopping the clock I have the code from Sacha Chua [2] in my dot-emacs. I suppose, that this does not work any more with the new org-code. As I frequently rely on the clock I would be glad to solve the problem. Does someone have a hint for me? (2) I did some tests with the org-odt-exporter, which where successful in case of a small test file but failed with some of my daily used file. In one case the emacs message buffer seemed to contain the whole export output (pasting just a few lines here) -------------------------------8<------------------------------------ #(" " 0 10 (face org-indent)) wrap-prefix #(" " 0 10 (face org-indent))) 48810 49241 (fontified nil org-category "hfk-design-durch-aneignung" line-prefix #(" " 0 10 (face org-indent)) wrap-prefix #(" " 0 13 (face org-indent))) 49241 49242 (fontified nil org-category "hfk-design-durch-aneignung" line-prefix #(" " 0 10 (face org-indent)) wrap-prefix #(" " 0 10 (face org-indent))) 49242 49340 (fontified nil org-category "hfk-design-durch-aneignung" line-prefix #(" " 0 10 (face org-indent)) wrap-prefix #(" " 0 13 (face org-indent))) 49341 49361 (original-indentation 0) 49361 49362 (fontified nil org-category "hfk-design-durch-aneignung" line-prefix #(" " 0 10 (face org-indent)) wrap-prefix #(" " 0 13 (face org-indent))) 49362 49374 (fontified nil org-category "hfk-design-durch-aneignung" line-prefix #( -------------------------------8<------------------------------------ I did get nothing else and wonder, what's the best way to debug such a case? Greetings Martin [1] <http://orgmode.org/manual/Installation.html> [2] <http://sachachua.com/blog/2007/12/clocking-time-with-emacs-org/> -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | G. Martin Butz, mb@mkblog.org, 0421 98749324, www.mkblog.org | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hi Martin, Martin Butz <mb@mkblog.org> writes: > (1) Clock in/out just by toggeling the task state does not work anymore. > For starting and stopping the clock I have the code from Sacha Chua [2] > in my dot-emacs. I suppose, that this does not work any more with the > new org-code. As I frequently rely on the clock I would be glad to solve > the problem. Does someone have a hint for me? You can add a function to `org-after-todo-state-change-hook', which will call `org-clock-in/out' at some point. But better to ask Sacha since this is her code. > (2) I did some tests with the org-odt-exporter, which where successful > in case of a small test file but failed with some of my daily used file. > In one case the emacs message buffer seemed to contain the whole export > output (pasting just a few lines here) > #(" " 0 10 (face org-indent)) wrap-prefix #(" " 0 10 > (face org-indent))) 48810 49241 (fontified nil org-category > "hfk-design-durch-aneignung" line-prefix #(" " 0 10 (face > org-indent)) wrap-prefix #(" " 0 13 (face org-indent))) > 49241 49242 (fontified nil org-category "hfk-design-durch-aneignung" > line-prefix #(" " 0 10 (face org-indent)) wrap-prefix #(" > " 0 10 (face org-indent))) 49242 49340 (fontified nil org-category > "hfk-design-durch-aneignung" line-prefix #(" " 0 10 (face > org-indent)) wrap-prefix #(" " 0 13 (face org-indent))) > 49341 49361 (original-indentation 0) 49361 49362 (fontified nil > org-category "hfk-design-durch-aneignung" line-prefix #(" " 0 > 10 (face org-indent)) wrap-prefix #(" " 0 13 (face > org-indent))) 49362 49374 (fontified nil org-category > "hfk-design-durch-aneignung" line-prefix #( > > I did get nothing else and wonder, what's the best way to debug such > a case? I suggest to bisect the .org source file until you find the part that prevents ODT exports. Best, -- Bastien
Martin Butz <mb@mkblog.org> writes:
> (2) I did some tests with the org-odt-exporter, which where successful
> in case of a small test file but failed with some of my daily used file.
> In one case the emacs message buffer seemed to contain the whole export
> output (pasting just a few lines here)
org-odt.el - The old exporter - hasn't changed much for most of one full
year. I wouldn't be surprised, if the problem is elsewhere.
If you can git bisect well and good.
Or
You can post the BEGINNING of stack trace. (Your stacktrace doesn't
seem to be from the beginning). Btw, it is not clear to me whether you
are getting a backtrace.
Or
Try minimal Emacs: emacs -L ~/src/org-mode/lisp -L ~/src/org-mode/contrib/lisp
I am willing to address whatever problem that you are seeing.
--
Thank you, Bastien and Jabunathan,
as often I failed to answer to the list and sent instead private
messages back. Sorry for that.
I will try to pinpoint the org-export-problem and deliver some more
detailed information.
Best
Martin
Am 09.01.2013 06:31, schrieb Jambunathan K:
> Martin Butz <mb@mkblog.org> writes:
>
>> (2) I did some tests with the org-odt-exporter, which where successful
>> in case of a small test file but failed with some of my daily used file.
>> In one case the emacs message buffer seemed to contain the whole export
>> output (pasting just a few lines here)
>
> org-odt.el - The old exporter - hasn't changed much for most of one full
> year. I wouldn't be surprised, if the problem is elsewhere.
>
> If you can git bisect well and good.
>
> Or
>
> You can post the BEGINNING of stack trace. (Your stacktrace doesn't
> seem to be from the beginning). Btw, it is not clear to me whether you
> are getting a backtrace.
>
> Or
>
> Try minimal Emacs: emacs -L ~/src/org-mode/lisp -L ~/src/org-mode/contrib/lisp
>
>
> I am willing to address whatever problem that you are seeing.
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| G. Martin Butz, mb@mkblog.org, 0421 98749324, www.mkblog.org |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hello K. Jambunathan,
(I guess Jambunathan is your sirname, but do not want to call you just "K").
one of the problems was my fault, I forgot to insert a "#+end_quote".
After completed the missing comment, all went well.
I encounter different problems, e.g. like an image link with missing
source. The exporter will not accept this. Also I had cases, where the
export will work, but LibreOffice will crash trying to load the
generated .odt-file. But I guess, this has nothing to do with org.
In another case the content.xml of the gererated .odt had some not
closed elements (LibreOffice gave an error message), which I could fix
and then repack the archive.
I now do at least have some means to cope with problems. Thanks for you
help.
Martin
Am 09.01.2013 06:31, schrieb Jambunathan K:
> Martin Butz <mb@mkblog.org> writes:
>
>> (2) I did some tests with the org-odt-exporter, which where successful
>> in case of a small test file but failed with some of my daily used file.
>> In one case the emacs message buffer seemed to contain the whole export
>> output (pasting just a few lines here)
>
> org-odt.el - The old exporter - hasn't changed much for most of one full
> year. I wouldn't be surprised, if the problem is elsewhere.
>
> If you can git bisect well and good.
>
> Or
>
> You can post the BEGINNING of stack trace. (Your stacktrace doesn't
> seem to be from the beginning). Btw, it is not clear to me whether you
> are getting a backtrace.
>
> Or
>
> Try minimal Emacs: emacs -L ~/src/org-mode/lisp -L ~/src/org-mode/contrib/lisp
>
>
> I am willing to address whatever problem that you are seeing.
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| G. Martin Butz, mb@mkblog.org, 0421 98749324, www.mkblog.org |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Butz <mb@mkblog.org> writes: > Hello K. Jambunathan, > > (I guess Jambunathan is your sirname, but do not want to call you just > "K"). No, don't do that :-). You will be addressing my father. Confusion is arises because of differences in naming across cultures. I live in India. In the state where I am from (Tamilnadu), we usually have just a single component to the name. i.e., there is no First, Middle or Last names and I really don't know what a "Surname" is. So "Jambunathan" is my given name. "K" is my Father's name that is abbreviated to just the initials. People usually call me "Jambu". > one of the problems was my fault, I forgot to insert a > "#+end_quote". After completed the missing comment, all went well. > > I encounter different problems, e.g. like an image link with missing > source. Try to narrow it down and pass across a simple snippet to me. I will be happy to fix it. You can also look at *Messages* buffer, you may get some clues. > The exporter will not accept this. Also I had cases, where the > export will work, but LibreOffice will crash trying to load the > generated .odt-file. But I guess, this has nothing to do with org. LibreOffice crashes usually when XML files are malformed. If you don't have rnc files, (use M-x rng-what-schema RET while in an XML file) then validation wouldn't catch errors. If you are running from git, rnc files are installed for you and you can do the following right within Emacs. 1. C-x C-f test.odt. Buffer will now be in archive-mode. 2. RET on content.xml and/or any of the other XML files/ 3. C-c C-n. nXML will tell you where validation has failed. This will give you clue on how to proceed further. It is quite possible that ODT exporter creates corrupt files. You can also run the exported file through any of the OpenDOcument validators in the cloud. They seem to come and go. So I will let you google around, instead of providing any pointers. See following node in the manual (info "(org) Validating OpenDocument XML") > In another case the content.xml of the gererated .odt had some not > closed elements (LibreOffice gave an error message), which I could fix > and then repack the archive. You should report this issue. I will be happy to fix. > I now do at least have some means to cope with problems. Thanks for > you help. --
Hi Jambunathan,
thanks for the information about your name. So now I know how I can
adress you - and not your father;)
As to the other very detailed infos about org-odt-export: Right now I
have some work to do, but will have a closer look probably next week...
Thanks a lot
Martin
Am 09.01.2013 21:19, schrieb Jambunathan K:
> Martin Butz <mb@mkblog.org> writes:
>
>> Hello K. Jambunathan,
>>
>> (I guess Jambunathan is your sirname, but do not want to call you just
>> "K").
>
> No, don't do that :-). You will be addressing my father.
>
> Confusion is arises because of differences in naming across cultures.
>
> I live in India. In the state where I am from (Tamilnadu), we usually
> have just a single component to the name. i.e., there is no First,
> Middle or Last names and I really don't know what a "Surname" is.
>
> So "Jambunathan" is my given name. "K" is my Father's name that is
> abbreviated to just the initials.
>
> People usually call me "Jambu".
>
>> one of the problems was my fault, I forgot to insert a
>> "#+end_quote". After completed the missing comment, all went well.
>>
>> I encounter different problems, e.g. like an image link with missing
>> source.
>
> Try to narrow it down and pass across a simple snippet to me. I will be
> happy to fix it. You can also look at *Messages* buffer, you may get
> some clues.
>
>> The exporter will not accept this. Also I had cases, where the
>> export will work, but LibreOffice will crash trying to load the
>> generated .odt-file. But I guess, this has nothing to do with org.
>
> LibreOffice crashes usually when XML files are malformed.
>
> If you don't have rnc files, (use M-x rng-what-schema RET while in an
> XML file) then validation wouldn't catch errors. If you are running from
> git, rnc files are installed for you and you can do the following right
> within Emacs.
>
> 1. C-x C-f test.odt. Buffer will now be in archive-mode.
> 2. RET on content.xml and/or any of the other XML files/
> 3. C-c C-n. nXML will tell you where validation has failed.
>
> This will give you clue on how to proceed further. It is quite possible
> that ODT exporter creates corrupt files.
>
> You can also run the exported file through any of the OpenDOcument
> validators in the cloud. They seem to come and go. So I will let you
> google around, instead of providing any pointers.
>
> See following node in the manual
>
> (info "(org) Validating OpenDocument XML")
>
>> In another case the content.xml of the gererated .odt had some not
>> closed elements (LibreOffice gave an error message), which I could fix
>> and then repack the archive.
>
> You should report this issue. I will be happy to fix.
>
>> I now do at least have some means to cope with problems. Thanks for
>> you help.
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| G. Martin Butz, mb@mkblog.org, 0421 98749324, www.mkblog.org |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~