bibdesk-users Mailing List for BibDesk

Yes, this is a bug, sorry for that. It will be fixed in the next release.

Christiaan

> On 24 Jan 2026, at 09:15, Arne Leijon via Bibdesk-users <bib...@li...> wrote:
> 
> When I select the Edit / Find / Database Find and Replace, nothing happens.
> No find panel shows up. 
> 
> It is now a few years since last time I needed this, so I do not know if it is related by my current BibDesk version or MacOS version.
> My main BibDesk database is rather big, about 12000 entries, but I have the same problem with another smaller database.
> 
> Recently updated BibDesk and MacOS.
> 
> Bibdesk v. 1.9.10
> MacOS Sequoia v. 15.7.3
> 
> Yours
> Arne

When I select the Edit / Find / Database Find and Replace, nothing happens.
No find panel shows up. 

It is now a few years since last time I needed this, so I do not know if it is related by my current BibDesk version or MacOS version.
My main BibDesk database is rather big, about 12000 entries, but I have the same problem with another smaller database.

Recently updated BibDesk and MacOS.

Bibdesk v. 1.9.10
MacOS Sequoia v. 15.7.3

Yours
Arne

> Le 22 janv. 2026 à 23:33, Christiaan Hofman <cmh...@gm...> a écrit :
> 
> You can find it here: https://bibdesk.sourceforge.io/FolderPenIcon.icns
> 

Thanks. An upscaled version can be interesting, but not easy to create. Also, the difficulty is that, in a very populated Dock, the icon is little, and so the details (the text \cite{}) are difficult to read.

This icon was very adapted in the era of skeuomorphism.

> On 22 Jan 2026, at 22:28, quark67 via Bibdesk-users <bib...@li...> wrote:
> 
> Hello,
> 
>> Le 22 janv. 2026 à 16:29, Christiaan Hofman <cmh...@gm...> a écrit :
>> 
>>> On 22 Jan 2026, at 04:58, Adam R. Maxwell via Bibdesk-users <bib...@li... <mailto:bib...@li...>> wrote:
>>> 
>>> I would never have changed it from Mike's original folder/pen icon, so you guys are lucky Christiaan is in charge now! 
>> 
>> 
>> I basically agree with that. Unfortunately, keeping the original icon became untenable because it is really low resolution (128 pixels rather than 1024), which becomes horrible on modern computers.
> 
> Can we see somewhere the original icon, please? Thanks.


You can find it here: https://bibdesk.sourceforge.io/FolderPenIcon <https://bibdesk.sourceforge.io/FolderPenIcon>.icns

Christiaan

Hello,

> Le 22 janv. 2026 à 16:29, Christiaan Hofman <cmh...@gm...> a écrit :
> 
>> On 22 Jan 2026, at 04:58, Adam R. Maxwell via Bibdesk-users <bib...@li... <mailto:bib...@li...>> wrote:
>> 
>> I would never have changed it from Mike's original folder/pen icon, so you guys are lucky Christiaan is in charge now! 
> 
> 
> I basically agree with that. Unfortunately, keeping the original icon became untenable because it is really low resolution (128 pixels rather than 1024), which becomes horrible on modern computers.

Can we see somewhere the original icon, please? Thanks.

> On 22 Jan 2026, at 04:58, Adam R. Maxwell via Bibdesk-users <bib...@li...> wrote:
> 
> 
>> On Jan 21, 2026, at 18:21 , quark67 via Bibdesk-users <bib...@li...> wrote:
>> 
>>> But changing the icons is a lot of work, especially as it should also work in older systems (Apple has now made it very hard if not impossible to be fully cross-compatible)
>> 
>> Yes, according to the last update (2025-11-12) at https://mjtsai.com/blog/2025/08/08/separate-icons-for-macos-tahoe-vs-earlier/
> 
> I would never have changed it from Mike's original folder/pen icon, so you guys are lucky Christiaan is in charge now! 
> 
> IMHO it's not really worth the effort to bend to every variation of Apple's design fads, especially if you support older platforms, since Apple will just find a way to make it look even stupider next year. Apple has made backwards compatibility a lot harder for developers over the last 15 years, and deserves nothing but ill will and castigation for it.
> 
> One of my favorite pithy comments on Apple's new icons was linked on Michael Tsai's blog:
> 
> https://mjtsai.com/blog/2026/01/13/apple-creator-studio/
> 
> Héliographe:
> 
> "If you put the Apple icons in reverse it looks like the portfolio of someone getting really really good at icon design."
> 
> https://mastodon.social/@heliographe_studio/115890819509545391
> 
> Adam
> 


