Enhance citar-display-transform-functions

[bdarcus]

Modify the defcustom so that transform functions can be specified by template, and adjust citar-get-display-value accordingly by adding an optional "template" argument.

So default works the same, but you can now also do this:

ELISP> (citar-get-display-value '("author" "editor") "francis2012" 'notes)
"Francis, Giles-Corti & Wood et al."

Close #694

Also, disable linting on everything before Emacs snapshot, since there are recent changes in indenting rules that cannot be accounted for cross-version.

---

Aside: I'm confused on how to clear the candidate cache, so I can force regeneration. This does not work, for example:

(clrhash (citar--format-candidates))

If you have time over the next few days, can you take a look at this @aikrahguzar @roshanshariff?

EDIT: I think I'm missing a piece here ATM, which is the template connection. But I'm tired, so will need to look at it again later. I mainly want confirmation this is a good idea though.

EDIT 2: took another look this morning. I think citar-format--entry is where this would be, but it currently takes a format rather the symbol for it. So will need to think about that.

[aikrahguzar]

I am a bit hazy on what is the purpose but the code looks alright and I left some minor comments.

[aikrahguzar]

Actually since citar-display-transform is getting so deeply nested it might be better to use a plist with template as keys.

[bdarcus]

Actually since citar-display-transform is getting so deeply nested it might be better to use a plist with template as keys.

I was wondering this also, and whether the transform details should stay with the template? Maybe something like:

(note
 (:template "${author editor} - ${title}" :transforms
            ((("author" "editor")
              citar--shorten-names))))

... or even:

(note
 (:template "${'author' 'editor'}" :transforms
            (:fields
              ("author" "editor")
              :funsymbol citar--shorten-names :args
              (3 "&")))
 main
 (:template "${'title'}")
 suffix
 (:template "${'=key=}"))

The purpose is to have different transforms for different contexts, most immediately for minibuffer vs note titles. See #694.

[aikrahguzar]

Aside: I'm confused on how to clear the candidate cache, so I can force regeneration. This does not work, for example:

(clrhash (citar--format-candidates))

I think (clrhash citar-cache--bibliographies) should do it.

[aikrahguzar]

... or even:

(note
 (:template "${'author' 'editor'}" :transforms
            (:fields
              ("author" "editor")
              :funsymbol citar--shorten-names :args
              (3 "&")))
 main
 (:template "${'title'}")
 suffix
 (:template "${'=key=}"))

I like the idea of unifying templates and transforms since they are very related and them being close together makes them easier to grasp. There is some chance of breakage because of that and unintended consequences.

[bdarcus]

I like the idea of unifying templates and transforms since they are very related and them being close together makes them easier to grasp. There is some chance of breakage because of that and unintended consequences.

On the second sentence, you mean if we keep them split, or make the change?

Regardless, the data structure is getting a little complex; I'm finding myself having to use YAML to think about it!

Maybe I need to think again about variable modifiers (not sure what to call them); something like:

${author editor:30%et-al} 

There, the simplest config could be something like:

((sn citar--shorten-names)
 (et-al citar--shorten-names 3 "&")
 (st citar--shorten-title)
 (dd citar--display-date))

That could allow citar-templates to remain the same at least, and offer greater flexibility.

But not clear that there's a convenient way to do default transforms on fields then. Might need to require people to specify transforms in that case, like ${author%sn}? There's something to be said for requiring templates to be explicit?

[bdarcus]

Maybe I need to think again about variable modifiers ...

I've reverted this to draft, and opened up an alternate branch with this idea in #735.

[bdarcus]

I'm going to close this, at least for now.