New issue 150: Review behaviour of options and plugins directives in included files https://bitbucket.org/blais/beancount/issues/150/review-behaviour-of-options-and-plugins
Martin Blais: Minimum: There should be a warning if ignored. Better: Consider alternative semantics. See thread below. On Sun, Dec 25, 2016 at 02:35:08PM -0500, Martin Blais wrote: > Tell me, how would you expect / like that the options and plugins > directives be interpreted over multiple files? > What seems to be a good behavior in your view? JFTR: I use a single "big ledger" file, so I don't personally suffer from the problem of repeating plugins in multiple files. Still, from a "ledger engineering" point of view, I'd love to have a single "include plugins.beancount" directive somewhere. Answering your question, as a user I'd love "include" to be completely transparent. That is: the behavior of beancount on a file that contains one or more "include" lines should be exactly the same of beancount called on a different file where all includes have been (transitively) resolved inlining the content(s) of the referenced file(s). I'd be totally fine if, to achieve this, you'll end up imposing draconian restrictions such as: "all 'plugin' and/or 'option' directives must appear at the beginning of the file obtained after resolving all 'include' directives". I do realize that this might entail implementing a two-stage parsing of sort, which might be annoying. But you asked about my favorite behavior, and that would be it :) Responsible: blais -- You received this message because you are subscribed to the Google Groups "Beancount" group. To unsubscribe from this group and stop receiving emails from it, send an email to beancount+unsubscr...@googlegroups.com. To post to this group, send email to beancount@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/20161226162846.36528.30348%40celery-worker-101.ash1.bb-inf.net. For more options, visit https://groups.google.com/d/optout.
