@MSGID: 1@dont-email.me> 9e1b79a3
@REPLY: 1@dont-email.me> d0760fd2
@REPLYADDR Harald Oehlmann <wortkarg3@yahoo.com>
@REPLYTO 2:5075/128 Harald Oehlmann
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 1@dont-email.me>
@RFC-References: 1@dont-email.me>
@TZUTC: 0200
@PID: Mozilla/5.0 (Windows NT 10.0; Win64; x64;
rv:102.0) Gecko/20100101 Thunderbird/102.15.0
@TID: FIDOGATE-5.12-ge4e8b94
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  
> which results in calls to several different procs.
> 
> Note that more specific bindings, such as  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
 --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.15.0
 * Origin: A noiseless patient Spider (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441