In the below examples, I am wondering if this is a Tk bug, or a user bug. One could argue that a programmer should not (by program) create a selection where the cursor is not also placed in or adjacent to the selection. So, I'm wondering if a ticket should be created for this.

Each of the 3 texting widgets,

entry
ttk::entry
text

say in the manual:

"If any normal printing characters are typed (in an entry), they are inserted at the point of the insertion cursor."

However, this is not always the case. The below 5 example programs demonstrate that when the program creates a selection, moves the insertion cursor outside the selection (or just leaves it where it was), and gives focus to the widget, typed characters (e.g. 123) will sometimes replace the selection, and sometimes not. If it replaces the selection, the inserted characters are not where the cursor was.

Note that interactive selections (user does the selection, not the program) don't apply since the cursor will always end up adjacent to the selection. I believe this is why this behavior may not have been noticed before.

The reason for these behaviors can be seen in the binding for <Key> which results in calls to several different procs.

Note that more specific bindings, such as <Key-BackSpace> take precedence and also have inconsistent results. The 2 entry's will delete the selection, but in ttk::entry the cursor is also moved. In text, it will delete 1 char at a time until it gets to the selection. Then it deletes the entire selection. However, the manual for text says:

"Backspace and Control-h delete the selection, if there is one in the widget. If there is no selection, they delete the character to the left of the insertion cursor."

And in addition, Control-h never deletes the full selection only 1 character at a time.

Examples (run each separately - I paste them into a windows console or rlwrap of wish):

ttk::entry .te -textvariable tevar ;# will delete selection
pack .te
set tevar "abc def ghi"
..te selection range 0 3
..te icursor end
focus -force .te

entry .te -textvariable tevar ;# will not delete selection
pack .te
set tevar "abc def ghi"
..te selection range 0 3
..te icursor end
focus -force .te

entry .te -textvariable tevar ;# will delete selection
pack .te
set tevar "abc def ghi"
..te selection range 0 3
..te icursor 0
focus -force .te

text .t ;# will not delete selection
pack .t
..t insert 0.0 "abc def ghi"
..t tag add sel 1.0 1.3
..t mark set insert end
focus -force .t

text .t ;# will delete selection
pack .t
..t insert 0.0 "abc def ghi"
..t tag add sel 1.0 1.3
..t mark set insert 1.3
focus -force .t

Am 04.09.2023 um 23:59 schrieb et99:
> In the below examples, I am wondering if this is a Tk bug, or a user
> bug. One could argue that a programmer should not (by program) create a
> selection where the cursor is not also placed in or adjacent to the
> selection. So, I'm wondering if a ticket should be created for this.
>
> Each of the 3 texting widgets,
>
> entry
> ttk::entry
> text
>
> say in the manual:
>
> "If any normal printing characters are typed (in an entry), they are
> inserted at the point of the insertion cursor."
>
>
> However, this is not always the case. The below 5 example programs
> demonstrate that when the program creates a selection, moves the
> insertion cursor outside the selection (or just leaves it where it was),
> and gives focus to the widget, typed characters (e.g. 123) will
> sometimes replace the selection, and sometimes not. If it replaces the
> selection, the inserted characters are not where the cursor was.
>
> Note that interactive selections (user does the selection, not the
> program) don't apply since the cursor will always end up adjacent to the
> selection.  I believe this is why this behavior may not have been
> noticed before.
>
> The reason for these behaviors can be seen in the binding for <Key>
> which results in calls to several different procs.
>
> Note that more specific bindings, such as <Key-BackSpace> take
> precedence and also have inconsistent results. The 2 entry's will delete
> the selection, but in ttk::entry the cursor is also moved. In text, it
> will delete 1 char at a time until it gets to the selection. Then it
> deletes the entire selection. However, the manual for text says:
>
> "Backspace and Control-h delete the selection, if there is one in the
> widget. If there is no selection, they delete the character to the left
> of the insertion cursor."
>
> And in addition, Control-h never deletes the full selection only 1
> character at a time.
>
> Examples (run each separately - I paste them into a windows console or
> rlwrap of wish):
>
> ttk::entry .te -textvariable tevar ;# will delete selection
> pack .te
> set tevar "abc def ghi"
> .te selection range 0 3
> .te icursor end
> focus -force .te
>
> entry .te -textvariable tevar ;# will not delete selection
> pack .te
> set tevar "abc def ghi"
> .te selection range 0 3
> .te icursor end
> focus -force .te
>
> entry .te -textvariable tevar ;# will delete selection
> pack .te
> set tevar "abc def ghi"
> .te selection range 0 3
> .te icursor 0
> focus -force .te
>
> text .t ;# will not delete selection
> pack .t
> .t insert 0.0 "abc def ghi"
> .t tag add sel 1.0 1.3
> .t mark set insert end
> focus -force .t
>
> text .t ;# will delete selection
> pack .t
> .t insert 0.0 "abc def ghi"
> .t tag add sel 1.0 1.3
> .t mark set insert 1.3
> focus -force .t
>

Thank you, Eric, for the great analysis.
Test hint: past the test scripts for setup and then press:
- a key
or backspace
or ctrl-backspace

Could you open a bug report for this?
At least, the documentation may be changed.
And a unified approach for all entry widgets would be great.

Take care,
Harald