#1579 PasteRectangular at end of italic-formatted lines adds one too many characters

Bug
closed-wont-fix
scintilla (292)
5
2014-02-13
2014-02-13
No

Here's how to reproduce:

Modify css.properties like so:

# Comment
- style.css.9=$(colour.code.comment.box),$(font.code.comment.box)
# Comment
+ style.css.9=$(colour.code.comment.box),$(font.code.comment.box),italics

Now create a CSS file like so:

body {
/
abcde
abcde
abcde
abcde

/
color: inherit; #fbf99d;
-moz-appearance: http://www.theninhotline.com/archives/news.images/tds.jpg;
}

There is a space at the end of the first "abcde", but not any others

Rectangular select and copy a column of letters in all the "abcde"'s, say "c".

Move to the end of the first line. Paste.

Expected output (those '.'s are spaces)

abcde.c
abcde.c
abcde.c
abcde.c

Actual:
abcde.c
abcde..c.
abcde..c.
abcde..c.

Why: the PasteRectangular code in Editor.cxx converts the position to an XOffset.

For example, in the above code, in my view, the position at the end of that
first line is pos 25, translated to xInsert 74

On the second line, before pasting, the xPosition is 66, so scintilla inserts
a space, moving the xPosition to 72. Not enough, so it inserts one more
space, moving xPosition to 80, and breaking out of the loop, as we've reached/passed
xPosition.

I gather the problem is that the initial xInsert looks at the upper-part of the
character, while

I haven't figured out why I get the space at the end of each line, but figure
it's for similar reasons.

Here's some debug output:

EOL padding by XFromPosition(sel.MainCaret()):154 : xInsert:162
XFromPosition(sel.RangeMain().caret):154
pdoc->InsertChar(sel.MainCaret():72, ' ')
after inserting, sel.MainCaret():73
... and XFromPosition(caret):160
... XFromPosition(sel.RangeMain().caret):160 # Note: both positions are the same
pdoc->InsertChar(sel.MainCaret():73, ' ')
after inserting, sel.MainCaret():74
... and XFromPosition(caret):168
... XFromPosition(sel.RangeMain().caret):168
i: 2, xInsert:162

So we start at X-point 154. We want to be at X-point 162

We insert a space and move over it, but that moves us only to X-point 160

We insert one more space, and now are moved to X-point 168

The first space moved us by 6 pixels, but the second moved us by 8.
In a monospace font, this seems wrong.

Discussion

  • Eric Promislow

    Eric Promislow - 2014-02-13

    Two of the paragraphs in the bug were due to different code. They should
    have been like this:

    For example, in the above code, in my view, the position at the end of that
    first line is pos 50, translated to xInsert 162

    On the second line, before pasting, the xPosition is 154, so scintilla inserts
    a space, moving the xPosition to 160. Not enough, so it inserts one more
    space, moving xPosition to 166, and breaking out of the loop, as we've reached/passed
    xPosition.

     
  • Eric Promislow

    Eric Promislow - 2014-02-13

    This is with Scite 333, btw

     
  • Neil Hodgson

    Neil Hodgson - 2014-02-13

    The sample appears to have been munged by the bug tracker code: there are no comments. Adding asterisks to the end of line 2 and the start of line 8 to make the abcde section a comment.

    Can't reproduce this on Windows or OS X using standard settings. Its possible that virtual space options could affect this so have you changed those? Have you set different base fonts or are using monospaced mode? Another possibility is that fractional positioning (as used with Direct2D or Cocoa) will have non-integral positions so may round badly.

    Your tracing information may indicate that there is a large difference between the default style (style 0) and the comment style. New text is inserted as style 0 and then later styled to comment style by lexing. If style 0 is significantly smaller than the comment style then the position after pasting one character will be less than a styled character width, leading to adding an extra space.

    It would be possible to lex after each character insertion but that would be slow - potentially problematic for large pastes or long lines. It may be possible to have a mode that treated text as truly monospaced during paste but that is likely to cause unexpected output in some cases. Insertions could inherit the style value from the previous character but that may just move the issue to other situations.

     
  • Eric Promislow

    Eric Promislow - 2014-02-13

    body {
    [slash][star]
    abcde
    abcde
    abcde
    abcde
    [star][slash]

    Your explanation now makes sense -- the characters are inserted as plain-text,
    and they occupy less horizontal space than when they're italicized.

    I'm fine if you make this bug as "wontfix" -- I don't consider it a serious
    problem, and lexing on each inserted character could be very expensive.

     
    • Neil Hodgson

      Neil Hodgson - 2014-02-13

      OK, closed-wont-fix.

       
  • Neil Hodgson

    Neil Hodgson - 2014-02-13
    • labels: --> scintilla
    • status: open --> closed-wont-fix
    • assigned_to: Neil Hodgson
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks