Trimming Spaces

In newer respository version (wish8.7) a bug has been introduced, trying to fulfill bug item 1082213. The author is writing:

Space characters that would go at the beginning of the next line are allocated to the current line. This gives the effect of trimming white spaces that would otherwise be seen at the beginning of wrapped lines.

But trimming spaces is obviously erroneous, in normal text (in general it's not Markup) the space has the same meaning as any other character and cannot be trimmed, this is like trimming an 'a'. See this example:

We assume that the user mistakenly typed two spaces instead of one between last two words. And here is the result:

wish8.6		wish8.7		revised

wish8.6 has a bad layout, and is showing the superfluous (first) space at end of line 2, although it is not visible, it's possible to set the cursor after this space. With wish8.7 the user cannot see the mistake, because the typo has been trimmed. So he will save the text with typos, (nearly) no chance to make corrections. It's obvious that only the revised version is showing the content satisfactorily (with this example). Any space should be visible. It's clear that one space is used for line wrapping. And if the user likes to trim spaces, he may do this explictly. And the revised version offers the new option -spacemode, which allows trimming of spaces when spaces are not relevant.

Now try this script:

Use the arrow keys to move the insert cursor forward and backward, the handling is unreasonable with wish8.7.

Bug report 1082213 is invalid, this is not a bug. This bug item is referencing a thread which compares the behavior of the text widget with the behavior of the label widget. It's clear that the label widget may have a different behavior (though this is no obligation), the label widget is not a text widget, and the text widget is not a label widget.