On 27 March 2014 21:21, Waldek Hebisch <[email protected]> wrote: > Bill Page wrote: >> >> On 24 March 2014 21:33, Waldek Hebisch <[email protected]> wrote: >> > Bill Page wrote: >> ... >> The only way I can see to prevent that is to actually re-code the >> TeXmacs symbols into utf-8 characters (where that is possible). Since >> we can handle utf-8 in FriCAS that might be a good idea. It is >> something we can try but at first attempt I found TeXmacs rather >> unfriendly to utf8 encoding. It might require someone with a little >> more knowledge of TeXmacs internals. > > I am affraid that bigger problem is caused by fonts. AFAICS, you > have "the same" character coded in differnt fonst via appropriate > prefix. Currently FriCAS has no way to attach font information > to characters (or symbols). We could do such thing similarly > to "scripts": effectively via appropriate mangling of symbol > name. Alternatively, we could take advantage of Lisp property > list and use it to attach arbitrary information to symbols. > In this case we probably would be forced to use uninterned symbols, > which would require adjustment in other parts of FriCAS. > Anyway, at some moment we will have a way to represent faces > and then Texmacs interace will have to convert between Texmacs > and FriCAS form.
So far I have not tried to do anything with fonts. I think that even in unicode blackboard bold, Frakur and script symbols are treated as different symbols - not distinguished by font as such. Of course there are a lot of other font characteristics like font size, color and various decorations etc. that might be "nice" to have available for FriCAS input and output. But for now just Greek and a few more characters that work would be enough. > >> >> > Producing for example TeX or MathML form inside Texmacs >> > session should give sensible results. >> >> ??? What purpose would TeX and MathML serve inside TeXmacs? > > Why not? User may want programtically generate TeX or MathML > documents and if Texmacs aspires to be preferable interface > it should allow to do so. > I suppose that you need to write it to some file somewhere. The application of TeXmacs that makes most sense to me is as a mathematical document system that includes FriCAS computed results. Using TeXmacs for more general things is much less interesting to me. There are other better alternative, e.g. the command line interface, for that. >> >> One problem that I am having right now is the display of SPAD compiler >> >> output from the ')compile' command in TeXmacs. It seems like we may >> >> not have the appropriate iohooks in place to demarc the output in such >> >> a way that TeXmacs can synchronize and format it properly. >> > >> > IIRC there are no iohooks specific to compiler. >> > >> >> >> How difficult would it be to add the same iohooks to the compiler >> output that we already have in the interpreter output? > > Depends on what exactly you need. There is toplevel ')compile' > handling which may produce some error messages, but when > arguments are OK it dispatches to proper compiler. For > Spad top function is 'compileSpad2Cmd'. At start it prints > message like: > > Compiling FriCAS source code from file > /mnt/lv3/fricas/axp19/pp1/pp4/OFTOOL.spad using old system > compiler. > > we could easily add a hook before this message. > Compilation is split into phases: reading and tokenizing, > forming piles, parsing, proper Spad compilation and > Lisp compilation. Parsing and proper Spad compilation > works on single toplevel pile at a time (such pile > correspond to a single constructor). The reading and > tokenizing work on the whole file, but is lazy way: > once a pile is complete is is passed the next stage. > For each constructor we get one or two (in case of > category with default implementations) Lisp files > to compile. > > We could easily add iohooks around existing stages > and hook at the end of whole compilation. There is > a glitch however: compilation may end up with an > error, then control is passed to toplevel. If we > add hooks inside normal program code, they will > be skipped in case of error. We can add hooks in > such a way that they will be run in error case too, > but in the past I noticed that construct that I used > to accomplish that interfered with debugging. So > there is some work to do to have precise hooks at > the end without lessening debugging capabilities. > It should be relatively easy to add a general hook > saying that there was error exit to toplevel. > The minimum kind of iohook that we need is to allow synchronization of input and output. TeXmacs needs to be able to tell when computer output starts and ends. This would allow TeXmacs to fold and hide this output by default. Right now including )compile xxx commands in the FriCAS session input results in a loss of synchonization so that parts of the compiler output seem to appear in other unrelated FriCAS inputs. -- 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 post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
