You need to be careful about which command it is to which you're passing the annotation option.

Here are a few alternatives.

Download plot_annotation.mw

@C_R It was an old (very old) design idea of Typesetting to have the mo (operator) and mi (identifier) be used to denote things intended to be pretty-printed in upright or italics, respectively.

But quite a short while after its original implementation (itself now over 20 years ago) some operators began being pretty-printed in upright, even if forcibly put into an "mi" construct. I recall asking about it (15+ years ago...) and not getting far.

You can see also similar treatment (done purely by the GUI, for rendering) of names sin, cos, ln, etc.

The rendering done by the GUI overrides/disregards the "mi", whether in the form,
   `#mi("sin");`
or,
    Typesetting:-mi(sin)

nb. You can force the output by using the function-call form, with options, eg.

    Typesetting:-mi("D",mathvariant="italic")

but the compact name-form doesn't support all such options (mathcolor being an exception). I suspect that this is similar to how right-click conversion to Atomic Identifier doesn't do the reverse action either, ie. it ignores italic characters interspersed in a name.

The first of these can be made more programmatic (if an example's scales differ from this, etc).

Download bode_fun.mw

Why not directly pass in the extra inequalities, as part of the set of conditions, rather than supplying them as assumptions?

It's possible that if you specify, say, R__1 < R[c] as an assumption then the result might tacitly include/imply that. (I didn't see clarification on that aspect in documentation.)

Download PlotsInequal_vs_SolveParametric_ac2015.mw

You could create a Paragraph Style Set (adjusted to use your choice for text and 2D Input, say), and then use that as your default.

You could also make those adjustments be the default for a new (otherwise empty) Document/Worksheet, and set that as your default Start Page when opening a New Document/Worksheet.

Several entities can be inserted typeset for 2D Input by using command-completion, even if they are not directly available already in any of the Palettes.

Download cmd_cmpl_ex.mw

In addition, you could produce just the `&cong;` as 2D-Input, and then select it with the left mouse-button, then use the right-click menu to convert it to "Atomic Variable", and then hit Enter so as to get that as output. The output could then be selected with the mouse and dragged into the Favorites palette. You could also do this for other entities, such as `&rarr;`, etc. And you just wanted to add them to the Favorites palette then you could also enter them in that plaintext input form, and drag their outputs similarly. You can find lists of HTML entities in several places, by web search.

There was a time when some of the names used for structured types were not protected. Ie, you could assign values to them, in which case type-checks involving them would break if you didn't prevent evauation with uneval-quotes (single right-ticks).

So it was commonplace to use 'specfunc', etc, quoted.

Some people like quoting the whole call, eg, 'specfunc(blah, foo)' even when it's not necessary and 'specfunc'(blah,foo) would do fine.

I dislike the first of those, because it's not carefully targeted. Your example is one where it goes awry, because it prevents the reference to the assigned local name y from evaluating.

I wish that the Help pages were more discriminating/targeted in use of quotes, vs merely blanket quoting.

Download delayed_vs_not.mw

The global name specfunc is protected in current versions (you can't assign to it), and there you don't need to quote it.

Here's a closer analog of your problematic example's issue, but done outside any procedure. You need indets to be able to see the assigned value of s. Note that your two original examples did not have a similar nature, even aside from one being in a procedure. The reason that they behaved differently is that in the procedure example you'd assigned something to the name used within the specfunc call. If you do that kind of similar thing outside of a procedure then it too would fail. (Your procedure's local and the expression's global were both named y, which perhaps made this key aspect about assignment less apparent to you.)

s := y;

            s := y

type( y(x), 'specfunc(s)' );

            false

type( y(x), 'specfunc'(s) );

            true

In your code's comments you wrote "same code fail". But it was not the same. In the failing procedure version you made an assignment and attempted to utilize it within the quoted portion. In your original failing procedure example the local named y could be also named something else, with identical failing behavior. Ie, here, indets does not receive something containing the value assigned to s, due to the overwide quoting. It's equivalent to your failing example.

In summary, what made your problematic example fail was not that it was the same code done inside a procedure. It failed because it was not the same code -- the name referenced inside the wide quotes was additionally assigned.

By the way, only some of the special names used for structured types are protected. In Maple 2024.2, for example,

Download types_prot.mw

You should (ideally) uneval-quote the ones which are not protected, to avoid problems if any such are ever later assigned. You can pretty much quote them all (and so avoid having to remember which...), if you place quotes around just the name and not some whole bracketed function-call.

An example with some exclusion,

Download type_D_fun.mw

You could tweak that Not type for the exclusion, but I'm not sure what other examples you might have.

nb. Note the use of the uneval-quotes around ':-De', to avoid a clash if that name has been assigned. And the best way in general is also to reference it with the colon-minus, ie. ':-De' because it might be declared local.

For r=3 you can look at 1-1/r=2/3.

And,

Download lmap_fun.mw

You wrote "output", and it's not clear what you need. The above are exact values.

Are you asking for a reference? You could look at section 2 (or section 4, equation 14) of the PDF file here.

I suppose that there are several ways to get the plot, depending on which coordinate systems you'd rather use.

Download 3dplotfun.mw

The ImageTools:-Preview command uses a 3D plot and puts the image data on a flat plane and shows it oriented head-on, so that it looks like a flat 2D image.

The ImageTools:-Embed command embeds an image (as a GUI construct) into a so-called Task region, which as you've noticed always gets shown after the usual output portion of an Execution Group or Document Block (paragraph).

But since the ImageTools:-Preview command was devised, 2D plots got the ability to use an image with the background option. The resulting file is quite large when saved, but you might be OK with it scaled even smaller than 500 pixels wide.

Download img_bg.mw

Using only uneval-quotes (ie, single right-ticks) here is not a robust way to prevent evaluation if you need to pass the expression (or a structure containing it) around in additional command/procedure calls.

The subsequent evaluations that occur for arguments of procedure calls will strip off uneval quotes, and produce the effect you're trying to avoid.

Instead, you could use an inert representation of the expression.

Download undesired_textplot_format_ac.mw

Is this the kind of effect you're after?

[note: Here I'm starting with the problematic indexed name being present.]

(It could be tweaked/adjusted... I don't know the extent of the kinds of indexes you'd need handled, etc. There are even much simpler/shorter ways, if you only want to handle names indexed by posint, etc.)

Download Evaluation_of_elliptic_integrals_ac.mw

If you just need to handle this one single indexed name, then here is an easier substitution, ie. directly constructed:

Of course, if you only needed a single substitution for varphi[0] then you might as well use,

    varphi[0] = varphi__0

which is of course easier still(!) and which you already know to work OK. I wrote you the earlier code so that the approach might be used for more complicated subscripted expressions or situations (for which a mere double-underscore could not suffice), programmatically. I don't know your full scenario(s).

Is this not fundamentally similar to your Question of Sept 2nd?

Download why_dsolve_cant_solve_ode_oct_4_2025_maple_ac.mw

I prefer the eval(..,..) way, and the thing you've actually requested is not a great approach IMO.

nb. One way to cause yourself grief is to re-order L, in which case your request can still be done, but in a different way(!) and with consequences that might be awkward for you. IMO this is a hint that it's not a good idea.

Download Using_the_constants_ac.mw