Hi, Nicolas Goaziou <n.goaz...@gmail.com> writes:
> Hello, > > Rasmus <ras...@gmx.us> writes: > >> The thing is semantics are pretty easy to mess up in HTML-like >> languages compared to, say, LaTeX, since I have to figure out the >> ending point. > > You don't have to figure that out. When using a headline filter, the > first headline relative tag always opens the current headline and the > last one always close it. Of course, this assumes that you can recognize > a top level headline just by looking at its tags. With a filter the endpoint isn't a problem. Only identifying the top-level can be tricky—but you could use <h·> tags, assuming they are not varying. >> A short trial suggests that this filter does the job: >> >> #+begin_src html >> (defun rasmus/org-html-headline-add-extra-div (headline backend info) >> "Add an extra :html-container around top level sections." >> (when (org-export-derived-backend-p backend 'html) >> (let ((element >> (plist-get (text-properties-at (next-property-change 0 headline) >> headline) :parent))) >> (when (= 1 (org-element-property :level element)) >> (save-match-data >> (string-match "\n" headline) >> (concat >> (replace-match >> (format "\n<%s class=\"outline-container-top\">\n" >> (org-html--container element info)) >> t nil headline) >> (format "</%s>\n" (org-html--container element info)))))))) >> #+end_html >> >> The critical part is the next-property-change. I assume that the >> first element is always the headline in question. >> (Do you know if this is generally true, Nicolas?) > > This will not always work. Text properties only exist on raw text. If > a headline do not contain raw text at all, like the following one, > > * =Verbatim= > > you will not get the correct element. That a shame. Is there any other 'easy' way to recover the element representation of, say, a headline? Often it's a lot easier to work with than regexp "hacks". Thanks, Rasmus -- Evidence suggests Snowden used a powerful tool called monospaced fonts
