bizarre editor behavior in 8.02 (win32)

[dmoore]

I was just typing a flat text file in CB (file extension .txt), switched windows to my web browser, switched back to CB only to find that every line longer than about 50 characters suddenly became invisible (text replaced with spaces). I closed the file and opened in VIM and the file was fine. I reopened in CB and lines were still missing. I played around with editor settings closed and opened a few files and things seem to have returned to normal, but I'm a little nervous about continuing to edit with CB. I don't know if my older CB settings files (from a 3+ month old nightly) were the culprit.

Has anyone else had experienced this?

[Ceniza]

I saw something similar today, even though I was editing a html file of a single line which was more than 200.000 characters long (and without code highlighting). When I tried to go to the beginning of the line the text was full of empty spaces, and moving with the arrows drew text over other text. It looked really strange, dude... and no... I wasn't high

I think it's a Scintilla problem.

[JGM]

html file of a single line which was more than 200.000 characters long

:shock:

[MortenMacFly]

html file of a single line which was more than 200.000 characters long

:shock:

Yes... that's the kind of stuff Ceniza is working on since he is over here, in Europe. ;-)

[MortenMacFly]

Has anyone else had experienced this?

Sorry, but: No.

I closed the file and opened in VIM and the file was fine. I reopened in CB and lines were still missing.

That *is* weired. Just to make sure: You are working on Windows or Linux? (VIM is available for Windows, too.) And did you close C::B for re-openeing the file before? Or did you re-open in the same running instance?

I don't know if my older CB settings files (from a 3+ month old nightly) were the culprit.

...depends. I (in fact) clean the file every now and then, especially if features are introduced that affect the configuration. So just try! ;-)

Anyways - as no data got lost I would agree with Ceniza that this is just a painting issue and this (like Ceniza said) would definitely point to (wx)Scintilla. I had in mind to update this component after the release (and core dev discussion) anyways... I am working for ~1 year with the latest version successfully.

[Jenna]

It's definitely a scintilla-problem. I just tested a larg one-line-.js-file in C::B and Scite.

And the behaviour is similar and sometimes very strange, like suddenly showing the line two times with a carte that's two lines high, or writing parts of the text at the same place, so that they get unreadable, or showing the text like blanks.

[Ceniza]

Sir Thomas found a way to reproduce it:

Create a new empty file (you don't need to save it) and write a long line, like aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa. Now, select that and then press Ctrl+D and keep it pressed for a while (or just copy and paste it over and over again), so it produces a huge line. At some point the selected portion will continue visible and selected, but the new text will be invisible.

[MortenMacFly]

Sir Thomas found a way to reproduce it:

It seems it's not Sir but Master. ;-)

Create a new empty file (you don't need to save it) and write a long line, like

Confirmed with latest (wx)Scintilla here, too. As you can see: The limit is a 64k border. As soon as the line is more than 64k this will happen.

Seems like another "64k is enough" issue... :lol: :lol:

[MortenMacFly]

LOL! It's fun playing around with a 65536 column line and a 65537 column line... Really funny. :lol: :lol: :lol:

[MortenMacFly]

Ok... it's even worse. I guess I know why - the reason is WX! :?
wxScintilla works internally with wxCoord. If you look into wx/defs.h you will read:

Code Select Expand

typedef int wxCoord;
Dammed. Nothing we can do about therefore. :| :cry:

Edit: Well... we could by e.g. changing this typedef to long and adjusting the other million parts of WX if needed and then provide our own WX version... How about that? :lol:

[Jenna]

As I wrote, I tested it also in Scite, and Scite is build without wxWidgets.
And the behaviour is similar.

And what's more, I can reproduce the problem with much less than 64k chars.
Even with less than 4k chars.
Beginning with 3795 the caret is no longer placed after the char, but right in the middle of it cutting of the rest.
If I then press the left key the caret is not erased when jumping to the new char, so multiple black lines (I don't want to say caret to them) appear.

Here is a snapshot with multiple "carets" (the first one) and one that shows the behaviour after switching away from C::B and then back:


[attachment deleted by admin]

[MortenMacFly]

Here is a snapshot with multiple "carets" (the first one) and one that shows the behaviour after switching away from C::B and then back:

I believe this is something different than the bug I was explaining. Do you have the EOL line enabled and set to a huge value, probably?! Settings -> Editor -> Margins and carets -> right margin hint...?! And if so, what happens if you turn that off?

[JGM]

This is funny, whats the point of creating such an endless line of code? to complicate more our lives?
A good example would be really appreciated 

P.S.
Something similar happened to me with scrollbars on long lines, but pressing th END key point me to the visible end of the line. Opted to format my code to become more prettier.

[MortenMacFly]

This is funny, whats the point of creating such an endless line of code? to complicate more our lives?
A good example would be really appreciated 

We want to scramble the C::B source code. Thus put all into one file and then all into one line. This saves webspace but are (unfortunately) more than 64k characters. ;-) :lol:

[Jenna]

Here is a snapshot with multiple "carets" (the first one) and one that shows the behaviour after switching away from C::B and then back:

I believe this is something different than the bug I was explaining. Do you have the EOL line enabled and set to a huge value, probably?! Settings -> Editor -> Margins and carets -> right margin hint...?! And if so, what happens if you turn that off?

Margin hints are set to none.
When I set to either line or highlight... and the hint column to 500 (that's the maximum) the "bad" behaviour starts later in the line, but still does.