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 rhettinger, terry.reedy
Date 2020-09-25.05:25:40
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1601011540.36.0.942593611255.issue41859@roundup.psfhosted.org>
In-reply-to
Content
I presume that at some point you got a completion box.  It disappeared with this traceback and when >>> appeared, you continued.  What python binary? 3.8.5?  3.8.6? My diagnosis so far.

__call__ is a method in CallWrapper.  The wrapped func is multicall.handler.  The exception was caught in the
    except: self.widget._report_exception()
clause of __call__, but it should never have been raised.

keyrelease_event catches internal errors.  If the insert cursor is not where IDLE expects, because "# we didn't catch an event which moved the insert", IDLE just closes box rather than trying to recover.  I presume that this should never happen.  But when it did, a ValueError was raised for the reason given.  In this error state, multicall.event_delete makes an invalid assumption.

The simple and immediate fix would be to catch the very rare delete failure.  A better and harder fix would be to catch the uncaught insert-moving event. For this, it would have been nice if keyrelease displayed a message identifying the released key with an email request.  I should  try to reproduce the failure (including on Mac) by trying every key (or type of key) that might possibly move the cursor.
History
Date User Action Args
2020-09-25 05:25:40terry.reedysetrecipients: + terry.reedy, rhettinger
2020-09-25 05:25:40terry.reedysetmessageid: <1601011540.36.0.942593611255.issue41859@roundup.psfhosted.org>
2020-09-25 05:25:40terry.reedylinkissue41859 messages
2020-09-25 05:25:40terry.reedycreate