Bruce, > > I really don't understand why the changed is needed. > > I've stated it twice, I believe, but it's now a longer thread, so: > > Org is set to get native citation support. > > Once that's merged, people who use this feature will be disappointed > to know that when using the natbib or biblatex export processors, > their citations and bibliographies will not render. > > As in, from their perspective, it will be broken upfront.
thanks. one important thing will be the manual section describing the new capability -- it should highlight the desirability of using latexmk ("or some process with similar behavior"), and describe the results one will get without it. presumably, people will initially need to read this section to figure out the syntax, etc.? i worry about breaking people's currently working setups. it seems there are N classes of users: 1. not using citation engine. 2. using citation engine 2a. ... and using default latex-to-pdf processing 2b. ... having customized that processing 2bi. ... in a way that works with new citation engine 2bii. .. in a way that does *not* work with new citation engine class 1 could likely benefit from latexmk, but it's optional. class 2a is probably the main class that would find it really helpful to have an automated latexmk. from *our* (the org-mode provider) point of view, i guess the 2b subclasses are indistinguishable. so, if the user finds herself in 2bii, she will have to grep the manual or the web. again, it would be good if information in the manual stuck out. maybe a "TROUBLESHOOTING" sub-section for the new feature? i wonder if we could detect 2a, and offer them the customization dialog? (one would want the user to be able to click the "do not show me this again" button, or equivalent.) packaging. :) cheers, Greg