Juan Manuel Macías <maciasch...@posteo.net> writes:
> Ihor Radchenko writes:
>
>>> - (org-back-to-heading t) ; Sets match data
>>> - (match-end 0))
>>> + (re-search-backward org-heading-regexp) ; Sets match
>>> data
>>> + (match-beginning 0))
>>
>> This will err when the source block is before the first headline in the
>> document.
>
> I've reverted the first line to (org-back-to-heading t), keeping the
> (match-beginning 0), otherwise you don't get the full headline and all
> property drawers would be exported. But it's strange, it doesn't give me
> any error when the source block is before the first headline in the
> document. Isn't that error prevented with this:
>
> (condition-case nil
> ...
> (error (point-min)))
>
> ?
Hmm. You are indeed right. I missed the condition-case part.
In any case, re-search-backward is not reliable when you have inlinetasks.
> By the way, I've noticed that it's not convenient to export numbered
> headers, so I've modified org-babel-export-comment-text-as-plain-text so
> that it removes header numbering. I don't know if it's ok to do it this
> way...
The path you took is indeed a bit awkward.
You may need to use the approach similar to orgtbl-to-latex.
Also, things to watch are org-export-exclude-tags,
org-export-with-section-numbers, org-export-with-archived-trees,
org-export-with-broken-links (we don't want tangle to fail because of
broken links), org-export-with-inlinetasks, org-export-with-toc,
and org-export-with-tasks.
> +(defun org-babel-export-comment-text-as-plain-text (text)
> + "Function to process raw Org TEXT collected to be inserted as
> +comments in tangled source-code files. This function is the
> +default value for `org-babel-process-comment-text'."
> + ;; Ensure that if TEXT is a header it is not numbered.
> + (let ((text-nonum (with-temp-buffer
> + (insert text)
> + (when (not (org-entry-get nil "UNNUMBERED"))
> + (org-entry-put nil "UNNUMBERED" "t"))
> + (buffer-string))))
> + (org-export-string-as text-nonum 'ascii t)))
"Function to" can be safely dropped. See D.6 Tips for Documentation
Strings in Elisp manual:
• The first line of the documentation string should consist of one or
two complete sentences that stand on their own as a summary. ‘M-x
apropos’ displays just the first line, and if that line’s contents
don’t stand on their own, the result looks bad. In particular,
start the first line with a capital letter and end it with a
period.
For a function, the first line should briefly answer the question,
“What does this function do?” For a variable, the first line should
briefly answer the question, “What does this value mean?”
Don’t limit the documentation string to one line; use as many lines
as you need to explain the details of how to use the function or
variable. Please use complete sentences for the rest of the text
too.
• The first line should mention all the important arguments of the
function, and should mention them in the order that they are
written in a function call. If the function has many arguments,
then it is not feasible to mention them all in the first line; in
that case, the first line should mention the first few arguments,
including the most important arguments.
• For consistency, phrase the verb in the first sentence of a
function’s documentation string as an imperative—for instance, use
“Return the cons of A and B.” in preference to “Returns the cons of
A and B.” Usually it looks good to do likewise for the rest of the
first paragraph. Subsequent paragraphs usually look better if each
sentence is indicative and has a proper subject.
Best,
Ihor
