Nicolas Goaziou writes: > Hello, > > Eric Schulte writes: > >> In my opinion the manual interleaving of "noexport" and "export" tags is >> overly cumbersome and is non-obvious. > > It is as non-obvious as the task it achieves. > >> The obscure nature of this solution is evidenced by multiple >> discussions and implementations of filter functions to handle >> situations which could be covered by this noexport/export pattern. > > I don't know what you are referring to, since this "noexport/export" > pattern isn't implemented yet. Do you have an example of such > a discussion that dismissed said pattern? > >> I think the attached patch should be applied to the core. It includes >> the following. >> >> - a single new export function which removes the headlines and contents >> (the "section" element) of headlines tagged "ignoreexport", then >> retains and promotes all sub-headlines contained therein. >> >> - a single new export tag named "ignoreexport" (ignore seems to be the >> crowd favorite, and adding "export" reduces possible conflicts with >> existing personal tags) > > Thank you for the patch. > > Again, my concern is that it introduces another tag for a task that > could be possible without it. "export", "noexport", "ignoreexport": this > all gets confusing. Furthermore, this tag should, at the bare minimum, > be configurable so it also introduces another keyword on par with > SELECT_TAGS and EXCLUDE_TAGS. > > Moreover, that task is highly specific; I'm not convinced we should have > a dedicated keyword for each of them. I'd rather have a simple solution > for selective export problems, even if, as a generic solution, it may > look clumsier. > >> From the included tests, the effect of this patch is to convert a tree >> like the following, >> >> ,---- >> | * H1 >> | Text1 >> | ** H2 :ignoreexport: >> | Text2 >> | *** H3 >> | Text3 >> | **** H4 >> | Text4 >> | *** H5 >> | Text5 >> | **** H6 :ignoreexport: >> | Text6 >> | ***** H7 >> | Text7 >> | ***** H8 >> | Text8 >> `---- > > Note that my suggestion is > > ,---- > | * H1 > | Text1 > | ** H2 :noexport: > | Text2 > | *** H3 :export: > | Text3 > | **** H4 > | Text4 > | *** H5 :export: > | Text5 > | **** H6 :noexport: > | Text6 > | ***** H7 :export: > | Text7 > | ***** H8 :export: > | Text8 > `---- > > In this case, it is more verbose. But the opposite would happen if you > needed to also ignore children within the "ignoreexport" headlines. > In order to get > > * H1 > ** H4 > > compare > > > * H1 > ** H2 :ignoreexport: > *** H3 :noexport: > *** H4 > > with > > * H1 > ** H2 :noexport: > *** H3 > *** H4 :export: > > This time, the brevity of :ignoreexport: is not so clear. Also, it will > not prevent the need to nest tags at some points. IOW, it is only > efficient for one very specific use case. Outside of this case, the new > tag would just be an annoyance and you would fallback > to :noexport:/:export: nesting, if implemented. And if we cannot avoid > tags nesting, I'd take 2 "nesteable" tags over 3 any day. > > Another point to consider is that :noexport:/:export has the advantage > to mark explicitly what will be included in the export process. As such, > I don't find less obvious than your proposal: in both cases, you have to > understand the rules applied behind the keywords anyway. And these rules > are well-known for "export" and "noexport" tags. > This is a specific tag for a specific but common use case. I'll defer to your judgment on the exporting code and instead share a filter function which may be added to personal configurations (I've added this to the FAQ as well [1]). Having looked more closely at my use cases (documented in the attached implementation), including the contents of ignored headlines is required for most practical applications (which may make the parse tree invalid, but which works well for every export backend I've used thus far).