hi I would like to overlay the hash info in results lines of this type #+RESULTS[6e22789c4866716ffb3d0966cbb07c80cacf2d3c]: [1] 1 by a description which shows the evaluation time, e.g. like this #+RESULTS[[6e22789c4866716ffb3d0966cbb07c80cacf2d3c][ evaluated 2013-01-28 Mon 09:33]]: as far as I can see it would require to modify one line in ob-core.el (when hash (concat "["hash"]")) e.g. by some polished version of this hack: (when hash (concat "[["hash"][" (with-temp-buffer (org-insert-time-stamp (current-time) 'hm)) "]]")) but, not sure if that is a good idea and what other changes this would require. best Thomas -- sent from Nil
Hi Thomas,
Thomas Alexander Gerds <tag@biostat.ku.dk> writes:
> (when hash (concat "[["hash"][" (with-temp-buffer
> (org-insert-time-stamp (current-time) 'hm)) "]]"))
>
> but, not sure if that is a good idea and what other changes this
> would require.
I'm not sure too (both whether this is a good idea and whether
this would trigger other changes)... but I'd say this is a very
specific need, and it can be fulfilled by asking the code to
insert a timestamp into the exported results, right?
See for e.g.:
#+BEGIN_SRC emacs-lisp :results raw
(message ";; %s" (format-time-string (cdr org-time-stamp-custom-formats)))
#+END_SRC
HTH,
--
Bastien
Hi Bastien,
thanks for you reply, in particular for showing how to avoid
org-insert-time-stamp to convert the current-time into a string.
I should have said more clearly what I had in mind with this. I was
thinking of a reproducible report or manuscript with R source blocks
that produce some results. Here org babel allows one to enable caching
for some or all source-blocks. My proposal has two advantages:
1) when visiting the cached results of a particular block after some
time, e.g. one year later, it would be visible *when* the block was
evaluated. This can be useful, e.g., when there are several versions of
the same dataset which are used to produce the cached results.
2) sometimes it may be unclear which blocks are evaluated when running
org-babel-execute-buffer or org-export-as-x, in particular for org-babel
novices. Thus, showing the evaluation time in the results header will
help to learn how caching works.
Cheers
Thomas
Bastien <bzg@altern.org> writes:
> Hi Thomas,
>
> Thomas Alexander Gerds <tag@biostat.ku.dk> writes:
>
>> (when hash (concat "[["hash"][" (with-temp-buffer
>> (org-insert-time-stamp (current-time) 'hm)) "]]"))
>> but, not sure if that is a good idea and what other changes this
>> would require.
>
> I'm not sure too (both whether this is a good idea and whether this
> would trigger other changes)... but I'd say this is a very specific
> need, and it can be fulfilled by asking the code to insert a timestamp
> into the exported results, right?
>
> See for e.g.:
> #+BEGIN_SRC emacs-lisp :results raw
> (message ";; %s" (format-time-string (cdr org-time-stamp-custom-formats)))
> #+END_SRC
> HTH,
--
Hi Thomas, I've just pushed this functionality up to the main branch. To make use of it add the following to your Emacs config. (setq org-babel-hash-show-time t) It works for me in some simple tests, and I can confirm that with this variable set to nil, I get no new failures in the Org-mode test suite, so it shouldn't introduce any problems. Thanks for suggesting this functionality, Thomas Alexander Gerds <tag@biostat.ku.dk> writes: > Hi Bastien, > > thanks for you reply, in particular for showing how to avoid > org-insert-time-stamp to convert the current-time into a string. > > I should have said more clearly what I had in mind with this. I was > thinking of a reproducible report or manuscript with R source blocks > that produce some results. Here org babel allows one to enable caching > for some or all source-blocks. My proposal has two advantages: > > 1) when visiting the cached results of a particular block after some > time, e.g. one year later, it would be visible *when* the block was > evaluated. This can be useful, e.g., when there are several versions of > the same dataset which are used to produce the cached results. > > 2) sometimes it may be unclear which blocks are evaluated when running > org-babel-execute-buffer or org-export-as-x, in particular for org-babel > novices. Thus, showing the evaluation time in the results header will > help to learn how caching works. > > Cheers > Thomas > > > > > > > Bastien <bzg@altern.org> writes: > >> Hi Thomas, >> >> Thomas Alexander Gerds <tag@biostat.ku.dk> writes: >> >>> (when hash (concat "[["hash"][" (with-temp-buffer >>> (org-insert-time-stamp (current-time) 'hm)) "]]")) >>> but, not sure if that is a good idea and what other changes this >>> would require. >> >> I'm not sure too (both whether this is a good idea and whether this >> would trigger other changes)... but I'd say this is a very specific >> need, and it can be fulfilled by asking the code to insert a timestamp >> into the exported results, right? >> >> See for e.g.: >> #+BEGIN_SRC emacs-lisp :results raw >> (message ";; %s" (format-time-string (cdr org-time-stamp-custom-formats))) >> #+END_SRC >> HTH, > -- > -- Eric Schulte http://cs.unm.edu/~eschulte
Hi Eric,
Eric Schulte <schulte.eric@gmail.com> writes:
> I've just pushed this functionality up to the main branch. To make use
> of it add the following to your Emacs config.
>
> (setq org-babel-hash-show-time t)
Thanks!
--
Bastien
Hi Eric,
Eric Schulte <schulte.eric@gmail.com> writes:
> I've just pushed this functionality up to the main branch. To make use
> of it add the following to your Emacs config.
>
> (setq org-babel-hash-show-time t)
Well, the patch breaks master, because of (defvar org-ts-regexp).
Can you fix this?
Thanks,
--
Bastien
Hi Eric
yes, it is in line 178 the call to
(defcustom org-babel-load-languages '((emacs-lisp . t)) ...
which seems to need `org-ts-regexp'
but, otherwise it works! Thank you very much for this option.
Best
Thomas
Bastien <bzg@altern.org> writes:
> Hi Eric,
>
> Eric Schulte <schulte.eric@gmail.com> writes:
>
>> I've just pushed this functionality up to the main branch. To make
>> use of it add the following to your Emacs config.
>> (setq org-babel-hash-show-time t)
>
> Well, the patch breaks master, because of (defvar org-ts-regexp).
>
> Can you fix this?
>
> Thanks,
--
Thomas A. Gerds -- Assoc. Prof. Department of Biostatistics
University of Copenhagen, Øster Farimagsgade 5, 1014 Copenhagen, Denmark
Office: CSS-15.2.07 (Gamle Kommunehospital)
tel: 35327914 (sec: 35327901)
Hello,
Eric Schulte <schulte.eric@gmail.com> writes:
> I've just pushed this functionality up to the main branch. To make use
> of it add the following to your Emacs config.
>
> (setq org-babel-hash-show-time t)
>
> It works for me in some simple tests, and I can confirm that with this
> variable set to nil, I get no new failures in the Org-mode test suite,
> so it shouldn't introduce any problems.
Well, it breaks the parser, somehow. Indeed, it expects from an
affiliated keyword such as #+results: (or #+caption for that matter) to
have only one secondary value. Sexp representation of these keywords is
already very complicated, it will not help to add values ad nauseum.
Also, if you use Org time-stamp syntax, at some point, someone will ask
the parser to be able to parse it. And it won't.
Eventually, it doesn't help to have hash syntax match Org links. This is
confusing.
Therefore, if this feature really has to be introduced, I suggest, at
the very least, to avoid using Org regular syntax for the reference to
time. It would also help to blur distinction between the time and the
hash string. Perhaps something like the following:
#+results[2013-01-30T20:15:37 hash-string]: name
Thank you.
Regards,
--
Nicolas Goaziou
Nicolas Goaziou <n.goaziou@gmail.com> writes: > Hello, > > Eric Schulte <schulte.eric@gmail.com> writes: > >> I've just pushed this functionality up to the main branch. To make use >> of it add the following to your Emacs config. >> >> (setq org-babel-hash-show-time t) >> >> It works for me in some simple tests, and I can confirm that with this >> variable set to nil, I get no new failures in the Org-mode test suite, >> so it shouldn't introduce any problems. > > Well, it breaks the parser, somehow. Indeed, it expects from an > affiliated keyword such as #+results: (or #+caption for that matter) to > have only one secondary value. Sexp representation of these keywords is > already very complicated, it will not help to add values ad nauseum. > > Also, if you use Org time-stamp syntax, at some point, someone will ask > the parser to be able to parse it. And it won't. > > Eventually, it doesn't help to have hash syntax match Org links. This is > confusing. > > Therefore, if this feature really has to be introduced, I suggest, at > the very least, to avoid using Org regular syntax for the reference to > time. It would also help to blur distinction between the time and the > hash string. Perhaps something like the following: > > #+results[2013-01-30T20:15:37 hash-string]: name > > Thank you. > Are there instances aside from "#+results" where one would want to pack ancillary information into a keyword? Perhaps both the hash and the time should be moved *outside* the keyword, e.g. something like the following, #+Results: name time hash What do you think? > > > Regards, -- Eric Schulte http://cs.unm.edu/~eschulte
Bastien <bzg@altern.org> writes: > Hi Eric, > > Eric Schulte <schulte.eric@gmail.com> writes: > >> I've just pushed this functionality up to the main branch. To make use >> of it add the following to your Emacs config. >> >> (setq org-babel-hash-show-time t) > > Well, the patch breaks master, because of (defvar org-ts-regexp). > Oh, my apologies. So this is a defconst not a defvar. > > Can you fix this? > As a temporary fix, I put the full defconst invocation into ob-core.el, but this can't be the best solution. What's the "best practice" for how to use a defconst defined in an external file (when you can't require that file because that file requires you)? Thanks, -- Eric Schulte http://cs.unm.edu/~eschulte
Eric Schulte writes: > What's the "best practice" for how to use a defconst defined in an > external file (when you can't require that file because that file > requires you)? Putting all definitions into a separate "leaf" file that can then be required from everywhere with impunity. Bastien doesn't like this idea, so the only way out would be autoloading such symbols, but of course autoloading a defconst is just a glorified way to put its definition in a leaf file. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Eric Schulte <schulte.eric@gmail.com> writes: > Are there instances aside from "#+results" where one would want to > pack ancillary information into a keyword? So far, only #+results and #+caption (for the short caption) are concerned. See `org-element-dual-keywords' for some more details. > Perhaps both the hash and the time should be moved *outside* the > keyword, e.g. something like the following, > > #+Results: name time hash > > What do you think? I think the hash string is fine where it is since there's already a keyword category for such constructs. It's even handy in the case of captions. It would be better if we don't overload this location, though. As far as the parser goes, both #+results[mix-time-and-hash]: name and #+results[hash]: name time are fine, as long as time isn't, as already explained, exactly an Org timestamp. The latter is perhaps more elegant. I guess it depends on how important the time information is. Anyway, use whichever suits you. Regards, -- Nicolas Goaziou
Hi Eric, Eric Schulte <schulte.eric@gmail.com> writes: > As a temporary fix, I put the full defconst invocation into ob-core.el, > but this can't be the best solution. Yep, having the same defconst twice... > What's the "best practice" for how to use a defconst defined in an > external file (when you can't require that file because that file > requires you)? To circumvent the dependency problem by having defconst in a separate file that any file can load safely -- since that file will not require any other file. I'm not ready yet to take that road for now, because it requires time and attention. I just hardcoded the regexp in ob-core.el and added a warning. Thanks, -- Bastien
Hi Achim,
Achim Gratz <Stromeko@nexgo.de> writes:
> Putting all definitions into a separate "leaf" file that can then be
> required from everywhere with impunity. Bastien doesn't like this
> idea,
Maybe you misunderstood me.
I am very much in love with the idea of putting defconst in a
separate file.
What I don't like *at all* is the idea you proposed to put every
variable (including user options) in a separate file. The reason why
I don't like this is because it will force potential contributors to
modify this "Yeah-I-contain-all-variables!"-file. This would be a
maintainance burden.
--
Bastien