Ondřej Grover <ondrej.gro...@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
