There is no mechanism for getting such context-menu direct changes (to the displayed plot) to be stored/saved as a plotting command.

That is one of the reasons why such context-menu changes to plots are not very useful. The corresponding command cannot be obtained directly.

If you are interested in discovering the plotting command and options for a particular look&feel you might try using the PlotBuilder instead. It lets you adjust properties and options in the context-panel, and has a button to reveal the equivalent plotting command.

You can invoke it either as the command  PlotBuilder(x^2)  or by choosing the  PlotBuilder  item from the panel context-menu shown when the focus is on  x^2  as output or 2D Input.

One way is to do these assignments, initallly:

kappa:=Typesetting:-mo("kappa", "italic"="true"):
phi:=Typesetting:-mo("phi", "italic"="true"):

That causes evaluated instances of names phi and kappa to pretty-print in output as that text form, in italics, similarly as for other regular names like x, t, F, etc.

You could also do it as,

kappa:=Typesetting:-mo("kappa", "italic"="true", "color"="Black"):
phi:=Typesetting:-mo("phi", "italic"="true", "color"="Black"):

A broader change is to execute the following command (but not in the same paragraph or execution group as restart).

interface(prettyprint=1):

That makes all output render in plain text. That handles all the Greek letters, etc, at once. But it also affects how other things like a Matrix or a piecewise are pretty-printed (more crudely). You might find this change too heavy-handed. The default for the GUI is prettyprint=3.  This can also be changed using the menubar item Tools->Options->Display->"Output display" and its choice "Character Notation", where the default is "2-D Math Notation".

@mmcdara As I mentioned before, there is usually no need to explicitly declare a variable as global at the top level, in order to use it on the left hand side of an assignment statement.

There doesn't seem (as yet) to be any reason given why you cannot do it similarly to this:

restart;
x:=0:

f := proc() 
  global x: 
  x:=x+1: 
end proc:

f()
                 1

In other words: like so,

restart:
# reading of some data files
:
:
# reshaping of the data
:
:
:

Main := proc()  # how I badly wrote this line was confusing in my previous reply
global G:
:
M := Maplet(......)
:
:
Display(M)
end proc:

G:=[ ]:
Main():

I asked earlier whether that kind of thing works in your Maple 2015, ie. whether the explicit top level global declaration of G were somehow required there.

What is the reason that you did the global declaration explicitly in Maple 2015? I'll repeat my very first query: What effect do you think it had?

If you do  lprint(eval(Bb,1))  then do you see integer values or merely unevaluated function calls to LArip? (You can try that for a small value of n, as a quicker test.)

So, is it fast because the actual work is not being done under the Grid:-Map calls, but only when you subsequently evaluate Bb? If so then the computational effort is not what is parallelized.

You might have noticed this even when testing smaller value of n if the output were not suppressed by terminating statements with full colons.

By using  Grid:-Set(LArip)  I can see actual improvement in the timing, because then your LArip procedure is actually called and computes withing the Grid:-Map.

I made another edit so that the values of r and M were accessible to LArip on each node.

If I force numcpus=2 at the start of the worksheet then for n=8 I get a real time elapsed of 43sec, while with numcpus=4 at the start then (after restart) I get a real time elapsed of 24sec.

Magma_GridMap_acc.mw

(Does it make sense to also give datatype=float[4] to the local A inside LArip?)

eval~(z,[rootsq0]);

If you plan on re-using the approach then you could make it into a (more conveniently re-usable) procedure.

I have a slight preference for adding the LEGEND call to the POLYGONS substructure's operands, rather than relying on that having a COLOUR substructure.

Also, even for your original you could get by with subsindets/evalindets directly on HS and HT, and save the actions both of putting their operands into lists and then making PLOT calls to bundle it back together.

For example,

with(plots): with(Statistics):
S := Sample(Normal(0, 1), 1000): T := Sample(Normal(1, 1), 1000):
HS := Histogram(S, color=gold, transparency=0.3):
HT := Histogram(T, transparency=0.3):
F := (P,L)->subsindets(P,specfunc(POLYGONS),p->POLYGONS(op(p),LEGEND(L))):
display(F(HS,"N(0,1)"),F(HT,"N(1,1)"));

[edit] I have removed something incorrect that I wrote about overrideoption not being relevant here. I apologize. The following works in Maple 2020 (and Maple 2017.2, but not 2016.2 or your Maple 2015.2).

with(plots): with(Statistics):
S := Sample(Normal(0, 1), 1000): T := Sample(Normal(1, 1), 1000):
HS := Histogram(S, color=gold, transparency=0.3):
HT := Histogram(T, transparency=0.3):
display(display(HS, legend="N(0,1)", overrideoptions),
        display(HT, legend="N(1,1)", overrideoptions));

But I'll also mention that in Maple 2017.2 (and onwards) the Histogram command accepts and makes use of the legend option. So this works directly,

display(Histogram(S, color=gold, transparency=0.3, legend="N(0,1)"),
        Histogram(T, transparency=0.3, legend="N(1,1)"));

