@Ronan 
No that I know of. It is not difficult to write one though - a matter of time only. I preferred to not invest on that - prefer everything in white and black, but did tweak Komodo in several ways for fast-programming activity.

Komodo has this useful functionality where you can program macros, assign triggering key combos, and have the output in a window at the bottom. I have one I call "mint selection" with the purpose you ask, that is to flash up bugs in a portion of code (possibly a whole file).

It is a good example of things I didn't find how to do in other editors so easily, so worth showing here as an example. I want to "Pass selection as input" (an option in Komodo's macros), where by selection I mean "something highlighted with the mouse", and on that selection, execute :
<Maple installation>/bin/mint -s -i 2 -I ~/Maple/lib -l

and in this Komodo macro I have "Command Output Tab", so that the output is presented on a window that opens at the bottom, and there I see, exactly where is the problem with a portion of code I wrote. I cannot write in that output window but I can copy something I see in it and paste in the working window. All extremely useful.

Komodo has several other facilities, I have/use approx 10 macros. It is a pity for me that its development for Macintosh stopped (I use Mac). I managed to have a working version for Monterrey and previous OS versions. Not for Ventura yet.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@zenterix 
I am forwarding the problem you posted to the people who take care of that, adding it to the database of issues too.

On the other topic you mentioned, I missed saying that - for programming purposes (not interactive mathematics) - I use a Programmer's File Editor. I do not program within a Maple input line. For me, that is just not comfortable, even if you work using 1D-Math notation. A programmer's editor has significant useful tools. I use a tweaked version of Komodo, but many good programmer editors exist. 

@nm 
Your question is answered in my previous answer; read it slower. I said "Regarding another part of your question, dsolve matches c__n to _Cn only for the integration constants that it introduces / uses, not for al possiblel n (infinitely many)." Pass a fourth order ODE that gets solved and you will see 4 c__n matched to _Cn, and not more than that.

@acer 
I see I wasn't as clear as I thought. In my reply, I mentioned dsolve((2)). Not dsolve((2), arbitraryconstants = subscripted). So, using dsolve((2)), not Physics, no arbitraryconstants = ..., no Maple/toolbox, no mapleinit file, nada, so in that state, not only Maple 2022.2 and 2022.1 trigger the same Warning message, which - I understand - is the issue of this thread, but also Maple 2021 triggers that undesired Warning. Try it; you can download "not related to physics.mw", the worksheet I used to produce my previous reply.

To summarize, this is not related to Physics. Somehow, there is something with the Units package and the input of the worksheet posted such that it triggers this Warning message. The fact that @C_R also uses Physics and the Maplesoft Physics Updates, is a red-herring and deviates the attention from the main issue; this is my understanding of the matter.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@acer 

Download not_related_to_physics.mw

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@itsme 
Interesting ... I never installed the Updates from Maple TTY (a terminal). I tried that now, and am able to reproduce your problem. That problem doesn't exist, however, if I install the Updates from the GUI (worksheet). So the solution is: the same input, as always, but within a worksheet, not  a terminal Maple; and I will take a look anyway to see what the problem with a terminal Maple is. 

PS Nov/16: the problem in Maple TTY is now fixed at the company. I will see to include the fix in one of the next versions of the Maplesoft Physics Updates.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@Carl Love 
The problem posted had nothing to do with the entering something assuming some_property, without specifying variables. The problem, as explained, was related to the use of quotes around the keyword 'right', and that is what got fixed in v.1340 of the Updates.

Your sentence (first paragraph, read it again) implies a recommendation to not use something assuming some_property including "[if you don't use that syntax] it works", followed by "Otherwise some problem occurs", and today "I've encountered an error (I don't remember details)". All that - for me - means "do not use it, it is problematic", while my opinion is use it! it is a great feature! Indeed, it is fantastically handy for symbolic experimentation. And if you find a problem and are able to remember it and post it, the problem will get fixed; we are rather quick at that. By the way, generally speaking, there is no software free of problems - only free of known problems.

Regarding your question,

"Suppose I were to write a command that used keyword parameters. How would I tell assuming about those keywords? "

