>
>> I'm sympathetic to arguments about maintaining simplicity of the core,
>> and even more so to arguments about maintaining structural validity of
>> trees during export.  I believe that this revised patch fully maintains
>> valid tree structures, and I'd suggest that the increase in complexity
>> of a single keyword is justified by the demonstrated user demand for
>> this functionality.
>
> It mostly preserves tree structure, indeed. More comments about this
> below.
>
> Just to be clear: I'm not against implementing the functionality. We can
> implement it without increasing complexity, so the demand is hardly
> a justification for this added complexity.
>
> Making :export: and :noexport: tags symmetrical is a good thing anyway:
> why could we add :noexport: within :export: trees but not the other way?
> And, as I demonstrated earlier, combination of both permits more
> patterns than :ignoreexport:. Therefore, we should implement it in any
> case. As a bonus, it provides a solution for the problem at hand.
>
> If this solution happens to be inadequate, then we can discuss about
> better solutions, this time with more options (a user-defined hook,
> a macro, a command, even a new tag if we cannot escape it...).
>
> Anyway, some comments follow about your code.
>
>> +(defun org-export-ignore-headlines-retain-and-promoting-children (data info)
>> +  "Remove headlines tagged \"ignoreexport\" retaining sub-headlines.
>> +DATA is the parse tree.  INFO is a plist containing export
>> +options.  Each headline tagged \"ignoreexport\" will be removed
>> +removing its contents but retaining and promoting any children
>> +headlines by a single level."
>> +  (org-element-map data org-element-all-elements
>
> Since you're only interested in headlines, org-element-all-elements -->
> headline
>

Done, thanks.

>
>> +    (lambda (object)
>> +      (when (and (equal 'headline (org-element-type object))
>
> This check is not necessary per the suggestion above.
>

Yes.

>
>> +                 (member "ignoreexport" (org-element-property :tags object)))
>> +        (mapc (lambda (el)
>> +                ;; recursively promote all nested headlines
>> +                (org-element-map el 'headline
>> +                  (lambda (el)
>> +                    (when (equal 'headline (org-element-type el))
>
> You don't need this `mapc' + `org-element-map' + `org-element-type'
> construct. More on this below.
>

This includes the section contents, and ensures the order in which the
children headlines are mapped, so that they are inserted with
`org-element-insert-before' in the correct order.  This is both because
I'm not sure what exactly is guaranteed WRT mapping order by
org-element-map, and also so the code is explicit about the ordering of
side effects with element insertion.

>
>> +                      (org-element-put-property el
>> +                        :level (1- (org-element-property :level el))))))
>
> Actually, hard-coding `1-' will not always work, because it assumes that
> children differ from their parent by exactly one level. This is not
> always the case.
>
>  * 1
>  *** 1.0.1
>  ***** 1.0.1.0.1
>  ***** 1.0.1.0.2
>
> Of course, this is a contrived example. Nevertheless, just to make it
> robust, promoting children should put the lowest level children to the
> level of their parent and preserve relative level differences between
> other children.
>

Good catch.  I've made this change.

>
>> +                ;; insert back into parse tree
>> +                (org-element-insert-before el object))
>> +              ;; drop first three elements of headline
>> +              ;; 1. headline tag
>> +              ;; 2. properties
>> +              ;; 3. section
>> +              (cdddr object))
>
> `cddr' is really `org-element-contents'. Also, some headlines do not
> have a section, which is not mandatory. In this case `cdddr' would also
> remove the first headline, which is wrong.
>
> This can be solved by replacing `mapc' + `org-element-map' + `cdddr'
> with:
>
>   (org-element-map (org-element-contents object) 'headline
>     (lambda (el) ...))
>

Thanks, better to stick with the org-element API.

>
>
> I appreciate your work on this, but let me stress it again: I'm
> convinced that :ignoreexport: tag is only a partial solution to the
> problem, and, as such, a dead-end. :noexport:/:export: combination is
> more versatile, at the price of some verbosity in some cases, but
> without the added complexity another tag would introduce.
>

We disagree here.  I think that the particular use case addressed by
this functionality is frequent enough to justify the tag, but I
understand your points especially given that most useful implementations
will require including the content of the ignored headline.

Best,

>
>
> Regards,


Footnotes: 
[1]  http://orgmode.org/worg/org-faq.html#ignoreheadline

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D (see https://u.fsf.org/yw)