IDLE: syntax highlighting and selected text

[Moosems]

Bug report

In the newest version of python (Python3.10.4) IDLE will remove syntax highlighting on selected text. How do I remove this? Is there anything in the tkinter source code that I have to change on my ened?

Your environment

• CPython versions tested on: Python 3.10.4
• Operating system and architecture: Macos
• IDLE info: Python 3.10.4 (v3.10.4:9d38120e33, Mar 23 2022, 17:29:05) [Clang 13.0.0 (clang-1300.0.29.30)] on darwin

Images:

Before selection:

After selection:

Example of other IDE's (What IDLE used to do):

[Moosems]

Any thoughts?

[arhadthedev]

Currently selection is implemented not as an overlay (as other programs do) but as a comment-like range with its own background and foreground:

Doing otherwise requires deep rewriting of grammar tree processing (after getting familiarized with all modules of IDLE). I suspect that currently there is nobody with enough free time to pull it out.

However... @terryjreedy (as a maintainer of IDLE), @taleinat?

[Moosems]

@arhadthedev It had the highlighting stay in 3.9 so it's a recent change

[terryjreedy]

This issue duplicates https://stackoverflow.com/questions/72367529/idle-highlighted-text-loses-syntax-highlighting, open 2 days earlier. @Moosems, if you are the same person or read the SO question, this fact should have been indicated there and here.

To expand on what I already said there:
1 Selection in IDLE with current 3.9.13 on macOS Catalina hides syntax tags, as shown in 'After selection'. I don't know the previous behavior across systems and releases, but I do know that there were issues with tk keeping up with Apple's breaking changes to its graphics system.
2 There is no standard for how selected text is indicated. Looking at more examples, there is not even agreement as to whether selection should be indicated by B) only changing the background or C) changing both or D) in particular, switching light and dark in foreground and background. Possibility A is no visible indication of selection (see below).
3 I do not consider the current noted behavior in IDLE, C or D, buggy. Changing to B would have to be tested across systems and would bring up the issue of whether the selection background 'works' with all the different foregrounds.

I don't believe that IDLE removes and restores syntax tags as selection is added and removed. Tk exposes selections as a special built-in undeletable tag. The standard behavior of tags is that the most recent tag wins. Thus the current behavior is exactly as I expect, with IDLE and tkinter having nothing to do with selections be added and removed by mouse and key action.

To find out more, I experimented with 4 variations of 'raw' tkinter code.

from tkinter import Tk, Text
r = Tk()
t = Text(r)
t.pack()
t.insert('insert', 'Hello gregarious Jim')
#t.tag_config('red', background='white', foreground='red')
# Selection does not change 'gregarious'.
t.tag_config('red', foreground='red')
# Selection changes background only.
# In first, cannot see boundaries of selection unless both outside.
t.tag_add('red', '1.6', '1.16')
# Default selection on Windows 10 is white on blue.
t.tag_config('sel', background='lightgray', foreground='blue')
# Adding this does not affect notes above.
# TBD. What if change default for widget?

A tag with both foreground and background configured can be selected (as in 'delete selection', ^X, deleting), but there is no visible indication of the extent of the selection. This, option A above, is not useful. A tag with only foreground configured changes background - option B. IDLE configures both for all tags. There is one IDLE tag that behaves like option A -- the checkpoint tag. All others, applied by the colorizer, act like option C -- selection overrides both fore and background. To make the example more like IDLE, I added the following, based on a statement in colorizer.py:

text.config(
    foreground='blue',
    background='pink',
    insertbackground='pink', # cursor
    selectforeground='green',
    selectbackground='yellow',
    inactiveselectbackground='yellow'
    )

The result is that that tag_add no longer colors 'gregarious'. I cannot investigate more now.

@arhadthedev I don't understand the relevance of grammar tree processing to colorizing.

[ss3387]

I am not sure if this is the right solution to this issue but I asked a 'similar' question in stack overflow recently here. The person who answered said to set the foreground of the text widget to "" which turned out to work for me.