Adding test for idlelib.ParenMatch for 3.4Will backport to 2.7 when this patch is OK.3 lines could not be tested in this patch.

I just discovered what I consider to be a bug in parenmatch. Consider(3  + 4 -   1)When I type the closing paren or put the cursor on the second line and hit ^0, the highlight extends from ( to ), inclusive, as it should. If I put the cursor on the first line and hit ^0, the highlight extends from just ( to +. I will review this next, looking for a possible fix and to make sure there is no test 'validating' the bug. It would be better to have a correst test that is skipped.

Attached is the 3.4 file I am ready to commit. Comments on Rietveld. I believe the 3 missed line could be hit by adding a delay to a test, but this seems pretty useless. The test file explicitly tests only two of the methods. Tests of other methods could be written, but since they would mostly be white-box tests that code does exactly what it says it does, this does not seem useful.What *would* be useful is a patch to ParenMatch.set_timeout_last to keep the highlight on for as long as ^0 is held down, if longer that .5 sec. Right now, it flickers on and off.The range bug, if such it is, is in HyperParser(self.editwin, "insert").get_surrounding_brackets().  I might take a look.

I did the trivial part of a 2.7 backport of 2 name changes, but the real problem is that 2.7 does not have unittest.mock (which is why I have not used it until now). I removed one use with a dummy class, but am leaving the other one in the last test to you.

I can take a look at get_surrounding_brackets() if you like, since I've worked with that code before.

Please do.#21686 is for hyperparser test, which is the next one I want to look at.

Patch as per tracker and Rietveld comments for 2.7Terry - I replaced the DummyFrame with a Mock, so that we can have consistent code across 2.7 and 3.4. I completed a docstring.(See Rietveld)

ParenMatch is indeed failing when the cursor is after the first parenthesis of the following code:(3 + 4 - 1)This happens both in Shell and Editor windows.I've traced the problem down to HyperParser. It doesn't properly support multi-line statements, as can be seen by the following line in HyperParser.__init__():stopatindex = "%d.end" % lno(this appears twice, once in each branch of the same if statement)Fixing this requires looking forward a few lines to find the end of the statement. I'm continuing to look through the code to try to find an efficient way to do this (without parsing the entire file).

Progress: As a hack for exploring this issue, I fixed this in the Shell window by having ParenMatch instantiate HyperParser in such a way that it parses the entirety of the current input. In ParenMatch.flash_paren_event(), I added:from idlelib.PyShell import PyShellif isinstance(self.editwin, PyShell):    hp = HyperParser(self.editwin, "end-1c")    hp.set_index("insert")    indices = hp.get_surrounding_brackets()else:    <current behavior>With this the given example works as expected in the Shell window, i.e. the entire expression is highlighted when the cursor is after the first bracket and pressing ^0.I still need to find a less hackish way to do this which will also work for editor windows.

I've opened a separate issue for the issue raised by Terry,#21756. Patch is included there.

New changeset8a64509b0bd5 by Terry Jan Reedy in branch '2.7':Issue#21694: Add unittest for ParenMatch. Patch by Saimadhav Heblikar.http://hg.python.org/cpython/rev/8a64509b0bd5New changeset385d4fea9f13 by Terry Jan Reedy in branch '3.4':Issue#21694: Add unittest for ParenMatch. Patch by Saimadhav Heblikar.http://hg.python.org/cpython/rev/385d4fea9f13

I changed the close to match what worked in test_hyperparser. At first, I still got the warning. To see if the remaining problem was the import of EditorWindow, I disabled that, and the message went away. When I re-enabled the import, it stayed away. Puzzling, but a bit more data.