emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@gmail.com>
To: "Juan Manuel Macías" <maciaschain@posteo.net>
Cc: orgmode <emacs-orgmode@gnu.org>
Subject: Re: [Patch] ob-tangle.el: New value 'ascii' for the header argument ':comments'
Date: Tue, 26 Jul 2022 13:35:59 +0800	[thread overview]
Message-ID: <87czdscu68.fsf@localhost> (raw)
In-Reply-To: <87czdt3yk3.fsf@posteo.net>

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

     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

   • 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.


  reply	other threads:[~2022-07-26  5:35 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-10 18:28 Juan Manuel Macías
2022-06-11  5:39 ` Ihor Radchenko
2022-06-11 11:20   ` Juan Manuel Macías
2022-06-14  3:58     ` Ihor Radchenko
2022-06-14 11:11       ` Juan Manuel Macías
2022-06-14 11:55         ` Ihor Radchenko
2022-06-15 10:30           ` Juan Manuel Macías
2022-07-21 13:44           ` Juan Manuel Macías
2022-07-25 13:34             ` Ihor Radchenko
2022-07-25 17:13               ` Juan Manuel Macías
2022-07-26  5:35                 ` Ihor Radchenko [this message]
2022-06-12 19:18 ` Rudolf Adamkovič
2022-06-12 19:55   ` Juan Manuel Macías
2022-06-13  8:24     ` Rudolf Adamkovič
2022-06-13 10:22       ` Juan Manuel Macías

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87czdscu68.fsf@localhost \
    --to=yantar92@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=maciaschain@posteo.net \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).