Denis Maier writes:
> Am 19.12.2022 um 23:20 schrieb András Simonyi: >> ... I've forgotten to add that another (probably more user friendly) >> option would be to design and implement some kind of filtering DSL. >> András >> On Mon, 19 Dec 2022 at 23:05, András Simonyi >> <andras.simo...@gmail.com> wrote: >>> >>> Dear All, >>> >>> On Mon, 19 Dec 2022 at 15:49, Christian Moe <m...@christianmoe.com> wrote: >>> >>>> Refinements welcome. I'm especially wondering what would be an elegant >>>> way to generalize this for more languages without defining a predicate >>>> for each language (given that we cannot pass the language as an >>>> additional argument in the print_bibliography line). >>> >>> Thanks for describing this usage! As for the problem of generalizing >>> to more languages, one relatively simple solution would be to allow >>> arbitrary sexps as filters. Then one could write something like >>> >>> #+print_bibliography: :filter (lambda (item) (bibitem-has-language item >>> "en"))) >>> >>> Would this type of extension be helpful? One (not necessarily >>> important) consequence would be that filters of this type would be >>> obviously unusable with the biblatex exporter. >>> >>> best wishes, >>> András > > I'd say both options are certainly useful. A filtering DSL is surely > the more user friendly option, but allowing lambda expressions would > probably be quicker to implement, and it would also allow for > predicates not anticipated by DSL designers. > > Best, > Denis Arbitrary sexps would give us more flexibility. Alternately, one could achieve more or less the same by letting :filter collect any additional arguments and pass them as &rest to the user's predicate function, something like: #+PRINT_BIBLIOGRAPHY: :filter bibitem-lang-p nb nn no :type article (This perhaps makes for cleaner solutions. And it is perhaps slightly better from a security viewpoint: I hope for a bright future of collaborative authoring in Org, so I'm wary of proliferating ways to execute arbitrary elisp that a user might not notice. But we do have such ways already, and it's possible to abuse the above solution as well, so I don't know.) Alternatively, I think there is a case for adding a user-friendly :language property to the print_bibliography keyword. On my bookshelf it vies with primary/secondary sources as the most common criterion for separate bibliographies. I was going to say that this is the only extension I can think of that is needed beside :(not)(csl)type and :(not)keyword, but of course people are sooner or later going to want easy-to-use properties to filter by author, publication date ranges, and probably other criteria I cannot think of right now, so it's a strategic decision for the maintainer(s) if you want to go that way. :-) Yours, Christian
