IDLE comes without a horizontal (bottom) scroll bar. In 
general this is preferable, but there are times when it's a 
nuisance.

It would be nice to have an option (easily accessible) to 
switch this on.

Logged In: YES 
user_id=149084

IDLE is intended to present a simple interface to
beginners and to encourage good style.  I believe that
GvR made a deliberate decision not to have a horiz
scroll bar to discourage lines longer that 80 char.

If you want to code a patch,  I'd accept it.  However,
the config switch should be in config-main.def only, and
the selection should not appear on the Options dialog.

That way an experienced user could set it in
.idlerc/config-main.cfg 

#15141, which I will close as a duplicate, makes the same request (for the edit window). Roger Serwy notes that his extension package
http://idlex.sourceforge.net/extensions.html
has horizontal.py, which does what is requested. He is willing for that (or other) extension(s) to be bundled with idle for default or optional activation. I presume that is done in some .cfg file. I re-opened for that purpose.

(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:
1. The shell window is a print output as well as code input window. Output should not necessarily be limited to 80 chars. With variable pitch font, that does not even make much sense.
2. Edit windows are not limited to python code. Else they would *always* syntax hilight. Or Pycode might be embedded in other formats. If #6858 were implemented, h scroll would be more useful.
3. Not everyone agrees with the 80 char limits.
4. People sometimes edit a file written by someone else.

Counter-arguments:
1. A full screen window allows about 200 chars or more, which is enough for any code entry and most print output and most 'files written by someone else'.
2. For exceptions, put cursor on long line and use => arrow key.

I wrote Horizontal.py as an extension in order to avoid forking IDLE. It 
should be simple to incorporate a toggling horizontal scroll bar within 
the EditorWindow class itself.
> (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?)

IdleX provides a dialog for enabling and disabling extensions.

The shell window has wrapping enabled on its text widget. A horizontal 
bar is not needed there.
> 2. Edit windows are not limited to python code. Else they would *always* syntax hilight. Or Pycode might be embedded in other formats. If #6858 were implemented, h scroll would be more useful.
True. The Editor window does not wrap, which is why the horizontal bar 
is needed there.
> 3. Not everyone agrees with the 80 char limits.
The limit does make printing code simpler, however.  But that's a 
separate discussion.
> 4. People sometimes edit a file written by someone else.
Yes, and often times it is one or two lines in the file that extend 
beyond the right border of the editor.
> Counter-arguments:
> 1. A full screen window allows about 200 chars or more, which is enough for any code entry and most print output and most 'files written by someone else'.
I shouldn't have to resize the editor to see its contents.
> 2. For exceptions, put cursor on long line and use =>  arrow key.
>
> ----------
> nosy: +serwy, terry.reedy
> resolution: rejected ->
> status: closed ->  open
> versions: +Python 3.4
>
> _______________________________________
> Python tracker<report@bugs.python.org>
> <http://bugs.python.org/issue1207613>
> _______________________________________
>

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
This was brought to my attention by Steven D'Aprano and specifically compare the IDLE editor to other editors.

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 #43467 closed as duplicate of this.