What are D, TB, and T under the various summation signs?

@Kitonum: If you have some specific arguments and some specific function, then using -> is indeed the simplest solution, I agree. But if they are variables themselves, then the -> construction cannot work. Or am I wrong?

@taro: You are welcome. With the verification by tomleslie as well, there does indeed seem to be a bug here.

@Mac Dude: Thanks for your input. It would seem to bolster the suspicion that Ctrl+Shift+Enter is a reasonably new feature.

Having Maple 15 installed, I wonder if you have Maple 17 installed as well. If you have, are you then able to replicate my problem?

@tomleslie: Thanks for your image of the relevant menu entries. In my Maple 17 there is only 'Worksheet' without any trailing 'Ctrl+Shift+Enter'. So it would seem that this particular shortcut sequence has indeed been added after Maple 17.

@taro: When I search for v__1211 in your attached worksheet, Maple finds only the three occurences in the execution (input) areas, but it neither finds nor get trapped at any of the corresponding occurences in the output areas.

However, when creating a simple worksheet of my own with that variable, I found the very behaviour you describe: 1.) Maple finds v__1211 in both areas, but it gets stuck in the output area, being unable to return to the occurrence in the input area; and 2.) if only a single underscore is used, i.e., v_1211, then there is no such problem.

@tomleslie: There seems to be no corresponding entry in Maple 17. The help page 'Common Actions in Using the Standard Worksheet Interface' has the following entry:

"Execute worksheet - Edit>Execute>Worksheet: Computes or recomputes the entire Maple worksheet when you have changed expressions that affect subsequent Maple commands." That is, just what I already do.

PS: Thanks for your help, even though it did not resolve the issue.

Use Save As instead of Save. Then it can be saved. I think it is standard mapleprimes behaviour.

@tomleslie: Thanks for your detailed reply.

Ctrl+Shift+Enter seems to have no effect in my case (I am using Maple 17).

You are, of course, absolutely right concerning my Alt+e+e+w: it is just working ones way through the menu system, and it is, no surprise, the way I arrived at it some years ago (and then just memorized it).

In order to obtain a freeze of Maple, I sometimes have to do other things before pressing Alt+e+w+w. However, no matter what the prior history is and no matter what keyboard sequence one enters, it should not, of course, cause Maple, or any program, to freeze; it should just silently ignore nonsense. I guess, you agree with me.

@Carl Love: That clarified things quite a bit. Thanks.

@Carl Love: For a short while yesterday your solution seemed to stop working. I did not understand why until I realized that I had accidentally, perhaps in connection with some cleaning up of my code, left out the 'set' in the set of type names not to be frozen. Although it indeed only works with that type present in the set, I cannot say that I really understand why (but that just shows, I guess, that at present I have only a very tenuous grasp on the frontend command). You are of course more than welcome to enlighten me a bit on the necessity of its presence.

@Carl Love: Thanks for your solution. It works. I have never used frontend before. Having read its help page, it seems to essentially perform back and forth substitution, from and to some 'placeholders' (the "unique names"). The advantage over doing this manually is that one avoids having to explicitly name these 'placeholders'; rather this is done behind the scene.

@Axel Vogt: Thanks for your suggestion, but as I wrote I would like to avoid doing substitutions.

@Carl Love: I see your point, and have noted your solution of replacing x[1] not by an expression but by a procedure.

@Carl Love: You are welcome.