I basically agree with that. Unfortunately, keeping the original icon became untenable because it is really low resolution (128 pixels rather than 1024), which becomes horrible on modern computers.That was really the main reason I updated the icons at the time, and then I sort-of followed the guidelines. I did not really like those (too uniform) styles, but I succumbed. But not completely, and that seems to bite now (in this case the little tab at the top causes it to be caged).

Christiaan

> On Jan 21, 2026, at 18:21 , quark67 via Bibdesk-users <bib...@li...> wrote:
> 
>> But changing the icons is a lot of work, especially as it should also work in older systems (Apple has now made it very hard if not impossible to be fully cross-compatible)
> 
> Yes, according to the last update (2025-11-12) at https://mjtsai.com/blog/2025/08/08/separate-icons-for-macos-tahoe-vs-earlier/

I would never have changed it from Mike's original folder/pen icon, so you guys are lucky Christiaan is in charge now! 

IMHO it's not really worth the effort to bend to every variation of Apple's design fads, especially if you support older platforms, since Apple will just find a way to make it look even stupider next year. Apple has made backwards compatibility a lot harder for developers over the last 15 years, and deserves nothing but ill will and castigation for it.

One of my favorite pithy comments on Apple's new icons was linked on Michael Tsai's blog:

https://mjtsai.com/blog/2026/01/13/apple-creator-studio/

Héliographe:

"If you put the Apple icons in reverse it looks like the portfolio of someone getting really really good at icon design."

https://mastodon.social/@heliographe_studio/115890819509545391

Adam

Hello,

> not completely sure what the exact requirements are (like corner radius)

You need to use the Icon Composer app, from Apple, it will help you. 

https://developer.apple.com/icon-composer/

Some help here : https://developer.apple.com/documentation/xcode/creating-your-app-icon-using-icon-composer/

I hope this can help.

But, yes, the current icon is very beautiful with its shiny pen.

> But changing the icons is a lot of work, especially as it should also work in older systems (Apple has now made it very hard if not impossible to be fully cross-compatible)

Yes, according to the last update (2025-11-12) at https://mjtsai.com/blog/2025/08/08/separate-icons-for-macos-tahoe-vs-earlier/

I have no longer a Mac under the previous system so I cannot compare.

> And right now, I don’t have the time to replace all the app and document icons (they come together).

Perhaps you could keep the document icons (eg /Applications/TeX/BibDesk.app/Contents/Resources/risDocIcon.icns) and for the app icon, use a yellow background and add the pen and the guillemets over it with Icon Composer app…

By the way, why is the main app icon (/Applications/TeX/BibDesk.app/Contents/Resources/BibDesk.icns) only 94 kB (great), 
but the /Applications/TeX/BibDesk.app/Contents/Resources/cacheDocIcon.icns 1.3 MB size (!!!), 
the /Applications/TeX/BibDesk.app/Contents/Resources/bibDocIcon.icns 648 kB size (!!!), 
the /Applications/TeX/BibDesk.app/Contents/Resources/risDocIcon.icns 657 kB size (!!!) 
and the /Applications/TeX/BibDesk.app/Contents/Resources/searchDocIcon.icns 439 kB size (!!!)?

Also 3.4 MB for /Applications/TeX/BibDesk.app/Contents/Resources/Assets.car seems a little big. Is this very necessary? Isn’t, for example, the file icon_512x512_Normal@2x_1.png (yellow textured square) a working file (for creating icons, like ico...@2x...?) and not a file really used by the app?

