Repository navigation
IDLE - Test ParenMatch #65893
Description
| BPO | 21694 |
|---|---|
| Nosy | @terryjreedy, @taleinat |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2014-06-17.22:10:08.859>
created_at = <Date 2014-06-08.13:31:25.392>
labels = ['expert-IDLE', 'type-feature']
title = 'IDLE - Test ParenMatch'
updated_at = <Date 2014-06-17.22:10:08.858>
user = 'https://bugs.python.org/SaimadhavHeblikar'bugs.python.org fields:
activity = <Date 2014-06-17.22:10:08.858>
actor = 'terry.reedy'
assignee = 'none'
closed = True
closed_date = <Date 2014-06-17.22:10:08.859>
closer = 'terry.reedy'
components = ['IDLE']
creation = <Date 2014-06-08.13:31:25.392>
creator = 'Saimadhav.Heblikar'
dependencies = []
files = ['35536', '35609', '35610', '35623']
hgrepos = []
issue_num = 21694
keywords = ['patch']
message_count = 12.0
messages = ['220034', '220415', '220420', '220421', '220511', '220513', '220529', '220532', '220536', '220543', '220881', '220908']
nosy_count = 5.0
nosy_names = ['terry.reedy', 'taleinat', 'jesstess', 'python-dev', 'Saimadhav.Heblikar']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue21694'
versions = ['Python 2.7', 'Python 3.4', 'Python 3.5']
Activity
SaimadhavHeblikar commentedon Jun 8, 2014
Adding test for idlelib.ParenMatch for 3.4
Will backport to 2.7 when this patch is OK.
3 lines could not be tested in this patch.
terryjreedy commentedon Jun 13, 2014
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.
terryjreedy commentedon Jun 13, 2014
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.
terryjreedy commentedon Jun 13, 2014
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.
taleinat commentedon Jun 13, 2014
I can take a look at get_surrounding_brackets() if you like, since I've worked with that code before.
terryjreedy commentedon Jun 13, 2014
Please do. bpo-21686 is for hyperparser test, which is the next one I want to look at.
SaimadhavHeblikar commentedon Jun 14, 2014
Patch as per tracker and Rietveld comments for 2.7
Terry - 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)
taleinat commentedon Jun 14, 2014
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).
taleinat commentedon Jun 14, 2014
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:
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.
taleinat commentedon Jun 14, 2014
I've opened a separate issue for the issue raised by Terry, bpo-21756. Patch is included there.
python-dev commentedon Jun 17, 2014
New changeset 8a64509b0bd5 by Terry Jan Reedy in branch '2.7':
Issue bpo-21694: Add unittest for ParenMatch. Patch by Saimadhav Heblikar.
http://hg.python.org/cpython/rev/8a64509b0bd5
New changeset 385d4fea9f13 by Terry Jan Reedy in branch '3.4':
Issue bpo-21694: Add unittest for ParenMatch. Patch by Saimadhav Heblikar.
http://hg.python.org/cpython/rev/385d4fea9f13
terryjreedy commentedon Jun 17, 2014
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.