> On Nov 13, 2015, at 04:05 , macula <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 ------------------------------------------------------------------------------ _______________________________________________ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
