emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [wip-cite-new] experimental citeproc-el based activation processor


From: Nicolas Goaziou
Subject: Re: [wip-cite-new] experimental citeproc-el based activation processor
Date: Tue, 22 Jun 2021 20:08:58 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Hello,

András Simonyi <andras.simonyi@gmail.com> writes:

>> - As suggested by Bruce D'Arcus, we might move `org-cite-get-boundaries'
>>   in `oc.el' proper, since it is also used elsewhere (at least in
>>   "oc-basic.el").
>
> sure, it makes more sense there, especially because I took the
> fragment from your code IIRC (apologies for the lack of explicit
> attribution)

No problem: I stole it back from you! ;) I added `org-cite-boundaries'
to "oc.el", so your library can make use of it (after a rebase).

>> - Nitpick: (car element) => (org-element-type element)
>
> I was actually wondering about this when I wrote the code and if I may
> nitpick on the nitpick, I find the documentation a bit confusing in
> this respect. If the list representation is meant to be
> internal/private only (I guess that is the case), then maybe this
> should be more explicit in the docstrings, because now the docstring
> of `org-element-context' says
>
> "Return smallest element or object around point.
>
> Return value is a list like (TYPE PROPS) [...]"
>
> Omitting the second part or having something like "Internally, return
> value is [...]" would go a long way toward conveying the message that
> one shouldn't rely on the list representation.

It's not that one shouldn't rely on the list representation, but the
expressiveness of `car' is very low, whereas `org-element-type' is
explicit. I was merely suggesting to lean towards expressiveness here.

Regards,
-- 
Nicolas Goaziou



reply via email to

[Prev in Thread] Current Thread [Next in Thread]