#3491 CR(0x0D) can be pasted into buffer via clipboard

Kazutoshi Satoda

Reproduction recipe:
- Do a HyperSearch.
- Select a node(s) in HyperSearch Results.
- Copy it. I use Ctrl+C here.
- Paste it into a buffer. I use Ctrl+V here.

Now there are CR(0x0D) characters at the ends of pasted lines. You can
find it by moving cursor at an end of line, or by using WhiteSpace

jEdit trunk r19118 (4.5pre1)
JDK 6u23
Windows XP

This also happens on copy&paste from Console and ErrorList plugins.

I verified that this also happens with jEdit 4.4.0, and doesn't happen
with jEdit 4.3.2 .


  • Wormbo

    There also seems to be another flavor of this bug: Pasting from an external application (UnCodeX, you can find it here on SF.net) into a jEdit buffer, I get weird "non-linebreaks". I think what happened there is that the application copied only LF to the clipboard, while the jEdit buffer was set to CRLF. (I'll file a bug report on that other application as well as it shouldn't have copied LF-only from CRLF files under Windows, but that's besides the point.)

    IMHO jEdit should normalize any line breaks in the pasted text to the line break style of the buffer being pasted into.

  • I'm unable to reproduce this problem with hypersearch or UnCodeX, maybe you have some samples for UnCodeX so that I could reproduce that ?

  • Did you try on Windows? This is likely a Windows specific issue because
    it seems a result of processing a text with CRLF as newlines.

  • I tried on Windows 7 32 and 64 bits

  • I just tried with Windows XP and unable to reproduce it

    • status: open --> pending-works-for-me
  • does it still happens ?

    • status: pending-works-for-me --> open-works-for-me
  • I verified at r19563; other environments are not changed. Nothing
    changed; the problem happens with trunk and 4.4.x, doesn't happen with

  • Wormbo

    Using daily version 2011-08-19_12-01-37 I've just seen the problem again, but after copying some other text (or the same text again), it no longer happened.

  • I have not idea of how to reproduce that and never saw that bug

    • assigned_to: kpouer --> nobody
    • status: open-works-for-me --> open
  • Steps to reproduce:

    1. Open jedit with no buffers
    2. type x in empty buffer
    3. search for x (checked hypersearch)
    4. right click on node: x (1 occurence), copy to clipboard
    5. paste it after x in your dirty buffer

    You will get something like that:

    Notice that travelling with right arrow you stop at the end of lines like an additional character was present there. Normally you skip the new line with one right arrow, here 2 are needed.

    My buffer options: line separator: dos/windows

    jedit 4.4.2, XP, jre 1.6.0_22

    • assigned_to: nobody --> kpouer
    • status: open --> closed-fixed
  • Fixed in rev 20576 and 20577

    In fact the copy of hypersearch node was adding line.separator to the clipboard.
    In Windows it is \r\n and when pasting to the textarea the \r is copied.
    But from what I see, the Windows applications do not copy the \r
    Notepad or Wordpad only copy a \n so now jEdit will do the same.

    • summary: Copying from HyperSearch Results brings CR(0x0D) into buffer --> CR(0x0D) can be pasted into buffer via clipboard
    • status: closed-fixed --> open
  • I think it is fixed in rev 20594 could you check it works for you ?
    I was unable to reproduce the bug with the Console or ErrorList

    Another thing :
    in the cleanup code there was this workaround from 2004 !

    // broken Eclipse workaround!
    // 24 Febuary 2004
    line = line.substring(0,
    line.length() - 1);

    I think that could be removed now, don't you ?
    I tried with Eclipse to copy and there was no such character, but maybe it happens on special conditions ?

    • status: open --> closed-fixed
  • Verified with trunk r20632. Thank you.

    Further discussion will go on jedit-devel.

    • status: closed-fixed --> open-fixed
    • status: open-fixed --> closed-fixed