It was discovered that when something is copied to the Clipboard in FAR (e.g. file names from FAR's panels), it leads to corrupted sumbols in Notepad++'es Clipboard panel.
To me, the issue looks rather like a bug in Notepad++, but the author of Notepad++ asked to confirm this with FAR team.
It is reproducible with both 64-bit and 32-bit FAR3.
Short technical details: Notepad++'s Clipboard panel supports both binary data and text data while reading from the Clipboard. Almost every application puts text data to the Clipboard, and Notepad++'es Clipboard panel handles it flowlessly. However, FAR seems to put binary data to the Clipboard, and it confuses Notepad++'es Clipboard panel.
Here is the full discussion of this issue:
https://github.com/notepad-plus-plus/no ... sues/13817
Could you take a look at this and shed some light?
FAR vs. Notepad++ : copying to Clipboard
- zg
- zero-gravity
- Posts: 5999
- Joined: Tue 15 Mar, 2005 17:36
- Location: riga
- Been thanked: 178 times
- Contact:
FAR vs. Notepad++ : copying to Clipboard
it depends. far uses n++ clipboard format "Notepad++ binary text length" to store text length. looks like n++ loads/stores length in bytes, but far in symbols. if n++ really stores length in bytes then bug is in far.
- zg
- zero-gravity
- Posts: 5999
- Joined: Tue 15 Mar, 2005 17:36
- Location: riga
- Been thanked: 178 times
- Contact:
FAR vs. Notepad++ : copying to Clipboard
but I am nt sure about this fix. here CF_NPPTEXTLEN interpreted as length in symbols without trailing zero. but here as length in bytes including trailing zero. if you do Edit->Paste Special->Copy Binary Content you get the same trash bytes without far.
FAR vs. Notepad++ : copying to Clipboard
There is a preliminary pull request where Notepad++ is about to go the wchar_t way, i.e. exactly how FAR Manager was doing before 6168.
If this pull request is approved and merged, then the changes in 6168 will need to be reverted once the new version of Notepad++ is released. I'll keep you updated.
If this pull request is approved and merged, then the changes in 6168 will need to be reverted once the new version of Notepad++ is released. I'll keep you updated.
FAR vs. Notepad++ : copying to Clipboard
OK, Notepad++ 8.5.5 RC is out:
http://download.notepad-plus-plus.org/r ... /8.5.5.RC/
The CF_NPPTEXTLEN behavior has officially been changed to the one used by FAR before 6168. So, probably, the corresponding code change for CF_NPPTEXTLEN needs to be reverted in FAR.
http://download.notepad-plus-plus.org/r ... /8.5.5.RC/
The CF_NPPTEXTLEN behavior has officially been changed to the one used by FAR before 6168. So, probably, the corresponding code change for CF_NPPTEXTLEN needs to be reverted in FAR.
Last edited by DV on Sun 06 Aug, 2023 13:32, edited 1 time in total.
- DrKnS
- Posts: 6114
- Joined: Thu 04 Aug, 2005 06:44
- Location: Kyiv
- Has thanked: 12 times
- Been thanked: 426 times
FAR vs. Notepad++ : copying to Clipboard
DV, as far as I can see, NP++ renamed their format from "Notepad++ Binary Text Length" to "Notepad++ Binary Length" and it is now always associated with CF_TEXT data.
Moreover, in this case CF_TEXT contains UTF-8 data.
In other words, we cannot use their format to simply store the text length.
To do it properly we have to also store/read UTF-8-encoded data, which simply isn't worth the effort.
The best way at this point is to remove everything NP-related from Far.
Moreover, in this case CF_TEXT contains UTF-8 data.
In other words, we cannot use their format to simply store the text length.
To do it properly we have to also store/read UTF-8-encoded data, which simply isn't worth the effort.
The best way at this point is to remove everything NP-related from Far.