Re: [O] [PATCH] Re: HTML export with ":export" parameter with Orgmode 9.0
Hello,
"Charles C. Berry" writes:
> OK. I changed the name to `org-export-process-with-babel', which
> I hope suggests more profound actions than
> `org-export-babel-evaluate'.
Thank you.
Thinking about it, wouldn't `org-export-use-babel' or even
`org-export-with-babel' (as `org-export-with-author'...) be simpler and
yet, as clear?
> I think the attached patch does this properly, but this is my first
> use of `define-obsolete-function-alias', so it might be best to check
> what I have done.
It looks good.
> From 3885129980a02eb0d4694e9e15888dea6ee95c60 Mon Sep 17 00:00:00 2001
> From: Charles Berry
> Date: Sat, 12 Nov 2016 18:54:20 -0800
> Subject: [PATCH] make-obsolete-variable `org-export-babel-evaluate'
What about:
Replace `org-export-babel-evaluate' with `org-export-process-with-babel'
> * doc/org.texi: Better explain what the variable
> `org-export-process-with-babel' does.
>
> * lisp/ob-exp.el: Small docstring change.
>
> * lisp/org-compat.el: Define `org-export-babel-evaluate' as the
> obsolete alias for `org-export-process-with-babel'.
>
> * lisp/ox-icalendar.el, lisp/ox.el, testing/lisp/test-ob-exp.el,
> testing/lisp/test-ob-lob.el, testing/lisp/test-ox.el: Change the
> obsolete variable name in many places.
Could you also specify the functions, or the manual section, being
modified?
OTOH, I don't think the chande made to "org-compat" requires an entry.
> Users were often confused that setting this variable to nil will cause
> header arguments to be ignored in addition to preventing code from
> being evaluated. It is hoped that the documentation changes and the
> name `org-export-process-with-babel' will better convey that everything
> babel does can be switched off with this variable.
> ---
> doc/org.texi| 24 +---
> lisp/ob-exp.el | 12 ++--
> lisp/org-compat.el | 2 ++
> lisp/ox-icalendar.el| 2 +-
> lisp/ox.el | 2 +-
> testing/lisp/test-ob-exp.el | 36 ++--
> testing/lisp/test-ob-lob.el | 2 +-
> testing/lisp/test-ox.el | 2 +-
> 8 files changed, 43 insertions(+), 39 deletions(-)
>
> diff --git a/doc/org.texi b/doc/org.texi
> index ede2352..81364d2 100644
> --- a/doc/org.texi
> +++ b/doc/org.texi
> @@ -14938,17 +14938,19 @@ Both the code block and its results will be
> exported.
> Neither the code block nor its results will be exported.
> @end table
>
> -It is possible to inhibit the evaluation of code blocks during export.
> -Setting the @code{org-export-babel-evaluate} variable to @code{nil} will
> -ensure that no code blocks are evaluated as part of the export process. This
> -can be useful in situations where potentially untrusted Org mode files are
> -exported in an automated fashion, for example when Org mode is used as the
> -markup language for a wiki. It is also possible to set this variable to
> -@code{inline-only}. In that case, only inline code blocks will be
> -evaluated, in order to insert their results. Non-inline code blocks are
> -assumed to have their results already inserted in the buffer by manual
> -evaluation. This setting is useful to avoid expensive recalculations during
> -export, not to provide security.
> +It is possible to inhibit the evaluation of code blocks and ignore header
> +arguments during export. Setting the @code{org-export-process-with-babel}
> +variable to @code{nil} will ensure that no code blocks are evaluated as part
> +of the export process. This can be useful in situations where potentially
> +untrusted Org mode files are exported in an automated fashion, for example
Nitpick: Org files
> +when Org mode is used as the markup language for a wiki. No header arguments
Nitpick: when Org is used as ...
Rationale : in both case, we refer to Org as a markup language, not as
an editing mode.
> +will be processed. For this reason it is often better to set `:eval
> +never-export' to prevent code evaluation but still allow headers to be
> +honored. It is also possible to set this variable to @code{inline-only}. In
> +that case, only inline code blocks will be evaluated, in order to insert
> +their results. Non-inline code blocks are assumed to have their results
> +already inserted in the buffer by manual evaluation. This setting is useful
> +to avoid expensive recalculations during export, not to provide
> security.
Could you add
@vindex org-export-process-with-babel
above the whole paragraph?
> Code blocks in commented subtrees (@pxref{Comment lines}) are never evaluated
> on export. However, code blocks in subtrees excluded from export
> diff --git a/lisp/ob-exp.el b/lisp/ob-exp.el
> index 6aebcd5..1d77e6a 100644
> --- a/lisp/ob-exp.el
> +++ b/lisp/ob-exp.el
> @@ -38,10 +38,10 @@
>
> (defvar org-src-preserve-indentation)
>
> -(defcustom org-export-babel-evaluate t
> - "Switch controlling code evaluation during export.
> +(defcustom org-export-process-with-babel t
Re: [O] “Match data clobbered by buffer modification hooks”
Nicolas Goaziou writes:
> Evaluate the following function (C-x C-e) and test again.
I am still experiencing the problem when I try to complete daily
recurring task and in the meantime I’ve migrated from Debian (Sid) to
Fedora (f25-beta) where there is only Emacs-25 packaged.
Here is the simple task causing the problem:
** TODO test
DEADLINE: <2016-11-13 Ned +1d>
:PROPERTIES:
:LAST_REPEAT: [2016-11-13 Ned 08:41]
:END:
In the attachment I include backtrace log. (debug.log)
Sincerely,
Gour
Your bug report will be posted to the Org mailing list.
Debugger entered--Lisp error: (error "Match data clobbered by buffer
modification hooks")
replace-match(#(" :LAST_REPEAT: [2016-11-13 Ned 08:41]" 0 3 (fontified nil)
3 4 (fontified nil) 4 15 (fontified nil) 15 16 (fontified nil) 17 39 (fontified
nil)) t t)
org--align-node-property()
org-indent-line()
org-entry-put(nil "LAST_REPEAT" "[2016-11-13 Ned 08:41]")
org-auto-repeat-maybe("DONE")
#[0 "\306\307!\210\310\307!\203 \311
\210\301\307\240\210\312\n!\203 \313\225Sb\210\312\314 \315Q!\204) \312\316!\210\317
\320 \317
\321\322\313\323\324\325!\326\"\327\330%DC\216\331\332\333\307\211$)\262\f
@ @\300\242\313\232\203` \300\332\240\210\334\202b A A\335\336!\313\224\337!\340B\"\211A@\3278\3418\206\200 \342 C\307 DE\235\211AF\203\265 \300\242\343\232\203\237 G\344=\204\260 \300\242\204\265 G\203\265 G\344=\204\265 \345
\202\374\300\242\346\232\203\323 G\203\306 F\204\323 \347\350\351\352E\"\332\307$\202\374\300\242\353=\203\356 \203\350 \211\205\374\211@\202\374E@\202\374\300\242\354=\203 E\232?\205\374\203\355EGG\356#E8\202\374E *\357*!@)\202\374G\307=\2031\300\242\360\232\2031\300\332\240\206\374\300\242\203\264\300\242\342\232\203A\332\202\374\300\242\361=\203L\332\202\374\300\242\362=\203]\206\374H@\202\374\300\242\363=\203tI\235A@\206\374I@\202\374\300\242\364=\203\222\365I! II\235A@\206\216I@)\202\374\300\242E\235@\206\374\300\242;\203\251\366\367\300\242\"\202\374\370\300\242!SE8\202\374\204\303\206\374E@\202\374\232\203\316\332\202\374\211\204\326\332\202\374\371>\203\372JK=\203\351\211@\202\374\211G\313V\205\374\206\374H@\202\374\211@ L\372\373LC#\206\nL\211 L\203\374L\374Q\202\374\375\376\377\f\201Y L\201Z \257\332\211M\203\222\fH\235?N\212\317
\321\322\313\323\324\325!\201[ \"\327\330%DC\216\212\214~\210\201\\ \201M \"+\262)\204\222\201] \201^ !\203{\366\201_ LO$\210\202\222\201` \201_ LO$\210\201a \201b \332\"\210\201c !\210\201d \307\211#\210\fL\232\203\324\201` \201e \332\201f \203\276\201g \202\301\201h \342\201f \201i \342##\266\202\"\210\202\201j \f!\203\201` \201k \332\201f \203\362\201g \202\365\201h \342\201f \201i \342##\266\202\"\210\n\204*\337L!\262 \340 B\"\262\n
A@\262
\327\n8\262\341\n8\262\300\242\201l >\203^\201` \201m \355PG\201n \340LP\"P>G#PG\201o \201p \340LP\"\374#$\210LH\235?NLH\235\205t\fH\235?\262
\203\202\201q !\210@\204\213\f\203*A\307=\204*\300\242\201r >\204*\340L@\"A@\206\256\356\340@\"8\262\334=\203\302A\334=\203\302\201s \262L\204\314Q\203\341L\203\353LR\235\203\353\fR\235\204\353\201t \332\211\201u #\210\211\203\f\203\201t \201u \201v
\"\210\204\f\334=\203\201w \362L\334$\210L\203*\203*\201w \201x L$\210\201y L!\210S\203BT\204B\201z \332\307\"\210U\203L\201{
\210\201| \201} !\210\300\242\203gLH\235\204g\337L!\262 \201~ \320 \201
\201\200 $\210\211\203\251\201\201 \201V !\203\242\317
\321\322\313\323\324\325!\201\202 \"\327\330%DC\216\201\203
V)\210\201\204 L!\210\201\205
\203\345n\204\345\212\201\206 \336!\210\312W!)\203\345`\356\211\225\206\314\336\225\\W\203\345\356\225\206\330\336\225b\210\312\374!\203\345\201\207
\210X\203\365\212\201\210 \201X \"\210)\301\242\205\374\311 .\207" [(nil)
(nil) org-outline-regexp org-todo-regexp org-log-done org-log-repeat
org-back-to-heading t org-in-commented-heading-p org-toggle-comment looking-at
0 " +" "\\( +\\|[ ]*$\\)" "\\(?: *\\|[]*$\\)" match-data point-at-bol
funcall make-byte-code "\301\300\302\"\207" vconcat vector [set-match-data
evaporate] 3 "\n\n(fn)" org-entry-get nil "LOGGING" note match-string 1
org-get-todo-sequence-head assoc 4 "" (4) prefix org-fast-todo-selection (4)
completing-read "State: " mapcar list right left - 2 last (4) none ...] 28
"\n\n(fn)"]()
funcall(#[0 "\306\307!\210\310\307!\203 \311
\210\301\307\240\210\312\n!\203 \313\225Sb\210\312\314 \315Q!\204) \312\316!\210\317
\320 \317
\321\322\313\323\324\325!\326\"\327\330%DC\216\331\332\333\307\211$)\262\f
@ @\300\242\313\232\203` \300\332\240\210\334\202b A A\335\336!\313\224\337!\340B\"\211A@\3278\3418\206\200 \342 C\307 DE\235\211AF\203\265 \300\242\343\232\203\2
Re: [O] “Match data clobbered by buffer modification hooks”
Hello, Saša Janiška writes: > Nicolas Goaziou writes: > >> Evaluate the following function (C-x C-e) and test again. > > I am still experiencing the problem when I try to complete daily > recurring task and in the meantime I’ve migrated from Debian (Sid) to > Fedora (f25-beta) where there is only Emacs-25 packaged. > > Here is the simple task causing the problem: > > ** TODO test >DEADLINE: <2016-11-13 Ned +1d> >:PROPERTIES: >:LAST_REPEAT: [2016-11-13 Ned 08:41] >:END: > > In the attachment I include backtrace log. (debug.log) I still cannot reproduce it. Judging by your report, you don't use a minimal init file either. Have you tried with -Q, modulo load-path setting to include Org 9.0? Regards, -- Nicolas Goaziou
Re: [O] Org-mode: need install/config help on org-plus-contrib-20161102
Hello, Paul Johnson writes: > Mr. Google says org mode in Emacs can work. I'll try that! (I said on > Wednesday). For 2 days I've been fighting with the install & > configuration. I am pretty sure I'm caught in a Bermuda triangle > configuration, where org-mode that comes with Emacs is too old, but > the new one from ELPA results in a fail because its pieces are not > finding what they want. See (info "(org) Installation") In particular, Important: you need to do this in a session where no ‘.org’ file has been visited, i.e., where no Org built-in function have been loaded. Otherwise autoload Org functions will mess up the installation. Regards, -- Nicolas Goaziou
Re: [O] Bug: Duplicated internal crossreference IDs in org-html-publish-to-html [9.0 (release_9.0-251-gc04501 @ /usr/share/emacs/site-lisp/org/)]
On Fr, 2016-11-11 at 17:50, Nicolas Goaziou wrote: [...] >> I would expect unique IDs instead. > > Fixed. Thank you. Thank you! Best regards Michael Strey -- http://www.strey.biz * https://twitter.com/michaelstrey
Re: [O] [bug] timed repeater shows up in wrong place
Hello, Samuel Wales writes: > ok, i have a new -Q minimal testcase, which is attached. it explains > how to run it at the top. > > the relevant part is at the bottom, so you could just copy that if you > prefer to try your own setup instead. it's 3 lines. > > the task is this: > > *** NEXT xyzzy test > SCHEDULED: <2016-11-07 Mon 17:00 .+1d> > make this be a date that is before real-time today > it should show up in agenda time grid > but it does not I can reproduce it, now. > note that this time, (setq org-agenda-repeating-timestamp-show-all nil). This was the missing setting. Notwithstanding the bug, I'm not sure to understand what is your use case here. If a nil `org-agenda-repeating-timestamp-show-all' treated time-stamps with a repeater as regular time-stamp in the agenda, I could see a use for that. However, AFAIU, a nil `org-agenda-repeating-timestamp-show-all' treats a time-stamp with a repeater as its closest repeat (from today). It makes little sense, in particular with schedules or deadlines. So, what is wrong with `org-agenda-repeating-timestamp-show-all' default value? Regards, -- Nicolas Goaziou
Re: [O] Bug: second batch of small documentation problems [9.0 (9.0-elpaplus @ /home/jorge/.emacs.d/elpa/org-plus-contrib-20161102/)]
Hello, Jorge Morais Neto writes: > On 11 November 2016 at 22:47, Nicolas Goaziou wrote: >> `org-tag-persistent-alist' is about "characters". I think it is clear >> that characters are case-sensitive already. > Currently, the docstring of org-tag-alist says "SELECT is a case-sensitive > letter" and the docstring of org-tag-persistent-alist says "SELECT is a > character". I thought I should point this out, but it is your call whether > this > inconsistency needs to be fixed. Fixed. >> AFAICT any character is allow, but how could we formulate this?. > Any Emacs character is allowed? If so, perhaps we could just say "SELECT is > an > Emacs character (this includes all Unicode characters)". But beware that I > know little Org and very little Elisp, so please take my suggestion with a > grain of salt. I was speaking about Org manual. In any case, I worked around this. Thank you. Regards, -- Nicolas Goaziou
Re: [O] [bug] timed repeater shows up in wrong place
On 11/13/16, Nicolas Goaziou wrote: > I can reproduce it, now. thanks. > If a nil `org-agenda-repeating-timestamp-show-all' treated time-stamps > with a repeater as regular time-stamp in the agenda, I could see a use > for that. not sure what you mean by this. > However, AFAIU, a nil `org-agenda-repeating-timestamp-show-all' treats > a time-stamp with a repeater as its closest repeat (from today). It which means today, right? in org 9, this has changed. > makes little sense, in particular with schedules or deadlines. i don't get why. > So, what is wrong with `org-agenda-repeating-timestamp-show-all' default > value? t you mean? if i am showing today and tomorrow, or the whole week, i don't want to see the repeater show up on every day. i just want it to show up today. then i doneify it, and then i just want it to show up tomorrow. this is org 8 behavior for me. not sure we're communicating accurately though. -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. And ANYBODY can get it. Denmark: free Karina Hansen NOW. UPDATE 2016-10: home, but not fully free
[O] Stuck projects documentation suggestion
Hi! Looking at http://orgmode.org/manual/Stuck-projects.html>, it wasn't clear to me that "+PROJECT/-MAYBE-DONE" was something called a "match syntax". If the documentation could be extended to include this information, and a link to the matching tags and properties page, it would be more understandable for new users. (Of course, it would also make the page more verbose, but I think the length of this page is short enough that it could probably be an acceptable trade-off.) The docstring for "org-stuck-projects" does include a reference to the match syntax. (However, "C-h v" (describe variable) didn't work for "org-stuck-projects" for me until I loaded "org-agenda", which was surprising from my perspective as a newbie.) All the best, Jon
Re: [O] [bug] timed repeater shows up in wrong place
Hello, Samuel Wales writes: > On 11/13/16, Nicolas Goaziou wrote: >> If a nil `org-agenda-repeating-timestamp-show-all' treated time-stamps >> with a repeater as regular time-stamp in the agenda, I could see a use >> for that. > > not sure what you mean by this. I mean that a variable ignoring all repeaters in agenda is useful. It means that, e.g., <2016-11-13 Sun +1d> is seen as <2016-11-13 Sun> To put it differently, this would ignore repeaters until the task is marked as done, which is repeaters original purpose. However `org-agenda-repeating-timestamp-show-all' seems to do something different. >> However, AFAIU, a nil `org-agenda-repeating-timestamp-show-all' treats >> a time-stamp with a repeater as its closest repeat (from today). It > > which means today, right? in org 9, this has changed. It doesn't mean necessarily today. Let's assume today is <2016-11-13 Sun>. Now, consider, e.g., <2016-11-09 Wed +3d> Closest repeat in the future is <2016-11-15 Tue +3d>, which is neither today nor tomorrow. AFAIU, a nil `org-agenda-repeating-timestamp-show-all' means that nothing will appear on <2016-11-09 Wed>, but the task will be displayed on <2016-11-15 Tue>, as if it was automatically marked as done without my consent. Odd. Note that I could understand the use for that. But there is worse: <2016-11-09 Wed .+3d> In this case, I cannot possibly guess when the next repeat is going to show, since it depends on the date at which the task is done. As a consequence, treating the above as <2016-11-09 Wed +3d> is just plain wrong IMO. Every repeat displayed in the agenda could be inaccurate. >> makes little sense, in particular with schedules or deadlines. > > i don't get why. Because schedules and deadlines are already repeated, somehow, in the agenda. Today being <2016-11-13 Sun>, let's consider a task, not done yet, with the following SCHEDULED time: <2016-11-09 Wed +1d> I will get "Sched.4x". Yet closest repeat is today, so a nil `org-agenda-repeating-timestamp-show-all' dumbly displays the task without the "Sched.4x". I lost the information the task started 4 days ago. If I mark it as done, it still appears on today, without any feedback telling me it is a new task that started 3 days ago, this time. Why would I want that? >> So, what is wrong with `org-agenda-repeating-timestamp-show-all' default >> value? > > t you mean? if i am showing today and tomorrow, or the whole week, i > don't want to see the repeater show up on every day. OK, if you mainly use "+1d" repeaters, it can be a bit verbose. But then again, if `org-agenda-repeating-timestamp-show-all' ignored the repeat altogether, it wouldn't fill up the agenda. > i just want it to show up today. then i doneify it, and then i just > want it to show up tomorrow. this is org 8 behavior for me. Again, if `org-agenda-repeating-timestamp-show-all' ignored the repeat part, you would still have this with schedules and deadlines, as exhibited above. The only difference would be with plain time-stamps (no SCHEDULED nor DEADLINE keyword). In Org 8, <2016-11-09 Wed +1d> appears today, no matter what "today" means for the agenda. Ignoring the repeater would not make it appear today unless today is <2016-11-09 Wed>, of course. > not sure we're communicating accurately though. It is difficult to communicate since the subject is not very well defined. In a nutshell, I fail to see any use for this variable for schedules and deadlines (except, perhaps, in the future part of the agenda). I also fail to see any use for it in conjunction with ".+" and "++" repeaters. I can be wrong, but I'd like to understand where. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] Re: HTML export with ":export" parameter with Orgmode 9.0
On Sun, 13 Nov 2016, Nicolas Goaziou wrote: Hello, "Charles C. Berry" writes: [snip] Thinking about it, wouldn't `org-export-use-babel' or even `org-export-with-babel' (as `org-export-with-author'...) be simpler and yet, as clear? You are right. `org-export-use-babel' it is. Thanks for the suggestions. I pushed them to master just now. Chuck
Re: [O] Org-mode: need install/config help on org-plus-contrib-20161102
On Sun, Nov 13, 2016 at 5:42 AM, Nicolas Goaziou wrote: > Hello, > > Paul Johnson writes: > >> Mr. Google says org mode in Emacs can work. I'll try that! (I said on >> Wednesday). For 2 days I've been fighting with the install & >> configuration. I am pretty sure I'm caught in a Bermuda triangle >> configuration, where org-mode that comes with Emacs is too old, but >> the new one from ELPA results in a fail because its pieces are not >> finding what they want. > > See (info "(org) Installation") > > In particular, > > Important: you need to do this in a session where no ‘.org’ file has > been visited, i.e., where no Org built-in function have been loaded. > Otherwise autoload Org functions will mess up the installation. > > That's a soul crusher. Thanks for explaining. I found another way to get this wrong. Switch between version 24.5 and 25.1. pj > Regards, > > -- > Nicolas Goaziou -- Paul E. Johnson http://pj.freefaculty.org Director, Center for Research Methods and Data Analysis http://crmda.ku.edu To write to me directly, please address me at pauljohn at ku.edu.
[O] Org mode mobile
Is their a newsgroup for mobil org? Is their a way to display a visual calendar in mobile org. Is their a way to syncronize my emacs calendar/ orgmode calendar with mobile org. Is their a way to sync my iPhone mobile org to my OS X emacs and org mode?
[O] sync iPhone mobile org to mac with cable
Is their a way to sync my iPhone mobile org to org mode or emacs with a cable?
Re: [O] [PATCH] Re: HTML export with ":export" parameter with Orgmode 9.0
Hello, "Charles C. Berry" writes: > Thanks for the suggestions. I pushed them to master just now. Thank you. Regards, -- Nicolas Goaziou
