A minor point is that the collect command allows for an optional argument, to specify post-processing action on the coefficients. So it can be done in one step like so:

collect( q(x,s), [exp((lh-x)*sqrt(s+thetac)/sqrt(Dc)),
                  exp(sqrt(s)*(-lh+x)/sqrt(Dp)),
                  exp((-2*lh+x)*sqrt(s)/sqrt(Dp)),
                  exp(-sqrt(s)*x/sqrt(Dp))],
         simplify );

Also, mapping simplify to the result of the shorter call to collect could in general affect not just the coefficients but also all of the collected subterms (which might possibly not be wanted). That doesn't happen here, however.

For this example it also turns out that the subterms to collect are the only instances of function calls to exp in the expression. So for this particular example it can also be done with a little less copy&pasting, as:

collect( q(x,s),
         indets(q(x,s),specfunc(exp)),
         simplify );

@Ronan There are lots of text editors, and some will offer nice things like colorized syntax (...think keywords like if, then, else, do, etc).

I use a command line shell in Linux, with the `vi` editor.

If you're using MS-Windows the I wouldn't know what to suggest as best. You could start using `notepad` though, as a simple mouse-driven editor that comes with MS-Windows and has the usual menu bar items for File/Save/Edit/Help.

At the risk of repeating myself, I'll say that I've seen many corrupted .mw files over the years. But I can't recall ever seeing a stock text file editor corrupting a file. I consider my project source code to be worth the protection.

I really don't think that you should be trying to use Maple's `save` command to "export" a procedure as source to a plaintext file. 

Since Ronan seems to really want to define the module export Rtest by obtaining it from its own .mla archive (rather than straight from source), then here's how to do all the steps.

There a few things I'd like to stress.

The first is that this seems clumsy -- why get the body of  the procedure from .mla when one already has the source? I've enumerated above some good reasons why defining all of the module from source can be better.

The next thing is that you don't use the read command to obtain the stored procedure from its .mla archive -- that happens automatically after augmenting libname with the .mla location.

The next thing is that if you want the module export to function even when the procedure-only .mla archive is not in libname then you have to assign the value assigned to the global name to the export name when defining the module. That is, you want the module export to be a full copy of the actual procedure, and not just a reference to the global name. See the comment about using eval for this, in the module definition below.

And lastly, in general this methodology will not work for reading in a module rather than a procedure, in the hope of assigning it in full as an export/local submodule and then saving the parent module to its own separate .mla archive. It won't work for several kinds of module, including: some that have some kinds of ModuleLoad procedure, some that have locals which have not been accessed prior to re-saving, and so on. This is just another reason for which it's a lot better to stick to reading in the entire module, and its submodules, etc, in the same session -- preferably all from text files.

Download ronan_method3.mw

Which options of the command contourplot do you want to use/mimic? Is it related to coloring and shading?

@adel-00 Yes, I understood what you meant. My answer is that there is at least one other way to approximate or interpolate or fit the curve reasonably accuractely and easily.

What is the expression assigned to the name result?

@Gillee "stop watch experiments" relate to "wall clock" timing and the results from calling time[real](...) rather than calling time(...).

Your statement -- about the results from calling time(...) being incorrect because they don't match your stop watch experiments -- is wrong. You have clearly misunderstood my main point. Results from time(...) are the sum of all subthreads, including overhead, and Need Not correspond to wall clock time. If you want to compare something to your stop watch then make it the results from calling time[real](...).

I am supposing that you want a solution which is fully programatic, so that the actual plot portion has a precise size (matching that of others, say). Otherwise you could use the right-click context menu to set the plot "manipulator" and zoom and pan by hand (thus creating the extra space for the well-placed annotation).

It might be possible to set up an easy-to-use procedure to do that fully programatically using the
DocumentTools:-Layout:-InlinePlot command.

I'll try and do that when I get computer access, perhaps this evening.

The idea is to increase the (viewport/bounding box) while zooming-out (scaling) by a corresponding factor so as the keep the actual plot size fixed. Then the plot could be positioned within the box by offsets (pan). If I recall the DocumentTools stuff allows these bits to be programmed.

I'll let you know if it works well for me, unless someone else codes it up first.

update: It turns out that I was mistakenly thinking of the way that zoom and pan works for 3D plots. I don't see how the above could be used for 2D plots, in which even manual zoom and pan affects the axis view. The suggestion to annotate by using plots:-textplot (which can be used to insert typeset math as well as text) seems like it may be the only simple approach.

@Christopher2222 I was going to have a look tonight (for a FromInert/ToInert try).

@Rouben Rostamian  The difficulty you cite is due to the colored replacement (here) not being a name, that's true. But it's due to it being a function call, rather than a string.

Typesetting:-mo (or mi, mn, etc) can be useful for purely display purposes. But so-called TypeMK atomic identifiers (as names proper) can sometimes provide a closer match in type to a given name.

It's a shame that after more than a decade these mechanisms of 2D typesetting are still under-documented.

@Kitonum Thanks. An improvement would be to handle differently any name which was already an atomic identifier in TypeMK form (so as to inject a mathcolor into it, or replace such).

But that case is more rare. It may be adequate to the OP to handle double-underscore "atomic" subscripted names, which the above code demonstrates.

Of course, other marked up atomic identifiers (e.g. names with overdot, circumflex, etc, as from the Layout palette) can also be colored via the main menubar. And then assignment can be made, as above. Such colored names could made with the mouse rather than programatically, which I suspect is what Robert Lopez's Answer alludes to.

The mechanism by which NumericEventHandler works is supposed to be local to the execution of a procedure, thereby providing local context analogous to environment variables.

Can you show a complete example (and result) where that is inadequate or works otherwise?

Did you try Student:-Precalculus:-CompleteSquare ?

e:= x^2+y^2-8*x-12*y-92:

Student:-Precalculus:-CompleteSquare(e, [x,y]);

                  2          2
           (y - 6)  + (x - 4)  - 144

@Markiyan Hirnyk How did you come up with the number 9? It's used as an input to Mma's DominantColors command, in your screenshot. What led to the choice of 9?

@kuwait1 No, yy is not a pair (system) of differential equations. That's the whole point of the earlier replies.

Change the colon to a semicolon and you'll see how.

Don't forget that f(x,y) has been assigned a value of x*y .