This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author terry.reedy
Recipients JayKrish, Todd.Rovito, philwebster, terry.reedy
Date 2013-07-12.07:49:13
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I want to commit this patch more or less as is so we can move forward with the tests that do not need anything more. We can then elaborate mock Text as needed and desired.

Looking at, for instance, I see that 'lineend' is an expression modifier in that same category as +/- chars/lines. So _decode should not really handle it until it handles such modifiers more generally.

As near as I could tell from experiment, 'm.n lineend' is the same as 'm.end', so the former is never needed and could be changed to the latter in Idle code. As far as you know, correct? The use for 'lineend' would seem to be after other modifiers, as in '1.0 +100c lineend', where the line whose end we go to is likely not line 1.

Remember that for advanced Text use, we have the option of using tk.Text for a test, at least at first. The gain would be not having to reproduce baroque behavior*. The cost would be making the test a gui test and running on fewer buildbots. I felt that the basic mock done so far would be worth the time because a) it would be useful for many tests and b) I would learn the Text widget and how to experiment with it to determine its under-documented behavior.

*For instance, having optional spaces within modifiers as well as using them to separate modifiers. Do you know if there is a coherent index grammar anywhere? Or is it only defined by the Text.index C code?
Date User Action Args
2013-07-12 07:49:14terry.reedysetrecipients: + terry.reedy, Todd.Rovito, JayKrish, philwebster
2013-07-12 07:49:14terry.reedysetmessageid: <>
2013-07-12 07:49:14terry.reedylinkissue18365 messages
2013-07-12 07:49:13terry.reedycreate