These files can probably be smaller.

Perhaps this can be in mind when you will have the time for modernize the icons?

Thanks.

Yes, it is really annoying Apple is enforcing standards. Though IO am not completely sure what the exact requirements are (like corner radius). 

But changing the icons is a lot of work, especially as it should also work in older systems (Apple has now made it very hard if not impossible to be fully cross-compatible). And right now, I don’t have the time to replace all the app and document icons (they come together). 

BTW, there should be a workaround to get rid of the gray borders. Show the app in Finder and call Get Info to get the info panel.Now go into the BibbDesk bundle (Show Package Contents in the contextual menu), and into Contents and Resources. Now find the file BibDesk.icns, and drop it on the Get Info panel to set the system icon to the actual icon.

Christiaan

> On 21 Jan 2026, at 22:10, Luc Bourhis via Bibdesk-users <bib...@li...> wrote:
> 
> Hi,
> 
> consider Bibdesk icon in my Dock on Tahoe
> 
> <Bibdesk.png>
> 
> and contrast with Apple own apps
> 
> <System.png>
> 
> Bibdesk icon does not seem to conform to Apple’s new standard enforced in Tahoe, thus padding it with that gray area. Bibdesk is not alone here actually. I see the same glitch with Skim for example.
> 
> Only a cosmetic problem of course but I am quite sensitive to cosmetics!
> 
> Best wishes,
> 
> Luc Bourhis

Hi,

consider Bibdesk icon in my Dock on Tahoe

The BibDesk development team is pleased to announce that a new version of BibDesk, version 1.9.10, is now available.
This release fixes a bug with reading the file search index cache in this morning’s release.

We thank the users who have contributed to BibDesk development by sharing their experiences with BibDesk, and testing nightly builds. 

This release can be obtained by selecting "check for updates" in the "BibDesk" menu, visiting the Sourceforge downloads page at

https://sourceforge.net/projects/bibdesk/ <https://sourceforge.net/projects/bibdesk/>

or by visiting the BibDesk home page at

https://bibdesk.sourceforge.io/ <https://bibdesk.sourceforge.io/>

or by following the link below, which will begin immediate download:

https://sourceforge.net/projects/bibdesk/files/BibDesk/latest/download <https://sourceforge.net/projects/bibdesk/files/BibDesk/latest/download>

For those interested follow the full release notes for this version, as well as the previous.

Release notes for BibDesk version 1.9.10

Bugs Fixed
  *  Fix reading of file search index cache

Release notes for BibDesk version 1.9.9

Bugs Fixed
  *  Fix committing field selection in sheet
  *  Fix a crasher in file content search

The BibDesk development team is pleased to announce that a new version of BibDesk, version 1.9.9, is now available.

We thank the users who have contributed to BibDesk development by sharing their experiences with BibDesk, and testing nightly builds. 

This release can be obtained by selecting "check for updates" in the "BibDesk" menu, visiting the Sourceforge downloads page at

https://sourceforge.net/projects/bibdesk/ <https://sourceforge.net/projects/bibdesk/>

or by visiting the BibDesk home page at

https://bibdesk.sourceforge.io/ <https://bibdesk.sourceforge.io/>

or by following the link below, which will begin immediate download:

https://sourceforge.net/projects/bibdesk/files/BibDesk/latest/download <https://sourceforge.net/projects/bibdesk/files/BibDesk/latest/download>

For those interested follow the full release notes for this version.

Release notes for BibDesk version 1.9.9

Bugs Fixed
  *  Fix committing field selection in sheet
  *  Fix a crasher in file content search

The BibDesk development team is pleased to announce that a new version of BibDesk, version 1.9.8, is now available.

We thank the users who have contributed to BibDesk development by sharing their experiences with BibDesk, and testing nightly builds. 

This release can be obtained by selecting "check for updates" in the "BibDesk" menu, visiting the Sourceforge downloads page at

https://sourceforge.net/projects/bibdesk/ <https://sourceforge.net/projects/bibdesk/>

or by visiting the BibDesk home page at

