Do you want something like this?

[edit] Originally I used the range 0*Unit(mm)..100*Unit(mm) along with the accomodating x*Unit(mm) in the calls to tau and Q when plotted. But that only works (by accident) in Maple 2017. So below I've changed the range to 0..100 instead, which makes more sense alongside the argument x*Unit(mm) and which seems to work in both Maple 2017 and Maple 2019.[/edit]

Plot_function_with_units_ac3.mw

[edit] How you approach this may well depend on what you start with. If you have the liberty of entering the initial expression passed to exp (or sin and cos) then it is easier since you can use a replacement symbol for Pi. My suggestions below are more for the case that you've already obtained the -1/2+1/2*I*3^(1/2) form. [/edit]

Here are three related ways.

The first two include examples of printing the inert % form of sin and cos calls without getting the gray elements in the output.

The third way simply delays evaluation (and in consequence is fragile because any subsequent full evaluation undoes the effect).

Download inert_rcistheta.mw

You may also use InertForm:-Display to show the %Pi from Carl's Answer without the gray symbol. Eg,

bar:=cos(2*%Pi/3)+I*sin(2*%Pi/3);
InertForm:-Display(bar, inert=false);
value(bar);

But in that case you cannot so easily extend the `print` facility to make that aspect automatic.

It is possible to adjust the underlying code so that it also colors (extended typesetting mode) typeset math.

The following seems to work ok for me in Maple 2016.2 through to Maple 2019.0.

Tabulate_mathcolor_hotedit.mw

I don't think that you are doing anything wrong. It's not easy to handle the (possible) splitting fields always best, in general. But your example shows that there's likely something to improve. (I'm submitting a bug report.)

Download evals_ac.mw

I have previously submitted bug reports for examples such as this where simplify(...,size) does not compress as much as can a judicious collect with simplification of the ensuing coefficients.

In this example that situation occurs for the subexpression within the radical.

I have an oracle that speculatively tries collecting w.r.t. the relevant names in the subexpression (sum), and indicates which compresses well or best. Hence the following suggestions, relating to collect w.r.t. g. These vary a little because more generally you may or may not want other kinds of simplification effects:

Download simplification_under_sqrt_ac.mw

Even if you use 2D Input mode the methodology of assigning a procedure with the syntax f(x) := ... is a bad idea, not least because it is ambiguous syntax that can easily lead to problems.

There are a variety of ways to accomplish the substitution for s2 within the procedure body.

First, in 2D Input,

Download subs_proc_2D.mw

And now in 1D Maple Notation,

Download subs_proc.mw

In the case that you have already assigned to s2 then you can use the unapply command directly. Eg,

s2 := 9:

f := unapply(x^2*s2+x+1+s2, x);

                   2
      f := x -> 9 x  + x + 10

f(2);

                48

As for how the body of the procedure gets pretty-printed (formatted as 2D Math), or not, you have a few alternatives.

restart;

s2 := 9:

f := unapply(x^2*s2+x+1+s2, x);

                   2
      f := x -> 9 x  + x + 10

lprint(eval(f));    # line-printing

  x -> 9*x^2+x+10

sprintf("%a", eval(f));    # as a string

           "x -> 9*x^2+x+10"

sprintf("%-P", eval(f));  # Maple 2019.0

         "x -> 9*x^2 + x + 10"

showstat(f);

  f := proc(x)
     1   9*x^2+x+10
  end proc

You could also set interface(prettyprint=1) (or 0) but keep in mind that would affect display of other expressions as well.

Why not scale down the 1014x1024 pixel image before using it? That should reduce the memory allocation by the kernel. (I chose 50x50, but you could experiment.)

Download smile_acc.mw

Also, here is a way to animate it as a 2D plot. (I used parts of a method from this old post, where the data of an image can be used as the color data of a densityplot structure.) I made it with 22 frames and displayed it with size=[500,500], but you could change those.

Download smile_acer.mw

Do you mean custom tickmarks along the axis?  If so then try searching the Maple Help for tickmarks.

You might try making sure that you have the latest point-release update for Maple 2016. That is a free download if you already have a valid installation of Maple 2016. (You can also check for updates within Maple's main menubar.)

The update to Maple 2016.2 is available here. It includes changes in the point-release(s) before it, eg. Maple 2016.1.

(One reason I mention this is that the update Maple 2016.1 release notes specifically mentions some "Enhancements to Maple's context-sensitive menus" to right-click context-menus. So perhaps that might address some of your performance issues.)

If the problems persist, then more details might help diagnose the problem. What packages, if any, do you have loaded when the context-menu is slow to generate and display? Is it only slow the first time in a session, including following any restart? Is it slow for a particular kind of expression? And, as Carl queried, do you have the language set to something other then English?

Maple has its own 3rd-party installer and uninstaller. While Maple itself (once installed) is 64-bit, its installer has some 32-bit runtime components.

So to install Maple 2018 or 2019 for Debian it is necessary to have some 32-bit compatibility packages installed. See this Maplesoft Tech Support page for a list (which includes a Debian note).

Yes, in principle it's possible to run Maple on Debian.

You can map the expand command over a matrix or Matrix.

The simplify command will map automatically over those, in modern Maple.

Download map_expand_matrix.mw

Yes. Your last paragraph describes what's happening.

It's not specific to the simplify command.

Why are you so surprised by this?

What would be your comprehensive delineation between circumstances where NULL inside an expression sequence should get flattened out and circumstances where it should not?

It doesn't seem like a very good idea to have an application that relies on the initial state of currentdir().

But cannot your application's startup code set currentdir to something relative to, say, kernelopts(':-homedir') ?

What sort of i/o do you intend on trying within the MaplePlayer? (There's a possibility that the MaplePlayer would have to look into a temp directory in the FileTools sense.)

Right, an Execution Group or Document Block can only have a sole Task region, which can have worksheet content embedded into it. So each call to Tabulate (or Explore, or InsertContent, or ImageTools:-Embed, etc) executed within the same Execution Group simply replaces the content in that sole Task Region.

Here are two approaches to getting what you've described.

The first way involves keeping a running Matrix that accumulates the various results. It simply replaces the embedded tabulation each time that additional results are added to the bottom of that Matrix. This is easy if the tabulations all have the same number of columns.  Tab1.mw

The second way involves keeping a running copy of the XML representations of separate Tabulate calls, stored separately as, say, entries of a Vector. At each iteration it embeds all the tabulations accumulated so far (in order) as separate Tables. This is more suitable if the various tabulations are quite different from each other, eg. different number of columns. Tab2.mw 

The Tabulate command is really just a convenient way to build -- and, normally -- embed the XML representing a GUI Table. The undocumented option output=XML allows the Tabulate command to return the XML for the constructed Table without actually embedding it. So the second approach simply stores them, allowing you to replace the sole Task region for an Execution Group or Document Block with whatever combination of such previously constructed Tables as you see fit.

Hopefully you can adjust one of the two approaches to your purpose. I used Maple 2018.0.

You already had them combined by using plots[display], but their curves are so close that they overlap and you can only see the one on top.

One alternative is to plot one of them as a line and the other as a point-plot.

I increased h for Runge while plotting List as a point-plot, since otherwise the point symbols overlap and don't look so good. But you could also use the smaller h and just plot every 2nd (or 10th, or whatever) entry of List generated using the smaller h.

I also added a legend entry to each.

Another alternative is to plot them side by side.

question_ac.mws

It'd be helpful if you told us what exactly you wanted the final combined plot to look like.