Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'

[Ihor Radchenko <yantar92@gmail.com>]

Juan Manuel Macías <maciaschain@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