Hello, Jambunathan K <kjambunat...@gmail.com> writes:
> 1. When org-inlinetask is NOT LOADED, inline tasks are treated as > regular headlines and are listified. (The "END" of inlinetask appears > as listified headline though) Loading org-inlinetask is the user's job. He has to assume weird things which will happen when the buffer holds inline tasks without them being loaded (but I give him an excuse as inline tasks are completely undocumented). > 2. If inlinetask is LOADED, the exporter could check the headline level > against org-inlinetask-min-level and take the following actions: > > - Continue to generate listified entries for inline tasks but > surround them with <div class="inlinetask"> ... </div> entries. > > - Strip the "END" list item from being generated > > I think org-inlinetask-export-handler could be reduced to > 1. removing the inlinetask when org-inlinetask-export is nil > 2. stripping the inlinetask of drawers etc etc. > > (Queestions: Does the org-inlinetask-export-handler treat nested > inline tasks well? Btw, Is nesting of inline tasks "legitimate" to > begin with? ) As far as I can tell, inline tasks are not designed to be nested. > I am sure html and odt exporters can take care of inlinetask purely > during post-processing and do away with templates altogether. Templates are fine as long as inline tasks are not loaded by default. If this changes, I agree there are better ways to handle them (one being what you explain above). But, a few weeks ago, Bastien suggested to think again inline tasks. So, that might not happen soon. > I am not sure about LaTeX exporter though. > > What do you & others think? Let me work on a patch from odt/html side of > things. What I think is that, for now, we just should keep the existing facility and implement a working default template for HTML (and a new one for ODT). Regards, -- Nicolas Goaziou
