Just to ease the suspense left at the end of the bug description,
using a caret to represnt the position of the caret,
(*) comment as displayed : competi^ors ate them
(*) type "t"
(*) result expected      : competit^ors ate them
(*) result observed      : competti^ors ate them

This behaviour seems to have been introduced in the ranged covered by
the daily dbgutil bibisect.  But dE reported seeing this in
LibreOffice version 4.2.5.2 release.  dE, are you sure about that?

I am setting platform to "Linux (All)", where I see the problem.  dE,
if you see it in a different environment, please set platform "All".


Bibisecting, I see from `git bisect good`:

    cbed87a20815ddd7af3afb31aa2fc7a29383ce89 is the first bad commit
    commit cbed87a20815ddd7af3afb31aa2fc7a29383ce89
    Author: Miklos Vajna <vmiklos@collabora.co.uk>
    Date:   Mon Jul 14 09:12:54 2014 +0200

        2014-07-14

    :100644 100644 e1fc757cdd55bdb9ef99cf03fa94bf273d3d4d89 31508c1bfc531c49bd73b38b184179cff25888fd M	build-info.txt
    :040000 040000 6de0846dd12d8771050276833a090bd4f845e838 98aff976032316877f486cf07bac7a0220ff532b M	opt

and from `git bisect log`:

    # bad: [df3584a60c00673e5f5b4b09bfbe1be300a144fc] 2014-09-07
    # good: [b3130c846de5cf1b4be48b48dfc780bb369549fa] 2014-05-21
    git bisect start 'origin/master' 'oldest'
    # bad: [cbed87a20815ddd7af3afb31aa2fc7a29383ce89] 2014-07-14
    git bisect bad cbed87a20815ddd7af3afb31aa2fc7a29383ce89
    # good: [35c0f684cef2fdbe270ff9d3b37169731ef61033] 2014-06-17
    git bisect good 35c0f684cef2fdbe270ff9d3b37169731ef61033
    # good: [863ef6c16b358103654ddcae453401e7a5c4a69e] 2014-06-30
    git bisect good 863ef6c16b358103654ddcae453401e7a5c4a69e
    # good: [329f284cf0438c52859ca4facd4f4950594352e1] 2014-07-07
    git bisect good 329f284cf0438c52859ca4facd4f4950594352e1
    # good: [aa277ae886d6e38dad4a356ebd6a1d6c96f5f084] 2014-07-10
    git bisect good aa277ae886d6e38dad4a356ebd6a1d6c96f5f084
    # good: [8c3f4fcfdbbd570efea0a46c219eab24fd5db44c] 2014-07-12
    git bisect good 8c3f4fcfdbbd570efea0a46c219eab24fd5db44c
    # good: [a5750a3c0c5d3b975a787f844d7ba60db53a765e] 2014-07-13
    git bisect good a5750a3c0c5d3b975a787f844d7ba60db53a765e
    # first bad commit: [cbed87a20815ddd7af3afb31aa2fc7a29383ce89] 2014-07-14

bisection is wrong, because the bug can be reproduced with good: [a5750a3c0c5d3b975a787f844d7ba60db53a765e] 2014-07-13, too.

The problem is that caret jumps over "ti" in one step, when you press -> once, it is "logically" after "t". When you press  ->  once more caret stands still, but the it is after "i".

Bisection did not make much sense in this case, it turned out that eb79c13a809c2edf99042b114ede512ebd4c2273 is the first bad commit
commit eb79c13a809c2edf99042b114ede512ebd4c2273
Author: Caolán McNamara <caolanm@redhat.com>
Date:   Thu Oct 10 10:12:44 2013 +0100

    update local font.conf for Calibri/Carlito Cambria/Caladea
    
    Change-Id: I9391876f2b09750ad5f44483f489743581948d21

Maybe the substituted font (Carlito) reports wrong metrics to LibreOffice.

@Andras

You are exactly right.  I should have been more willing to believe the
bug description.  Then I would not have reported bibisect results
which are pure noise, with "good" and "bad" depending on nothing more
than how I moved the caret before typing the "t".  Desk, meet forehad.

@all

The comment is in font Calibri, but the combination of LibreOffice and
my setup provoke the font control to show mouseover message "Font
name.  The current font name is not available and will be
substituted."  When the (substituted?) font displays "ti" with a
ligature, the caret as rendered does not move inside the ligature;
without a ligature, the bug is not evident.  In the buggy version,
text within a cell behaves the same way as the comment.

For comparison, in a bibisect version where Calc displays the bug,
Writer displays the same "... substituted." mouseover for font
Calibri, there is a ligature "ti", but the caret happily shows itself
within the ligature when it is logically within the ligature.

I have rewritten the bug summary in line with my observations here.
Improvements welcome, of course.

Terry.

Further to results from daily dbgutil bibisect:

    test       date        commit   source hash
    ---------  ----------  -------  -----------
    last good  2014-07-13  a5750a3  dde00f1
    first bad  2014-07-14  cbed87a  f445ae5

The below is the commit at which I see the issue appear.

(*1 Comment 5 appears to be a red herring - it's easy to mistake this, but to reproduce properly you have to make sure using the cursor keys that the actual (not visible) position of the cursor is inside the ligature)
(*2 The previous suggestion of commit eb79c13a809c2edf99042b114ede512ebd4c2273 perhaps applies if there is an externally packaged Carlito available? The end result is of course the same)


Adding Cc: to caolanm@redhat.com; Can you tell if this is our bug or somehow an issue within the font itself?


commit bde5e683286096b9255254b28a862e519d57f547
Author: Caolán McNamara <caolanm@redhat.com>
Date:   Wed Oct 23 14:57:32 2013 +0100

    bundle Carlito and Caladea
    
    Change-Id: Ibb68ad33764bcbab88e68c35805a00287177a5c8