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 GeeTransit, terry.reedy
Date 2019-08-21.21:41:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I won't merge with mousescroll duplicated, or worse, triplicated.  If 'self.text/canvas' is replaced with 'event.widget', then the 'self' parameter can be deleted and the function made a standalone module function.  For now, put it in tree, copied with the docstring from  Then import it into editor.  (Reason: Avoid creating more import loops.)

This will make mousescroll depend on IDLE not subclassing text/canvas and overriding yview_scroll.  It currently does not and I expect it never will.  But, to be safe, this should be added to the docstring, and tested (fairly simple) along with other added tests.

The labels partially blocking the canvas bindings is nasty.  Mousescroll is wrapped as a tk script for each label.  I expect to eventually replace  the labels and other visual tree stuff with a ttk.Treeview.  Then no canvas wheel bindings will be needed.  In anticipation of that, replace 'yview_scroll(' with the equivalent 'yview(SCROLL,' (Treeview only has the latter.)  The resulting line will be
        event.widget.yview(SCROLL, lines, "units")

For some reason, creating a module browser for pyshell takes 3 times as long with my repository 3.9 debug build as with my 3.8 installed normal build.  (The ration is usually about 2.)  But the patch with the extra bindings and wrappings  does not make it much worse, if any.

Scrolling by moving mouse while holding down middle mouse wheel seems to be built into Text.  But I never/seldom use it and have not tried to add it to anything else.  At least on Windows, it works differently than on Firefox.  Text only moved with drag, which makes it jerky, not with distance from start position.  And one cannot only scroll part of a large file, not to top and bottom.  Notepad and notepad++ do not have it.  So skip it for now.

When one edits a branch and pushes commits to ones github fork, the changes appear on any existing PR.  Closing a PR and reopening a new one is unusual and loses comments.  Post to core-mentorship if you need help with git and our workflow.  My PR-15360 comment applies to the current one.
Date User Action Args
2019-08-21 21:41:51terry.reedysetrecipients: + terry.reedy, GeeTransit
2019-08-21 21:41:50terry.reedysetmessageid: <>
2019-08-21 21:41:50terry.reedylinkissue37902 messages
2019-08-21 21:41:50terry.reedycreate