New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Idle Editor: Bottom Scroll Bar #42010
Comments
IDLE comes without a horizontal (bottom) scroll bar. In It would be nice to have an option (easily accessible) to |
Logged In: YES IDLE is intended to present a simple interface to If you want to code a patch, I'd accept it. However, That way an experienced user could set it in |
bpo-15141, which I will close as a duplicate, makes the same request (for the edit window). Roger Serwy notes that his extension package (Note: it would seem nice to be able to get a list of extensions available and those enabled from the menu. Or is there a reason not too?) Some arguments for h. scroll:
Counter-arguments:
|
I wrote Horizontal.py as an extension in order to avoid forking IDLE. It
IdleX provides a dialog for enabling and disabling extensions. The shell window has wrapping enabled on its text widget. A horizontal
|
patch to be pulled from idlex |
I don't like telling people to hand-edit .idlerc files. It causes too many problems. We added Extensions tab to avoid this. I think all supported options should be on dialog. Windows are resizable and accommodate lines up to current width. Default width is user settable option. So people who want to edit 100 char lines for code can and have editor open with 100 char width. Shell,Edit, and Output windows should not necessarily be same. Currently, Shell wraps both input and output while Editor Output truncate code input and grep output respectively. I plan to review this, including possible scrollbar, but not a priority. |
I hope you don't mind that I made a change for this. I was working with 'Find in files' and couldn't see the full line, so I figured out where to add the scroll bar. I only found this ticket after the fact. If it's not appropriate, I can withdraw the PR. |
Output Window definitely needs a scrollbar available on screens where it cannot be stretched to 160 chars or so. Thinking about it, if one greps idlelib in a local install, with a url something like C:/users/somename/appdata/local/python/lib/idlelib/*.py, one only needs 100 chars to pick up the idlelib file name and code, but needs the scrollbar to display the last 100 chars instead of the first 100 chars. To add to msg16443: the fact that one can stretch the window much wider than 80 chars means that omitting a scrollbar does not enforce an 80-char limit. |
A horizontal text bar is added to a text view as needed (recent patch) when one is used for the font sample. The latter fits or not according to the font size. The same could be used for editor, or better, editor windows could inherit from text views. |
Some IDLE users really want a horizontal scrollbar (for the editor), and even consider its absence to be a reason to not use it. Stackoverflow 2012: https://stackoverflow.com/questions/10301071/is-there-a-horizontal-scroll-bar-in-pythons-idle Reddit 2020: https://stackoverflow.com/questions/10301071/is-there-a-horizontal-scroll-bar-in-pythons-idle I have decided to not wait until a possible major refactoring to add this feature. The patch needs several revisions (see review). I neglected to mention above (msg352888) that the scrollbar added to the font sample box is a Scrollbar subclass, textview.AutoHideScrollbar, that only appears when needed. After experimenting with editing the font sample, I think we can just add this with no option to disable it. Since editor windows already allow lines longer than the window width and already have horizontal scrolling by cursor motion, such as by Home, End, and Left and Right arrow keys, adding a horizontal scrollbar makes scrolling easier, but does not really change editor window behavior. The disappearance of the scrollbar when a long line is sufficiently shortened makes it easier to determine when one has shortened a line enough to meet the window width as a limit, if one wishes. The shell is a different issue. It wraps at the window width, just like standard interactive Python (as least on Windows with Command Prompt and macOS with Terminal). I think something like the following is better wrapped. If nothing else, copying to paste is easier ;-). >>> 2**1024
179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137216 So, at least for now, no hbar for Shell. |
We've run into a significant technical hurdle in trying to implement a horizontal scrollbar: The Tk text widget sets the horizontal scroll position only according to the currently visible lines! If the text was scrolled to the right, scrolling down to where there are only shorter lines will scroll the text back to the left!! Implementing this will require either getting a fix for this into Tk itself, or finding a good workaround. The workaround I was considering--wrapping the text widget with a frame and implementing custom scrolling logic--is very unlikely to provide reasonable performance with large files. This is because it will have to have all of the text widget rendered at all times, which the Tk Text widget takes special care to avoid in order to achieve good performance. |
Request in bpo-43467 closed as duplicate of this. |
I still would like to add this. I closed the PR because it is at an impass. I'd like to make other editor changes first before trying to resolve merge conflicts or think about another approach. I'd like also to read the IdleX code. |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: