Your report touches on four different issues.

1. IDLE uses tkinter for the GUI and tkinter wraps tcl/tk 8.6 or earlier, which only handles Basic Multilingual Plane chars (codepoints 0000 to FFFF). The gun and knife chars are out of that range.  I have read that 8.7 will handle all unicode chars and that it might be released this year.  This will fix multiple IDLE issues (#21084, #22742, #13153, #14304).

2. Until 3.3, CPython used two internal unicode encoding schemes: Narrow and wide builds.  Narrow builds used pairs of surrogate chars in the BMP to represent chars not in the BMP.  So your '3 char' string is stored as 5 chars.

# -*- coding: utf-8 -*-
text = u"🔫 🔪"
for c in text:
    print(ord(c))

*prints, on 2.7.13 on Windows
55357
56619
32
55357
56618

Windows releases and a few *nix releases used narrow builds.  I have Windows, so I could copy and paste your string and run the above.  Most *nix releases used wide builds and could not.

In 3.3, CPython switched to a flexible representation used on all releases.  Like earlier wide builds, it does not use surrogate chars, and the above no longer loads into a text widget, let alone run.

3. Any exception not caught by IDLE generates a traceback that appears on the console used to start IDLE, if there is one.  Otherwise, it is lost.  Running "<python3> -m idlelib" in a console and loading the code above results in a traceback ending with "_tkinter.TclError: character U+1f52b is above the range (U+000)-(U+ffff) allowed by Tcl".

I have though about (and previously commented about) trying to put such messages in a tk message box when IDLE and tk are still functioning well enough to do so before stopping.

4. It appears the IDLE opens a file that is not already open by creating a blank editor window and then loading the file into it.  In this case, when the load fails, a frozen window is left that blocks IDLE closing.  This nasty behavior, which I verified, is new to me, so I am leaving this issue open specifically for this bug.

A likely fix is to catch TclError in the appropriate place (not yet known to me), recover (delete the new EditorWindow and ???), display an explanatory error message, and continue when user hits [OK].

We already have a test string.  If needed, I will try to separate 'opening a file name' from 'reading the contents', so a test can use a simple mock file object.

If a file were opened and read *before* creating a new window, there would be less cleanup to do.