Re: Bug: Off-by-one when archiving to top level date [9.3.6 (9.3.6-17-g389288-elpa @ /home/charlestam/.emacs.d/elpa/org-20200224/)]

Wow it's been a while. Sorry I dropped this! To reproduce the bug, open the following content in `emacs -q` and run org-archive-subtree on the TEST ITEM: #+COMMENT: Local Variables: #+COMMENT: mode: org #+COMMENT: org-archive-location: "::datetree/" #+COMMENT: org-odd-levels-only: t #+COMMENT: En

Re: How to set options for verbatim environments produced by org babel

Thanks, Eric. I didn’t know results could be detached from their code blocks via names. That’s really useful. However, a clean way to pass options to the verbatim (or listing) environment used for displaying results would be great nonetheless. Titus On 2020-11-09 Mo 13:23, Eric S Fraga w

Re: [PATCH] ob-java

That is true. I will make it less rigid. On Mon, Nov 9, 2020 at 9:07 AM Jarmo Hurri wrote: > > Hello Ian! > > ian martins writes: > > > Let me know how it goes. > > The new version seems to be sensitive to whitespace: > > # - > * this one works >

How to wrap Org code generated by a source block?

Hi everyone, I want to generate some parts of my document programmatically from an emacs-lisp src block - i.e. the code produces Org markup which I want to then export. Is there a way to wrap the #+RESULTS block in an environment that still gets evaluated as Org text (e.g. when exporting)? More d

Re: Thoughts on the standardization of Org

* Maxim Nikulin [2020-11-09 17:06]: 2020-11-08 Jean Louis wrote: That is right, I am using it since years in ~/.mailcap that works well for mutt email client. text/org; emacsclient %s; nametemplate=%s.org; text/x-org; emacsclient %s; nametemplate=%s.org; Just for curiosity, couldn't

Re: Thoughts on the standardization of Org

2020-11-10 Greg Minshall wrote: i would guess using 'cat -v' to read e-mail is 100% safe. even throwing in uudecode(1), or whatever is needed to decode base64, (and then piping through 'cat -v', of course ), it's probably still safe. Please, check that you have at least updated tmux before ap

Re: Viewing link information

2020-11-10 ian martins wrote: There is a shortcut to copy the link here . You could display it in the same way. It seems that original question was on viewing link, not copying it. As to copy, another possibility (borrowed from some stackove

Re: How to wrap Org code generated by a source block?

> On Nov 10, 2020, at 6:13 AM, Diego Zamboni wrote: > > I want to generate some parts of my document programmatically from an > emacs-lisp src block - i.e. the code produces Org markup which I want to then > export. Is there a way to wrap the #+RESULTS block in an environment that > still g

Re: How to wrap Org code generated by a source block?

Hi Chuck, Thanks! =:results drawer= is exactly what I was looking for :) I tried also with =:wrap src org=, but then upon export it's exported literally as Org src code, instead of interpreted as such. The drawer was exactly what I needed, and allows reevaluation of the block, replacing all the r

org-agenda-get-timestamps and properties

Hi, I have a problem with my appt.el replacement I develop. When debugging, I found that `org-agenda-get-timestamps' does, depending on the position of the SCHEDULED spec, do return a timestamp when an entry is formatted like this: ** APPT 10:40 Xyz :PROPERTIES: :ID: 1d313f9a-3044-

bug#44524: 28.0.50; Wrong place saved in org file with save-place-mode

tags 44524 fixed close 44524 28.0.50 quit > Package: emacs,org-mode > > 0. emacs -Q > 1. enable save-place-mode > 2. visit an org file with a single line: > > #+DATE: 2020-11-08 > > The cursor always jumps to the fixed place inside the date, > and doesn't remember its previous position. Here is a

Re: [PATCH] ob-ruby.el: allow specification of ruby command w/header arg

> Using the :ruby header arg. > > * lisp/ob-ruby.el (org-babel-execute:ruby): Locally set > `org-babel-ruby-command' using a header argument. > > TINYCHANGE > --- > lisp/ob-ruby.el | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/lisp/ob-ruby.el b/lisp/ob-ruby.el > index 669c2eabf..

