Uwe Stöhr wrote: > Am 07.01.2012 19:25, schrieb Georg Baum: > >>>> This would be a fileformat change and will fix >>>> http://www.lyx.org/trac/ticket/6819 . >> >> I would prefer to fix the GUI first before adding more packages. > > In fact there is no GUI entry necessary. > >>> Is there a reason why one should not want to use cancel when entering >>> the \cancel command? Is the intent of Georg's patch really to list all >>> packages known to mankind, or only handle the few ones that are known to >>> cause incompatibilities? >> >> I am aware of some issues that require to skip automatic loading of >> packages: >> >> 1) Conflicts with self defined macros or other packages. > > Not the case for cancel. For self-defined commands it is the duty of the > user to check possible interferences with packages. Our policy is not to > try to provide workarounds for things the user can do wrong in the > preamble.
Sometimes there are reasons why a user cannot decide himself. For example, document classes provided by publishers often define a lot of commands that need to be used. Or consider customized stuff at universities, or working with colleagues who come from LaTeX and still want to use the commands they are used to. \cancel is a quite generic name, so I would not be surprised to see it in personal or corporate macro collections. >> 2) The user wants to provide an alternative definition of some commands. >> This is frequently the case for special symbols, e.g. \coloneq. >> mathtools.sty contains a generic definition, but if you use times fonts >> you might prefer the native character, which is made accessible by >> txfonts.sty. > > Not the case for cancel. > (Btw. in this case the user could use TeX-code at the beginning of the > document to redefine it.) This does not work if the other stuff is loaded before cancel. In any case it is ugly. >> 3) You use a combination of symbols that require two incompatible >> packages. > > Also not known for cancel. I had a look at the usual newsgroups and > forums. Yes, for cancel this is true. >> I do not think that each already supported package needs an auto setting, >> but I would not introduce support for new packages without it. > > I don't agree to this. The majority of our modules are there to add > support for a certain package. There might always be conflicts to other > packages, but unless no conflict was reported, we don't need to act. It is > in my opinion not a good UI to provide expert stuff which is only > hypothetically useful. For the rare cases where an expert user wants to > play with packages and definitions, he can use the preamble or TeX-Code. In fact this is not possible for packages loaded by math insets. It works for packages loaded by text insets: In this case the user simply does not need to use these insets, but write his own commands in ERT. Then LyX will not load any package for those commands. In math, there is no real ERT, since the math parser _always_ creates insets for known commands. Using ERT for the whole formula may be an option if these commands are isolated in simple formulas, but if they occur in bigger formulas putting the whole formula in ERT is not an option, since you do not understand the formula anymore without syntax highlighting. > We should only provide an UI for packages where conflicts are known or > cases like your second point. You can make a UI that does not get in the way, e.g. where you only see those packages that are not set to default values, and the opther ones only if you want to change something. Apart from that this should clearly be labelled as expert stuff, so that people who do not understand what it means do not touch it. I really do not understand why you are so reluctant to add this little setting. It have made it really easy now, and there are requests for even more control over autoloaded packages in trac, so why not start with this simple yet useful option? Georg
