A note on the first 3 comments in msg223086 of 2014-07-15.

1. Canvas versus Text: The prototype posted by Brian Oakley on SO had to use a Canvas because it was meant to work even with texts with multiple fonts and in-line widgets.  IDLE's editor, intended mainly for .py files, does not allow either.  As long as line numbers use the same font as the text, they have the same height and vertical spacing as the text.

I checked that this remains true when non-latin character sets are mixed in.  I pasted the config font sample into a numbered editor and it worked perfectly. At least on Windows, tk fonts are vertically monospaced at least for this sample, and I assume for all.  To do this, either ascii/latin/etc lines are over-spaced or hanji/kanji/hangul lines are underspaced.  Source Code Pro, which I normally use, does the former.  Courier does the latter.

2. Call versus Event notification.  IDLE's menu and hot keys generate pseudoevents handled by one event handler.  Some tk widgets generate widget-specific pseudoevent that can be handled by any handler.  IDLE's config dialog pushes font change notifications by calling text methods that amount to event handlers.  It can do this because 'listed windows' are registered as listeners by being on the list of such instances.

I suggested 5 years ago that we might switch font change notification to events.  I don't think so now.  The current system allows control of the order in which texts within a code frame respond to config changes.  It works better if code contexts, when present, change before the main text.

3. Line number foreground and background.  We made them configurable to user preference.  Possibilities are: same as text; toned down version of text (for instance, black on white to dark gray on light gray), or contrasting with text.

(I discussed 4. global versus local setting on 7/21.)