On Fri, Sep 20, 2002 at 08:42:49AM +0200, Andre Poenitz wrote: > On Fri, Sep 20, 2002 at 09:53:54AM +0300, Martin Vermeer wrote: > > > So I'd rather have AMS detection completely removed from validate(), but > > > - for convenience reasons as probably most users don't care - switched on > > > by default. This way it is possible to disable AMS if it is really not > > > wanted and everybody can get want he wants. > > > > So, you are worried about sometimes AMS getting switched on erroneously, > > and as a solution you want to switch it on always... with the option of > > manually switching it off? > > I do not care for the default, but I care about the wrong detection and > having no way to switch it of. > > > Whatever it is, what you propose is not a 'solution' to the 'problem' > > described... > > Of course it is. Which case is not covered?
See below. The case of AMS not being really needed and the user not realizing it. > > I think we discussed this way back. What about combining auto-detection > > with a "suppress AMS" checkbutton? And if validate fails to auto-detect, > > you can still put it manually in the preamble... but our aim should be, > > like with ERT, to make that unnecessary. (Be aware that the condition > > where auto-detection fails, *cannot be handled* by a person without some > > LaTeX background knowledge.) > > This is a solution, too, but I fail to see how this is better. It does more precise auto-detection. Less cases where AMS is included 'just in case', without really being needed. The issue is obviously not the processing power needed to include AMS, but rather the possibility, however remote, of its inclusion messing up something. I just don't see the need to take unnecessary risks. And 'just in case' is *ugly*. Development-wise, the advantage is that validate gets field testing, as AMS is what exercises it most (Wasn't that how I found the fontinset-within-fontinset bug? Actually no. But I could have :-). I like having a mechanism for only including packages when needed, and I want it to be bug-free and as 'sharp' as possible. Yes, *if* we err, we should err on the side of unnecessary inclusion. But we should not just throw in the towel! ... > Andre' Martin
msg45033/pgp00000.pgp
Description: PGP signature