> On Nov 13, 2015, at 23:23, Christiaan Hofman <cmhof...@gmail.com> wrote: > >> >> On Nov 13, 2015, at 20:52, Adam R. Maxwell <amaxw...@me.com >> <mailto:amaxw...@me.com>> wrote: >> >> >>> On Nov 13, 2015, at 04:05 , macula <ir...@me.com <mailto:ir...@me.com>> >>> wrote: >>> >>> Regarding the huge diffs, I am fully in agreement with Michael. Autofile >>> is a great feature, and so is the preview side panel, and it would be a >>> pity to view this as an either/or proposition. >> >> The underlying code for files is pretty complicated, and some if it >> has been there since the editor window had a drawer where you could >> view a single attached PDF :). >> >> The fileview and alias code was a massive rewrite, and it's just >> not really compatible with the older attachment code. Maybe it could >> be changed at the serialization level to only save a path, but reading >> it would then be tricky… >> >>> I just feel that the new >>> BibDesk is somehow rubbing against the aesthetic and openness of the >>> Bib(La)TeX format. >> >> I disagree with this; we namespace our private fields with a bdsk- >> prefix, to avoid clobbering anyone else's data. By comparison, >> I think BibLaTeX is not compatible with BibTeX as it's been defined >> for years (notably having changed the semantics of a field or two). >> This makes it impossible for BibDesk to support both. >> >> BibDesk's Date-Modified, Date-Added, Annote, Abstract are exceptions >> that predate our notion of private fields. >> >>> Many if not all of us are scholars and share our >>> materials with students and colleagues. Part of the appeal of this >>> format is that its plain-text elegance and standardization liberate the >>> data from any particular software. The very fact that BibDesk now >>> presumes to "own" the database is a bit contrary to the philosophy of >>> BibTeX, I think. >> >> To be clear, we "own" the bdsk-fields, and other well-behaved software >> should just ignore those. Sharing a .bib and set of attached files on >> a fileserver or cloud is an extremely complicated case, especially when >> multiple users can access it. Apple screws it up regularly, so I just >> prefer not to even try :). >> >>> More practically, wouldn't this issue be solved if there was a scheme >>> for storing the links locally in a separate file? I am thinking of a >>> simple one-to-one index assigning each bibliographic entry (identified >>> either by its BibTeX key or by a BibDesk-generate UUID) to a list of >>> links to the entry's attachments? >> >> Two separate files would be a disaster with Finder copies and >> moving/renaming/sharing. I suppose one could store it in the resource >> fork or extended attributes, but that's a different ball of hurt. >> >> We considered doing this in a number of ways (a new data file format, >> a package-based format). The former died on the vine, and the >> latter makes it hard to get to the .bib file for TeX usage, and isn't >> really compatible with version control systems. >> >>> For the time being, Michael, I am thinking to move my BibDesk-owned bib >>> file out of the git repo and into dropbox, then use bibtool to produce a >>> git-friendly version stripped of all links. >> >> You can probably do this with a template also, or use the minimal >> BibTeX export (but that might remove too much). >> >> I'm not entirely unsympathetic to the problems here, but they're not >> trivial to solve in a way that is robust, user-friendly, and backwards >> compatible. >> >> Adam >> > > > Optionally leaving out the alias data would lead to somewhat fragile data, so > the link could easily be lost. And it would make it very hard to move the > database in your file system. It would certainly lead to data that is not > backwards compatible, because currently the link is simply discarded when the > alias data is missing. Also, using a full path instead of the alias would > generally not solve anything because in general the directory structure on > different file system will not match, so such a partial solution would be > greatly reduced in value. So though I am also sympathetic to the problem, I > am very much ambivalent to whether we should really try to solve this. > > Christiaan
To test some of this out I have added a hidden (boolean) preference in the latest nightly build to only save the relative path of the linked files. It’s a boolean pref with key BDSKSaveLinkedFilesAsRelativePathOnly (see the Wiki on how to set this). Be careful though. The data will be much more fragile, and the saved data will not be compatible with older versions of BibDesk (i.e. before 1.6.4 (3701)). (When you’d open a file saved with this option in an older version of BD the linked files will be gone). For now this is just for testing purposes. I am not sure what to do with this, whether to advertise this on the Wiki, integrate this as an actual pref (that could be dangerous), or remove it later. Christiaan
------------------------------------------------------------------------------
_______________________________________________ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
