Georg Baum wrote:
Helge Hafting wrote:
Surely, lyx 1.5.0 will have many new features, so a new
file format is to be expected? There will be unicode,
there will be new insets of which nicefrac is only one.
Of course. The question is whether we bump up the file format just for the
nicefrac change.
Not much of a problem, I think. 1.5svn is a development version,
so its file format can be a moving target. Or is the intention to
have perfect support at all times? I don't know how much work
it is to bump the number. But surely we can delay "official"
support: Keep adding good patches, and bump the version
when enough stuff has accumulated.
I am not sure that a nicefrac: on/off/auto is that useful,
perhaps you can explain the need, when would you
want to force it off?
We had that problem with the wasy package. It conflicts with some other
packages. Some have workarounds, so that a certain order of inclusion needs
to be honored. This can't be done if the wasy package is automatically
loaded, and conflicts with some user loaded package.
The solution for this problem is for now: Don't load the wasy package
automatically, let the user load it manually.
I don't know at all if nicefrac could be problematic, if somebody knows that
this is not the case then all is fine.
Is there more to it than
don't use "nice fractions" if you don't like the look?
You could provide your own nicefrac command in the preamble for example. Or
you could load it manually (see above), or there is another package that
provides a nicefrac command.
I think we should in general avoid to add new packages to LaTeXFeatures
unless the already existing conflicts are solved and we have a more
flexible package loading mechanism. The more package syou load
automatically, the more conflicts can arise.
What should such a system look like?
A document settings page listing every package we support,
with radio buttons for "off" and "auto"?
"Auto" should work for the common ERT-free document always.
"off" for the expert, who loads packages manually or provides
the commands in the preamble.
"on" could be provided too but isn't strictly necessary, someone
who want to load a certain package in order to use it in ERT only
will know how to put \usepackage in the preamble. He has to do
that anyway for packages without lyx support.
As for avoiding new features - I was rather hoping for the opposite.
As long as someone volunteer to implement properly, and the
feature itself is good -- lets make lyx a more feature-rich
document processor. This leads to a bigger userbase
and more developers. :-) And less need to keep other
wordprocessors around.
Helge Hafting
