I've just created a simple Maple worksheet and opened it in WordPad, which I previous to your comment wasn't aware of was an option (so thanks for that), and you are right about the encoding="UTF-8" in the first line. I suppose that the bad formatting behaviour, at least in comparison with Maple 9.5 (from which I've recently upgraded), comes from the use of XML coding. I've a hard time, though, understanding how these formatting misbehaviours can have passed unseen by in the testing process at Maple: the annoying tabbing behaviour previously reported surely must have been noticed, or what?

I'm not quite certain that this answer of mine is relevant for you, but I've also experienced quite odd formatting behaviour in Maple 11, see thread1 and thread2, respectively. First of all, how do you actually determine when Maple is switching to UTF-8 encoding? Where do you look? Can you see all the hidden formatting codes (which I suppose are the culprits)?

Thanks!

Thanks!

Thanks for testing. I've just done the same test, using Maple 11 Classic Interface, and I get the same result as you do, i.e., no lost kernel connection. Do you dare to test it using the non-classic interface?

Thanks for testing. I've just done the same test, using Maple 11 Classic Interface, and I get the same result as you do, i.e., no lost kernel connection. Do you dare to test it using the non-classic interface?

Very nice - I was not aware of that.

Very nice - I was not aware of that.

eval(A = B) in the first paragraph should of course read evalb(A = B).

If A itself contains some arctan-expression(s), then the outlined procedures don't work, as they will produce lists containing more than just the asked for B.

If A itself contains some arctan-expression(s), then the outlined procedures don't work, as they will produce lists containing more than just the asked for B.

Thanks for clearing up the way expression sequences works; I was not aware that they were automatically flattened.

It seems you are quite right. However, it does not seem obvious to me, because to me NULL ought to be behave like any other datatype that can be assigned. But maybe it's just me!?

It seems to do the job I had in mind - thanks a lot!

Thanks for your efforts to reproduce my results. It seems you are quite right that by using Enter instead of Shift-Enter, i.e., using one execution group per code line, makes the end of any one code line accessible. But, I'm sorry, this is not satisfactory to me, for the following reasons: 1. It is of no use when programming large chunks of code, like packages. 2. Using a new execution group for each new code line makes Maple (correctly) complain about "premature end of input". 3. It was not a problem in Maple 9.5, and indeed it should be no problem in any well-behaved text editor. Yesterday I thought I had a little Heureka-moment when I found the option 'indentamount' for the interface(...) command. The default value is 4, which is equal to the difference between the number of characters, 8, one tab indentation corresponds to, and the missing number of characters, 4, at the end of the line. So I tried writing

interface('indentamount' = 8);

but unfortunately to no avail. Ending on a general note, I cannot help wonder why these problems of mine are not more commenly reported. Are almost no one using tab indentation in their coding?