Very long line of code and multi-caret bug (is it?)

[Curculigo]

I had never intended to trigger multi-caret. I performed a scroll-bar drag (see #543), placed the mouse pointer in the position I wanted to edit and have never made a double click, Ctrl + D, or Ctrl + Shift + D. The fact is, I didn't see any other mouse cursors, either. But when I started to edit, I found it was doing the edit in another location on the line, not the location of my mouse cursor. Esc didn't help. I pressed Ctrl + Z like crazy and finally it allowed me to be back to the state before I did the scroll-bar drag.

[SpartanJ]

Ctrl + Click creates a new cursor, 99% chances this is what happened.

[SpartanJ]

Escape cancels the multi-cursors btw.

[Curculigo]

Ctrl + Click creates a new cursor, 99% chances this is what happened.

I didn't press Ctrl.

[Curculigo]

Escape cancels the multi-cursors btw.

If it was really multi-caret. There were no other cursors. If there was, I could see it. It was doing the editing in another location different from the mouse cursor. This location didn't have any mouse cursor. Esc didn't help. I tried to add real multi-caret to try to see if really multi-caret was the culprit. Didn't work either. I can move the mouse cursor to any location I want, but the editing was still being done at that location. I have never chosen that location. It seemed it was somehow picked by ecode when I moved the horizontal scroll bar. Only Ctrl + Z can help me to escape it.

[Curculigo]

Another possibility: Something to do with the word wrap margin? I have never used the word wrap feature, though. What is the default word wrap margin? 80 or 120? These values are the most common.

This line of code is indeed not that long, so the word very is a bit misleading. I can't remember if the location it was doing the editing was in the word wrap margin or not.

[Curculigo]

This issue is not always happening. I don't have any way to accurately reproduce it. But it's annoying.