[O] bug#23299: 25.1.50; org-timestamp-change: Invalid time zone specification: (nil nil nil)
Thanks for reporting the problem. As Eli suggested, it was a typo in org.el that was exposed by recent changes to encode-time. I installed into master the attached patch, which I think fixes the bug. From 313e98ceb078468498998305749b2790b7ba Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 20 Apr 2016 00:06:01 -0700 Subject: [PATCH] Fix org-timestamp-change typo MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Problem reported by Peter Münster (Bug#23299). * lisp/org/org.el (org-timestamp-change): Fix typo that relied on undocumented behavior in ‘encode-time’. In practice the old code used local time, so use that. --- lisp/org/org.el | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/lisp/org/org.el b/lisp/org/org.el index 3abf627..b0e1e20 100644 --- a/lisp/org/org.el +++ b/lisp/org/org.el @@ -17459,8 +17459,7 @@ org-timestamp-change (+ (if (eq org-ts-what 'hour) n 0) (nth 2 time0)) (+ (if (eq org-ts-what 'day) n 0)(nth 3 time0)) (+ (if (eq org-ts-what 'month) n 0) (nth 4 time0)) -(+ (if (eq org-ts-what 'year) n 0) (nth 5 time0)) -(nthcdr 6 time0))) +(+ (if (eq org-ts-what 'year) n 0) (nth 5 time0 (when (and (member org-ts-what '(hour minute)) extra (string-match "-\\([012][0-9]\\):\\([0-5][0-9]\\)" extra)) -- 2.5.5
Re: [O] ox-odt.el
On Tue, Apr 19 2016, Nicolas Goaziou wrote: > Hello, > > Colin Baxter writes: > >> The line >> >> (expand-file-name "../../etc/styles/" org-odt-lib-dir) ; git >> >> in the defconst org-odt-styles-dir-list at line 181 of ox-odt.el points to >> "git/org-mode/lisp/etc/styles/". Should it not point to >> "git/org-mode/etc/styles/"? This would be achieved by changing the line to >> >> (expand-file-name "../etc/styles/" org-odt-lib-dir) ; git > > Fixed. Thank you. > > Regards, Thank you.
Re: [O] Invalid-read-syntax
On Tue, Apr 19 2016, Nicolas Goaziou wrote: > Hello, > > Colin Baxter writes: > >> With the latest org-mode release_8.3.4-739-g7894129, I'm getting an lisp >> error >> (invalid-read-syntax "#"). This ocurs with emacs-25.1.50.1 and >> emacs-24.5.1. > > Could you provide an ECM? What command triggered that? > > Regards, I'm afraid I don't know what ECM means. If you can give me some more information, I'll have a go at providing it. The error is immediately triggered when I launch emacs. The offending lines in my ~/.emacs are just (add-to-list 'load-path (expand-file-name "~/git/org-mode/lisp")) (add-to-list 'load-path (expand-file-name "~/git/org-mode/contrib/lisp")) There are no errors if I use org-mode release_8.3.4-721-g16ad80. The error occurred first with release_8.3.4-739-g7894129 and is present also with release_8.3.4-743-g516bbf. The package ox-html looks a candidate for suspicion, perhaps. Best wishes, Colin.
[O] changing to IN-PROGRESS starts clocking it
How can I have a task which when I change its state from TODO or NEXT to IN-PROGRESS starts clocking it until its state is changed back from IN-PROGRESS to some other state, when the clocking will cease? Any ideas please? Thanks Sharon. -- A taste of linux = http://www.sharons.org.uk TGmeds = http://www.tgmeds.org.uk Debian 8.4, fluxbox 1.3.7, emacs 25.0.92 signature.asc Description: PGP signature
Re: [O] [PATCH] Make lexical eval default for elisp src blocks
Hello, John Kitchin writes: > Set default in `org-babel-default-header-args:emacs-lisp'. Add an > optional argument to the eval function. Applied. Thank you. However, it seems that some tests are now failing. I guess this is related to Babel calls, which are eval'ed as emacs-lisp source blocks. I have planned to change how Babel calls are evaluated during the next days. This may make the failures disappear. Meanwhile, we could force :lexical "no" in that case. WDYT? Regards, -- Nicolas Goaziou
Re: [O] tables, comment in one line, export to html
On Tuesday, 19 Apr 2016 at 19:54, Uwe Brauer wrote: > Cool, thanks very much I tried out > > | name | result | @@html:@@ > | Smith | 10 | @@html:@@ > > Which does almost all I want, it inserts an empty third column, but I > presume this cannot be changed? Without real hackery, not unless you want the comment construct to be part of the previous column in org? I.e. move the | before the @@ to the end of the line. -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.90.1, Org release_8.3.3-535-g7213aa
Re: [O] Bug: org-bibtex-read strips too many braces (8.3.4-39-ge0acd8-elpaplus)
On Tuesday, 19 Apr 2016 at 20:43, timor wrote:
> Yes. Looking at the BibTeX Files I am dealing with, the use of inner
> braces is usually justified (except for the example I gave, but it is
> not org-mode's job to correct poor BibTeX, I think). Therefore they
> should be kept intact when reading the field.
Inner braces need to be preserved as they are often there to protect
capitalisation, e.g. for TLAs and names like McDonald, but also for
compound names such as {van der Waals} which together form a single
component of a name. So it's not just the title that needs to be
treated carefully but other entries (author, editor, booktitle).
--
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.90.1, Org release_8.3.3-535-g7213aa
Re: [O] Bug: org-bibtex-read strips too many braces (8.3.4-39-ge0acd8-elpaplus)
2016-04-20 9:45 GMT+02:00 Eric S Fraga : > So it's not just the title that needs to be > treated carefully but other entries (author, editor, booktitle). You are correct. The piece of code in question is actually called for all fields, not only title. I was using the title as an example. So if this is changed, it will also preserve the inner braces for all the other fields.
Re: [O] Invalid-read-syntax
On Wed, Apr 20 2016, Alan Schmitt wrote: > On 2016-04-20 07:59, Colin Baxter writes: > >> On Tue, Apr 19 2016, Nicolas Goaziou wrote: >> >>> Hello, >>> >>> Colin Baxter writes: >>> With the latest org-mode release_8.3.4-739-g7894129, I'm getting an lisp error (invalid-read-syntax "#"). This ocurs with emacs-25.1.50.1 and emacs-24.5.1. >>> >>> Could you provide an ECM? What command triggered that? >>> >>> Regards, >> >> I'm afraid I don't know what ECM means. If you can give me some more >> information, I'll have a go at providing it. > > It's a TLA (three letters acronym) for MWE (minimal working example) in > French: Exemple Complet Minimal. > > HTH, > > Alan Thanks for the clarification of ECM. The file /lisp/ox-html.el of org-mode release_8.3.4-743-g516bbf has binary content at line 1952, whereas the same file of org-mode release_8.3.4-721-g16ad80 has not. Perhaps this is significant. Best wishes, Colin.
Re: [O] [PATCH] new :async feature for org-babel-clojure
Hi Nicolas, Any news regarding these latest fixes to that patch? Thanks, Fred Here is my proposal to create a new :async feature for Org-babel-clojure. This is discussed at length in this blog post: http://fgiasson.com/blog/index.php/2016/04/05/using-clojure-in-org-mode-and-implementing-asynchronous-processing/ I added the commit of the changes, the commit for the ORG-NEWS file and the commit for the Worg documentation. IMPORTANT NOTE: this includes the patches for the new :async feature *AND* the new org-babel-clojure-sync-nrepl-timeout setting (for consistency's sake) Thanks, Fred
Re: [O] [PATCH] Make lexical eval default for elisp src blocks
I think it would be fine to make :lexical "no" be the default, since that should preserve what we are used to. Users can alway set a different default of their own, or make it "yes" when they know it is needed. Nicolas Goaziou writes: > Hello, > > John Kitchin writes: > >> Set default in `org-babel-default-header-args:emacs-lisp'. Add an >> optional argument to the eval function. > > Applied. Thank you. > > However, it seems that some tests are now failing. I guess this is > related to Babel calls, which are eval'ed as emacs-lisp source blocks. > > I have planned to change how Babel calls are evaluated during the next > days. This may make the failures disappear. Meanwhile, we could > force :lexical "no" in that case. > > WDYT? > > > Regards, -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] Invalid-read-syntax
Colin Baxter writes: > The file /lisp/ox-html.el of org-mode release_8.3.4-743-g516bbf has > binary content at line 1952, whereas the same file of org-mode > release_8.3.4-721-g16ad80 has not. Perhaps this is significant. > Perhaps I'm missing something but I don't see anything like that.I also don't see any changes to ox-html.el between 16ad80 and 516bbf. I checked out 516bbf and lines 1950+ of ox_html.el look like this: (when title (format (if html5-fancy "\n%s\n%s" "%s%s\n") (org-export-data title info) Maybe your local copy is corrupted somehow? What happens if you git checkout -- .../lisp/ox-html.el ? -- Nick
Re: [O] BUG: Wrong indentation inside src block
I believe that this diff is part of that commit - http://repo.or.cz/org-mode.git/blobdiff/1045e9e9c0e6438f5ee9dc4f0e5c720a8b670cdd..a311a856514e9245074b02c89d51a9f339784d1c:/lisp/org.el Nicolas Goaziou writes: > Hello, > > fm4d writes: > >> Well, the behaviour is IMO different because something happend in the >> commit >> http://repo.or.cz/org-mode.git/commit/a311a856514e9245074b02c89d51a9f339784d1c >> that broke it. The indent-tabs-mode is off. > > Actually, that commit changes nothing. Could you double check your bisecting? > > Regards, -- ~~~ fm4d ~~~
Re: [O] changing to IN-PROGRESS starts clocking it
Michael Welle writes: > Hello, > > Sharon Kimble writes: > >> How can I have a task which when I change its state from TODO or NEXT to >> IN-PROGRESS starts clocking it until its state is changed back from >> IN-PROGRESS to some other state, when the clocking will cease? > > you can utilise the org-after-todo-state-change-hook. Something like > this should do the trick: > > (defun foo () > (when (and (string= org-state "IN-PROGRESS") > (string= org-last-state "TODO") >(not (string= org-last-state org-state))) > (org-clock-in))) > > (add-hook 'org-after-todo-state-change-hook 'foo) > > The same mechanism can be used to clock out again. > Thanks Michael, it works very well. This is the actual coding that I used - --8<---cut here---start->8--- #+begin_src emacs-lisp (defun org-clockin () (when (and (string= org-state "IN-PROGRESS") (string= org-last-state "TODO") (not (string= org-last-state org-state))) (org-clock-in))) (add-hook 'org-after-todo-state-change-hook 'org-clockin) #+end_src #+begin_src emacs-lisp (defun org-clockout () (when (and (string= org-state "TODO") (string= org-last-state "IN-PROGRESS") (not (string= org-last-state org-state))) (org-clock-out))) (add-hook 'org-after-todo-state-change-hook 'org-clockout) #+end_src --8<---cut here---end--->8--- Thanks Sharon. -- A taste of linux = http://www.sharons.org.uk TGmeds = http://www.tgmeds.org.uk Debian 8.4, fluxbox 1.3.7, emacs 25.0.92 signature.asc Description: PGP signature
Re: [O] Invalid-read-syntax
On Wed, Apr 20 2016, Nick Dokos wrote: > Colin Baxter writes: > >> The file /lisp/ox-html.el of org-mode release_8.3.4-743-g516bbf has >> binary content at line 1952, whereas the same file of org-mode >> release_8.3.4-721-g16ad80 has not. Perhaps this is significant. >> > > Perhaps I'm missing something but I don't see anything like that.I also > don't see any changes to ox-html.el between 16ad80 and 516bbf. I > checked out 516bbf and lines 1950+ of ox_html.el look like this: > >(when title >(format > (if html5-fancy > "\n%s\n%s" > "%s%s\n") > (org-export-data title info) > > Maybe your local copy is corrupted somehow? What happens if you > > git checkout -- .../lisp/ox-html.el > > ? > > -- > Nick git checkout /path/to/ox-html.el worked and removed the binary stuff. I guess it must have been corrupted during the git pull. Thank you. Best wishes, Colin.
Re: [O] Bug: org-bibtex-read strips too many braces (8.3.4-39-ge0acd8-elpaplus)
Hello, timor writes: >> If that's the case, we could indeed remove the duplicate '(123 . 125). > Very nice. Done, in master branch. There are actually no tests for org-bibtex.el. Anyone using this library (or not!) is more than welcome to write some, BTW. Regards, -- Nicolas Goaziou
Re: [O] Bug: Problem with LaTeX export, footnotes in table headers, and longtabu [8.3.4 (8.3.4-31-gcb683e-elpa @ /home/berhol/.emacs.d/elpa/org-20160404/)]
Hello, bh...@despammed.com (Berthold Höllmann) writes: > Even so there seem to be two different routines for writing the column > header for the first and the subsequent pages (in the first one the \\ > follows directly to the '}', whereas the second time a space is added), > it seems, the string is generated only once, because the "[1]" is > missing on the second "\footnotemark", but added to the third one. This is exactly that. In `ox-latex-table-row', string bound to argument CONTENTS is used twice. I guess we could workaround that by first checking if there is any footnote reference within the row and, in that case, force re-exporting each cell in the row. OTOH, Org already piles up workarounds in order to support footnotes within tables (and other locations) in LaTeX export. We will probably need to stop at some point, and handle this at the LaTeX level (i.e., with an appropriate package). WDYT? Regards, -- Nicolas Goaziou
Re: [O] BUG: Wrong indentation inside src block
Hello, fm4d writes: > I believe that this diff is part of that commit - > http://repo.or.cz/org-mode.git/blobdiff/1045e9e9c0e6438f5ee9dc4f0e5c720a8b670cdd..a311a856514e9245074b02c89d51a9f339784d1c:/lisp/org.el The commit you point to is a branch merge. It is a kind of "meta commit" that incorporates changes made in a set of previous commits. I think your culprit happened earlier. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] Make lexical eval default for elisp src blocks
Hello, John Kitchin writes: > I think it would be fine to make :lexical "no" be the default, since > that should preserve what we are used to. Users can alway set a > different default of their own, or make it "yes" when they know it is > needed. Fair enough. Done. Thank you. Regards, -- Nicolas Goaziou
Re: [O] BUG: Wrong indentation inside src block
Nicolas Goaziou writes: > Hello, > > fm4d writes: > >> I believe that this diff is part of that commit - >> http://repo.or.cz/org-mode.git/blobdiff/1045e9e9c0e6438f5ee9dc4f0e5c720a8b670cdd..a311a856514e9245074b02c89d51a9f339784d1c:/lisp/org.el > > The commit you point to is a branch merge. It is a kind of "meta commit" > that incorporates changes made in a set of previous commits. I think > your culprit happened earlier. > > Regards, Yes, well, I did not dig deeper into the 'maint' branch to find the exact commit that caused it and since I managed to fix it and nobody else is able to reproduce the issue I dont think I will.
Re: [O] [PATCH] new :async feature for org-babel-clojure
Hello, Frederick Giasson writes: > Any news regarding these latest fixes to that patch? They look good. Thank you for the heads-up. Could you merge patches 1 2 and 5 (Org series) into a single one for inclusion? As for 3 and 4, I think a more general mechanism for asynchrnous eval'ing would be preferable. Besides, AFAIU, because of ; Wait until the nREPL code finished to be processed (while (not (member "done" status)) (nrepl-dict-put response "status" (remove "need-input" status)) (accept-process-output nil 0.01) (redisplay)) `org-babel-execute:clojure' is still somewhat synchronous, isn't it? Regards, -- Nicolas Goaziou
Re: [O] BUG: Wrong indentation inside src block
fm4d writes: > Yes, well, I did not dig deeper into the 'maint' branch to find the > exact commit that caused it and since I managed to fix it and nobody > else is able to reproduce the issue I dont think I will. I understand. OTOH, if you find the energy to dig deeper, it may help us understanding what makes the issue visible in your situation only. Regards,
[O] Bug: File mode specification error opening Org file without headline on first line [8.3.4 (8.3.4-39-ge0acd8-elpa @ /home/nlj/.emacs.d/elpa/org-20160418/)]
For several months now I have been getting the error "File mode
specification error: (error Before first heading)" when I open some of
my Org files. [After the error message, the file opens just fine and Org
works normally.]
What distinguishes the Org files that do not suffer from this problem
from those that do is that they have a headline in the first line of
the file.
A fairly minimal recipe:
1. $ cat > ~/temp-org-test.org
An introduction.
* A Headline
Some text.
** Sub-Topic 1
** Sub-Topic 2
*** Additional entry
^D
2. $ emacs &
3. Visit ~/temp-org-test.org
At this point the error message "File mode specification error: (error
Before first heading)" is displayed.
Note: This test file is from
http://orgmode.org/worg/dev/org-syntax.html.
Setting debug-on-error, I get the following backtrace:
Debugger entered--Lisp error: (error "Before first heading")
signal(error ("Before first heading"))
error("Before first heading")
outline-back-to-heading()
outline-flag-subtree(t)
hide-subtree()
(save-excursion (goto-char (point-min)) (hide-subtree) (show-children
keep-levels) (condition-case err (while (outline-get-next-sibling)
(hide-subtree) (show-children keep-levels)) (error nil)))
outline-hide-sublevels(1)
org-overview()
org-content()
org-set-startup-visibility()
org-mode()
set-auto-mode-0(org-mode nil)
set-auto-mode()
normal-mode(t)
after-find-file(nil t)
find-file-noselect-1(# "~/temp-org-test.org"
nil nil "~/temp-org-test.org" (801256 64773))
find-file-noselect("/home/nlj/temp-org-test.org" nil nil nil)
find-file("/home/nlj/temp-org-test.org")
On the other hand, if I edit the test file and add a headline on the
first line of the file, for example
* COMMENT This is dummy headline
then the error does not occur. Of course, this seems a rather ugly
work-around.
Emacs : GNU Emacs 25.0.92.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.9)
of 2016-04-18
Package: Org-mode version 8.3.4 (8.3.4-39-ge0acd8-elpa @
/home/nlj/.emacs.d/elpa/org-20160418/)
current state:
==
(setq
org-export-backends '(ascii beamer html icalendar latex odt)
org-tab-first-hook '(org-hide-block-toggle-maybe
org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
outline-minor-mode-hook '(outshine-hook-function)
org-speed-command-hook '(org-speed-command-default-hook
org-babel-speed-command-hook)
org-reverse-note-order t
org-occur-hook '(org-first-headline-recenter)
org-checkbox-hierarchical-statistics nil
org-metaup-hook '(org-babel-load-in-session-maybe)
org-agenda-start-on-weekday nil
org-log-done t
org-format-latex-options '(:foreground default :background default :scale 1.5
:html-foreground "Black" :html-background
"Transparent"
:html-scale 1.0 :matchers ("begin" "$1" "$" "$$"
"\\(" "\\["))
org-confirm-shell-link-function 'yes-or-no-p
org-finalize-agenda-hook '(nlj-agenda-to-appt)
org-startup-folded 'content
org-file-apps '((auto-mode . emacs) ("\\.mm\\'" . default) ("\\.x?html?\\'" .
default)
("\\.pdf\\'" . "evince %s"))
org-agenda-skip-scheduled-if-done t
org-support-shift-select 'always
org-default-notes-file "/data/org//notes.org"
org-capture-templates '(("t" "Todo" entry
(file+headline (concat org-directory
"/organiser.org") "Todos")
"* TODO %?\n:LOGBOOK:\n CREATED: %U\n:END:\n%i\n"
:prepend t
:kill-buffer t :empty-lines 1)
("e" "Event" entry
(file+headline (concat org-directory
"/organiser.org") "Events")
"* %?\n:LOGBOOK:\n CREATED: %U\n:END:\n%i\n"
:kill-buffer t
:empty-lines 1)
("a" "Appointment" entry
(file+headline (concat org-directory "/organiser.org")
"Appointments")
"* APPT %?\n:LOGBOOK:\n CREATED: %U\n:END:\n%i\n"
:kill-buffer t
:empty-lines 1)
("l" "Log" plain (file (concat org-directory
"/log.org"))
"* %U\n\n%?\n%i\n" :kill-buffer t :empty-lines 1
:clock-in t
:clock-resume t)
("n" "Note" entry
(file+headline (concat org-directory "/notes.org")
"Notes")
"* %^{Enter Note Title}%^g\n :PROPERTIES:\n
:Created: %U\n :END:\n\n%?\n%i\n" :kill-buffer t :empty-lines 1 :clock-in t
:clock-resume t)
("o" "Old-style Dated Note" entry
(file+headline (concat org-directory "/notes.org")
"Dated Notes")
"* %U\n%?\n%i\n" :kill-buffer t :empty-lines 1
:clock-in t
Re: [O] Bug: File mode specification error opening Org file without headline on first line [8.3.4 (8.3.4-39-ge0acd8-elpa @ /home/nlj/.emacs.d/elpa/org-20160418/)]
nljlistb...@gmail.com (N. Jackson) writes: > For several months now I have been getting the error "File mode > specification error: (error Before first heading)" when I open some of > my Org files. [After the error message, the file opens just fine and Org > works normally.] I'm not able to reproduce this with your test file. Do you see the error if you load Org with no other packages and no configuration? Based on your configuration dump, it seems like you're using outshine, in which case this may have already been reported [1]. That issue seems to be fixed in the latest version of outshine. [1] http://thread.gmane.org/gmane.emacs.orgmode/100973/focus=101007 -- Kyle
[O] How to export ASCII paintings to HTML
Hi everyone, I am using some "ascii drawings" in my post, but I have some problems while exporting to html. this is my ascii drawing in my org file. (1) When i use* #+BEGIN_HTML,* the ascii exported as plain text. as this: - |parent | screen | | |view | | | | | | | | | | | | | | | | | |view | | | | | | | | | | | | | | | | | | | | | | | - (2 )Then I tried *#+BEGIN_QUOTE*, but there is a "table" build error: *org-html-table-cell: Args out of range: [left left left], 3* (3) And *#+BEGIN_VERSE* gives me this: Is there any way I can export the "ascii drawing" correctly??? thanks all -- Best Regards, Luis Xu
Re: [O] How to export ASCII paintings to HTML
I think you're looking for #+BEGIN_VERBATIM. :)
Re: [O] How to export ASCII paintings to HTML
Still get the build error: org-html-table-cell: Args out of range: [left left left], 3 On Thu, Apr 21, 2016 at 10:33 AM, Adam Porter wrote: > I think you're looking for #+BEGIN_VERBATIM. :) > > > -- Best Regards, Zhengchao Xu
Re: [O] How to export ASCII paintings to HTML
Luis writes: > Still get the build error: org-html-table-cell: Args out of range: > [left left left], 3 It would be easier to help if you provided the code you're trying to export, e.g: #+BEGIN_SRC org * A heading Some text #+BEGIN_VERBATIM | this is cool ---> org-mode | #+END_VERBATIM #+END_SRC
