Ihor Radchenko writes: > I'd like to add a new section to Org mode manual. > The new section will describe all the steps performed by Org export > process. This should hopefully create a more clear picture on how > various export hooks and filters are used. > > The patch is attached. > I'd appreciate feedback from people not familiar with ox.el. Thank you all for the feedback! I am attaching revised version of the patch with most of the comments addressed. I will put more detailed responses inline. "Thomas S. Dye" writes: > I'm not too familiar with ox.el. > > I edited mostly to use an active voice. I put author queries in > parentheses. I haven't paid attention to manual formatting > conventions. > > IMO, more links would likely be helpful. > > * Suggested revision > ... I believe that I have addressed everything you commented on. Karthik Chikmagalur writes: > - When exporting a sub-tree, at what stage of the export process is the > buffer narrowed to the sub-tree? I added a clarification on subtree export now. > - Are "inner" and "outer" templates described in the manual, and if they > are could you add a link to those sections when mentioning them in > this summary? I only found references to the plist properties > BEAMER_INNER_THEME etc. This is internal terminology. I changed the wording, expanding on what inner and outer template do. Matt writes: > Here are all the hooks and functions for org-export (via =C-h v > org-export--hooks TAB= and =C-h v org-export--function TAB=). I see > 59 of them. > ... > * Feedback 1: > How are the functions not present in the patch handled? - I fixed the obsolete variable names. - `org-export-stack-mode-hook' is not directly relevant to the export process - it is for asynchronous export listing buffer - Syntax-specific filters are applied according to the corresponding Org syntax element. I tried to make it more clear. - Special filters, like `org-export-before-parsing-functions' are described separately. I think I have mentioned all of them. > I would write out "src" as "source". Do we have an official way to > refer to source blocks? For example, we standardize on "Org": > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/doc/Documentation_Standards.org#n47 We use "source block", "code block", and "source code block" across the manual. Not "src block" though. I went with "code block" in the patch. I am not sure if it is necessary to standardize the above three terms. They are all equally understandable I believe. > Remove the trailing period or add periods to all the others. I tend > leave the period of the last sentence of a list. I'm not sure of a > style guide that recommends one or the other. Maybe someone knows > what's "right"? No idea. We do not have a consistency in the manual either. I went with ";" as Thomas suggested. > Maybe use "converted" instead of "transcoded"? I'm a native speaker > but I wonder if "converted" is a simpler word for people who aren't. "transcoded" is closer to what we use in the code. I tried to use "converted" in more general description, but still hint on the internal terminology.