This is an interesting one. When I wrote this command, I also provided a mechanism to indicate to assuming the keywords of a user-written command. Then Maple's syntax improved and now every procedure's parameter enclosed within {} is automatically a keyword (see ?argument_processing). So now there are two mechanisms to tell assuming about those keywords:

1. Just create your procedure using {} to indicate a proc's parameter is a keyword, and assuming will automatically take that info into account, and will not place any assumption on it.
2. Use: "keywords" assuming command keyw1, keyw2, ... in a Maple worksheet or in the Maple initialization file to indicate to assuming the keywords or keyword positions of the procedure command. A range of positions can be specified by using i..j. For example, 2..3 refers to the second and third position and 5..-2 refers to the fifth to second-to-last argument(s). If no keywords or positions are included, the "keywords" assuming command calling sequence returns the recognized keywords and/or keyword positions for command.

Naturally, the way "1." is the simpler and generally speaking it can cover all user-written command's keywords. The way "2." is more involved, and provides more flexibility, mainly for Maple commands written before the introduction of keywords using {}. 

As an example of 1., consider P := proc(x, {real::truefalse := false}) if real then 1; else 0; fi; end. Next input P(x, real) assuming positive and ou receive 1, indicating no assumption was placed on the keyword real.

As an involved example of 2. input "keywords" assuming int and you will see how the keywords of int are set. For simpler ones, try prem or normal instead of int.

Summarizing: I recommend using something assuming some_property as a very handy and quick way for doing symbolic exploration. If you find a problem please remember to post it, we fix things quickly, and yes, you can indicate the keywords of commands you write, either automatically (item 1. above) or in more ellaborate ways (item 2.).

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions

@C_R 
Yes, though I'd need to see if I can include it working with the Maplesoft Physics Updates for Maple 2022; tomorrow or next week, I will write here again about that.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@awass 
As described in the post, a literal subscript is a letter followed by __ followed by a number, e.g., c__1. They look very similar to c[1], but if you look at the number you see it is italicized instead of roman. So, if you want to assign after dsolve has returned it, go with c__1 := 7, not c[1] := 7. Depending on your work, you may prefer subs(c__1 = 7, solution) instead of assigning a value.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft.

@vv 

The issue of this thread was about the un-initialization of Physics; that is resolved.

You bring other things to the table. Regarding your first item above, as explained on the help page ?Physics,diff, you have that :-diff and Physics:-diff use the same differentiation rules - say `diff/abs`. Then when Physics is loaded, we automatically switch the differentiation rules of all the complex components to use Wirtinger derivatives. So we need to choose what to return when Physics is not loaded and you call Physics:-diff:

1. We keep the differentiation rule unchanged because Physics is not loaded (my choice at this point) at the cost you mention; or
2. We change the differentiation rule just because you called Physics:-diff, even when you didn't load Physics.

There are other more convoluted options, but generally speaking, you cannot have it all.

Regarding your second item, what you say is not correct in that even without having Physics loaded, if you input Physics:-Setup(wirtingerderivatives = true), you have the differentiation rules for the complex components redefined accordingly - you can use them. And if next, at any point, you input Physics:-Setup(wirtingerderivatives = false) you have those differentiation rules redefined back to their original value.

With that cleared, it remains something you touch laterally, which is the Maple definition of the differentiation rule for the complex components when Physics is not loaded. That is something (unrelated to Physics) that can be adjusted further. Do you have a concrete suggestion? We could just use:

So, basically, return them uncomputed, only represented, and in the case of a composite function, apply the chain rule. Any better idea? For reference, this is the current value of these rules:

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@vv 
I see, I was probably sleeping at this end :) indeed you mentioned "d/dx for x real". I suppose I was looking for an alternative for complex z in general. Not that that derivative always exists, but sometimes it does. Your rule for real x is thus not what we need.

Independent of that, I didn't spend more time on this yet, but what you call "the bug" might be an issue with the evaluation of abs(1, z). Anyway, I will continue this conversation in this other Mapleprimes thread.

best

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Download your_suggested_differentiation_rules.mw

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft.

@Carl Love 

