How to handle special chars in bib-keys?

[jgru]

Dear @bdarcus,
dear citar-users,

I have a question regarding the handling of special chars like slashes in bibliography-keys which are commonly used by the big bibliography databases, e.g. DBLP.

I would like to leave the keys which were given by those services, i.e. untouched and implement a custom mangling for files and notes to transform a key like DBLP:journals/ijim/AlmogbelA22 to almogbel2022.{pdf,org} .
I thought of overriding citar-file--make-filename-regexp (keys extensions &optional additional-sep).

Has somebody done something similar before and is willing to share some code or do you not see any need for keeping those precise bib-keys? If you have any tips regarding this issue, I would be glad to hear them.

Best regards,
jgru

[jgru]

I tried to extend citar-file--make-filename-regexp with something like this:

(keys (mapcar #'(lambda (k) (if (string-match-p "/" k)
                            (downcase (car (last (split-string k "/"))))
                            k))
              keys)))

However, does not work, although the resulting regexp should match. I assume, this is rooted in the way citar-file--directory-files works and "derives keys" from matched filenames.

Since I am looking for easy and future-proof solution, I thought I might just add the file = {transformedkey.pdf} field in the bibliography entries, but this requires a change to citar-file--get-note-filename.

(defun citar-file--get-note-filename (key dirs extensions)
  "Return existing or new filename for KEY in DIRS with extension in EXTENSIONS.
This is for use in a note function where notes are one-per-file,
with citekey as filename.
Returns the filename whether or not the file exists, to support a
function that will open a new file if the note is not present."
  (let ((files (citar-file--directory-files dirs (list key) extensions
                                            citar-file-additional-files-separator))
        (key (if (string-match-p "/" key)
                                     (car (last (split-string key "/")))
                                     key)))
    (or (car (gethash key files))
        (when-let ((dir (car dirs))
                   (ext (car extensions)))
          (expand-file-name (concat key "." ext) dir)))))

Problematic is here that the function citar-has-file is used to determine the availability as well.
Since this approach feels quite hacky and inconsistent, do you have any better ideas?

[bdarcus]

I've been pretty distracted with work stuff past weeks/months, and so have not been coding for awhile. So it's hard to get my brain to process this!

Just to clarify, are you only want to transform the keys?

[jgru]

I've been pretty distracted with work stuff past weeks/months, and so have not been coding for awhile. So it's hard to get my brain to process this!

Thank you very much for your reply - especially under heavy workload.

Just to clarify, are you only want to transform the keys?

Exactly, basically I want a transformer function translating keys to filenames.

A generic defcustomed citar-transform-key-func would be great. But a note on how to patch it would be fine as well.

My modification of citar-file--get-note-filename works for opening notes, however, it only opens those, but does not display that they are available due to the innerworkings of citar-file--directory-files. I somehow need to put the transformation in there, since modifying citar-file--make-filename-regexp is not enough.
Any tip how I could accomplish this?

Thank you very much for citar in general and in advance for eventual further help.

[jgru]

Hi @bdarcus, I got it to work by modifying the function citar-file--has-file in addition.
The WIP can be found here: jgru@1e444aa
If you think this might be something to upstream, I can refactor the transfom-function to be configurable via def-custom. What do you think?

Best regards,
jgru

[bdarcus]

Hi @jgru - I think if we were going to add it it would be to enable specific, more general, features.

Perhaps obvious might be #397 (though this will also depend on upstream improvements for parsing) and/or #518?

WDYT?

[jgru]

Hi @bdarcus, thanks for getting back to me. Actually that might be beneficial for #518.
I think I'll come up with a draft for a more generic approach to the code presented earlier today and ping you at time.