[Maxima-commits] [git] Maxima CAS branch, master, updated. branch-5_31-base-183-gf44d669

>   From: Rupert Swarbrick <rswarbrick at gmail.com>
>   Date: Thu, 5 Dec 2013 19:53:37 +0000
>
>   Hi there,
>
>   I didn't realise the commits were potentially controversial - I would
>   have asked on the mailing list first if I had. Comments below.
>
>   Leo Butler <l_butler at users.sourceforge.net> writes:
>   >>   On 2013-12-04, Leo Butler <l_butler at users.sourceforge.net> wrote:
>   >>   > Rupert, I wonder if you won't reconsider & revert these commits. I
>   >>   > think they increase the complexity of the display machinery with, at
>   >>   > most, a small offsetting gain.
>   >>   >
>   >>   > You can use the *prompt-prefix* & *prompt-suffix* to achieve what your
>   >>   > commit notes say motivated the commits. See below.
>   >>
>   >>   Well, I see there are 3 related commits. The first (d8dfa0) which
>   >>   collects prompt formatting into a single function, makes sense to me.
>
>   I believe the first commit should be applied regardless of the others,
>   because it simplifies the maxima code that makes the prompt-prefix and
>   prompt-suffix machinery work.

Yes, I re-read the git diffs and re-built Maxima with the commits and
I don't see a problem with the first commit.

My original message is partly down to haste and confusion on my part,
and partly down to a genuine interest in keeping this part of Maxima
stable and backwards-compatible.

>
>   >>   I'm leaning against the second (fdcd93) -- as pointed out above,
>   >>   it seems like the existing machinery could be used toward the same
>   >>   end.
>
>   I intentionally didn't try to use *prompt-prefix* and *prompt-suffix*
>   here because I know that they are designed for front-ends to "tag" their
>   prompts easily. Since they are just strings, I couldn't think of a way
>   to add a note after the prompt without potentially clobbering them. But
>   maybe I missed something?
>
>   Robert/Leo: Can you suggest a way that I could hook in the logic that I
>   want from the third patch without adding some sort of hook like this?
>   Obviously, I'm not particularly bothered about exactly how the result is
>   printed, but I was trying to "engineer it right".

If I understand your first commit, you have centralized all references
to *prompt-suffix* and *prompt-prefix* into format-prompt. If this is
the case, then you could do a replacement like

*prompt-prefix* --> (funcall-or-eval *prompt-prefix*)

where

(defun funcall-or-eval (x)
       (cond ((stringp x) x)
             ((functionp x) (funcall x))
	     ;; other cases
	     (t (error ...))))

and similarly for the suffix. I am not sure about the wisdom of such a
change, but it would a relatively unobtrusive way to add more hooks...

>
>   Also, I'm not convinced about the "complexity of the display machinery"
>   argument. Perhaps Leo refers to the complicated-looking UNWIND-PROTECT
>   form in my PROMPT-NOTES function? But the point is that, if you want the
>   user to be able to supply something that does a computation before a
>   prompt, you need to make sure that it doesn't end up in an infinite
>   loop... I'm pretty certain that logic would need to appear somewhere
>   whatever the proposed mechanism.

No, the whole prompt-notes business seems unnecessarily complicated
and unneeded in src code when it can be accomplished with the existing
*alt-display.d* hooks or something like that above.

>
>   >>   The third (f44d66) (revised to make use of existing
>   >>   machinery) seems like it would be suitable for a collection of
>   >>   solved problems or how-to cookbook -- not sure if it should be in
>   >>   share.
>
>   Fair enough: I don't have any strong feelings about this. Can you
>   suggest a good place for it to go?

http://sourceforge.net/apps/phpbb/maxima/viewforum.php?f=3
github

Leo