Add optional affixation symbol for currently cited references

[andersjohansson]

It's helpful to see what you’ve already cited in the current document.This is something I have missed from my earlier system that extended org-zotxt (before org-cite).

I'm not sure if you want to include something like this, and it is not finished for anything more than org.

An implementation for fetching cite keys in org-mode is included, with configuration for fetching in narrowed buffer or not, and from several org buffers.

Optional grouping by currently cited is also included, however, this seems to interfere with the multi-selection display based on grouping.

(Took some time to go through my citar config and this branch today)

[bdarcus]

Cool; related: #645 #699.

[andersjohansson]

Screenshot:

This is with:

(setq citar-symbols
   `((file ,(all-the-icons-faicon "file-o" :face 'all-the-icons-green :v-adjust -0.1) . " ")
     (note ,(all-the-icons-material "speaker_notes" :face 'all-the-icons-blue :v-adjust -0.3) . " ")
     (link ,(all-the-icons-octicon "link" :face 'all-the-icons-orange :v-adjust 0.01) . " ")
     (cited ,(all-the-icons-faicon "quote-right" :face 'org-cite) . " ")))

[bdarcus]

So on #645, If it's too much of a hassle, we can save it for later., but as you work on this, can you think about how to do both together?

It could avoid us having to add additional defcustoms and such.

[andersjohansson]

By the way, it does a lot of parsing of org-files (on every invocation of citar-org-select-key or citar-org-insert-citation, but I have so far (have used this for a few months) not experienced this as slowing down citing.

[aikrahguzar]

An implementation for fetching cite keys in org-mode is included, with configuration for fetching in narrowed buffer or not, and from several org buffers.

This can be done for latex by parsing the aux file produced after compilation. reftex probably has something like that too. Parsing aux file should be simpler and faster and will include citations from all the files that are used to produce the document. It has the disadvantage that it will be reflect the document at the time of last compilation but I don't think it possible to write latex without compiling very often.

[bdarcus]

Thinking about it from the user-facing configuration end, would not something like this work for addressing #645?

(defvar citar-indicators
  (list (list :indicator "F"
              :function #'citar-has-files
              :hidden-text "has:files")
        (list :indicator "L"
              :function #'citar-has-links
              :hidden-text "has:links")
        (list :indicator "N"
              :function #'citar-has-notes
              :hidden-text "has:notes")))

And then a function like this:

(defun citar--make-indicator-processors (ispecs)
  "Return a list of indicator processors."
  (mapcar
   (lambda (ispec)
     (list :indicator (plist-get ispec :indicator)
           :hidden-text (plist-get ispec :hidden-text)
           :function (funcall (plist-get ispec :function))))
   ispecs))

Then the resulting list could be let-bound to a variable, and the affix built by iterating through that.

(when (funcall (plist-get proc :function) citekey) (plist-get proc :indicator))

---

Also, I will note that one of the use cases I identified for that is related to this PR. I had in mind an indicator for citar-org-roam that show whether any notes in the database cited the reference, and therefore signal which references citar-org-roam-cited would return any results for (which is the primary function of these indicators).

[bdarcus]

OK, @andersjohansson, I merged #753. If you rebase from main (or just create a new branch, since I created a number of merge conflicts for you!), I think it should be easy to adapt this to that. Conceptually it all works the same; it's just the configuration and supporting functions is more general.

[andersjohansson]

Cool! I re-implemented it with following #753. This actually makes it reasonable to do this as a plugin to citar. The only point where I would need to use advice in that case would be for the points where I do the buffer parsing (the not very carefully chosen citar-org-select-key and citar-org-insert-citation).

I'm not sure if you are interested to merge this eventually?

The configuration of pretty symbols would look like this then. A bit more tedious to edit the :symbol slot of the indicator structs.

(setf (citar-indicator-symbol citar-indicator-files)
      (all-the-icons-faicon "file-o" :face 'all-the-icons-green :v-adjust -0.1)
      (citar-indicator-symbol citar-indicator-links)
      (all-the-icons-octicon "link" :face 'all-the-icons-orange :v-adjust 0.01)
      (citar-indicator-symbol citar-indicator-notes)
      (all-the-icons-material "speaker_notes" :face 'all-the-icons-blue :v-adjust -0.3)
      (citar-indicator-symbol citar-indicator-cited)
      (all-the-icons-faicon "quote-right" :face 'org-cite))

(setq citar-indicators (list citar-indicator-links
                             citar-indicator-files
                             citar-indicator-notes
                             citar-indicator-cited))

[andersjohansson]

Oh, I saw you added indicator configuration here as well: https://github.com/emacs-citar/citar/wiki/Indicators.

[bdarcus]

I'm not sure if you are interested to merge this eventually?

I'm not opposed at all; with this all configurable, users can use or not. And I do like the idea.

From my POV whether to include is really about the general fit, and this one seems to fit, as it's really about writing in the major modes, and isn't about any specific other packages.

I think the design question would just be whether and how to integrate into the major-mode adapter system.

I suppose the "list-keys" key is all that's really required, though it's currently defined as only include the citekeys in the "current buffer."

This actually makes it reasonable to do this as a plugin to citar.

Yes; I'll leave it up to you, though just note that the citar-capf was originally spun out, but we merged it back in because it was such a small amount of code.

The only point where I would need to use advice in that case would be for the points where I do the buffer parsing (the not very carefully chosen citar-org-select-key and citar-org-insert-citation).

Not following here, but if you need to advice, perhaps there are tweaks to that code that would avoid that?

I developed citar-org-roam independently of citar in part to test and refine the API, and I think it's better because of it.

I'll also try to test this (been busy with other things). Is it ready for that?

[andersjohansson]

I'm not sure if you are interested to merge this eventually?

I'm not opposed at all; with this all configurable, users can use or not. And I do like the idea.

From my POV whether to include is really about the general fit, and this one seems to fit, as it's really about writing in the major modes, and isn't about any specific other packages. :+1:

I think the design question would just be whether and how to integrate into the major-mode adapter system.

I suppose the "list-keys" key is all that's really required, though it's currently defined as only include the citekeys in the "current buffer."

Oh yes! I had missed that this was already there. I kind of reimplemented it with my function for org mode (+ the multi-buffer stuff, but that should ideally perhaps be designed in a smarter way no matter).

My suggestion now then, to add this in a simple enough, but still general way, would be to try to reuse the list-keys functions for the current major mode to populate the lookup hash-table at a suitable time. The question is where to do this.

I created a new suggestion over at #761