https://bibdesk.sourceforge.io/ <https://bibdesk.sourceforge.io/>

or by following the link below, which will begin immediate download:

https://sourceforge.net/projects/bibdesk/files/BibDesk/latest/download <https://sourceforge.net/projects/bibdesk/files/BibDesk/latest/download>

For those interested follow the full release notes for this version.

Release notes for BibDesk version 1.9.8

Bugs Fixed
  *  Fix template editor for multiple BibTeX types
  *  Reopen last open files or default file for every launch type
  *  Improve committing edits
  *  Fix a memory leak
  *  Improve UI updating when information changes
  *  Fix autosizing columns
  *  Use modern browser for import from web
  *  Display linked files and URLs in text import sheet
  *  Fix downloading from web
  *  Fix toolbar customization for document
  *  Support setting custom shortcuts for bookmarks and search bookmarks

BibDesk has never escaped underscores on import, as far as I know. I hope that helps.

Nathan

> On Nov 6, 2025, at 10:48 AM, Metcalf, Thomas H CIV USN NRL WASHINGTON DC (USA) via Bibdesk-users <bib...@li...> wrote:
> 
> What confuses me is that some entries I’d added earlier also had underscores in the Eprint field, but they were all escaped. I don’t know if BibDesk did this upon import or if they came that way from the repository. To check, I re-downloaded a reference from the same repository (pubs.aip.org) which had escaped underscores in the Eprint field and compared with the newly downloaded, error-causing file. For both entries, the underscores were not escaped. So it seems to me either earlier versions of BibDesk used to do this on import, or the repository used to escape the underscores but doesn’t anymore.

I do see that there are several discussions in previous years about underscores in URLs, but in this case, something which had been working fine just gave me an error and I’m trying to figure out whether BibDesk or the repository from which I got the BibTeX entry from has changed.

The error in question is in the “Eprint’ field: I recently added a few new references to a bibliography for a paper, they had unescaped underscore characters, and LaTeX threw an error.

I’m currently using BibDesk Version 1.9.7 (6117) and my document uses the REVTeX 4.2f package which includes apsrev4-2.bst and which uses hyperref. My general method of adding references to .bib files is to download the BiBTeX citation from the journal page, then import into via New Publication from File. I don’t remember when I upgraded to this version of BibDesk but I do know that the version of REVTeX has stayed the same.

What confuses me is that some entries I’d added earlier also had underscores in the Eprint field, but they were all escaped. I don’t know if BibDesk did this upon import or if they came that way from the repository. To check, I re-downloaded a reference from the same repository (pubs.aip.org) which had escaped underscores in the Eprint field and compared with the newly downloaded, error-causing file. For both entries, the underscores were not escaped. So it seems to me either earlier versions of BibDesk used to do this on import, or the repository used to escape the underscores but doesn’t anymore.

I can fix the issue by manually escaping the underscores or deleting the Eprint field, but I’d like to figure out what happened to disrupt the automatic process.

--Tom Metcalf

On 2 Oct 2025, at 15:05, Christiaan Hofman <cmh...@gm...> wrote:
> 
>> On 2 Oct 2025, at 12:13, Trevor Jenkins <bsl...@gm... <mailto:bsl...@gm...>> wrote:
>> 
>> I’m working with some documents/bibliographies that include Korean text. pdflatex bails on any Korean text. Xetex seems to be the favoured version of TeX but after changing the TeX executable I cannot get BibDesk to produce a preview of any entry that includes Hangul. My bibtex program is still the usual executable. What do I need to do to get BibDesk to produce the preview for such references?
> 
> 
> You may also have to change the text encoding in the TeX Preview preferences.Usually UTF-8 works best.

Already have it set to UTF-8 for preview; been so since I first started with BibDesk.

Turns out the TeX template encoding setting was (part of) the culprit. Changing that to UTF-8 as well fixed the problem.

감사합니다. Thank you!

Regards, Trevor.

<>< Re: deemed!

