@Markiyan Hirnyk Yes, I am quite aware that was the original question. My answer relates to how the context-menu can be augmented with some additional commands (which can also induce some replacement) and I explicitly stated as much.

The reason I gave the answer is that it is the kind of question that new users ask, and it may still be of some value to the Asker or others.

The precise answer to the original question is no, it cannot be done.

Apart from the sheer magnitude of the task there are considerable difficulties in the way of a user trying to achieve such an enhancement programmatically. One obstacle is that various commands have alternate calling sequences, the legal set of which are not programmatically available. While many newer commands use the builtin parameter-processing for proc definition there are many which do not -- the logic of what is acceptable as command arguments cannot itself be picked apart and massaged into a scheme for automatically generating all valid menu actions. This is also true of many command which do use such parameter-processing. A very hard part woudl lie in programmatically generating the menu items for all calls where additional arguments are legal, or required. This is on top of the notion that such a complete menu system would be so large that using it would likely be impractical.

There is much more involved in the general topic of the question asked here. For one thing, it is important to note that the ability to write arbitrary programs in the Maple language means that there will always be a much broader set of things that can be done with custom programming than can ever be done in practice with any finite set of context-menu items. Interactive Maple use via context-menus may be great for students learning math but it can never match the power of a programming language for more general computation. Hence I tailored an answer that may be useful to students.

@tomleslie Since you now indicate your initial response to my Answer wasn't directly related to my Answer (or its statements about calling the print command from within Document Blocks) then I've changed your Comment into an Answer.

When a Document Block is not in "expanded" state then it consists of a pair of Execution Groups. The output of the first is supressed and the input of the second is supressed from display. The output of the first is used as input for the second, behind the scenes in the GUI when the Block is "collapsed" = not "expanded". This scheme causes all normally printed output to be queued (as the redirected material) and only printed altogether once the first Execution Group (containing the user's command) finishes computing.

If you execute the code in either of the two collapsed Document Blocks in the attached Document you should see that the printed results for either collapsed Block are displayed in two clumps. The individual printed statements do not get printed one at a time, asynchronously. The same goes for lprint, printf, and userinfo statements.

doubters.mw

If you were to expand either one of the two Document Blocks (select with mouse, menubar "View" submenu) then you'd see a pair of Execution Groups for each, with red prompts. If you were to execute only the first of the pair of Execution Groups in an expanded Document Block then the results would display asynchronously, just as Worksheet users expect.  There is an "output redirected" comment, between the Groups, if an entire expanded Block is executed together, say using the menubar's `!!!` icon.

This is just one reason why I don't use Documents, and stick to Worksheets.

I see an expectedly close result in Maple 15.01, but not in Maple 16.00 onwards.

It may be possible to work around the issue by assigning UseHardwareFloats:=false and retaining Digits=10, without having to incur even more extra cost of higher that default working precision. (That still won't be as fast as hardware double precision at the key steps internally, of course.)

restart:                                      
with(Statistics):                             

r := RandomVariable(NegativeBinomial(3, 0.1)):

Mean(Sample(r, 10000)); Mean(r): evalf(%);    
                               101.792300000000

                                  27.00000000

UseHardwareFloats:=false:
Mean(Sample(r, 10000)); Mean(r): evalf(%);

                                  27.02560000

                                  27.00000000

@Mac Dude FYI, I included another kind of example (affecting BesselY, BesselK and perhaps AiryAi, AiryBi but not others it seems):

restart;                   
evalf( BesselY(0, 2/3*x) );
                          BesselY(0., 0.6666666667 x)

restart;                   
UseHardwareFloats:=true:   
evalf( BesselY(0, 2/3*x) );
Error, (in evalf/BesselY) cannot handle unevaluated name `x` in evalhf

kernelopts(version);
           Maple 2015.2, X86 64 LINUX, Nov 13 2015, Build ID 1087698

@Mac Dude I will submit an SCR (Software Change Request, ie. bug report).

Simpler example:

restart:

evalf(LambertW(3));

                                  1.049908895

restart:           

UseHardwareFloats:=true:                

evalf(LambertW(3));     
Error, invalid input: evalf/LambertW uses a 2nd argument, zz, which is missing

In addition to Thomas's suggestion, you could upload a worksheet in which the error occurs. Something else seems to have come before the problematic execution, since the floats are printed with more than default digits.

@Bendesarts I hope this is clear. When you reopen this sheet you should be able to immediately execute the last line, to show that P is the Matrix of data, without re-executing any of the earlier lines.

DT3.mw

@sarra How about...

Download aHH.mw

I am not seeing that error, if I paste or type it in as 1D or 2D input in a Worksheet using Maple 2015.0 on Windows 7, with the restart in either a separate or the same execution group or document block.

Could you please upload a Worksheet or Document that demonstrates it?

acer

@sarra 

Download H1.mw

@vv The conversion to exp broke for this in Maple 10.03.

restart;

kernelopts(version);

             Maple 10.02, X86 64 LINUX, Nov 8 2005 Build ID 208934

ee := 3^(-(1/2)*n)*2^((1/6)*n)-2^((2/3)*n)*6^(-(1/2)*n):

convert(ee,exp);

    exp(-1/2 ln(3) n) exp(1/6 ln(2) n) - exp(2/3 ln(2) n) exp(-1/2 ln(6) n)

simplify(combine(%));

                                       0

And,

restart;

kernelopts(version);

            Maple 10.03, X86 64 LINUX, Mar 24 2006 Build ID 222373

ee := 3^(-(1/2)*n)*2^((1/6)*n)-2^((2/3)*n)*6^(-(1/2)*n):

convert(ee,exp);

                        (n/6)  (n/2)     (n/3) 2  (n/2)
                       2      6      - (2     )  3
                       --------------------------------
                                 (n/2)  (n/2)

...with the ensuing difficulties we see in this thread.

@vv If n=s+t*I then with arbitrary real s and t we get coverage of arbitrary complex n which was the question at hand.

I doubt anyone's suggesting that Maple ought not be able to get all this easily -- I'm not.

@faisal You can send me a contact (via email) using the "Contact" button here. After I reply to that by email you can send me a longer message with an attachment, say.

@faisal If you are using Maple 2015 then it may be that you did not intend the extra (errant) space between brackets in D(F) (etainf) and that the GUI automatocally inserted it.

If you are using Maple 2015 then you could disable so-called Smart operators by unchecking the box in the preferences dialogues. See the main menubar and Tools->Options->Interface->"Smart operators". It is a bug in the Smart operator facility that it inserts an extra space between round brackets in so common a situation as the initial conditions on derivatives as expected by the dsolve command! You can disable this feature and save that preference globally, so as to cover future Maple sessions.

See also here and here.