On 17.9.2013, at 03:45, Eric Abrahamsen wrote: > > On 09/17/13 03:26 AM, Rasmus wrote: >> Hi Carsten, >> >> Carsten Dominik writes: >> >>>> Note: I should be obvious that I prefer to load as little stuff be >>>> default as possible. That is: I'm biased, but it's OK when everyone >>>> knows. >>> >>> Yes. Of course the cleanest solution would be to load as little >>> as possible. But convenience and backward compatibility are >>> also a concern which I would like to consider. >> >> I agree. And, as said, people who want a 'clean' solution (to his or >> her mind) can easily get that. So convenience is certainly something >> that should be considered! >> >>>>> - to add the rotating package >>>>> - do document that the tabu package is needed when specifying tabu >>>> >>>> Note the package loading order might matter. >>> >>> Yes, I am aware of this. Can you be specific for this case? I guess >>> rotating has no load sequence issues. >> >> I doubt rotating causes issues as it provides its own environments >> cf. section 2.2 of its manual. I didn't find any reports on the >> Internets. >> >>> Does tabu have such issues [of conflicting with other packages]? >>> With which packages (what you know) >> >> I don't think tabu causes any problems. It states it doesn't rewrite >> any existing code (as e.g. tabularx does) cf. p. 1. >> >> Perhaps, Eric Abrahamsen (Cc'ed) has more experience with tabu >> (according to the log Eric added tabu support). >> >> Unfortunately, I haven't moved to tabu yet. Supposedly, it can >> replace most other tabular packages including longtable and it's >> compatible with many other packages cf. p. 9 of its manual (but that's >> another story). > > I'm not an expert, but I haven't read about or experienced any > particular clashes, so I've made this my standard table package. I'd > feel a little weird about enforcing that on most users, though... > >>>>> - do document that amsmath in needed when generating a matrix >>>> >>>> and subscripts. And sometimes math (e.g. align). >>> >>> amsmath is (edited) in the defualt list, patch by you IIRC. So we >>> actually do not have to say something about this in the manual. >> >> No. >> >>>>> The reasoning: >>>>> >>>>> - wrapfig and longtable have been in there for a long time, we want to >>>>> avoid breaking existing files whenever possible >>>> >>>> Assuming a mechanism exists that can detect when tabu is to be loaded >>>> why only apply it there and not to the other optional packages? >>> >>> Because any automatic mechanism may cause problems with load sequence, >>> so packages that are problematic in this way should require user attention. >>> Hmm, have I just argued agains longtbl by saying this? >> >> If we are (i) aware of no known problems with a package and (ii) we >> assume that loading package X–Z have little impact on compilation time >> is it then not more rational to just add them as a default package? >> >> While automatic package handling is very exciting it could go awry. > > [...] > > I'm not too in favor of automatic package detection. Unless it works > nearly perfectly, it just seems like trading one kind of user irritation > for another. > > Personally, I _always_ blast the default packages and load my own stuff. > > One potential middle ground would be providing defaults "sets": for > instance LATEX_MATH_DEFAULTS (or whatever), that provided a couple > choices for math-related package suites that are known to work well > together. > > Meh, maybe not. > >> Fixes are usually available. For instance, I use a filter to disable >> fontenc/inputenc if pdflatex is not used (it breaks xelatex for me). > > If anything was going to be automatically detected and handled, it seems > like it should be this. This is one of the main reasons I gave up trying > to use the defaults at all. Rasmus, I'd be interested to see a patch to this effect. Thanks for your input, Eric. - Carsten > > Not too helpful, I know... > > E