That makes no sense. I think you are thinking about an alias file. But I am talking about alias data. There is no method to open a file from alias data (except by using system framework methods).
Christiaan > On 15 May 2025, at 16:47, Alexander,J <[email protected]> wrote: > > If the bookmark is an alias, isn't it possible to open the file directly via > the alias, without needing to recover/construct the path? That might not be > possible, though, with the functions available in emacs. > >> On 15 May 2025, at 15:37, Christiaan Hofman <[email protected]> wrote: >> >> There is no documentation of this format. It is basically private.I can give >> you some partial information. Basically, it is base64 encoded plist data. >> The plist is a dictionary with 2 keys: relativePath and bookmark. The >> relativePath gives the path relative to the .bib file. The bookmark is alias >> data generated by Apple, and its format is not documented. So when you get >> the(full) path (from this alias data), that is largely by accident. The only >> robust way to get the (full) path is by resolving the alias using the system >> Foundation framework (i.e. using an Objective-C or Swift program). Perhaps >> the best is to get the relative path, and also pass the .bib file path to >> your function. >> >> For instance, you could get the plist data from the command line using: >> >> echo “BDSKFILEVALUE” | base64 -D | plutil -convert xml1 -o - - >> >> And you can get the relative path using: >> >> echo “BDSKFILEVALUE” | base64 -D | plutil -extract relativePath raw -expect >> string -o - - >> >> Christiaan >> >>> On 15 May 2025, at 11:48, Alexander,J <[email protected]> wrote: >>> >>> Is there documentation describing how to decode the values of the >>> Bdsk-File-* fields, and extract the path to the file? >>> >>> I ask because I've written the following Emacs macro which, when invoked >>> while the cursor is sitting on a citation key, attempts to open the first >>> such file (if it exists) associated with that entry. At the moment, this >>> seems to work, but when I inspect the results of the Base64 decoding (by >>> visiting the "*Bibdesk Info*" buffer), there's a lot of noise in the buffer >>> and the file path appears in all lower-case... which makes me worry that >>> this macro is working largely by accident and there is a more robust way of >>> doing this. >>> >>> Many thanks, >>> >>> Jason >>> >>> >>> (defun open-bibdesk-file () >>> "Extract the bdsk-file-1 field and open the file." >>> (interactive) >>> (save-window-excursion >>> ;; Use existing reftex function to locate the entry >>> (reftex-view-crossref 2) >>> >>> ;; Now we're in the bib file at the entry >>> (let (citation-key field-content) >>> ;; Find the citation key >>> (save-excursion >>> (when (re-search-backward "^@\\w+{\\([^,]+\\)," nil t) >>> (setq citation-key (match-string 1)))) >>> >>> ;; Find the bdsk-file-1 field in the current entry >>> (save-excursion >>> (if (re-search-forward "bdsk-file-1\\s-*=\\s-*{\\([^}]*\\)}" nil t) >>> (progn >>> (let* >>> ((Bdsk-File-1 (match-string 1)) >>> (fstr (base64-decode-string Bdsk-File-1)) >>> (info-buffer (get-buffer-create "*Bibdesk Info*")) >>> path) >>> (string-match "\\(users/[- ,A-z0-9/_?]*.pdf\\)" fstr) >>> (setq path (format "/%s" (match-string 0 fstr))) >>> (with-current-buffer info-buffer >>> (erase-buffer) >>> (insert (format "path: %s" path)) >>> (insert (format "\n\n%s" fstr))) >>> (if (and path (file-exists-p path)) >>> (shell-command (concat "open " (shell-quote-argument >>> path))) >>> (message "File not found"))))))))) _______________________________________________ Bibdesk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-users
