On Jan 8, 2010, at 7:51, Adam R. Maxwell wrote: > > On Jan 7, 2010, at 9:43 PM, david craig wrote: > >> >>> you just need to stop abusing the global macro feature :). The entire >>> point of it is to display macros that you do not want included in your >>> database. >> >> More to the point, from the point of view of maintaining a single master >> bibliographic databse that makes it easy to generate bibliographies for >> individual papers, the whole point of THAT is not having to maintain >> multiple copies of the same set macros. > > There are too many uses of "that" in this sentence for me to figure out what > you're saying, at least at this time of night. Do you want separate files or > one big file? What problem are you really trying to solve? > >> It's not such a big deal to include that list in the same file as the >> bibliography database, but surely it's not so hard to see why the global >> macros feature might also make sense for this purpose, even if it is not >> how you have learned to conceptualize it? > > I wouldn't say that I "learned to conceptualize" it; I'm fairly confident in > saying that you're trying to abuse it, since I wrote the original > implementation. Although it's improved in the last 4.5 years, I don't think > the purpose has changed; it was designed to be complementary to the expansion > of month fields. > > http://bibdesk.cvs.sourceforge.net/viewvc/bibdesk/bibdesk/BibPref_Defaults.m?revision=1.11.4.2&view=markup&pathrev=TRY_CMH_CROSSREF_BR_1x > >> There is a practical reason for maintaining a separation between the >> master bib entries and the macros. As an example, say one journal wants >> full journal titles, another abbreviated ones. If you maintain two >> parallel sets of journal title expansions, you can have BibDesk load the >> set of macros you need from the appropriate external file before >> exporting the group to an independent bib file. > > I'm confused again. You want a standalone file and also want to keep your > macros in separate files? If you go with separate files, you're supposed to > feed them to BibTeX for expansion in your .tex files, not have BibDesk expand > them. Or do you want it to rewrite your .bib file with a different set of > macros from the global macros? Again, this is not what global macros are > designed for; they're a display/search convenience when you choose to use > separate files. > > Having said that, there is some benefit to this type of feature for template > users, but the global macro system is not the right place to handle it. >
It may be useful for some users, but that does not mean it's something that should be implemented. Apple has the 80% rule: design for 80% of your users, and don't implement features for 20% of your users. This would certainly apply to features that would affect the 80% or more, which is clearly what you're asking. So it's most certainly not under consideration. As Adam mentioned, for the 20% who want to do things different from anybody else and the design, we have some highly customizable power-user features, in this case export through templates. And that can do what you want (publications have a "usedMacro" property for that purpose, the full keypath for a collection tag should be "[email protected]"). You can take some sample templates from the Wiki as a starting point. > [...] > >> Any of that make sense? I'm open to other approaches, but the simple >> option I suggested in the previous email of including the option to >> include global macros when exporting a group would be one way to take >> care of it quite simply. > > Adding another context menu item and checkbox just adds more confusion to the > interface. There is a standard way to save/export, and too many ways of > doing the same thing leads to problems. > And a table context menu is the absolute wrong way to have a save item. > Again, what problem are you really trying to solve, and why? Christiaan ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Bibdesk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-users
