From: Rasmus <rasmus@gmx.us>
To: emacs-orgmode@gnu.org
Subject: Re: [PATCH]Extend export hook example for removing headlines with tag ignore_heading
Date: Mon, 13 Apr 2015 21:59:05 +0200 [thread overview]
Message-ID: <87a8ybkdfa.fsf@pank.eu> (raw)
In-Reply-To: CAOyjJOJNCmEY4=ZT-YZAQGBgUj6QwWPSCAaUx8FzmO++g4bmSA@mail.gmail.com
Ondřej Grover <ondrej.grover@gmail.com> writes:
> I have no idea how to get around this. It stems from the basic problem in
> Org mode that there are no entry closures AFAIK: To export the "export" it
> would have to be under a heading that does not have the :noexport: tag.
> This is actually one of the reasons why ignoreheading is used in many
> cases, to separate entries without creating a real headline.
This is the format. Comparing to org-inlinetasks, I prefer the standard
way. I put my noexport headings in the end of the document.
>> If this is often needed feature, ox.el and potentially backends should be
>> patched to support it. I think it would be great if ox did support it.
>> Of course, Nicolas would have the final say in such a matter.
>>
> I'm ok with that too, but it should be easily accessible so that people
> don't end up using broken snippets from the Internet.
> Therefore, such exporting functionality (I think it's mostly backend
> agnostic) would have to be well documented in the manual.
Patches welcome. Note it's a difficult tasks and you should read up on
previous discussions of this topic beforehand.
>> But I'm not sure so difficult hacks should be promoted in the manual.
>>
> It would indeed be better if the user only enabled some option documented
> in the manual instead of using code snippets.
It's perfectly fine to use filters and hooks. I have 12 in my latex
configuration alone. But it's hacks. The manual should not promote
hacks.
Org-hacks on Worg already has a section on ignoreheading, though it should
be updated to mention the solution in ox-extra.el.
> I think it's still reasonably simple and clear for an example. It shows
> many useful things.
But it lacks correctness. Why not solve a simpler problem that can be
solved correctly?
> +Two hooks are run during the first steps of the export process. The
> +first one, @code{org-export-before-processing-hook} is called before
Missing comma: ,
> +expanding macros, Babel code and include keywords in the buffer. The
> +second one, @code{org-export-before-parsing-hook}, as its name suggests,
"as its name suggests," is unnecessary.
> +happens just before parsing the buffer. Their main use is for heavy
> +duties, that is duties involving structural modifications of the
> +document.
The first part of the sentence is unnecessary.
> For example, one may want to remove every headline with the
> +@samp{ignore_heading} tag (excluding those with the @samp{noexport} tag)
> +in the buffer and promote their children during export. The following
See above.
> @lisp
> @group
> -(defun my-headline-removal (backend)
> - "Remove all headlines in the current buffer.
> +(defun ignored-headlines-removal (backend)
> + "Remove all headlines with the ignore_headline tag in the current buffer
The first line should be a complete sentence, and it's too long here.
> +and promote all child headlines underneath them.
> BACKEND is the export back-end being used, as a symbol."
> (org-map-entries
> - (lambda () (delete-region (point) (progn (forward-line) (point))))))
> + (lambda () (progn (org-map-tree (lambda () (when (> (outline-level) 1)
> + (org-promote))))
> + (delete-region (point) (point-at-eol))))
> + "+ignore_heading-noexport"))
>
progn is unneeded.
> +The second argument to the @code{org-map-entries} function is an
> +agenda-style match query string (@pxref{Matching tags and properties}).
Fine.
> +Note the underscore in the tag, it is not recommended to use the
> +@samp{ignoreheading} tag because the Beamer export backend treates it in
> +a similar, yet more complicated way. It may also be useful to exclude
> +the @samp{ignore_heading} tag from inheritance (@pxref{Tag
> +inheritance}). Also note that functions used in these hooks require a
> +mandatory argument, a symbol representing the back-end used.
This promotes poor usage patterns IMO cf. above.
—Rasmus
--
This is the kind of tedious nonsense up with which I will not put
next prev parent reply other threads:[~2015-04-13 19:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-13 15:23 [PATCH]Extend export hook example for removing headlines with tag ignore_heading Ondřej Grover
2015-04-13 16:09 ` Rasmus
2015-04-13 18:13 ` Ondřej Grover
2015-04-13 19:42 ` Nicolas Goaziou
2015-04-13 22:40 ` Suvayu Ali
2015-04-13 19:59 ` Rasmus [this message]
-- strict thread matches above, loose matches on Subject: below --
2015-04-12 11:59 Ondřej Grover
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
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=87a8ybkdfa.fsf@pank.eu \
--to=rasmus@gmx.us \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
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).