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

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.

[dmoore]

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 

in my case it wasn't code, just word wrapped text. (some documentation i was writing)
lines were as long as 1500 characters (a long paragraph)

[JGM]

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:

I would believe you more if it was an obfuscation contest   :lol:

in my case it wasn't code, just word wrapped text. (some documentation i was writing)
lines were as long as 1500 characters (a long paragraph)

Thats sounds some kind of reasonable but a 64k long line, like has been talked here :?

[Jenna]

Thats sounds some kind of reasonable but a 64k long line, like has been talked here :?

HTML pages that are optimized for size and optimized and/or obfuscated JavaScripts are other examples that make sense and can reach much more than than 64k.

[JGM]

Nice example  , I doesn't thought about that 

Honestly, I prefer to use a tool that automates that kind of work for publishing, not manually edit infinite lines of text.
i would become more blind than I am  :roll:

[Ceniza]

Something bugs me... why does Martin/Morten/Mortin (you've got so many names, bloody cake) say that the wxCoord typedef is the reason for the 64k limit? Both in 32 and 64 bits architectures the size of int is 32 bits, and the size of short 16 bits. 32 bits can handle 4G...

Someone still using 16 bits C++ compilers it seems?

[MortenMacFly]

Something bugs me... [...] that the wxCoord typedef is the reason for the 64k limit?

Mmmmh... we were not talking about short... right?! Probably because I was drunk?

[thomas]

If that was the case, you should not be able to display more than a few thousand lines of code either (and Code::Blocks confirmedly handles 1.9 million lines of code).
Also, if it was limited by the coordinates, then using a font twice as large should make the bug occur after displaying half as many characters.

[MortenMacFly]

If that was the case, you should not be able to display more than a few thousand lines of code either (and Code::Blocks confirmedly handles 1.9 million lines of code).
Also, if it was limited by the coordinates, then using a font twice as large should make the bug occur after displaying half as many characters.

It's not enough if I lay on the ground ashamed already... :oops: you must kick me another time... Who's next?!