Re: [O] company-mode completions for noweb references
On Tuesday, 6 Nov 2018 at 19:32, Nik Clayton wrote: > Hoi, > > I've been writing a few things using Org where I'm making frequent use of > noweb references in SRC blocks, and decided that completion would be handy > for them. Thanks for this. Very useful. I'll incorporate it into my config and will come back if I see anything strange. -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.13-783-g97fac4
Re: [O] Tasks performed on a certain day
What about passive date stamps? TODO Thing ? -k. Please excuse brevity. Sent from tiny pocket computer with non-haptic feedback keyboard. On Tue, Nov 6, 2018, 17:19 Leo Gaspard Eric S Fraga writes: > > On Tuesday, 6 Nov 2018 at 22:59, Leo Gaspard wrote: > >> It is a task, so I want to be able to mark it as done and not see it for > >> the rest of the day. But at the same time I can't SCHEDULE <> it, > >> because otherwise if I don't do it the right day then it still bothers > >> me the day after, at which I can't do it any longer any way. > > > > what if you add a, for instance, MISSED task indicator, equivalent to > > DONE so that you can record that you didn't do the task and then move > > on to the next scheduled time? > > I was hoping for something that would automatically mark the task as > missed (well, I don't care about the task being marked as missed > actually, just about it no longer appearing on my agenda), but I guess > if it's not possible then this can do. Thank you :) > >
Re: [O] Tasks performed on a certain day
Eric S Fraga writes: > On Tuesday, 6 Nov 2018 at 22:59, Leo Gaspard wrote: >> It is a task, so I want to be able to mark it as done and not see it for >> the rest of the day. But at the same time I can't SCHEDULE <> it, >> because otherwise if I don't do it the right day then it still bothers >> me the day after, at which I can't do it any longer any way. > > what if you add a, for instance, MISSED task indicator, equivalent to > DONE so that you can record that you didn't do the task and then move > on to the next scheduled time? I was hoping for something that would automatically mark the task as missed (well, I don't care about the task being marked as missed actually, just about it no longer appearing on my agenda), but I guess if it's not possible then this can do. Thank you :)
Re: [O] Bug: ODT export fails if NAME: and ref: equation [9.1.14 (9.1.14-1-g4931fc-elpa @ /home/kdm/.emacs.d/elpa/org-20180910/)]
On Mon, Nov 5, 2018, 13:59 Nicolas Goaziou > What would be the expected output? > There is no output. It doesn't even export. It's a showstopper. No references to equations allowed or the exporter fails. -k.
[O] Org --> Canvas LMS
So, this really isn't ready for anyone else to use yet, but I've spent the last day or so exploring the API for the Canvas Learning Management System and adapting my grading system to interact with it. My results are rough and I think a little buggy (I'm worried about timeouts and how to manage them), but still promising. My University just adopted Canvas in September and while I don't like to use the interface, it has a pretty robust API and the prospects for usability are actually pretty good. I have been grading in org-mode for the last couple of years but my system was always wonky; I've cleaned the code up a tiny bit (still polluting with (message) calls all over the place), and it seems a bit more stable. Not sure if anyone else is tied in to Canvas, but if it might be useful my work is in this git branch here: https://github.com/titaniumbones/Org-Marking-Mode/tree/use-structured-course-def Let me know if you have a chance to give it a try. Thanks, Matt
Re: [O] Bug: Capture template insertion fails with #+FOO [9.1.14 (9.1.14-1-g4931fc-elpa @ /home/phil/.emacs.d/elpa/org-9.1.14/)]
On Mon, 5 Nov 2018 at 21:46, Nicolas Goaziou wrote:
>
> Philip Hudson writes:
>
> > On Sun, 4 Nov 2018 at 14:03, Nicolas Goaziou wrote:
>
> >> No, it is not the case. AFAIU, in the minimal failing case, you capture
> >>
> >> #+FOO: bar
> >> * Baz
> >>
> >> This is _not_ a node. A node starts with a headline and everything is
> >> contained within that headline. So it doesn't qualify as a valid `entry'
> >> capture type.
> >
> > That's disappointing, and, obviously, news to me. So I have not
> > encountered a regression but rather a tightening of the existing
> > documented contract. Is that a fair interpretation of what you're
> > saying? If so, and not that I doubt you, do you have a reference for
> > that?
>
> It is not a tightening of anything. The function responsible for the
> raised error is `org-capture-verify-tree'. It is called from the
> function responsible for capturing `entry' types since December 2010:
>
> commit 8aacc708dd038fd0d351abbed04d49f813f8a7bf
> Author: Carsten Dominik
> Date: Thu Dec 16 16:51:04 2010 +0100
>
> Capture: Better error message for invalid entry-type templates
>
> It seems to me the intent is clear, and from the documentation,
> I wouldn't have thought about inserting data before the headline.
Ah-ha! I thought not. I want to contest the use of the word "data"
here; see below.
> I'm
> surprised that your template even worked at some point.
This is baffling to me, but ultimately unimportant..
> I did my homework, though. I tried the following set-up
>
> (setq org-capture-templates
> '(("B" "BUG" entry (file "/tmp/bug-capture.org") "#+BAR: baz\n* Foo"
> :immediate-finish t)))
>
> Even in Org 8.2.10, which is old in my book, I got an error mentioning
> the template was invalid.
>
> > The idea of 'entry type for templates, and of a node as we are
> > discussing it, is that a well-formed and valid Org file is composed
> > exclusively of these entities and nothing else. Correct?
>
> Not at all. I'm absolutely not talking about what is a valid Org file.
> See for this.
>
> I'm talking about what can be captured using an `entry' template, i.e.,
> a node/heading/entry and that's it.
>
> > Sorry if this is getting tiresome. At this point I'm content for you
> > to close this issue and move on if you'd rather. I'll change my
> > template type to 'plain, or find some other workaround. But if you'd
> > like to keep going for the sake of clarifying what the right and
> > proper meaning of 'entry and "node" are then I'm glad to participate.
>
> Entry, node, and heading (and to some extent, headline) are synonyms.
> They mean star(s) at the beginning of line, followed by a space, and
> optionally other stuff of that line.
>
> Contents can be anything as long as no line starts with as many or less
> stars followed by a space, i.e., there is no headline of a lesser or
> equal level.
>
> In any case, if documentation needs to be clarified, please let me know.
I'm not ready to let go of the question of the definition of an entry.
You have been very clear and categorical about the definition of a
top-level entry/node/heading as a chunk of text starting with a single
asterisk (followed by whitespace, arbitrary heading text, optional
tags and optional further lines of text -- the foundational structure
all Org users are familiar with). You insist that if there is
Something Else before that asterisk -- "data", in your latest reply --
then your chunk of text is simply and categorically not an entry. Such
a chunk of text may or may not /contain/ an entry, but it is
definitely not itself an entry.
Can we agree that what we are doing here is lexing? That is essential
to my argument that follows. If we are, then I think I have a good
case to make. Here it is:
For any preceding Something Else to disqualify a chunk of text as an
entry, it must first be Something. Lexically speaking, in-buffer
settings are comments; thus, lexically speaking, they are whitespace;
thus, lexically speaking, they are Nothing, not Something. That is my
argument for allowing preceding in-buffer settings within the
definition of an entry, not just in the context of org-capture but
throughout Org.
I hope I'm making myself clear. Am I wrong about any of this, and if
so, why and how? What I really want to know is: what is wrong with my
suggested change, temporarily stripping leading in-buffer settings
during the call to `org-capture-verify-tree'? What breaks? What do we
lose by implementing it? What do we gain by not implementing it? What
depends on such a change /not/ being made? As I said myself, it feels
like an inglorious kludge, but would it actually be wrong in some way
within the semantics and working constraints of Org? Should that
temporary stripping-out of preceding in-buffer settings actually be
implemented not in `org-capture-verify' but in the core-Org function
it calls, `org-kill-is-subtree-p', thus
[O] company-mode completions for noweb references
Hoi, I've been writing a few things using Org where I'm making frequent use of noweb references in SRC blocks, and decided that completion would be handy for them. This function will complete "^<<" with a list of the defined named blocks in the current file, if you're in a SRC block. It could be made smarter (e.g., only offer the completion if ":noweb yes" is set, only offer to complete from named blocks with the same language as the current block), but I thought I'd throw it out here in case anyone else finds it useful. Best, N (defun my/org-src-block-name-backend (command arg ignored) "Complete `<<' with the names of defined SRC blocks." (interactive (list 'interactive)) (cl-case command (interactive (company-begin-backend 'my/org-src-block-name-backend)) (init (require 'org-element)) (prefix (and (eq major-mode 'org-mode) (eq 'src-block (car (org-element-at-point))) (cons (company-grab-line "^<<\\(\\w*\\)" 1) t))) (candidates (org-element-map (org-element-parse-buffer) 'src-block (lambda (src-block) (let ((name (org-element-property :name src-block))) (when name (propertize name :value (org-element-property :value src-block) :annotation (org-element-property :raw-value (org-element-lineage src-block '(headline) (sorted t); Show candidates in same order as doc (ignore-case t) (duplicates nil) ; No need to remove duplicates (post-completion ; Close the reference with ">>" (insert ">>")) ;; Show the contents of the block in a doc-buffer. If you have ;; company-quickhelp-mode enabled it will show in a popup (doc-buffer (company-doc-buffer (get-text-property 0 :value arg))) (annotation (format " [%s]" (get-text-property 0 :annotation arg) (add-to-list 'company-backends 'my/org-src-block-name-backend)
Re: [O] Tasks performed on a certain day
On Tuesday, 6 Nov 2018 at 22:59, Leo Gaspard wrote: > It is a task, so I want to be able to mark it as done and not see it for > the rest of the day. But at the same time I can't SCHEDULE <> it, > because otherwise if I don't do it the right day then it still bothers > me the day after, at which I can't do it any longer any way. what if you add a, for instance, MISSED task indicator, equivalent to DONE so that you can record that you didn't do the task and then move on to the next scheduled time? untested... -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.13-894-gf79545
Re: [O] Bug: Capture problems with newlines [9.1.14 (9.1.14-9-g131531-elpa @ /home/calvin/.emacs.d/elpa/org-20181105/)]
Hello,
Calvin Beck writes:
> I have this problem where I have a capture template like this:
>
>> ("t" "Todo" entry (file+headline "~/org/todo.org" "Tasks")
>>"* TODO %?\n SCHEDULED: %t\n %a\n")
>
> And then if I have another heading under Tasks...
>
>> * Tasks
>> * HEADING2
>
> Then when capturing a todo entry, if I delete the last line I get something
> like...
>
>> * Tasks
>> ** TODO
>>SCHEDULED: <2018-11-05 Mon>
>>link* HEADING2
>
> And similarly, if I edit the last line in the capture template I get...
>
>> * Tasks
>> ** TODO
>>SCHEDULED: <2018-11-05 Mon>
>>link
>> the stuff that I added at the end of my capture template* HEADING2
>
> This is counter intuitive, as you expect the capture to be isolated from
> the other headings. Additionally, it's not obvious that you are messing
> up other headings when you are using org-capture, so you can end up
> losing tasks and headings, which seems like a very bad behaviour!
Could you test again with development version? I think it was fixed
recently.
Regards,
--
Nicolas Goaziou
Re: [O] [BUG][ODT] ODT_STYLES_FILE not read as a list
On 06-11-18 16:35, Christian Moe wrote:
>
> I believe the need to use quotation marks around the style file name was
> removed at some point
I didn't know that. I had a quick look at the changes to ox-odt.el for
the last few months, but it doesn't seem to be mentioned in any of the
commit messages. Or was this a more global change?
Does this also count for the regular #+INCLUDE: statement? I just tested
it and for #+INCLUDE: it seems to work both with and without quotes
(although the manual uses quotes).
Best,
Lennart.
> , and the manual is out of date. Instead of
>
> #+ODT_STYLES_FILE: "template.ott"
>
> the manual ought now to read:
>
> #+ODT_STYLES_FILE: template.ott
>
> Yours,
> Christian
>
> L.C. Karssen writes:
>
>> Hi list,
>>
>> Not sure if this is related (or fixed with the aforementioned patch)
>> because I'm not using a list for the ODT style file.
>>
>> Today, after upgrading from Org 9.1.13 (actually installed from melpa on
>> 20180625) to melpa version 20181105 exporting to ODT stopped working. In
>> my org file the style file name was enclosed in double quotes (as
>> specified in the manual [1]):
>>
>> #+ODT_STYLES_FILE: "template.ott"
>>
>> The error message is:
>>
>> OpenDocument export failed: Invalid specification of styles.xml file:
>> "\"template.ott\""
>>
>> Removing the quotes fixes the export to ODT.
>>
>>
>> Best regards,
>>
>> Lennart.
>>
>> [1] https://orgmode.org/org.html#Applying-custom-styles
>>
>>
>> On 05-11-18 09:49, Christian Moe wrote:
>>>
>>> Thanks, Nicolas!
>>>
>>> I'll test on my end when it shows up in ELPA.
>>>
>>> Yours,
>>> Christian
>>>
>>> Nicolas Goaziou writes:
>>>
Hello,
Christian Moe writes:
> It seems the ODT exporter currently fails to read the ODT_STYLES_FILE
> option as a list, as in this example from the manual
> ([[info:org#Applying custom styles]]):
>
> #+ODT_STYLES_FILE: ("/path/to/file.ott" ("styles.xml" "image/hdr.png"))
>
> This is needed if you want a complex style with e.g. an image in the
> header.
>
> Exporting this causes an "Invalid specification of styles.xml file"
> error on my recent ELPA version. The problem seems to be that the option
> is treated as a string and never tested to see if it contains a list.
>
> To reproduce the problem, place the attached documents
> odt-styles-test.org and odt-test-styles.odt in the same directory, then
> export odt-styles-test.org to ODT. The result should have a unicorn in
> the letterhead.
>
> The below quick-and-dirty patch seems to fix it, but I'm sure there's a
> better approach.
Thank you. I applied your patch with an additional check: the value should
be enclosed within round brackets.
Regards,
>>>
>>>
--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
L.C. Karssen
's-Hertogenbosch
The Netherlands
lenn...@karssen.org
http://blog.karssen.org
GPG key ID: A88F554A
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
signature.asc
Description: OpenPGP digital signature
Re: [O] using flet to suppress meta generation in html export?
AH, THISI S SUPER-HELPFUL, aARON. MANY THANK. i'M HOPING THAT BY THE TIME i RETIRE i WILL BEGIN TO UNDERSTAND LEXICAL SCOPING IN LISP... On Tue, Nov 6, 2018 at 10:35 AM Aaron Ecay wrote: > Hi Matt, > > 2018ko azaroak 6an, Matt Price-ek idatzi zuen: > > > > Hi, > > > > I was writing a function to quickly post the ocntents of subtrees to the > > Canvas Learning Management System. I was trying to strip down the > exported > > HTML to an absolute minimum and had forgotten about the body-only > paramter > > to org-export-as (!!). So, my solution was to try to rebind > > 'org-html--build-meta-info to always just return "". However, I can't > > seem to do it properly and I'm wondering if someone can help me figure > out > > what's wrong. It's my first time using cl-flet! And I know there are > > various approaches, but I odn't understnad whyt this is notworking, when > > for instance, this does work for me: > > > > (cl-flet ((+ > >(lambda ( args) (message "no plus!" > > (+ "whoops")) > > ;; "no plus!" > > > > Meanwhile, here's my non-functional code: > > Quoting from the info page (info "(cl) Function Bindings"): > > The bindings are lexical in scope. This means that all references > to the named functions must appear physically within FORMS. > > I believe that you can accomplish what you are trying to do with: > > (cl-letf (((symbol-function 'org-html--build-meta-info) >(lambda ( args) ""))) > your-code-here) > > You could also do something like: > > (let ((my-advice (lambda ( _) ""))) > (advice-add 'org-html--build-meta-info :override my-advice) > (unwind-protect > (progn > your-code-here) > (advice-remove 'org-html--build-meta-info my-advice))) > > (Why do I think this is better, despite being more verbose? Advice-add > is specifically designed to change the binding of functions at runtime, > and so it does some specialized things that cl-letf doesnʼt do. This in > turn means that it should be a more robust way of accomplishing the > desired outcome.) > > -- > Aaron Ecay >
Re: [O] [BUG][ODT] ODT_STYLES_FILE not read as a list
I believe the need to use quotation marks around the style file name was
removed at some point, and the manual is out of date. Instead of
#+ODT_STYLES_FILE: "template.ott"
the manual ought now to read:
#+ODT_STYLES_FILE: template.ott
Yours,
Christian
L.C. Karssen writes:
> Hi list,
>
> Not sure if this is related (or fixed with the aforementioned patch)
> because I'm not using a list for the ODT style file.
>
> Today, after upgrading from Org 9.1.13 (actually installed from melpa on
> 20180625) to melpa version 20181105 exporting to ODT stopped working. In
> my org file the style file name was enclosed in double quotes (as
> specified in the manual [1]):
>
> #+ODT_STYLES_FILE: "template.ott"
>
> The error message is:
>
> OpenDocument export failed: Invalid specification of styles.xml file:
> "\"template.ott\""
>
> Removing the quotes fixes the export to ODT.
>
>
> Best regards,
>
> Lennart.
>
> [1] https://orgmode.org/org.html#Applying-custom-styles
>
>
> On 05-11-18 09:49, Christian Moe wrote:
>>
>> Thanks, Nicolas!
>>
>> I'll test on my end when it shows up in ELPA.
>>
>> Yours,
>> Christian
>>
>> Nicolas Goaziou writes:
>>
>>> Hello,
>>>
>>> Christian Moe writes:
>>>
It seems the ODT exporter currently fails to read the ODT_STYLES_FILE
option as a list, as in this example from the manual
([[info:org#Applying custom styles]]):
#+ODT_STYLES_FILE: ("/path/to/file.ott" ("styles.xml" "image/hdr.png"))
This is needed if you want a complex style with e.g. an image in the
header.
Exporting this causes an "Invalid specification of styles.xml file"
error on my recent ELPA version. The problem seems to be that the option
is treated as a string and never tested to see if it contains a list.
To reproduce the problem, place the attached documents
odt-styles-test.org and odt-test-styles.odt in the same directory, then
export odt-styles-test.org to ODT. The result should have a unicorn in
the letterhead.
The below quick-and-dirty patch seems to fix it, but I'm sure there's a
better approach.
>>>
>>> Thank you. I applied your patch with an additional check: the value should
>>> be enclosed within round brackets.
>>>
>>> Regards,
>>
>>
Re: [O] using flet to suppress meta generation in html export?
Hi Matt, 2018ko azaroak 6an, Matt Price-ek idatzi zuen: > > Hi, > > I was writing a function to quickly post the ocntents of subtrees to the > Canvas Learning Management System. I was trying to strip down the exported > HTML to an absolute minimum and had forgotten about the body-only paramter > to org-export-as (!!). So, my solution was to try to rebind > 'org-html--build-meta-info to always just return "". However, I can't > seem to do it properly and I'm wondering if someone can help me figure out > what's wrong. It's my first time using cl-flet! And I know there are > various approaches, but I odn't understnad whyt this is notworking, when > for instance, this does work for me: > > (cl-flet ((+ >(lambda ( args) (message "no plus!" > (+ "whoops")) > ;; "no plus!" > > Meanwhile, here's my non-functional code: Quoting from the info page (info "(cl) Function Bindings"): The bindings are lexical in scope. This means that all references to the named functions must appear physically within FORMS. I believe that you can accomplish what you are trying to do with: (cl-letf (((symbol-function 'org-html--build-meta-info) (lambda ( args) ""))) your-code-here) You could also do something like: (let ((my-advice (lambda ( _) ""))) (advice-add 'org-html--build-meta-info :override my-advice) (unwind-protect (progn your-code-here) (advice-remove 'org-html--build-meta-info my-advice))) (Why do I think this is better, despite being more verbose? Advice-add is specifically designed to change the binding of functions at runtime, and so it does some specialized things that cl-letf doesnʼt do. This in turn means that it should be a more robust way of accomplishing the desired outcome.) -- Aaron Ecay
Re: [O] [BUG][ODT] ODT_STYLES_FILE not read as a list
Hi list,
Not sure if this is related (or fixed with the aforementioned patch)
because I'm not using a list for the ODT style file.
Today, after upgrading from Org 9.1.13 (actually installed from melpa on
20180625) to melpa version 20181105 exporting to ODT stopped working. In
my org file the style file name was enclosed in double quotes (as
specified in the manual [1]):
#+ODT_STYLES_FILE: "template.ott"
The error message is:
OpenDocument export failed: Invalid specification of styles.xml file:
"\"template.ott\""
Removing the quotes fixes the export to ODT.
Best regards,
Lennart.
[1] https://orgmode.org/org.html#Applying-custom-styles
On 05-11-18 09:49, Christian Moe wrote:
>
> Thanks, Nicolas!
>
> I'll test on my end when it shows up in ELPA.
>
> Yours,
> Christian
>
> Nicolas Goaziou writes:
>
>> Hello,
>>
>> Christian Moe writes:
>>
>>> It seems the ODT exporter currently fails to read the ODT_STYLES_FILE
>>> option as a list, as in this example from the manual
>>> ([[info:org#Applying custom styles]]):
>>>
>>> #+ODT_STYLES_FILE: ("/path/to/file.ott" ("styles.xml" "image/hdr.png"))
>>>
>>> This is needed if you want a complex style with e.g. an image in the
>>> header.
>>>
>>> Exporting this causes an "Invalid specification of styles.xml file"
>>> error on my recent ELPA version. The problem seems to be that the option
>>> is treated as a string and never tested to see if it contains a list.
>>>
>>> To reproduce the problem, place the attached documents
>>> odt-styles-test.org and odt-test-styles.odt in the same directory, then
>>> export odt-styles-test.org to ODT. The result should have a unicorn in
>>> the letterhead.
>>>
>>> The below quick-and-dirty patch seems to fix it, but I'm sure there's a
>>> better approach.
>>
>> Thank you. I applied your patch with an additional check: the value should
>> be enclosed within round brackets.
>>
>> Regards,
>
>
--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
L.C. Karssen
's-Hertogenbosch
The Netherlands
lenn...@karssen.org
http://blog.karssen.org
GPG key ID: A88F554A
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
signature.asc
Description: OpenPGP digital signature
Re: [O] [feature] Handle recurrence in <> and [] dates
Hi Julius, Julius Dittmar writes: > if you want a task to re-open at a later date upon closing, add a line of > :REPEAT_TO_STATE: TODO > to the PROPERTIES drawer of that task. Well, I guess I stated my problem poorly, sorry :) Here is a translated example task from my .org file: *** TODO Check bank report SCHEDULED: <2000-02-10 Thu +1m> Dated [2000-01-01 Sat +1m] The point of this “Dated” field being to tell me to which report I should be looking, given I sometimes am a month late or so in checking my reports, and just put them in the (physical) drawer as I receive them. This “Dated” field is exactly what I would like to see updated when I mark the task as done (like the SCHEDULED date), but it looks like it doesn't move. Is there a trick to do this? Cheers, Leo
[O] using flet to suppress meta generation in html export?
Hi,
I was writing a function to quickly post the ocntents of subtrees to the
Canvas Learning Management System. I was trying to strip down the exported
HTML to an absolute minimum and had forgotten about the body-only paramter
to org-export-as (!!). So, my solution was to try to rebind
'org-html--build-meta-info to always just return "". However, I can't
seem to do it properly and I'm wondering if someone can help me figure out
what's wrong. It's my first time using cl-flet! And I know there are
various approaches, but I odn't understnad whyt this is notworking, when
for instance, this does work for me:
(cl-flet ((+
(lambda ( args) (message "no plus!"
(+ "whoops"))
;; "no plus!"
Meanwhile, here's my non-functional code:
(defun org-lms-headline-to-announcement ( course)
(interactive)
(unless course
(setq course org-lms-course))
(cl-flet ((org-html--build-meta-info
(lambda ( args) "")))
;; (prin1 (symbol-function 'org-html--build-meta-info))
(let* ((org-export-with-toc nil)
(org-export-with-smart-quotes nil)
(org-html-postamble nil)
(org-html-preamble nil)
(org-html-xml-declaration nil)
(org-html-head-include-scripts nil)
(org-html-head-include-default-style nil)
;;(atext (org-export-as 'html t))
(atitle (nth 4 (org-heading-components)))
(org-html-klipsify-src nil)
(org-export-with-title nil)
(courseid (plist-get course :id))
(atitle (nth 4 (org-heading-components)))
(atext (org-export-as 'html t nil t))
)
;; (message "BUILDMETA DEFN")
;; (prin1 (symbol-function 'org-html--build-meta-info))
(message "%s" atext)
(org-lms-canvas-json-request
(format "courses/%s/discussion_topics" courseid) "POST"
`(("title" . ,atitle)
("message" . ,atext)
("is_published" . t)
("is_announcement" . t))
(well, I mean, it works now that I am doing body-only! doh!
I appreciate any hints, thank you!
Matt
[O] Tasks performed on a certain day
Hello world, I am trying to figure out a way to represent, in org-mode, tasks that should be performed exactly on one day of the week. For instance, taking out the garbage. It is a task, so I want to be able to mark it as done and not see it for the rest of the day. But at the same time I can't SCHEDULE <> it, because otherwise if I don't do it the right day then it still bothers me the day after, at which I can't do it any longer any way. Does anyone have a trick to handle this kind of “on-this-date task” with org-mode? Cheers, Leo
Re: [O] [feature] Handle recurrence in <> and [] dates
Hi Leo, if you want a task to re-open at a later date upon closing, add a line of :REPEAT_TO_STATE: TODO to the PROPERTIES drawer of that task. Hth, Julius
Re: [O] [feature] Handle recurrence in <> and [] dates
Hello all! It's been ~2 weeks so I hope you'll forgive me bumping my post :) Do you have an opinion about this idea? Cheers, Leo Leo Gaspard writes: > Hello all! > > I have been using org-mode for a few days (switching over from > todo.txt [1]), and for the time being my experience has been great! > > There is a single thing I found weird up to now: it seems that > recurrence tags in <> and [] “tags” don't get bumped when a task is > completed and has a recurrence set in its SCHEDULED or DEADLINE date. > > The reason I'd like this is because I have monthly bank statements, > which come in the next month, and I'd like to store the bank statement's > date in a [] “tag” so that I can easily know which statement I'm > supposed to handle, even though this date is neither a SCHEDULED (as I > don't have the statement yet at the date it's produced) nor a DEADLINE > (for the same reason). > > What do you think about this? > > Anyway, thanks a lot for the great work! > > Cheers, > Leo > > > [1] http://todotxt.org/
[O] org 2 gfm markdown and back again
Hi fellow people :) So like a lot of you, I'd love to write all my documentation in orgmode. However I work with gitlab flavoured markdown a lot in our environment. Wishfully one can convert easily between orgmode and markdown and back again. Therefore I need to be able to convert easily back and forth between the two formats. There are some issues with this and wondering what your experiences are with this (for those that are interested)? I wrote about this situation briefly in my blog on plain text documentation. [1] https://divansantana.com/plain-text-documentation/index.html pandoc orgmode support is not good enough at converting orgmode to markdown and back again. For example converting this org file[2] to markdown with pandoc does not result in this properly formatted gfm markdown file[3]. [2] https://gitlab.com/ambrevar/ambrevar.gitlab.io/blob/master/source/guix-packaging/index.org [3] https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/posts/packaging-tutorial.md Using the various ~org-md-~ functions from ~ox-md.el~ is better. However it only supports org2markdown, not the reverse. Furthermore, it still doesn't do a perfect job with the conversation. Pierre Neidhardt wrote a nice wrapper which improves the org2markdown export[4]. [4] https://gitlab.com/ambrevar/ambrevar.gitlab.io/blob/master/source/guix-packaging/org2md.el The result works very well in my testing. However this still doesn't solve the markdown2org situation. Anyone thought of something box to improve this situation? -- Divan Santana https://divansantana.com
[O] Bug: Capture problems with newlines [9.1.14 (9.1.14-9-g131531-elpa @ /home/calvin/.emacs.d/elpa/org-20181105/)]
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
I have this problem where I have a capture template like this:
> ("t" "Todo" entry (file+headline "~/org/todo.org" "Tasks")
>"* TODO %?\n SCHEDULED: %t\n %a\n")
And then if I have another heading under Tasks...
> * Tasks
> * HEADING2
Then when capturing a todo entry, if I delete the last line I get something
like...
> * Tasks
> ** TODO
>SCHEDULED: <2018-11-05 Mon>
>link* HEADING2
And similarly, if I edit the last line in the capture template I get...
> * Tasks
> ** TODO
>SCHEDULED: <2018-11-05 Mon>
>link
> the stuff that I added at the end of my capture template* HEADING2
This is counter intuitive, as you expect the capture to be isolated from
the other headings. Additionally, it's not obvious that you are messing
up other headings when you are using org-capture, so you can end up
losing tasks and headings, which seems like a very bad behaviour!
Furthermore, I feel like this conflicts with some editing habits. If I
want to edit the last part of a buffer I hit `M->` and start typing. I
think this is a pretty common idiom, but this conflicts badly with
org-capture.
Thanks! I hope there is some kind of fix possible.
Emacs : GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu)
of 2018-09-29
Package: Org mode version 9.1.14 (9.1.14-9-g131531-elpa @
/home/calvin/.emacs.d/elpa/org-20181105/)
