@Joe Riel 

Experience shows that, in general, these attributes (like fontsyle), only work in the Typesetting export form like:

Typesetting:-mrow(Typesetting:-mi("Δ",fontstyle="normal"),Typesetting:-mi("x"));

@John Fredsted 

I am no shell-programming wizard either. As you may realize, this is not necesary for the setup that I have described here. So, at least it seems worth trying.

About lua and python, I have only a minimal idea. When I want to code some tool I look at some similar code already available and browse at the documentation. The interesting characteristic of these languages is that they run interpreted, the same as Maple. So, at the basic level, all these languages look similar (e.g you will find conditional constructs and the like). If something does not work, just modify the code and try again. Besides, as an exercise done only occasionally, it does not seem to me as something of too much concern. And as last resource, I can try help you with the little that I know...

@Markiyan Hirnyk 

You are very optimist! For me it is under destruction...

@John Fredsted 

Yes, I have tried jEdit also. But , it is also Java...(i.e. not a native application). To my taste, this architecture affects too much its performance and reliability. And it is too much structured (too little configurable). Certainly, Medit is an IDE-like editor, meaning that I can use it both as an editor and as an interface for other applications, Maple in particular. No need to switch windows, if you do not want to (this what I meant by IDE-centric approach). One of the reasons for choosing it is its programability using shell commands, lua and python. Certainly it is quite light and basic (unlike some other stablished and idiosincratic IDEs like Eclipse, or editors like Emacs). Just configure a few dialog items or write a short script file and I have a tool for launching a new version of Maple (or any other application). Basically all that I need. 

About choosing what to execute, I just comment out what I do not want to be executed, using single # or multiple line comments (* *). I have programmed some editor tools that help handling them. E.g. select some lines and get them commented out and back. Anyway, code in the CLI frequently may run like 10-100 times faster than in the Standard GUI (mostly because of typesetting overhead, I guess). So, running the whole code instead of a piece (a would be block) is frequently not of so much concern. And yes, I may run it by pressing a single key (associating the tool to the key).

@Carl Love 

Very interesting experiments Carl. In Maple 17.02 on Linux 32-bit I get:

> st:= kernelopts(cputime):  t:= st:
> while t = st do  t:= kernelopts(cputime)  end do:
> t - st;
                              0.00400000000000000
> convert(%, rational);
                                     1/250
> 
> st:= time():  t:= st:
> while t = st do  t:= time()  end do:
> t - st;
                                     0.004
> convert(%, rational);
                                     1/250

(most of the time, occasionally an O(10^(-3)) difference appears).

@John Fredsted 

Not very much really. Several years ago, after an evaluation of the circumstances and trends, I have decided to move to an IDE-centric approach for using Maple. And since I have found Medit, I use Maple mainly from it (meaning that I can choose to use either the CLI or one of the GUIs to run my code). I am reasonably confortable with this choice, it has improved the efficiency of my usage of Maple sharply, and I am sure that it has saved me a lot of headaches.

@John Fredsted 

This is what I have called the GUI conundrum (you may have to go down to the linked comment, this site is breaking apart). So, you have both the situation of a GUI that is flaky, and a manager that says that is good for everybody. So good, he claims, that has no plan for a better one (see this thread). If he had recognized that his plans did not went well, but could not offer something better, he should strive to get the best out of this situation in collaboration with the users and provide, at least, such diagnostic tools, I think.  

@John Fredsted 

No, John, the problem is not with you but with Maplesoft, that should provide clearly documented, easy to use, diagnostic tools for the Standard GUI. It is their basic duty to the all those users that suffer its problems and want this situation to improve. And hardly useful SCRs  could be submitted without these tools as many of these bugs have a complex nature, frequently they are hard to reproduce, consequently unlikely to be fixed.  

@Axel Vogt 

Indeed, everything not violating the laws of Physics can be done at some cost :)

Maple documentation is poor in this area. But I understand that the process goes, basically, like: parse -> DAG creation -> automatic simplification -> evaluation. And the problem here is that arithmetic expressions parsed with the top level power operator are automatically simplified before doing anything else. So, either the parser is modified by adding a "label" to those expressions, so that they avoid beeing handled by automatic simplification (apparently what you suggest), and being dispatched instead directly to a more "intelligent" procedure. Or, the automatic simplifier is modified, possibly by changing simpl (in particular, currently there is no routine `simpl/^` ). Of course, this problem occurs while at top level, as overloading of `^` could always be done by implementing a package "ModularArithmetics", say. Objects also provide an overloading route for some builtin procedures, but I do not see how useful they could be in this case.

On the other hand, Mathematica documentation is even poorer, but probably the process goes like: parse -> tree creation -> preprocess -> evaluation. And evaluation goes by the set of transformation rules that apply to the object and its parts, by means of down values and up values. May be that this design makes setting alternative computation routes for diverse contexts (like modular arithmetics) more strightforward.

@Carl Love 

Which is the source for this lower bound figure (1/64)s? I do not recall reading a statement like that in the documentation.

@John Fredsted 

There is a verbose option for Java (see e.g. here). The way that I am using it on Linux is launching the Standard GUI by means of a customized script . It allows me also, for instance, to change the maximum heap. With option verbose and standard heap, its first line looks like:

/opt/maple17/jre.IBM_INTEL_LINUX/bin/java -verbose -Xmx512m -Dsun.java2d.pmoffscreen=false
...

I have not yet checked its equivalent on Windows. You will find also more tools in the linked page.

@Axel Vogt 

I think that the origin of this poor excuse is at the basics of Maple design, namely automatic simplification, note the unevaluation quotes:

> '5^100';
7888609052210118054117285652827862296732064351090230047702789306\

  640625

I understand, that this expansion is made before the builtin procedures `^` or `modp` had chance of doing anything. Meaning that overloading them would not help. A more drastic change would be needed. Quite unlikely...

@acer 

Perhaps, what evalb compares is a stripped down version of the procedure DAGS:

> trace(evalb):
> f1:=proc(x) description "f":x^3 end proc:
> g1:=proc(x) description "g":x^3 end proc:
> 
> addressof(eval(f1));
                                   3035936018
> addressof(eval(g1));
                                   3035936066
> evalb( eval(f1) = eval(g1) );
execute evalb, args = proc (x) description "f"; x^3 end proc = proc (x) 
description "g"; x^3 end proc
                                      true

@Mac Dude 

Note that on the Mac, Maple uses the Java provided by the operating system, while on the rest of the OSs, Maple uses its own.

@John Fredsted 

There should be no message to the console while things go right. But, have you observed it later on when you freeze the GUI by your key sequences?