Extend the existing alternative set of key bindings for terminals (was: Second Ctl in keychord not detected)
"Loris Bennett" writes: >> Then, it is terminal input problem. See >> https://stackoverflow.com/questions/0801/why-does-ctrl-not-work-when-i-bind-it-to-a-command-in-emacs/8511#8511 > > You're right, the problem also happens locally when I start Emacs with > '-nw'. Thanks for the link - I'll have a look at the various solutions, > although it might just be easier to rebind the command ;-) On Org side, we have an alternative set of key bindings that is more compatible with terminals (see org-use-extra-keys). I think that C-c C-, should also be covered there. Or maybe some other keys as well. Loris, would you be interested to check which default bindings from org-mode-map work and which don't work in tmux/terminal and report here? Also, it appears to me that we may keep losing terminal-incompatible keys in future unless we provide some mechanisms to check terminal compatibility automatically. Any ideas? Best, Ihor
Re: Yet another browser extension for capturing notes - LinkRemark
just a quick fwiw before i try to reply to the longer message by max. my own suggestion is modest for metadata, [even for science papers and things with funny web construction]. just title like org-capture extension. no need to cite in my case. my needs for saving and restoring, however, are more fancy. something like achieving a 1:1 mapping from firefox selected tabs, or a tree style tabs extension tree, to their counterparts in org, even when those counterparts have notes and such. this might include marking the org version as deleted/doneified] merely by closing tab in firefox. vice-versa would be straightforward. so it's really a "get organized and don't get confused by having both firefox and org" kinda thing.
Re: Problem when tangling source blocks with custom coderefs
Hi Tom, The simplest fix right now would be to prepend your coderef > with the python comment symbols # |hello| so that at the very least it > won't break your tangled files. Actually, that is exactly what I have done as a quick fix. It has a minor inconvenience: anything else included on the line is colored as if it were a comment in the final PDF, and I intended to add a symbol to mark the reference. Not a big deal, but it looks different than intended. I would like to see this implemented, > so let's see what Nicolas has to say. I would like to contribute something. Maybe a test to show what is the behavior to expect. Thanks for your reassurance that this is not an error on my side!
Re: handling as special special block in derived export
Matt,
> On Jan 19, 2022, at 5:52 AM, Matt Price wrote:
>
> However, I'd really like to add a less verbose syntax, like this:
>
> #+begin_r-stack :frag (appear appear)
> [[imglink1]]
> [[imglink2]]
> #+end_r-stack
>
> My question is: will the exporter preserve information from these header-like
> arguments, and is
> there a mechanism I can use in a custom ~special-block-function~ to make use
> of htem?
>
Not as you have it there, but
#+header: :frag (appear appear)
#+begin_r-stack
[[imglink1]]
[[imglink2]]
#+end_r-stack
parses as
(special-block
(:type "r-stack" :begin 727 :end 815 :contents-begin 775 :contents-end 801
:post-blank 0 :post-affiliated 759 :header
(":frag (appear appear)")
:mode nil :granularity element :parent nil))
if that helps.
Chuck
Re: call blocks as a function from inside elisp code
Hi George, Here is an example of how I call nested elisp and python. The python block is an input argument to the elisp block in this case, but the python block could be called directly as well. I'm not sure how to pass arguments to the block from inside elisp via org-babel-eval though, that seems like it would require some deeper tampering/advising of functions. Best, Tom https://github.com/SciCrunch/sparc-curation/blame/master/docs/queries.org#L1704-L1707 #+begin_src elisp :results none :exports none (ow-babel-eval "neru-simplified") #+end_src The implementation I use is included below and is source dfrom https://github.com/tgbugs/orgstrap/blob/bc981b957967be8d872c08be9ba7f2dbde5caf1d/ow.el#L786-L803 (defun ow-babel-eval (block-name universal-argument) "Use to confirm running a chain of dependent blocks starting with BLOCK-NAME. This retains single confirmation at the entry point for the block." ;; TODO consider a header arg for a variant of this in org babel proper (interactive "P") (let ((org-confirm-babel-evaluate (lambda (_l _b) nil))) ;; FIXME TODO set messages buffer size to nil (save-excursion (when (org-babel-find-named-block block-name) ;; goto won't raise an error which results in the block where ;; `ow-confirm-once' is being used being called an infinite ;; number of times and blowing the stack (org-babel-goto-named-src-block block-name) (unwind-protect (progn ;; FIXME optionally raise errors on failure here !? (advice-add #'org-babel-insert-result :around #'ow--results-silent) (org-babel-execute-src-block)) (advice-remove #'org-babel-insert-result #'ow--results-silent)) (defun ow--results-silent (fun args) "Whoever named the original version of this has a strange sense of humor." ;; so :results silent, which is what org babel calls between vars ;; set automatically is completely broken when one block calls another ;; there likely needs to be an internal gensymed value that babel blocks ;; can pass to eachother so that a malicious user cannot actually slience ;; values, along with an option to still print, but until then we have this (let ((result (car args)) (result-params (cadr args))) (if (member "silent" result-params) result (apply fun args
Re: handling as special special block in derived export
I am not sure this is quite what you are looking for. You could use a macro
like this.
{{{r-stack(((src1 . fade-out) (src2 . fade-in) (src3 . fade-out)))}}}
* code :noexport:
#+macro: r-stack (eval (r-stack $1))
#+BEGIN_SRC emacs-lisp
(defun r-stack (src-alist)
"SRC-alist will be a string containing a list of (src . data-fragment)
src is a url or filename
data-fragment
Returns a string for export."
(let ((src (read src-alist)))
(format "#+BEGIN_EXPORT html
%s
,#+END_EXPORT"
(string-join
(cl-loop for (src . data-fragment) in src
collect
(format " "
data-fragment src))
"\n"
(r-stack "((src1 . fade-out) (src2 . fade-in) (src3 . fade-out))")
#+END_SRC
#+RESULTS:
: #+BEGIN_EXPORT html
:
:
:
:
:
: #+END_EXPORT
You could also make a link do that.
John
---
Professor John Kitchin (he/him/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu
On Wed, Jan 19, 2022 at 9:42 AM Matt Price wrote:
> I am trying ot figure out if I can create a simplified syntax for a
> particular special block in a derived HTML exporter.
>
> I'm trying to produce HTML like this:
>
>data-fragment="fade-in" src="..."/>
>
> The derived backend (org-re-reveal) already has an
>
> #+ATTR_REVEAL that an make the data-fragment attributes, so it's not hard to
> produce
> the desired outpu:
>
> #+begin_r-stack
> #+ATTR_REVEAL: :frag appear[[imglink1]]
> #+ATTR_REVEAL: :frag appear[[imglink2]]#+end_r-stack
>
> However, I'd really like to add a less verbose syntax, like this:
>
> #+begin_r-stack :frag (appear appear)[[imglink1]][[imglink2]]#+end_r-stack
>
> My question is: will the exporter preserve information from these header-like
> arguments, and is
> there a mechanism I can use in a custom ~special-block-function~ to make use
> of htem?
>
> Thanks for your help as always!
>
> Matt
>
>
Re: [PATCH] ob-plantuml: Allow setting PlantUML args for jar file
On 18/01/2022 20:30, Ihor Radchenko wrote:
Dejan Josifović writes:
But, since ob-plantuml already had variable for arguments for executable
it fells natural to me to have customizable variables for when using
jar. These headers are of course easier, but the user would have to
write them on each source block to achieve something that should be
globally customizable (like charset).
FYI, you can customise any header arg globally. See manual page 16.3
Using Header Arguments.
info "(org) Using Header Arguments"
https://orgmode.org/manual/Using-Header-Arguments.html
#!/bin/bash
gjl_package=plantuml
gjl_jar="plantuml.jar"
source /usr/share/java-config-2/launcher/launcher.bash
It seems with with the suggested patch both -Djava.awt.headless=true and
-headless are passed to jar. I suspect it is either redundant or
launcher.bash converts "-headless" to "-Djava.awt.headless=true". In
ubuntu there is no room for special treatment of "-headless" option by
the shell wrapper:
--- >8
if [ -n "${JAVA_HOME}" ] && [ -x "${JAVA_HOME}/bin/java" ] ; then
JAVA="${JAVA_HOME}/bin/java"
elif [ -x /usr/bin/java ] ; then
JAVA=/usr/bin/java
else
echo Cannot find JVM
exit 1
fi
$JAVA -jar -Djava.net.useSystemProxies=true
/usr/share/plantuml/plantuml.jar ${@}
8< ---
I feel that running headless mode in the ob-plantuml is deliberate.
https://plantuml.com/faq
"Basically, this is because PlantUML needs to have access to some
graphical resources"
I have no idea what is actually affected.
Which peace of code (java or plantuml.jar) handles "-headless" option?
This question affects decision if jar and executable wrapper modes may
share same list of arguments. Plantuml site recommends namely
-Djava.awt.headless=true. Anyway with or without the patch,
"-Djava.awt.headless=true" is added unconditionally in the jar mode. I
would revert that patch and either add it to java header argument or to
a new defcustom.
Are there cases when :cmdline header argument is not enough and extra
custom variable org-plantuml-args (org-plantump-executable-args) should
be used?
Actually I have realized that I do not understand why babel code uses
mix of defcustom and header arguments. The latter are more flexible and
may be adjusted per source block. On the other hand they may be set in
init file. Even java executable and path to jar file may be obtained
from header arguments.
Re: call blocks as a function from inside elisp code
On Wednesday, 19 Jan 2022 at 09:56, George Mauer wrote: > So is there a way to do the equivalent of #+call: > gim/get-python-program-info(filename="foo/bar/some_module.py") from > *inside* an elisp code block? I am aware that I can call things via > noweb, but I'm trying to see if I can avoid that for several other > reasons Two ways I can think of: 1. use the :post header argument to chain calls or 2. invoke (org-sbe "blockname") although I am not sure if you can pass variables. org-sbe is a macro in ob-table.el. There may be (very likely) a more general way to evaluate a src block from with elisp. HTH, eric -- : Eric S Fraga, with org release_9.5.2-306-g9623da in Emacs 29.0.50
call blocks as a function from inside elisp code
Hi everyone, I know that I can call a source block as a function in a header argument such as :var, inside noweb annotations, or with a #+call: as described here https://orgmode.org/manual/Evaluating-Code-Blocks.html I am interested in going one step further though. I have one emacs-lisp block that generates a list of python files which mention a search term provided by a variable (eg gim/get-file-list(search="_utilities") ) I have another code block written in python that given a python filename will do some ast parsing to tell me some interesting facts about it (eg #+call: gim/get-python-program-info(filename="foo/bar/some_module.py") ) What I would like to do is to chain the two together (ideally inside a code block so I can dynamically format the output) so that I can get info on *each* of the files produced by the first block. So is there a way to do the equivalent of #+call: gim/get-python-program-info(filename="foo/bar/some_module.py") from *inside* an elisp code block? I am aware that I can call things via noweb, but I'm trying to see if I can avoid that for several other reasons
Re: Second Ctl in keychord not detected
Ihor Radchenko writes: > "Loris Bennett" writes: > Does anyone know what is happening to the second Ctl and how the problem can be fixed? >>> >>> Try to run M-x describe-key C-c C-, and look at the output. >> >> The second C- disappears. >> >> I also get >> >> C-c C-. -> C-c . > > Then, it is terminal input problem. See > https://stackoverflow.com/questions/0801/why-does-ctrl-not-work-when-i-bind-it-to-a-command-in-emacs/8511#8511 You're right, the problem also happens locally when I start Emacs with '-nw'. Thanks for the link - I'll have a look at the various solutions, although it might just be easier to rebind the command ;-) Cheers, Loris -- This signature is currently under construction.
Re: Question Regarding Creating Workflow For Automatic Formulas For Finance Based Org Spreadsheet
On Mon, 10 Jan 2022 at 10:31, Neil Jerram wrote: > > On Mon, 10 Jan 2022 at 03:42, Samuel Banya wrote: > > > > Ah, Ledger is way too complicated for what it's worth. I've seen videos on > > YouTube about it, and every person who's praised it is pretty much too > > smart enough to be able to explain it in simple terms. > > I have similar observations. I don't (so far) see that Ledger (or > alternatives) offers enough added value to be worth incorporating in > my workflow, compared to directly processing the raw data. > > The value that would be of interest to me is: > - Classifying/grouping transactions at analysis time (not entry time) > according to a set of rules/regexps etc. > - Drawing insights by analysing past expenditure, with that kind of > classification. > - Using such insights as part of future budgeting. > - An overall functional approach, where the raw data is never changed, > and the other inputs to an analysis can be tweaked on each run. > > I wish plaintextaccounting.org had a forum/ML for discussing this kind > of thing, as it isn't specific to any of ledger/hledger/beancount in > particular. I have been reading the Ledger manual, and wanted to follow up because it turns out Ledger (with ledger-autosync) actually *can* do the workflows that I'm interested in (above). - ledger-autosync can read my OFX files and output Ledger transactions with Expenses:Unknown everywhere. - Ledger supports account definitions with regexps, that mean "if you see a transaction with *Unknown, and the description matches this regexp, treat the *Unknown as actually this account". - Then I can execute whatever reporting I need. So, although it's not Ledger's primary use case, it seems Ledger can operate "functionally" with the OFX files as the raw data and account definitions saying how to categorize those, and considering the generated Ledger journal to be ephemeral. Assuming I don't run into gotchas, I reckon that makes me a Ledger convert, and I can discard all my own code. Best wishes, Neil
Re: Second Ctl in keychord not detected
"Loris Bennett" writes: >>> Does anyone know what is happening to the second Ctl and how the problem >>> can be fixed? >> >> Try to run M-x describe-key C-c C-, and look at the output. > > The second C- disappears. > > I also get > > C-c C-. -> C-c . Then, it is terminal input problem. See https://stackoverflow.com/questions/0801/why-does-ctrl-not-work-when-i-bind-it-to-a-command-in-emacs/8511#8511 Best, Ihor
Re: Second Ctl in keychord not detected
On Wed, Jan 19, 2022 at 01:08:10PM +0100, Loris Bennett wrote: > Hi, > > This is not really an Org question but an Emacs or possibly tmux > problem. However, the problem manifests itself in an Org context. I guess this is tmux. It behaves more or less like an oldskool terminal, where C- is transferred as the ASCII code with bit 7 masked out. This would mean only C-@ (mapped to ASCII 0, which might have its own... interesting issues) through a few chars after CTRL-Z do make sense in this context. This "protocol" can't even express things like CTRL-. or CTRL-, -- that luxury is reserved to more GUI-ish environments :-) (NOTE: just a guess, I haven't direct experience with tmux). Cheers -- t signature.asc Description: PGP signature
handling as special special block in derived export
I am trying ot figure out if I can create a simplified syntax for a particular special block in a derived HTML exporter. I'm trying to produce HTML like this: The derived backend (org-re-reveal) already has an #+ATTR_REVEAL that an make the data-fragment attributes, so it's not hard to produce the desired outpu: #+begin_r-stack #+ATTR_REVEAL: :frag appear[[imglink1]] #+ATTR_REVEAL: :frag appear[[imglink2]]#+end_r-stack However, I'd really like to add a less verbose syntax, like this: #+begin_r-stack :frag (appear appear)[[imglink1]][[imglink2]]#+end_r-stack My question is: will the exporter preserve information from these header-like arguments, and is there a mechanism I can use in a custom ~special-block-function~ to make use of htem? Thanks for your help as always! Matt
Re: Second Ctl in keychord not detected
"Loris Bennett" writes: > installed. I am using tmux and want to run > > org-insert-structure-template > > which is bound to > > C-c C-, > > When I type that, however, the function > > org-priority > > is executed instead, which is bound to > > C-c , > Does anyone know what is happening to the second Ctl and how the problem > can be fixed? Yes. I actually asked about this recently. The problem is that in a terminal, C-, doesn't exist. Hitting C-, gets you just a comma. In other words, there is no control character in existence that would be sent in a terminal when the user hits C-,. I asked for suggestions for remapping org-insert-structure-template to some other keys and got a suggestion on how to find what key combinations are free. Also a suggestion to use older way to get the template (require 'org-tempo and use < s TAB). Problem with that old way is that it doesn't wrap region in the +BEGIN_SRC/+END_SRC tags, it just dumbly inserts them. I typically start writing code in an ORG document and *then* realize it should be inside those tags so C-c C-, would be perfect. Just not in a terminal. It might be worth reporting this key binding as a bug since it doesn't work in a terminal. Other than mapping org-insert-structure-template to some other key combination or using
Re: Second Ctl in keychord not detected
Hi Ihor, Ihor Radchenko writes: > "Loris Bennett" writes: > >> C-c , >> >> Does anyone know what is happening to the second Ctl and how the problem >> can be fixed? > > Try to run M-x describe-key C-c C-, and look at the output. The second C- disappears. I also get C-c C-. -> C-c . C-c C-; -> C-c ; C-c C-: -> C-c : C-c C-\ -> C-c \ C-c C-= -> C-c = but C-c C-c -> C-c C-c C-c C-_ -> C-c C-_ C-c C-@ -> C-c C-@ Gnome could potentially also be intercepting some keys. Cheers, Loris -- This signature is currently under construction.
Re: Second Ctl in keychord not detected
"Loris Bennett" writes: > C-c , > > Does anyone know what is happening to the second Ctl and how the problem > can be fixed? Try to run M-x describe-key C-c C-, and look at the output. Best, Ihor
Second Ctl in keychord not detected
Hi, This is not really an Org question but an Emacs or possibly tmux problem. However, the problem manifests itself in an Org context. I have started using Org on a remote server which has Emacs 27 (Org 9.3) installed. I am using tmux and want to run org-insert-structure-template which is bound to C-c C-, When I type that, however, the function org-priority is executed instead, which is bound to C-c , Does anyone know what is happening to the second Ctl and how the problem can be fixed? Cheers, Loris -- This signature is currently under construction.
Re: Yet another browser extension for capturing notes - LinkRemark
András Simonyi writes: >> As a side note, citeproc-el currently has poor performance on large org >> files. It is unusable for me. > > Could you elaborate? In theory, oc-cs.el's performance should depend > only on the number of citations (as opposed to the size of the Org > document) and be in the same ballpark as pandoc's citeproc. It'd be > interesting to know the details since I plan to work on speeding up > citeproc-el's rendering, although you are the first one to actually > complain :-). There is no doubt why I complain - 15Mb "bibliography" file. The oc-csl.el performance depends on the size of the Org document during caching stage. Moreover, every time I change the Org document, caching is repeated. Every time I open the file using oc-csl.el, caching is repeated. Every time I revert file using oc-csl.el, caching is repeated. I think that the easiest solution for citeproc would be not calling org-bibtex-headline on every single headline, but using regexp search for "BTYPE" property. Best, Ihor
Re: Org Syntax Specification
Tom Gillespie writes:
> 3. When I say grammar in this context I mean specifically an eBNF that
>generates a LALR(1) or LR(1) parser. This is narrower than the
>definition used in the document, which includes things that have to
>be implemented in the tokenizer, or in a pass after the grammar has
>been applied, or are related to some other aspect beyond the pure
>surface syntax.
I feel that we should not be trying to fit into LR at the expense of
complicating the document. When looking at earlier versions of the
grammar, I mostly had GLR in mind.
> In my thinking I separate the context sensitive nature of parsing from
> the nesting structure of the resulting sexpressions, org elements,
> etc.The most obvious example of this is that the sexpression
> representation for headings nests based on the level of the heading,
> but heading level cannot be determined by the grammar so it must be
> reconstructed from a flat sequence of headings that have varying level.
1. I think that results sexpression is important to describe. We
eventually plan to provide a reference test set to verify external
parsers against org-element.el [1]. It is important to describe the
nesting with this consideration.
2. You actually can determine the end of heading if you are allowed to
do lookaheads (which is anyway necessary to parse
#+begin_blah..#+end_blah). The end of current heading is
"eof|^\*{,N-current-heading} "
[2] https://list.orgmode.org/spmq6a$2s5$1...@ciao.gmane.io/T/#t
> ... I think the
> other issue I was having here is that the spec for tables is spread
> allover the place, and it would be much easier to understand and
> implement ifit were all in one place.
That sounds fine for me. Though your next suggestion appears to be
exactly opposite:
> I think your version is quite a bit more readable. Can we list the
> set of all the elements that can be ended by a new lineas well as
> those that cannot (iirc they are elements such as footnotes that can
> only be ended by a double blank line or a heading)?
The intention behind listing the exceptions for table cells was exactly
as you thinking about open-ended elements.
>> I am not sure here. Inline tasks are special because a one-line inline
>> task must not contain any text below, cannot have planning or
>> properties.
>
> Then they are no longer inline tasks, but instead parse as headings, correct?
They are still inline tasks. Consider the below example:
* Normal heading
Paragraph
** Inline task
SCHEDULED: <2022-01-19> <- this is an ordinary paragraph, not a part of inline
task
Continuing "SCHEDULED" paragraph, not a part of inline task
* Next heading
The parsed sexp will be
(heading
(paragraph)
(inlinetask)
(paragraph))
(heading)
>> If we mention this, we also need to elaborate kind of element is
>> #+todo:, where it can be located, and how to parse multiple instances of
>> #+todo in the document.
>
> Yes. What I have written for laundry is that only #+todo: declarations
> that appear in the zeroth section will be applied (this is true for
> all document level configuration keywords). There is also a
> possibility that we might be able to support including #+todo:
> keywords (and #+link: definitions or similar) in further sections, but
> that they would only apply to headings that occur after that line in
> the file. Such behavior is likely to be confusing to users so probably
> best to only guarantee correct behavior if they are put in the zeroth
> section.
>
> The reason it is confusing/problematic is that there could be
> a #+todo: buried half way down a file, the buffer configuration is
> updated, and then a user can use keywords up the file in the elisp
> implementation. Another implementation that parses a file
> incrementally would not encounter the buried #+todo: keyword until
> after they have already emitted a heading,changing how a heading is
> parsed. There is a similar issue with the #+link: keyword.
That's why it was initially not included into the syntax document. If we
fall into this rabbit hole, we also need to describe things like
CATEGORY, PROPERTY, OPTIONS, PRIORITIES, PROPERTY, SEQ_TODO, STARTUP,
TYP_TODO, etc.
>> > +All content following a heading that appears before the next heading
>> > +(regardless of the level of that next heading) is a section.
>>
>> Note that it is not true for one-line inline tasks.
>
> I'm not quite sure which part you are referring to here.
I only left the relevant part this time. Also, see the example above.
Inline task only consists of a single line. Nothing below is a part of
it.
> Let's look into how much work it will be and how disruptive it might
> be? We are already changing to heading in the elisp so maybe now
> would be a good time to also change from section to segment?
> Alternatively we could start by updating the documentation and include
> a note that segments are currently called sections by org
Re: Yet another browser extension for capturing notes - LinkRemark
Dear All, On Wed, 19 Jan 2022 at 10:56, Ihor Radchenko wrote: > As a side note, citeproc-el currently has poor performance on large org > files. It is unusable for me. Could you elaborate? In theory, oc-cs.el's performance should depend only on the number of citations (as opposed to the size of the Org document) and be in the same ballpark as pandoc's citeproc. It'd be interesting to know the details since I plan to work on speeding up citeproc-el's rendering, although you are the first one to actually complain :-). best wishes, András
Re: Yet another browser extension for capturing notes - LinkRemark
András Simonyi writes: > Just wanted to note that the CSL-based export processor, oc-csl.el, > already supports this: you can add an Org file as a bibliography, cite > items described by ol-bibtex style headings and export the citations. Thanks for telling! oc-csl is tricky because it relies on external library. So, it's hard to know what it can do and what it cannot do. As a side note, citeproc-el currently has poor performance on large org files. It is unusable for me. > It'd be very nice indeed if other built-in processors supported the > format too (e.g., "basic"). As for external ones, the CSL-based > activation processor I wrote > (https://github.com/andras-simonyi/org-cite-csl-activate) also > supports it Interesting. By the way, I recommend using composition instead of display property for rendering. See prettify-symbols-mode. Best, Ihor
Re: Yet another browser extension for capturing notes - LinkRemark
Dear All, On Wed, 19 Jan 2022 at 04:24, Ihor Radchenko wrote: > > Scientific papers require more work, it is necessary to make them > > available to org-cite somehow. Some nerds use quite peculiar blog > > engines and strange setting of metadata. So shopping on some sites might > > work better than other cases. > > I have plans to implement something called oc-org.el The plan is > using ol-bibtex-compatible Org headings as a source of citations. Just wanted to note that the CSL-based export processor, oc-csl.el, already supports this: you can add an Org file as a bibliography, cite items described by ol-bibtex style headings and export the citations. It'd be very nice indeed if other built-in processors supported the format too (e.g., "basic"). As for external ones, the CSL-based activation processor I wrote (https://github.com/andras-simonyi/org-cite-csl-activate) also supports it and there are plans to add support to Citar as well (through parsebib); see the discussion at https://github.com/bdarcus/citar/issues/397. best wishes, András > Best, > Ihor >
