Creating table of summarized org-mode result fields in column view "report"
I keep a daily log file where there are some summarize colon delimited files each day inserted via a template (from Alfred's snippet feature). ``` org-mode * 2020-03-11 Wed ** 07:37 Log 2020-03-12 Wed :logs: *** The Day This: ?? That:-- Other: ??? Thing: ??? Highlights:??? ``` I would like to parse certain of the daily field entries, into by-day colunmnar entries in desc ending order into an org column view "chart" if it's possible so that I can easily visually parse how those things went each day (sure, org-table might work too but this seemed cleaner and more visually appropriate if possible. ``` | Day | This | That | Other | Thing | Highlights | ``` spaced widely across the screen. Effectively, a columnar report of the dayes and the "fields" (I'll worry about monthly views etc after the basics sorted... =] ). I imagine someone has already done something similar but googling has not given joy (possibly my google-fu needs work) in terms of finding something already existing other than a way to do something vaguely similar for pdf output (whereas I am thinking of it more like a sort of agenda report as it were. Can anyone point me to something similar already? (and is this even possible with column view instead of say, turning it into an org-table within a buffer. Would appreciate advice on how to approach this if it is something I need to write from scratch as konwledge of org-mode internals is, at best, weak (ahem... =p ). thanks! Daryl.
Re: Bug: HTML not formatted correctly from R source code block [9.3.6 (9.3.6-23-g01ee25-elpaplus @ /home/opdfa/.emacs.d/elpa/org-plus-contrib-20200309/)]
Hello again Jack, I am trying to use ob-session-async as a workaround for this problem. In my R :session, the correct output is printed to screen, followed by a UUID if I use :results output html, which is printed as, e.g., [1] "ob_comint_async_R_end_4d2e818b7c2544da6f026d0413c7ac6c" Alternatively, if I use :results value html then the tempfile path is printed as: [1] "ob_comint_async_R_file_/tmp/babel-6BGHQK/R-QNasco" The problem, however, is that what is exported to html and displayed in the exported block is either the actual UUID or the tempfile path and not the results from evaluating the R code. In the case of the tempfile, the tempfile exists but is empty. Any advice as to how to resolve this would be greatly appreciated, thanks. Best regards, Steve On Wed, 11 Mar 2020 13:37:01 +1030 Steven Delean wrote: > Hi Jack, > > Thanks for your response. > > Yes, I am using :session evaluation here, set using #+PROPERTY: > > However, ":results value html" does not work for me. In fact, this produces no > table output at all in the resulting exported html file. > > The output sent to the R :session buffer is printed correctly (when using > either :results value html or :results output html). As you say, it is the > exporter that is removing ">" from the output. > > If I remove :session evaluation, I also get no output at all from these code > blocks in the exported html. > > The change has been introduced within the last 12 months, as my scripts > exported with correct html formatting when I used them for last years' > classes. > > Best regards, > Steve > > On Tue, 10 Mar 2020 17:17:48 -0700 > Jack Kamm wrote: > > > Hi Steve, > > > > Steven Delean writes: > > > > > HTML table produced from a source code block (using R code) does not > > > display because html code is not formatted correctly in the exported html > > > output. > > > > I believe this is the same issue as reported here: > > https://lists.gnu.org/archive/html/emacs-orgmode/2020-02/msg00267.html > > > > Though, that thread was for ":session" blocks, and it's unclear whether > > you're using session or non-session evaluation here. > > > > Anyways, that thread suggests that ":results value html" works > > correctly, does switching to that work for you? > > > > If I'm correct, the basic problem is that ob-R tries to remove > > interactive shell prompts like ">" from the output. This can also cause > > other problems. I think it can be fixed by changing ob-R to use > > `ess-eval-region' to evaluate code, I'll try to submit a patch for this > > after 9.4 is released.
Re: removal of org-maybe-keyword-time-regexp
On 03/11/20 23:20 PM, Nicolas Goaziou wrote: > Hello, > > Eric Abrahamsen writes: > >> But if we use `make-obsolete-variable', the CURRENT-NAME arg can be a >> simply explanatory string. > > You're right. However, I'm not sure what the CURRENT-NAME should be, > besides "don't use this, you probably want something else" I would have liked to know what the "something else" was! Or even "Org link regexps have been rewritten", something like that. > Also, my suggestions still holds: it is useful to warn upstream about > it. Absolutely. I don't think Org has a responsibility to maintain backwards compatibility for these variables, and upstream packages should be tracking changes. But the more help we can provide, the better. >> I was also recently bit by the removal of a bunch of regexps (in my >> case, link regexps), and it would have been useful to have some sort of >> a pointer, either in the obsolescence message or in the docs, about what >> we're supposed to do instead. > > I'm not sure about what "bunch of regexps" you are talking about. Looks like commit "Move link-related core functions out of \"org.el\"". Nearly a year ago -- I wasn't paying attention! But defining link regexps as aliases of other link regexps meant that the regexps matched, but the match groups were off: that led to silent failure, and took quite a while to debug. I guess I would have preferred a loud failure. Anyway, it's not a big deal, I only bring it up because someone else did! Eric
Re: removal of org-maybe-keyword-time-regexp
Hello, Eric Abrahamsen writes: > But if we use `make-obsolete-variable', the CURRENT-NAME arg can be a > simply explanatory string. You're right. However, I'm not sure what the CURRENT-NAME should be, besides "don't use this, you probably want something else" Also, my suggestions still holds: it is useful to warn upstream about it. > I was also recently bit by the removal of a bunch of regexps (in my > case, link regexps), and it would have been useful to have some sort of > a pointer, either in the obsolescence message or in the docs, about what > we're supposed to do instead. I'm not sure about what "bunch of regexps" you are talking about. Regards, -- Nicolas Goaziou
Re: removal of org-maybe-keyword-time-regexp
Nicolas Goaziou writes: > Hello, > > Julien Cubizolles writes: > >> I'm using org-caldav (https://github.com/dengste/org-caldav/) to >> synchronize the calendar on my Android phone and Org. Recently this >> synchronization stopped working because org-caldav relies on >> org-maybe-keyword-time-regexp that has been dropped from Org. As a >> workaround, could this variable be reintroduced in org so as not to >> break this very useful package ? > > Could you contact upstream instead? > > AFAICT, they use this variable only twice. The first occurrence doesn't > seem useful (they check for a planning info keyword in a headline, which > cannot happen), it is probably enough to look for `org-ts-regexp-both'. > > I'm not sure about the second one. I guess it would be better for them > to use something like: > > (and (re-search-forward "org-planning-line-re" nil t) > (org-at-planning-p) > (progn >(org-skip-whitespace) >(looking-at org-ts-regexp-both))) > > The (small) issue here is that we cannot properly deprecate a variable > that is not replaced with something else (i.e., we're not using > `define-obsolete-variable-alias' here). But if we use `make-obsolete-variable', the CURRENT-NAME arg can be a simply explanatory string. I was also recently bit by the removal of a bunch of regexps (in my case, link regexps), and it would have been useful to have some sort of a pointer, either in the obsolescence message or in the docs, about what we're supposed to do instead.
Re: removal of org-maybe-keyword-time-regexp
Hello, Julien Cubizolles writes: > I'm using org-caldav (https://github.com/dengste/org-caldav/) to > synchronize the calendar on my Android phone and Org. Recently this > synchronization stopped working because org-caldav relies on > org-maybe-keyword-time-regexp that has been dropped from Org. As a > workaround, could this variable be reintroduced in org so as not to > break this very useful package ? Could you contact upstream instead? AFAICT, they use this variable only twice. The first occurrence doesn't seem useful (they check for a planning info keyword in a headline, which cannot happen), it is probably enough to look for `org-ts-regexp-both'. I'm not sure about the second one. I guess it would be better for them to use something like: (and (re-search-forward "org-planning-line-re" nil t) (org-at-planning-p) (progn (org-skip-whitespace) (looking-at org-ts-regexp-both))) The (small) issue here is that we cannot properly deprecate a variable that is not replaced with something else (i.e., we're not using `define-obsolete-variable-alias' here). Regards, -- Nicolas Goaziou
Re: Insert PROPERTIES drawer after heading creation
Hi Lawrence, On Wed, Mar 11, 2020 at 7:56 PM Lawrence Bottorff wrote: > I read that too, but couldn't fathom what they meant. Still, I'm not sure > what they mean by "prefix argument." > The prefix argument in this case is not so important as the OUTPUT-BUFFER argument, which you were passing as =t=: "If OUTPUT-BUFFER is not a buffer and not nil, insert the output in current buffer after point leaving mark after it." which is why the output is inserted in the buffer. And why does (shell-command "uuidgen" t) produces two outputs? For other > readers, this is what they look like in *scratch* > > (shell-command "uuidgen" t) > 2827 > b5da7e0a-84c0-4db8-91f3-871b681f3022 > The first number is the return value of shell-command, which is (I think) the position in the buffer at which the pointer was when the function was evaluated (or something like this). Here's the output from two consecutive executions in my *scratch* buffer: (shell-command "uuidgen" t) 173 5E69575E-2807-40BB-B1FE-10058D3C0666 (shell-command "uuidgen" t) 243 A7FD662E-A752-4E02-B4E0-A3E48CC7E7AB The "173" happens to appear at point position 173 in the buffer, and same for the 243 (you can verify this with "C-u C-x ="). Hope this helps! --Diego
Re: Insert PROPERTIES drawer after heading creation
I read that too, but couldn't fathom what they meant. Still, I'm not sure what they mean by "prefix argument." And why does (shell-command "uuidgen" t) produces two outputs? For other readers, this is what they look like in *scratch* (shell-command "uuidgen" t) 2827 b5da7e0a-84c0-4db8-91f3-871b681f3022 (org-id-uuid) "0bb7a4e1-9fc2-4428-b8de-a2d9ef5c56ab" Also, does anyone know how I could have done this by "advise"-ing a function in org-mode tempo templates? I could never figure out what function was actually handling the <...-TAB. On Wed, Mar 11, 2020 at 10:37 AM Diego Zamboni wrote: > > On Wed, Mar 11, 2020 at 2:14 PM Lawrence Bottorff > wrote: > >> Yes, thanks. That substring was a bad copy. Any insight why the >> (shell-command "uuidgen" t) wasn't working? >> > > I hadn't looked at it yet, but the documentation for =shell-command= gives > the answer: > > Execute string COMMAND in inferior shell; display output, if any. > With prefix argument, *insert the COMMAND’s output at point*. > > > So this function does not return a string that can be concatenated with > others, it actually inserts the output in the buffer, so it's not > guaranteed it will land where you need it. > > To have the output of the command returned as a string, I think you should > use =shell-command-to-string=. > > --Diego > >
removal of org-maybe-keyword-time-regexp
I'm using org-caldav (https://github.com/dengste/org-caldav/) to synchronize the calendar on my Android phone and Org. Recently this synchronization stopped working because org-caldav relies on org-maybe-keyword-time-regexp that has been dropped from Org. As a workaround, could this variable be reintroduced in org so as not to break this very useful package ? Julien.
Re: Insert PROPERTIES drawer after heading creation
On Wed, Mar 11, 2020 at 2:14 PM Lawrence Bottorff wrote: > Yes, thanks. That substring was a bad copy. Any insight why the > (shell-command "uuidgen" t) wasn't working? > I hadn't looked at it yet, but the documentation for =shell-command= gives the answer: Execute string COMMAND in inferior shell; display output, if any. With prefix argument, *insert the COMMAND’s output at point*. So this function does not return a string that can be concatenated with others, it actually inserts the output in the buffer, so it's not guaranteed it will land where you need it. To have the output of the command returned as a string, I think you should use =shell-command-to-string=. --Diego
Re: Bug: built-in macros not working anymore [9.3.6 (9.3.6-23-g01ee25-elpaplus @ c:/Users/mda/.emacs.d/elpa/org-plus-contrib-20200309/)]
Hello,
"Dauer, Michael" writes:
> worked at least with 9.1.x, but not anymore
>
> * test
> dfgfas
> {{{author}}}
> dasfas
Fixed. Thank you.
Regards,
--
Nicolas Goaziou
Re: raw replace not working
Hello, Roger Mason writes: > Hello, > > I using Org mode version 9.2.3 (release_9.2.3-390-gfb5091 @ > /home/rmason/.emacs.d/org-git/lisp/) in GNU Emacs 26.3 (build 1, > amd64-portbld-freebsd11.3, X toolkit, Xaw3d scroll bars). > > Here is an ECM: > > #+begin_src shell :results raw replace > #!/usr/bin/env zsh > > mkdir -p Supercell > for i in 1 2 3 > do > touch Supercell/111_stuff.cif > done > ls Supercell > > #+end_src > > #+RESULTS: > 111_stuff.cif > 111_stuff.cif > 111_stuff.cif > > Is there something I'm doing wrong or is this a limitation of org > 9.2.3? It is a limitation of Org. Raw results cannot be replaced because Org cannot know what is the result. You may wrap the output within a drawer. Regards, -- Nicolas Goaziou
raw replace not working
Hello, I using Org mode version 9.2.3 (release_9.2.3-390-gfb5091 @ /home/rmason/.emacs.d/org-git/lisp/) in GNU Emacs 26.3 (build 1, amd64-portbld-freebsd11.3, X toolkit, Xaw3d scroll bars). Here is an ECM: #+begin_src shell :results raw replace #!/usr/bin/env zsh mkdir -p Supercell for i in 1 2 3 do touch Supercell/111_stuff.cif done ls Supercell #+end_src #+RESULTS: 111_stuff.cif 111_stuff.cif 111_stuff.cif Is there something I'm doing wrong or is this a limitation of org 9.2.3? Cheers, Roger
Re: Insert PROPERTIES drawer after heading creation
Yes, thanks. That substring was a bad copy. Any insight why the (shell-command "uuidgen" t) wasn't working? On Wed, Mar 11, 2020 at 3:03 AM Diego Zamboni wrote: > Hi LB, > > How about using the =org-id-uuid= function instead of shelling out to > uuidgen? In my quick test the following seems to behave properly: > > (defun template-myid () > (insert "\n:PROPERTIES:\n:TIME: " > (format-time-string "%Y-%m-%dT%H:%M:%S") > "\n:VERTEX: " > (org-id-uuid) > "\n:EDGES: \n:END:")) > > Note that I also removed the wrapping (substring (format ...)), which > didn't seem to be necessary. > > --Diego > > > On Wed, Mar 11, 2020 at 5:39 AM Lawrence Bottorff > wrote: > >> I want to insert upon creating a heading a PROPERTIES drawer. So far I >> have this >> >> (defadvice org-insert-heading (after add-id-stuff activate) >> (template-myid)) >> >> (defun template-myid () >> (insert "\n:PROPERTIES:\n:TIME: " >> (substring (format "%s" (format-time-string "%Y-%m-%dT%H:%M:%S"))) >> "\n:VERTEX: " >> (substring (format "%s" (shell-command "uuidgen" t))) >> "\n:EDGES: \n:END:")) >> >> This is working -- sort of. My problem is the uuid is getting thrown >> around. The output looks like this >> >> * Heading >> :PROPERTIES: >> :TIME: 2020-03-10T23:34:17 >> :VERTEX: 12836 >> :EDGES: >> :END:32bf9499-f9e2-49d9-b8e7-9edb40272411 >> >> Not sure how to make this behave. >> >> LB >> >
Re: Bug: built-in macros not working anymore [9.3.6 (9.3.6-23-g01ee25-elpaplus @ c:/Users/mda/.emacs.d/elpa/org-plus-contrib-20200309/)]
On Wednesday, 11 Mar 2020 at 10:57, Dauer, Michael wrote: > worked at least with 9.1.x, but not anymore Confirmed with org up to date as of a few minutes ago. Error message: org-macro-replace-all: Undefined Org macro: author; aborting -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-412-ge18415
Bug: built-in macros not working anymore [9.3.6 (9.3.6-23-g01ee25-elpaplus @ c:/Users/mda/.emacs.d/elpa/org-plus-contrib-20200309/)]
worked at least with 9.1.x, but not anymore
* test
dfgfas
{{{author}}}
dasfas
Emacs : GNU Emacs 26.3 (build 1, x86_64-w64-mingw32)
of 2019-11-01
Package: Org mode version 9.3.6 (9.3.6-23-g01ee25-elpaplus @
c:/Users/mda/.emacs.d/elpa/org-plus-contrib-20200309/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-html-format-inlinetask-function
'org-html-format-inlinetask-default-function
org-odt-format-headline-function 'org-odt-format-headline-default-function
org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-all append local] 5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-babel-show-result-all append local]
5]
org-babel-result-hide-spec org-babel-hide-all-hashes org-eldoc-load)
org-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function #[257 "\300 \236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-ascii-format-drawer-function #[771 " \207" [] 4 "\n\n(fn NAME CONTENTS
WIDTH)"]
org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php" . php)
("C" . c) ("C++" . c++)
("asymptote" . asy) ("bash" . sh) ("beamer" . latex) ("calc" .
fundamental) ("cpp" . c++)
("ditaa" . artist) ("dot" . fundamental) ("elisp" . emacs-lisp)
("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh) ("sqlite" . sql))
org-occur-hook '(org-first-headline-recenter)
org-export-coding-system 'utf-8
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-odt-format-inlinetask-function
'org-odt-format-inlinetask-default-function
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-open-link :export
org-attach-export-link :complete
org-attach-complete-link)
("id" :follow org-id-open) ("eww" :follow eww :store
org-eww-store-link)
("rmail" :follow org-rmail-open :store org-rmail-store-link)
("mhe" :follow org-mhe-open :store org-mhe-store-link)
("irc" :follow org-irc-visit :store org-irc-store-link :export
org-irc-export)
("info" :follow org-info-open :export org-info-export :store
org-info-store-link)
("gnus" :follow org-gnus-open :store org-gnus-store-link)
("docview" :follow org-docview-open :export org-docview-export :store
org-docview-store-link)
("bibtex" :follow org-bibtex-open :store org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :export org-bbdb-export :complete
org-bbdb-complete-link
:store org-bbdb-store-link)
("w3m" :store org-w3m-store-link) ("file+sys") ("file+emacs")
("shell" :follow org-link--open-shell)
("news" :follow #[257 "\301\300\302 Q!\207" ["news" browse-url ":"] 5
"\n\n(fn URL)"])
("mailto" :follow #[257 "\301\300\302 Q!\207" ["mailto" browse-url
":"] 5 "\n\n(fn URL)"])
("https" :follow #[257 "\301\300\302 Q!\207" ["https" browse-url ":"]
5 "\n\n(fn URL)"])
("http" :follow #[257 "\301\300\302 Q!\207" ["http" browse-url ":"] 5
"\n\n(fn URL)"])
("ftp" :follow #[257 "\301\300\302 Q!\207" ["ftp" browse-url ":"] 5
"\n\n(fn URL)"])
("help" :follow org-link--open-help) ("file" :complete
org-link-complete-file)
("elisp" :follow org-link--open-elisp) ("doi" :follow
org-link--open-doi))
org-latex-format-headline-function
'org-latex-format-headline-default-function
org-link-elisp-confirm-function 'yes-or-no-p
org-latex-format-inlinetask-function
'org-latex-format-inlinetask-default-function
org-html-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
org-html-format-headline-function
'org-html-format-headline-default-function
)
Emacs : GNU Emacs 26.3 (build 1, x86_64-w64-mingw32)
of 2019-11-01
Package: Org mode version 9.3.6 (9.3.6-23-g01ee25-elpaplus @
c:/Users/mda/.emacs.d/elpa/org-plus-contrib-20200309/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-html-format-inlinetask-function