> On 2 Oct 2025, at 12:13, Trevor Jenkins <bsl...@gm...> wrote:
> 
> I’m working with some documents/bibliographies that include Korean text. pdflatex bails on any Korean text. Xetex seems to be the favoured version of TeX but after changing the TeX executable I cannot get BibDesk to produce a preview of any entry that includes Hangul. My bibtex program is still the usual executable. What do I need to do to get BibDesk to produce the preview for such references?
> 
> Environment
> MacTex 2023 (plan to upgrade to 2025 version ASAP)
> macOS 15.6 Sequoia (holding off on upgrade to Taheo because of report problems)
> BibDesk 1.9.7
> 
> Regards, Trevor.
> 
> <>< Re: deemed!


You may also have to change the text encoding in the TeX Preview preferences.Usually UTF-8 works best.

Christiaan

I’m working with some documents/bibliographies that include Korean text. pdflatex bails on any Korean text. Xetex seems to be the favoured version of TeX but after changing the TeX executable I cannot get BibDesk to produce a preview of any entry that includes Hangul. My bibtex program is still the usual executable. What do I need to do to get BibDesk to produce the preview for such references?

Environment
MacTex 2023 (plan to upgrade to 2025 version ASAP)
macOS 15.6 Sequoia (holding off on upgrade to Taheo because of report problems)
BibDesk 1.9.7

Regards, Trevor.

<>< Re: deemed!

Dear Alan,

I see no reason why one should change well established syntax rules of BibTeX. Sharing with others is exactly the reason why one should stick to the rules and conventions. I appreciate that BibDesk is enforcing those rules and conventions precisely for those reasons. The fact that many programmers responsible for citation exports from many journals are ignorant of those rules is also no reason to arbitrarily change those rules, e.g. in BibDesk. They simply have to learn. I regularly find myself reminding journals repeatedly of those rules, sic. To use throughout in all TeX, LaTeX, BibTeX etc. UTF-8 would be a major revision with far reaching consequences requiring huge programming efforts I would rather not recommend.

Regards,
Andreas


ETH Zurich
Prof. em. Dr. Andreas Fischlin
Formerly IPCC Vice-Chair WGII
Systems Ecology - Institute of Biogeochemistry and Pollutant Dynamics
CHN E 24
Universitaetstrasse 16
8092 Zurich
SWITZERLAND

and...@en... <mailto:and...@en...>
www.sysecol.ethz.ch/people/andreas.fischlin.html <http://www.sysecol.ethz.ch/people/andreas.fischlin.html>

+41 44 633-6090 phone
+41 79 595-4050 mobile

             Make it as simple as possible, but distrust it!
________________________________________________________________________















> On 7 Jun 2025, at 17:46, Adam R. Maxwell via Bibdesk-users <bib...@li...> wrote:
> 
> 
>> On Jun 7, 2025, at 08:18 , Alan Munn via Bibdesk-users <bib...@li... <mailto:bib...@li...>> wrote:
>> 
>> It seems that BibDesk doesn't allow accented characters in cite keys, even though neither bibtex nor biber cares about such a restriction necessarily. Is there a way to turn off this restriction? Although I'm happy to have my own keys so restricted, when sharing .bib files with others it makes things complicated since entries with such keys can't be imported.
> 
> Technically a BibTeX citekey is a LaTeX command, so restricted to the same set of characters. The restriction is relaxed quite a bit to include things like dashes, but it doesn't extend to accented characters. I can imagine UTF-8 might pass through biber or bibtex, but you're playing with fire.
> 
> This looks like a pretty good answer. BibDesk basically assumes you're using LaTeX (and IIRC the btparse library enforces this):
> 
> https://tex.stackexchange.com/questions/581901/what-is-the-safe-character-set-for-a-bibtex-label#
> 
> Adam
> 
> _______________________________________________
> Bibdesk-users mailing list
> Bib...@li...
> https://lists.sourceforge.net/lists/listinfo/bibdesk-users

> On Jun 7, 2025, at 08:18 , Alan Munn via Bibdesk-users <bib...@li...> wrote:
> 
> It seems that BibDesk doesn't allow accented characters in cite keys, even though neither bibtex nor biber cares about such a restriction necessarily. Is there a way to turn off this restriction? Although I'm happy to have my own keys so restricted, when sharing .bib files with others it makes things complicated since entries with such keys can't be imported.