You can make print_table a keyword parameter (option).

Specifying that procedure parameter as {print_table::=truefalse:=false} means that it's default value is false. You can then pass either print_table=true or just print_table to see it work.

You can also omit it in the call, in which case it takes on its default value.

integ_R_ac.mw

This example can be dealt with using overrideoption .

restart:
with(Statistics):
data:=Vector[row]([2,5.3,4.6,.88,2.5,5.9,5,10,1.7,7.8,7.2,
                   9.42,9.01,3.42,4,11.59,8,10.3,1.5,8.5,11.4]):
a:=SunflowerPlot(data,length=4,size=[600,200],color=red):
plots:-display(a,color=red,overrideoption);

SunflowerPlot(data,length=4,size=[600,200],color=red,overrideoption);

overrideoption.mw

restart;
y:=t->808.2213240*(1 - 0.63*(1993551437/1601983488 - sqrt(3)/2)^0.3)
      *(1 - 335345*(45188/147189 - 53/(4820*ln(2)))
            *335345^(131537/203808)*131537^(72271/203808)
            *(1 - 1/(1 + (203808*exp(-677.0138344*t))/131537)^(131537/203808))
            /34603964738):

fsolve(y-196.9594856);

          -0.002844711966

fsolve(y(t)-196.9594856,t);

          -0.002844711966

plot(y-196.9594856, -1e-2..1e-2);

fsolve_examp.mw

Your query is unclear: is your problem that you cannot do multiple (separate) plots, or arrays of plots, or that they appear only after all usual output, or all of the above, oder...?

You can use the plots:-display command to assemble Arrays of plots that print in a GUI table. You can use the print command to get single (or Arrays) of plots interleaved with regular output. 

A usual Worksheet/Document "table" is not really a programmatically accessible structure, so there is no easy way to use its cells for data.

But there is an alternative DataTable embedded component, which makes its entries be immediately accessible programmatical since its entries are stored in an rtable (eg. Matrix).

Do you need an example, or would you prefer to look at its Help page examples first? You can also look at its Help page in Maple's own offline Help facility.

If you have a program or procedure then it's more common to approach this from the other direction, ie. programmatically construct Matrix/Array/Vector of the data and then 1) plot directly using those, and 2) display the computed data in some tabulated format using printf or Tabulate.

With your choices for gridrefine, crossingrefine, numpoints, rational, etc, you can still suppress the line through the additional signchange=false option.

The signchange=false option instructs implicitplot to exclude points on the line x=-mu across which F1 changes sign without attaining zero.

It's not clear whether you bumped all those options as attempt to fix your issue, or for some other reason. Perhaps you actually have some other example, since this one can be solved explicitly and plotted much more efficiently with the plot command and its discont option.

I decreased the very extreme gridrefine and crossingrefine from 15 to 3, which would still exhibit the line without signchange=false. But at 15 a great deal of work is done for practically no benefit.

restart;
F1:=1/(x + mu) + x - 1:

plots:-implicitplot(F1 = 0, mu = -8 .. 8, x = -4 .. 4,
                    color = blue, thickness = 2, rangeasview,
                    gridrefine = 3, crossingrefine = 3, rational,
                    signchange=false,
                    numpoints = 100000, resolution = 3000);

plot([solve(F1,mu),x, x=-4..4], discont, view=[-8..8,-4..4],
     color=blue, thickness = 2, labels=[mu,x]);

impl_signchange.mw

See the Help page for mod, where it specifically explains how &^ differs from just ^.

n := 4142074788597595058238933087635402958555715420375128103710780511:
m := 65108105099101044032:
e := 3467995563410655813589059428902496618444213189544232426283402949:

m &^ e mod n;

     24733671999927750262610339317849962811213365592569778941953149

Specifically, that Help page says this:

     To compute i^n mod m where i is an integer, it is undesirable to
      use this "obvious" syntax because the powering will be performed
      first over the integers (possibly resulting in a very large integer)
      before reduction modulo m. Rather, the inert operator &^ should
      be used: i &^ n mod m.  In the latter form, the powering will be
      performed intelligently by the mod operation.

restart;
ig := sqrt(x)*sin(sqrt(3)*ln(x)/2):

H := int(ig,x):

A := simplify(subs(s=ln(x),
                   IntegrationTools:-Change(H, s=ln(x))));

  -1/6*x^(3/2)*(3^(1/2)*cos(1/2*3^(1/2)*ln(x))-3*sin(1/2*3^(1/2)*ln(x)))

simplify(diff(A, x) - ig);

                 0

That syntax error does not occur in 1D Maple Notation (plaintext) input, as of Maple 2019.0.

It still produces a syntax (parsing) error in 2D Input, in Maple 2020.1.

It was not discerning that the statement that precedes the local declaration is empty, and in consequence should not affect the validity of the syntax. It might be more clear to you if typed as follows:

proc(x)
  :
  local y;
  y:=x+1;
end proc;
Error, unexpected local declaration in procedure body