UVviewsoft forums

It seems this only happens with word-wrapped files: drag the mouse and press Alt to mark a column. The marked text in the column obviously jumps over (ie doesn't mark) physical lines that are continuation lines of a longer logical line. At some point this detection misfires and suddenly parts of continuation lines are marked which should not be marked. If I continue dragging there comes a point when Cud gets back to looking correct but sooner or later it misfires again. It's kinda hard to explain but obvious if you mark a longer column in a long word-wrapped file with many continuation lines.

I just updated wiki--
https://wiki.freepascal.org/CudaText#Wh ... _sometimes

I had seen this section (and your recent change) but that's not describing the same thing.

What that section describes is simply a cosmetic problem. My problem is not cosmetic: if I copy the marked column when it's displayed correctly I get the expected column text in the clipboard. But when the problem happens I definitely and reproducibly get a wrong result in the clipboard.

EDIT: Steps to reproduce.
1. Mark the full text of my post no 1.
2. Copy this ten times into an empty editor.
3. Word wrap must be on.
4. Move the mouse to the "t" of "this" in the very first line.
5. Begin alt dragging mouse down. The moment the mouse pointer reaches the second physical line (ie the first continuation line), the marked column jumps.
6. When it reaches the first physical line of the second logical line, all is OK.
7. When the mouse pointer reaches the second physical line of this line, the marked column jumps again.
And so on. If you copy the marked column block you will see that the copy is correct when the pointer is in the first physical line and wrong otherwise.

EDIT2: At least Cud can be made to do the right thing, so it's more an inconvenience than a real bug. AkelPad is completely broken in this respect.

hm, I don't see wrong text in clipboard. I selected in 1st line from "this" to "doesn't" ("doesn't" on continuation like) / copied / pasted / result ok.

I seee visual bug - Cud fills the area after 1st wrapped line.

Hm... that'll be great fun, to reproduce this baby.

Alexey wrote:hm, I don't see wrong text in clipboard. I selected in 1st line from "this" to "doesn't" ("doesn't" on continuation like) / copied / pasted / result ok.

Well, I definitely do. I just double-checked: I start with the "t" in "this", move to the "s" in "this" and then stop on the "a" of "logical" in the next line (in my case, your window size will be different). I copy and get:

this only happens with word-wrapped files: drag the mouse and press Alt to mark a column. The marked text in the column obviously jumps over (ie doesn't mark) physical lines that are continuation lines of a longer logica

I checked with no lexer and various text lexers, no difference.

Alexey wrote:I seee visual bug - Cud fills the area after 1st wrapped line.

Exactly. And what is filled by Cud is what I get in the clipboard. If it were only for the visual effect, I would say it's just a cosmetic bug and not that important.

EDIT: I am wondering whether it's worth much of your time to investigate this (or are you a perfectionist ). If a user knows how, they can avoid the problem and if not they can always switch off word-wrap, do the column mark and copy and then switch word-wrap back on.

yes, I got the same selection from "this" to "a" in "logical". same copied text.
and it is OK.
it is the same logic I wrote in wiki.

Here is the program's logic in all these cases (with full-width characters and with word-wrapped lines). Program calculates (line1, column1) text position of column block left-top edge. Then program calculates (line2, column2) text position of column block right-bottom edge. Then program selects characters in range column1...column2 in all those affected lines line1...line2. And this program logic produces so weird look in word-wrapped mode.

because you selected from X1 to X2 in the single line.

Alright... but when the mouse pointer then wanders into the second line, all of sudden everything's OK. It's puzzling that Cud gets this right but doesn't get right in the same line.

Whatever... probably best to close this issue.

And perhaps you could put up a couple of pics (or even a short animated gif) with a clear explanation as to what happens and how to avoid it. I know it, you know it but a newcomer might be puzzled.

I don't get what is bad. it is ok even in the same line (in continuation part). it is the same logic as wiki tells.
maybe you can show screeenshots with text above..

updated wiki, added picture
https://wiki.freepascal.org/images/5/52 ... -weird.png
Hope it is good info.
what to add more?

There are two different issues: a) what is happening (and what is currently the logic of the program) and b) what should IMHO be happening.

I can live with a) as I can deal with it and if it stays that way, that's fine. The image explains what is to be expected but perhaps you could mention that what is copied is not what (at least some) users expect. Because...

b) I am one of those who think a line is a line and a column is a column. That a logical line is folded into continuation lines has in my view nothing to do with the logic of columns. To take the image from the Wiki: I start alt-dragging with the "I" of "Ipsum" to the "m" of "reprimique". Next I move the pointer down into the next physical line to the blank behind "percipitur" and my firm expectation is (or has been) that NOTHING MORE GETS SELECTED when I do this because it's all on the same logical line. The part between "Ipsum" and "reprim" was selected by the first move and when moving down into the continuation line this selection should in my view not change. Only when the mouse pointer reaches the "b" of "liber" in the next LOGICAL line everything between "Ipsum" and "lib" would be selected. And so on.

In other words: the selection in the first physical line defines once and for all which and how many characters (ie start and end point) are selected per logical line, not the position of the mouse in continuation lines further down.

However, as already mentioned I agree that this probably too much work for little effect so if a) remains the way Cud does it that's OK.