Technically a BibTeX citekey is a LaTeX command, so restricted to the same set of characters. The restriction is relaxed quite a bit to include things like dashes, but it doesn't extend to accented characters. I can imagine UTF-8 might pass through biber or bibtex, but you're playing with fire.

This looks like a pretty good answer. BibDesk basically assumes you're using LaTeX (and IIRC the btparse library enforces this):

https://tex.stackexchange.com/questions/581901/what-is-the-safe-character-set-for-a-bibtex-label#

Adam

That is not correct, BibTeX and biber only allow a restricted set of ASCII characters in the cite key.

Christiaan

> On 7 Jun 2025, at 17:18, Alan Munn via Bibdesk-users <bib...@li...> wrote:
> 
> It seems that BibDesk doesn't allow accented characters in cite keys, even though neither bibtex nor biber cares about such a restriction necessarily. Is there a way to turn off this restriction? Although I'm happy to have my own keys so restricted, when sharing .bib files with others it makes things complicated since entries with such keys can't be imported.
>  
> Thanks
> Alan
>  
> --
> Alan Munn
> am...@gm...

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>It seems that BibDesk doesn&#39;t allow accented characters in cite keys, even though neither bibtex nor biber cares about such a restriction necessarily. Is there a way to turn off this restriction? Although I&#39;m happy to have my own keys so restricted, when sharing .bib files with others it makes things complicated since entries with such keys can&#39;t be imported.</div>

<div>&nbsp;</div>

<div>Thanks</div>

<div>Alan<br/>
&nbsp;</div>

<div class="signature">--<br/>
Alan Munn<br/>
am...@gm...</div></div></body></html>

Jason: As is mentioned in the FAQ in the BibDesk wiki, there are some open-source programs that can decode Bdsk-File-* fields. I mention them in case you didn't know and wanted to look at their code.

The Python script bibdesk2zotero by Ed Summers makes use of some Python libraries: https://github.com/edsu/bibdesk2zotero <https://github.com/edsu/bibdesk2zotero>

The Better BibTeX for Zotero plugin implemented Bdsk-File-* decoding in response to this issue: https://github.com/retorquere/zotero-better-bibtex/issues/2374 <https://github.com/retorquere/zotero-better-bibtex/issues/2374>

And its TypeScript code can be seen in this commit: https://github.com/retorquere/zotero-better-bibtex/commit/dfb04822c01c31845c24ab07ccffa25e4212ac3a <https://github.com/retorquere/zotero-better-bibtex/commit/dfb04822c01c31845c24ab07ccffa25e4212ac3a>

Nathan

> On May 15, 2025, at 3:21 PM, Alexander,J <ja...@ls...> wrote:
> 
> Ah, yes - you’re right. I had been making that assumption. 
> 
> Given these considerations, I think I’ll just stick with my current method that accidentally works, and file these helpful notes away for the time when it no longer works and I need to find a better solution. 
> 
> Thank you!
> 
> Jason
> 
> Sent from my iPhone
> 
>> On 15 May 2025, at 17:47, Christiaan Hofman <cmh...@gm...> wrote:
>> 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 <ja...@ls...> 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 <cmh...@gm...> 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 <ja...@ls...> 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")))))))))

Ah, yes - you’re right. I had been making that assumption. 

Given these considerations, I think I’ll just stick with my current method that accidentally works, and file these helpful notes away for the time when it no longer works and I need to find a better solution. 

Thank you!

Jason

Sent from my iPhone

> On 15 May 2025, at 17:47, Christiaan Hofman <cmh...@gm...> wrote:
> 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 <ja...@ls...> 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 <cmh...@gm...> 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 <ja...@ls...> 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
> Bib...@li...
> https://lists.sourceforge.net/lists/listinfo/bibdesk-users

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 <ja...@ls...> 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 <cmh...@gm...> 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 <ja...@ls...> 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")))))))))