Re: How to wrap Org code generated by a source block?

> On Nov 10, 2020, at 10:10 AM, Diego Zamboni wrote: > > I tried also with =:wrap src org=, but then upon export it's exported > literally as Org src code, instead of interpreted as such. The drawer was > exactly what I needed, and allows reevaluation of the block, replacing all > the resul

[FR] Don't hardcode checker functions prefix in org-lint

Hi All, This is a small feature request for `org-lint' not to hardcode the checker functions' prefix, as it currently does. `org-lint' is a small gem in Org, specially to those fat-fingered folks such as myself, to the point that it's been some time since I've been fancying using it to check

Re: Thoughts on the standardization of Org

* Maxim Nikulin [2020-11-10 19:31]: > 2020-11-10 Greg Minshall wrote: > > > > i would guess > > using 'cat -v' to read e-mail is 100% safe. even throwing in > > uudecode(1), or whatever is needed to decode base64, (and then piping > > through 'cat -v', of course ), it's probably still safe. > >

Re: Thoughts on the standardization of Org

* Maxim Nikulin [2020-11-10 19:22]: > > * Maxim Nikulin [2020-11-09 17:06]: > > > 2020-11-08 Jean Louis wrote: > > > > That is right, I am using it since years in ~/.mailcap that works well > > > > for mutt email client. > > > > > > > > text/org; emacsclient %s; nametemplate=%s.org; > > > >

Re: Thoughts on the standardization of Org

Jean Louis writes: > * Maxim Nikulin [2020-11-10 19:31]: >> 2020-11-10 Greg Minshall wrote: >> > >> > i would guess >> > using 'cat -v' to read e-mail is 100% safe. even throwing in >> > uudecode(1), or whatever is needed to decode base64, (and then piping >> > through 'cat -v', of course ),

Re: Thoughts on the standardization of Org

This is a great sub-thread that should probably be its own top level thread on org security. Org files are mostly benign unless the user does something extremely dangerous like setting enable-local-eval t. However, there are some areas where arbitrary code can be executed (as intended) that some u

Re: Thoughts on the standardization of Org

Tom Gillespie writes: > This is a great sub-thread that should probably be its own top level > thread on org security. > > Org files are mostly benign unless the user does something extremely > dangerous like > setting enable-local-eval t. However, there are some areas where > arbitrary code ca

Re: How to wrap Org code generated by a source block?

> I tried also with =:wrap src org=, but then upon export it's exported > literally as Org src code, instead of interpreted as such. An alternative might also be =:wrap export org=. Diego Zamboni writes: > Hi Chuck, > > Thanks! =:results drawer= is exactly what I was looking for :) > > I tried

Re: Thoughts on the standardization of Org

Maxim, thanks. small note. > The sour story is that it is unsafe to feed non-trusted files directly > to terminal. A filter against control sequences is required. thus, the '-v' argument to cat(1) (which Rob Pike famously considered harmful. :) cheers.

Re: Thoughts on the standardization of Org

* Tim Cross [2020-11-11 01:30]: > > Jean Louis writes: > > > * Maxim Nikulin [2020-11-10 19:31]: > >> 2020-11-10 Greg Minshall wrote: > >> > > >> > i would guess > >> > using 'cat -v' to read e-mail is 100% safe. even throwing in > >> > uudecode(1), or whatever is needed to decode base64, (an

Re: Thoughts on the standardization of Org

Jean Louis writes: > * Tim Cross [2020-11-11 01:30]: >> >> Jean Louis writes: >> >> > * Maxim Nikulin [2020-11-10 19:31]: >> >> 2020-11-10 Greg Minshall wrote: >> >> > >> >> > i would guess >> >> > using 'cat -v' to read e-mail is 100% safe. even throwing in >> >> > uudecode(1), or whatever

Re: [PATCH] ob-java

Hi Jarmo, Jarmo Hurri writes: > (I wonder if it would be possible to have timestamps in worg. I have > bumped into situations before where I have not known the temporal > relationship between worg documentation and current org version.) Good point. I think worg documentation, when related to a