Maple's dsolve and pdsolve can tackle differential equations with anticommutative variables. How is that done? Using Physics. That explains all the occurrences of "if `Physics/Initialized` = true then ..." in the differential equation routines that are the majority of the list you show, The calls in diff/xxx, expand, combine and simplify are kinda obvious too: they currently handle anti and non-commutative variables (btw, not a small feat!). The calls in assuming routines are also natural: Physics includes Physics:-Assume that has some advantages with regards to the older lowercase assume command, that is optionally (user setting) used by assuming.

So Physics allows for doing more things, impossible to do in standard computer algebra systems because the computational domain in Physics is larger than just complex variables and functions or matrices. The simplest example is that of algebraic and unit vectors - not matrix representations of them. Tensors and not commutative variables are another one. Then these occurrences of the word Physics in internal routines only extend the functionality of these commands to handle this extended computational domain when Physics is loaded. 

Overall, you can look at this in two ways: Physics changes Maple - I don't want changes, or Physics - optionally - extends what Maple can do, to include the mathematical objects we physicists use all the time to express formulations. Of course, there are nuances, as this thread shows, but essentially that is all about.

My take, obvious from context, is that I am extremely, even passionately, motivated by the second interpretation, that  Maple Physics optionally extends what Maple can do without Physics. And being fully aware of what Maple can do nowadays after you input with(Physics), I sometimes can't even believe it. It is a dream come true. That also matches the feedback I receive from the physics community. Btw, although I am sometimes viewed as a differential equation or mathematical functions guy, and I am that, I am a physicist by formation and heart.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@Carl Love @Preben Alsholm @vv @acer, each of these threads has juice. There seems, indeed, to be:

• an issue in forget (with regards to the syntax form forget(.., x))
• an issue in unwith (the need for unwith to call forget is clear, not happening)
• an issue in Physics: although if you input with(Physics) it is expected that the derivatives of the complex components (e.g. conjugate) are redefined so that dz/dconjugate(z) = dconjugate(z)/dz = 0 (Wirtinger derivatives), on the other hand, after reading this thread, I think calling Physics:-diff (and not with(Physics)) should not do this redefinition. And these things need to be documented somewhere visible.

I am a bit overloaded this week but I will try to address some or all of these issues (the one in forget may be out of reach) and upload the adjustments for everybody in the following Maplesoft Physics Updates.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Hi @Preben Alsholm 
You are right, unwith unloads the package and forget clears remember tables from results obtained with the package, both concepts apply to any package. This is expected and what one needs to do, @Carl Love, when you want to restore the previous behavior without restart.

@acer , forget - say diff - with subfunctions = true clears remember tables of everything that starst with diff, e.g. `diff/conjugate`, but I suppose you are aware of that so maybe it's Sunday morning here and I'd need to read your answer more carefully.

@vv, several things, not "almost everything", is redefined when you load Physics. The redefinitions are as in more functionality is available, e.g. you can differentiate with respect to a function (say conjugate(z)), and then there are very few exceptions, less than a handful of extended-different behavior that makes sense in the Physics context; e.g. after with(Physics), Heaviside(0) = 1/2 instead of Heaviside(0) = undefined. In this example, more importantly, for all the functions shown by FunctionAdvisor(complex_components), Physics' default is usewirtingerderivatives = true (about that, check this Mapleprimes post), i.e.: z and conjugate(z) are considered in equal footing, dz/dconjugate(z) = dconjugate(z)/dz = 0.

The key idea behind the Physics package integrated into the Maple system is that it extends the default computational domain with vectors, tensors, anti and non commutative variables and functions, curved spacetimes, Wirtinger derivatives for the complex components, differentiation using a jet concept (q(t) and diff(q(t),t) as independent differentiation variables); Etc. All this is explained in ?Physics. Whoever doesn't need any of that, just doesn't load Physics, and whoever needs that, needs it within the Maple system, not separated.

Finally, @Carl Love and @acer , I am surprised that forget(.., conjugate(f(x))) used by Carl, or even forget(.., x) didn't clear the remember table of :-diff. That requires a further look since the expected behavior is for forget to have cleared all tables containing the second (and any subsequent) argument; though this has nothing to do with Physics.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft