Compare Tool: Strg+Cursor is depending on the Encoding

[TMg]

When comparing two text files with "Compare By Content..." I found a Bug: When turning on "Edit mode" and pressing Ctrl+Cursor left and Ctrl+Cursor right the text cursor acts different with UTF-8 encoding and with ANSI encoding. With UTF-8 encoding when pressing Ctrl+Cursor key the text cursor only jumps to the end of words followed by a space. With ANSI encoding the text cursor jumps to the start of words. And it jumps to a lot more boundaries, not only to spaces.

Other programs do this similar to what the compare tool does with ANSI encoding. That's what I expect.

Example:
<example><tag>Example Text Word</tag></example>

Word boundaries with ANSI encoding:
<|example><|tag>|Example |Text |Word</|tag></|example>

Word boundaries with UTF-8 encoding:
<example><tag>Example| Text| Word</tag></example>

Deutsch: Beim "Vergleich nach Inhalt..." von zwei Textdateien fiel mir ein Bug auf: Im Bearbeitungsmodus verhalten sich die Tastenkombinationen Strg+Pfeil links und Strg+Pfeil rechts mit UTF-8-Codierung anders als mit ANSI-Codierung. Mit UTF-8-Codierung springt der Textcursor mit Strg+Pfeiltaste nur an Wortenden direkt vor Leerzeichen. Mit ANSI-Codierung springt der Textcursor an Wortanfänge. Es werden auch wesentlich mehr Stellen angesprungen, nicht nur bei Leerzeichen. Das Verhalten mit ANSI-Codierung ist das, was ich aus anderen Programmen kenne und erwarte.

[petermad]

I can confirm this bug.

[ghisler(Author)]

This isn't a bug, the two functions are just completely different implementations. The problem with UTF-8 is to correctly detect word separators.

[TMg]

I know this are different implementations. That's the problem. Both should work the same way. At least for the characters that are the same in both encodings.