When teaching Python, it is common to have someone encounter as code issue where the code looks fine, but it raising a SyntaxError.   Usually, the problem is solved by deleting the line and retyping it.

I would think that IDLE would be able to detect unprintable characters and deal with them in some way (display a placeholder, elide them from the text, add a warning message, or some such).  If IDLE can help out in this regard, it would improve the end-user experience.

With respect to Shell, this is a request that IDLE move further away from strictly imitating Python running in a dumb terminal and better help users with intelligent action and information.  I want both to improve editing and make entry of a statement  in Shell more or less the same as as entering one in the Editor. 

Goal for this issue: make specific error visible and allow specific correction without retyping the complete line.  When?  see below.

First, what invisible characters are an issue? Do you mean truly no-space invisible or displayed as spaces?  For the moment, I assume the issue is ascii control chars.

On Windows, some can be entered directly with KeyPress-Alt, up to 3 keypad digits, KeyRelease-Alt.  But there are various interactions with interpretations as DOS graphics characters (alt-1 = light smiley face, alt-01 = \x01 displayed as box), old keyboard codes (alt-3 = HOME key), and IDLE bindings (alt-2 = dark smiley face + IDLE zoomheight, alt-02 = \x02 displayed as space + zoomheight, maybe twice).  (I checked that zoomheight return 'break'.)  A mess.

Once a control char is entered into tk text, which is most easily done with an escapes within a string, some appear as half-width boxes, which interact a bit badly with fixed-width ascii; some appear as spaces, the subject of this issue; and a few otherwise (I think at least one on one OS is no-space invisible, which would also be the subject of this issue).  By experiment, details depend on the OS.

Realistic test case: 'for iin [1]: pass'.  The char before 'in' is \x02, displayed by tk Text on Windows as ' '.  Perhaps the user only meant to zoom or unzoom the window and was not aware of the difference between the regular 2-@ key and numpad 2.

When this code is submitted and the symtax error detected, the control char gets a red background.  In the editor, the cursor is placed after the error char after the SyntexError box is dismissed.  An experienced user should know to delete the 'space' and enter a real space, but still would not understand the error or how it got there.

In Shell, one currently has to retrieve the statement as the new prompt and move the cursor to the false space.  Before implementing the fix below, I would like to change Shell so one can edit syntax errors in-place, just as in the editor.  IDLE compiles code for syntax checking before submitting the code object to be exec-ed.  There is no need to freeze the code, display a traceback, and display a new prompt.

Possible improvement 1: check a marked chars or scan the entire reported error line for control chars other than newline and tab in a string and replace any found with red-background '\xnn' escapes.

At present, I would prefer to reserve bulk scanning for bulk text entry via pasting or file reading.  For interactive entry ...

Possible improvement 2: IDLE already checks each character typed to see whether it is a '.' in code, '/' or (on Windows) r'\\' in string, or '\n' anywhere.  (And it also checks syntax coloring.)  Add a check for controls chars and immediately replace with red escape (or whatever else we decide on).  Leave the cursor immediately after the error.  Put an error message either on the status bar or in a non-modal popup similar to a calltip.

I already want to get rid of the SyntaxError box and replace it with a display of just the error message, as above, without the boilerplate around it.

Neither check will catch problemmatic non-ascii chars displayed as no-space or a space. This set likely depends on the font and OS and you did not specify this an an issue.  IDLE cannot see what is on the screen.
  
In any case, worrying about non-ascii should be a followup to an initial patch.  If we do, we can selectively include problematic visible chars, such as smart quotes.

The isprintable() method on str objects may be of help.