Re: [O] [bug?] org-repair-property-drawers does not repair whole file
Gregor Zattler telegr...@gmx.net writes: As you might guess this part represents an email, the multi line node being the message body. How would one incorporate such info in proper org-mode syntax? Since as of now I do not query the name=value pairs this is no strict necessity for me. It depends on what you want to do with that data. You may use another drawer, e.g. :EMAIL: or a quote block, or an example block... Is there a syntax checker for org-mode files? There is no invalid syntax in Org mode. What you wrote is a valid drawer, albeit not a valid properties drawer. Regards,
Re: [O] [bug?] org-repair-property-drawers does not repair whole file
Hi Nicolas, * Nicolas Goaziou m...@nicolasgoaziou.fr [08. Mar. 2015]: Gregor Zattler telegr...@gmx.net writes: Sadly no: I reapplied `org-repair-property-drawers' on my org file with no customisation at all: emacs-snapshot -Q -nw -L /home/grfz/src/org-mode/lisp/ file.org ~/src/org-mode/etc/ORG-NEWS I loaded `org-repair-property-drawers' from ~/src/org-mode/etc/ORG-NEWS and executed it in file.org. Result is ’(nil nil nil nil nil nil nil nil nil nil nil nil ... )’ and the buffer file.org remains unmodified. Doesn't the function fix the anon file you sent? No. I removed the line numbers so that the stars of the headings are at the first column and invoced `org-repair-property-drawers' in the same way as described above. The buffer remains unmodified and the output is `nil'. Is it possible to have access to the file? You might want to hide contents first with the following function (defun scramble-contents () Yes. I scrambled it with your function, changed tags (which were not scrambled by `scramble-contents') and obfuscated clock lines. The result is attached. Thanks for looking into this, but if it’s only me: It would be not much work to clean up the file by hand. Gregor scrambled.org.gz Description: application/gzip
Re: [O] [bug?] org-repair-property-drawers does not repair whole file
Gregor Zattler telegr...@gmx.net writes: No. I removed the line numbers so that the stars of the headings are at the first column and invoced `org-repair-property-drawers' in the same way as described above. The buffer remains unmodified and the output is `nil'. I cannot reproduce it. Is it possible to have access to the file? You might want to hide contents first with the following function (defun scramble-contents () Yes. I scrambled it with your function, changed tags (which were not scrambled by `scramble-contents') and obfuscated clock lines. The result is attached. I see invalid property drawers, e.g., :PROPERTIES: :Xxxx: Xxx, xx Xxx xx:xx:xx + :Xxxx: Xxx Xx x.xxx...@xxx.xx :Xxx-XX: ....@xxx.xx :Xxx: XXX XXX - XX xx xx.xx. - Xx xx. xx:xx :Xx: Xx Xx x.xxx...@xxx.xx, Xxx Xx x.xxx...@xxx.xx, Xx Xx x.xxx...@xxx.xx, X X x.xx...@xxx.xx, X X x.xx...@xxx.xx, X Xxxx x.xx...@xxx.xx, X Xxxx x.x...@xxx.xx, Xxx Xx x.xxx...@xxx.xx, Xxx X Xxxx x.x...@xxx.xx, Xxxx Xxxx x.xx...@xxx.xx, Xxx X x.xx...@xxx.xx, Xx Xxx x....@xxx.xx, Xxx X x.xx...@xxx.xx, X Xx x....@xxx.xx, Xxx X x.xx...@xxx.xx, Xxxx Xxxx x.x...@xxx.xx, X Xxxx x.x...@xxx.xx :Xxxx: X XXXxxx, xx xx.x. xxx xxx xxx X xxx XXX. Xxx xxx xxx Xxxx xxx, xxx Xx xxx X , x xxx Xxxx xx : XXX xX XXX xXxxx XXX xXx XXX xXxx xxx X - Xxx xx xxx xx X xxx ? (Xxx x XX) XXX xXxxx xxx Xxxx xxx Xx xxx Xx (Xxx x XX) XXX xX xxx Xxx /Xxx xxx XX xxx XXX (Xxx x XX) XXX xX xxx XXX-XXX (Xx!) xxx Xxx xxx XXX (Xxx x XX) XXX xX Xxx xxx xxx, xxx xx Xxxx xxx X xx (xx. xx:xx, xxx Xx xxx xxx). Xxx xxx Xx, xxx xxx x (xxx) x xxx. X X xxx xxx xx Xx. Xxx :END: A property drawer can contain only node properties, and there is one node property per line. Ill-formed property drawers were not moved. Regards,
Re: [O] [bug?] org-repair-property-drawers does not repair whole file
Hi Nicolas, org-mode developers and users, * Nicolas Goaziou m...@nicolasgoaziou.fr [09. Mar. 2015]: Gregor Zattler telegr...@gmx.net writes: I see invalid property drawers, e.g., :PROPERTIES: :Xxxx: Xxx, xx Xxx xx:xx:xx + :Xxxx: Xxx Xx x.xxx...@xxx.xx :Xxx-XX: ....@xxx.xx :Xxx: XXX XXX - XX xx xx.xx. - Xx xx. xx:xx :Xx: Xx Xx x.xxx...@xxx.xx, Xxx Xx x.xxx...@xxx.xx, Xx Xx x.xxx...@xxx.xx, X X x.xx...@xxx.xx, X X x.xx...@xxx.xx, X Xxxx x.xx...@xxx.xx, X Xxxx x.x...@xxx.xx, Xxx Xx x.xxx...@xxx.xx, Xxx X Xxxx x.x...@xxx.xx, Xxxx Xxxx x.xx...@xxx.xx, Xxx X x.xx...@xxx.xx, Xx Xxx x....@xxx.xx, Xxx X x.xx...@xxx.xx, X Xx x....@xxx.xx, Xxx X x.xx...@xxx.xx, Xxxx Xxxx x.x...@xxx.xx, X Xxxx x.x...@xxx.xx :Xxxx: X XXXxxx, xx xx.x. xxx xxx xxx X xxx XXX. [... 17 lines deleted ...] Xxx :END: A property drawer can contain only node properties, and there is one node property per line. As you might guess this part represents an email, the multi line node being the message body. How would one incorporate such info in proper org-mode syntax? Since as of now I do not query the name=value pairs this is no strict necessity for me. Is there a syntax checker for org-mode files? Ill-formed property drawers were not moved. Thanks for your explanation and time spent, Gregor
Re: [O] [bug?] org-repair-property-drawers does not repair whole file
Gregor Zattler telegr...@gmx.net writes: Sadly no: I reapplied `org-repair-property-drawers' on my org file with no customisation at all: emacs-snapshot -Q -nw -L /home/grfz/src/org-mode/lisp/ file.org ~/src/org-mode/etc/ORG-NEWS I loaded `org-repair-property-drawers' from ~/src/org-mode/etc/ORG-NEWS and executed it in file.org. Result is ’(nil nil nil nil nil nil nil nil nil nil nil nil ... )’ and the buffer file.org remains unmodified. Doesn't the function fix the anon file you sent? Is it possible to have access to the file? You might want to hide contents first with the following function (defun scramble-contents () (interactive) (let ((tree (org-element-parse-buffer))) (org-element-map tree '(code comment comment-block example-block fixed-width keyword link node-property plain-text verbatim) (lambda (obj) (cl-case (org-element-type obj) ((code comment comment-block example-block fixed-width keyword node-property verbatim) (let ((value (org-element-property :value obj))) (org-element-put-property obj :value (replace-regexp-in-string [[:alnum:]] x value (link (unless (string= (org-element-property :type obj) radio) (org-element-put-property obj :raw-link http://orgmode.org;))) (plain-text (org-element-set-element obj (replace-regexp-in-string [[:alnum:]] x obj) nil nil nil t) (let ((buffer (get-buffer-create *Scrambled text*))) (with-current-buffer buffer (insert (org-element-interpret-data tree)) (goto-char (point-min))) (switch-to-buffer buffer Regards,
Re: [O] [bug?] org-repair-property-drawers does not repair whole file
Hi Nicolas, * Nicolas Goaziou m...@nicolasgoaziou.fr [08. Mar. 2015]: Unfortunately it doesn't ring a bell. Running `org-repair-property-drawers' on your file repairs it. Would it be related to `org-inlinetask' (i.e., different behaviour if the library is loaded or not)? Sadly no: I reapplied `org-repair-property-drawers' on my org file with no customisation at all: emacs-snapshot -Q -nw -L /home/grfz/src/org-mode/lisp/ file.org ~/src/org-mode/etc/ORG-NEWS I loaded `org-repair-property-drawers' from ~/src/org-mode/etc/ORG-NEWS and executed it in file.org. Result is ’(nil nil nil nil nil nil nil nil nil nil nil nil ... )’ and the buffer file.org remains unmodified. This is with: GNU Emacs 25.0.50.2 (i686-pc-linux-gnu, GTK+ Version 3.14.5) of 2015-03-08 on boo Org-mode version 8.3beta (release_8.3beta-893-g1219b0 @/home/grfz/src/org-mode/lisp/) I rechecked with emacs24: GNU Emacs 24.4.91.1 (i686-pc-linux-gnu, GTK+ Version 3.14.5) of 2015-03-08 on boo and same org-mode: same result. Ciao, Gregor -- -... --- .-. . -.. ..--.. ...-.-
Re: [O] [bug?] org-repair-property-drawers does not repair whole file
Hello, Gregor Zattler telegr...@gmx.net writes: I invoked org-repair-property-drawers on a fairly large org-mode file. It did sort some PROPERTIES drawers in front of LOGBOOK ones but not all. Since I do not understand the logic of org-repair-property-drawers I prepared a file with the structure of the org-mode file after running org-repair-property-drawers on it: egrep ^\*+|^ *:PROPERTIES:|^ *:LOGBOOK:|^ *:END: file.org |nl headings-properties-logbook-numbered sed -e s/\(^ \+[0-9]\+[[:space:]]*\*\+[[:space:]]*\)\(TODO\|INPROGRESS\|WAITING\|VERIFY\|DONE\|DELEGATED\|CANCELLED\|PUTOFF\|IDEA\)*\(.*$\)/\1\2/ headings-properties-logbook-numbered headings-properties-logbook-numbered.anon I don’t how to isolate the bug or the circumstances which trigger it. The file headings-properties-logbook-numbered.anon is attached to this email. I hope it might be useful to you to find the bug. Unfortunately it doesn't ring a bell. Running `org-repair-property-drawers' on your file repairs it. Would it be related to `org-inlinetask' (i.e., different behaviour if the library is loaded or not)? Regards, -- Nicolas Goaziou
[O] [bug?] org-repair-property-drawers does not repair whole file
Dear org-mode developers, dear Nicolas, I invoked org-repair-property-drawers on a fairly large org-mode file. It did sort some PROPERTIES drawers in front of LOGBOOK ones but not all. Since I do not understand the logic of org-repair-property-drawers I prepared a file with the structure of the org-mode file after running org-repair-property-drawers on it: egrep ^\*+|^ *:PROPERTIES:|^ *:LOGBOOK:|^ *:END: file.org |nl headings-properties-logbook-numbered sed -e s/\(^ \+[0-9]\+[[:space:]]*\*\+[[:space:]]*\)\(TODO\|INPROGRESS\|WAITING\|VERIFY\|DONE\|DELEGATED\|CANCELLED\|PUTOFF\|IDEA\)*\(.*$\)/\1\2/ headings-properties-logbook-numbered headings-properties-logbook-numbered.anon I don’t how to isolate the bug or the circumstances which trigger it. The file headings-properties-logbook-numbered.anon is attached to this email. I hope it might be useful to you to find the bug. Via grep -A2 LOGBOOK headings-properties-logbook-numbered.anon|grep PROPERTIES I can see, that there are 18 occurrences where there is a PROPERTIES drawer after a LOGBOOK drawer instead before. Some of the corresponding headings had tags, some not. And also some of the not corresponding headings had tags and some not. Ciao, Gregor -- -... --- .-. . -.. ..--.. ...-.- 1 * 2:PROPERTIES: 3:END: 4:LOGBOOK: 5:END: 6 *** DONE 7 :PROPERTIES: 8 :END: 9 :LOGBOOK: 10 :END: 11 *** INPROGRESS 12 :LOGBOOK: 13 :END: 14 *** 15 :LOGBOOK: 16 :END: 17 *** 18 :LOGBOOK: 19 :END: 20 * DONE 21:LOGBOOK: 22:END: 23 * 24 *** 25 :LOGBOOK: 26 :END: 27 * 28:LOGBOOK: 29:END: 30 * 31:LOGBOOK: 32:END: 33 *** CANCELLED 34 :LOGBOOK: 35 :END: 36 *** 37 *** 38 * DONE 39:LOGBOOK: 40:END: 41 * 42 * DONE 43 *** TODO 44 :LOGBOOK: 45 :END: 46 *** DONE 47 :LOGBOOK: 48 :END: 49 *** CANCELLED 50 :LOGBOOK: 51 :END: 52 *** DONE 53 :LOGBOOK: 54 :END: 55 * DONE 56:LOGBOOK: 57:END: 58 * DONE 59:LOGBOOK: 60:END: 61 *** PUTOFF 62 :LOGBOOK: 63 :END: 64 *** TODO 65 * 66 * 67 * 68 * 69 * 70 * 71 :LOGBOOK: 72 :END: 73 *** PUTOFF 74 :LOGBOOK: 75 :END: 76 *** DONE 77 *** TODO 78 *** INPROGRESS 79 :LOGBOOK: 80 :END: 81 *** DELEGATED 82 :PROPERTIES: 83 :END: 84 :LOGBOOK: 85 :END: 86 * CANCELLED 87:LOGBOOK: 88:END: 89 * 90 * 91 * 92 * 93 * 94 *** INPROGRESS 95 :LOGBOOK: 96 :END: 97 * 98 * 99 * DONE 100:LOGBOOK: 101:END: 102 *** INPROGRESS 103 :LOGBOOK: 104 :END: 105 *** CANCELLED 106 :LOGBOOK: 107 :END: 108 *** INPROGRESS 109 :LOGBOOK: 110 :END: 111 * 112 * 113 * 114 * 115 *** INPROGRESS 116 :LOGBOOK: 117 :END: 118 * 119 *** 120 *** 121 *** 122 *** 123 *** 124 * 125 * 126 * 127 * 128 *** DONE 129 :LOGBOOK: 130 :END: 131 * 132 * 133 *** 134 *** 135 * 136 *** 137 * 138:PROPERTIES: 139:END: 140 *** 141 *** 142 *** 143 *** 144 :PROPERTIES: 145 :END: 146 *** 147:PROPERTIES: 148:END: 149 *** 150 * 151:PROPERTIES: 152:END: 153 * 154 * DONE 155 :LOGBOOK: 156 :END: 157 * 158:PROPERTIES: 159:END: 160 *** DONE 161 :LOGBOOK: 162 :END: 163 :PROPERTIES: 164 :END: 165 *** DONE 166 :LOGBOOK: 167 :END: 168 *** DONE 169 :LOGBOOK: 170 :END: 171 *** DONE 172 :LOGBOOK: 173 :END: 174 * 175 * 176 *** DONE 177 :LOGBOOK: 178 :END: 179 *** DONE 180 :LOGBOOK: 181 :END: 182 *** DONE 183 :LOGBOOK: 184 :END: 185 * 186 *** DONE 187 :LOGBOOK: 188 :END: 189 :PROPERTIES: 190 :END: 191 *** DONE 192 :LOGBOOK: 193 :END: 194 *** DONE
