Martin Rubey wrote:
> Waldek Hebisch <[EMAIL PROTECTED]> writes:
> > BTW. I just noticed that setting output format to say TeX also affect
> > HyperDoc examples.
>
> This suggests that it is not easy..., do you have *any* idea how I could
> detect
> who is running me :-)
>
The standard technique is to set a flag at call place. If there is no
existing flag, then we should add a new one.
> >
> > We should probably make a function:
> >
> > printPrompt() ==
> > ioHook("startPrompt")
> > PRINC(MKPROMPT())
> > ioHook("endOfPrompt")
> >
> > and call it in all apropriate places
>
> I thought that this might be appropriate, but there are places where I'm not
> sure whether the ioHook should be called.
>
I would say: when in doubt call ioHook. In places where you are sure that
ioHook should not be called directly use PRINC(MKPROMPT()). But
if you do not want decorated prompt, then there is question if we
should print prompt at all in such place.
>
> > > - ioHook("endOfOutput")
> > > intSetNeedToSignalSessionManager()
>
> > Why do you remove this hook? IIRC this hook is the only way to be sure that
> > output is complete -- you may get error almost everywhere during evaluation
> > and printing and errror handler will skip rest of printout and return to
> > toplevel.
>
> It did not work reliably. In particular, it did not cover system commands.
System commands are deliberatly treated differently than other commands.
I understand that you found no use for "endOfOutput" in axiom mode, but
I wuold prefer to keep it for other possible uses (unless ignoring it
takes too much work).
> Decorating the prompt seems to work always.
>
> What I really need / would like to have:
>
> * number one priority: markers that tell me whether FriCAS is expecting input.
> (using this patch: QueryUser and ReadLine. Actually, maybe it would be
> better to make both carry the same name, but I don't know. Not so
> important.) Without this, it is nearly impossible to do reliable
> communication with emacs.
>
> * markers that decorate output and, specially, the prompt. (The prompt should
> definitively appear in a different color than other output in emacs.)
>
> * markers that separately decorate algebra output. Another nice thing would
> be
> to decorate the line number appearing before the output.
>
> * markers that decorate Time and Type. It would be extremely nice if we could
> spit out a separate marker for Type, but looking at the code suggests that
> this is not trivial. I'll try this after having completed the basic stuff.
>
I belive that for this you want separate output format, one where
type and time do not appear on a single line.
> * markers that decorate messages and error messages.
>
> Maybe I decorate sayKeyedMsg directly (in msgdb.boot)? Yes, I like this
> best: I could give ioHook as optional arguments the arguments of
> sayKeyedMsg,
> that might also solve the Time and Type problem (although not as nice as
> could be, since I will still have to reparse the output to look for the
> Type...)!
>
>
> Maybe we should decorate read_line directly, depending only whether we are
> reading from standard input or not, or giving the stream as an optional second
> argument to ioHook?
>
Currently detection of standard input does not work in sbcl (actually
I am affraid it works only with gcl).
One extra remark: do what you need for Emacs interface. If I was
critical in some places it just that I would like markers to be
usefull not only for Emacs. But since Emacs is first (and currently
only) user we certainly want to adapt markers to Emacs needs.
--
Waldek Hebisch
[EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
