> Dedicated functions give easy inflexible option which should > satisfy needs of most users. Users needing more can use > general interface suffering full complexity and possible > uglyness (like 'pretend' above).
I'm not completely against your suggestion setFormatMathJaxOn() setFormatMathJaxOff() One could even achieve a certain order by the order in which these commands are executed. But in my proposal just a minute ago, I only added the "setFormats!" version, because that will stay anyway and I am not yet completely decided about setFormatMathJaxOn(). >> Currently ")set output ... on" for different formats outputs always in >> the order given by i-output.boot. Using setFormats!([F1, F2, F3]) would >> allow the user to decide the order and also to compile his/her own >> domain of type FormatterCategory and use it. > Well, adding user-settable order to 'i-output.boot' would be > rather easy. Simply nobody bothered to implement this. > My plan was to switch to tabular description. More precisly > currently 'i-output.boot' contains bunch of variables for > each format. I want to change this to a record. Records > can be created at runtime so one could register new format > if desired. OTOH with well designed output system there > would be almost no need for user formats (useful formats > should be already included). Well, in fact, I would like to get rid of all those variables and also reduce i-output.boot for the output of types. Algebra output could be done by Format2D. The only "bug" in Format2D is that it does not break lines. I will now play around with it and see what *my* needs are and perhaps other people also come forward with their wishes. > Those changes are currently suspended, as Formatted plays > its own tricks, at least partially incompatible with the design > above. ATM I am waiting for "dust to settle", that is > too see what exactly you want to change. Not exactly clear what you mean here, but my wish was to bring more stuff from BOOT to SPAD. Adding a new Formatter should be an action of writing a .spad file and add register it in the Makefile, but not additionally change something in setvart.boot, setvars.boot, msgdb.boot, and i-output.boot. Certainly, that's not a very big deal, but that's what I chose. My first intention was to improve the TexFormat domain to be able to compile book.pdf, but it ended in a compleltely different approach of handling the OutputForm structure which in turn made it relatively easy to come up with FormatMathJax, Format1D, and Format2D. Maybe some day I spend some time to also put Texmacs and MathML formats into my scheme. However, since I do not use those much, it may need some users to push me. > Repeating what I wrote some time ago: formatter should be > resposible for rendering OutputForm on a stream. Where > stream output goes should be due to separate managment > layer. If different formatters output on the same > stream it should be manager task to decide on order, etc. > AFAICS Formatted wants to manage such things, and this > is a problem: when there are two managers we get chaos > and lack of proper coordination. Right, that it is a problem with two output managers. However, I do not see my new framework as a big problem to "output on different streams", because the main domain that is connected to actual output is FormattedOutput. And, honestly, this is just my invention to connect my formatter domains to actual output on a stream (the "formatted" stream. I do not insist on this. This domain is pretty small and we can certainly coordinate in removing this domain or adapting it so that your "stream idea" gets realized. All the rest of the formatting framework is independent of actual streams. Ralf -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ed54b185-426b-4c52-a3f4-174d327eac02%40hemmecke.org.
