Daan Ro <daant...@gmail.com> writes: >> Would you consider it? See >> https://orgmode.org/worg/org-contribute.html#copyright > > I have already done the copyright assignment.
Oops. Right. I did not search by email, and you are listed under slightly different name there. >> > + (let* ((cands (hash-table-keys completion-hash-table)) >> > + ;; Handle regexp separator? >> >> Is it a TODO? You missed this question. >> dlet is unnecessary here. A normal let will do because `crm-separator' >> is already a dynamically scoped variable. > > I was thinking what if crm.el isn't already loaded? org.el has > defvar-ed crm-separator but a test like this would still give an > unintended separator: > .. Well. Right. Although dlet is a fairly unusual way to do it (not wrong; just unusual). We usually do something like (defvar crm-separator) ; defined in crm.el (let ((crm-separator ...)) ...) > The previous patch worked for me but I'm still not skeptical about the > dynamic option's code quality. Is inserting candidates in a temporary > buffer separated by newline then search on them really the > optimal/flexible way? It is one way. I'd personally just use `string-match-p' matching the strings directly. > +*** New option ~org-cite-basic-complete-key-crm-separator~ > + > +This option makes ~org-cite-basic--complete-key~ use > +~completing-read-multiple~ instead of the default consecutive prompts. > +It can also be set to dynamically compute the ~crm-separator~ so not > +to appear in completion candidates. Talking about an internal function (...--...) can be confusing. Instead, we should simply say that it affects default completion for citations. -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
