Feature request: Make workspaces show the whole content of files/strings

Workspaces (and text panes in general, I believe) stop displaying once they encounter a NUL character. This means that opening a file with an embedded NUL results in a substantial amount of the file being hidden from the reader, as if it did not exist.

For example, I have a stack dump which includes the following lines:
xmNmnemonic
        client = {0} $NUL

where NUL represents the NUL character.

Notepad++, for example, proceeds to show me the remaining ~6,000 lines. VA Smalltalk, on the other hand, pretends there are only 2,900 and no more.


(As an aside, I really like the glyphs Notepad++ uses for non-printable characters. In this case, it was a reverse video of the word "NUL" with attractively rounded corners. I have recently encountered something along these lines for non-printing Unicode characters, in which the glyph shows 4 or 6 miniscule hex digits. Yes, you need really good glasses!)


Thank you!

Hi Richard,

Hello all,

Case 57412 opened for handling truncation of text with nulls

On Friday, March 6, 2015 at 2:23:43 PM UTC-5, Seth Berman wrote:

Hello all,

The issue with truncation has to do with using the wrong compatibility method in CwScintillaEditor>>setString:.

It should be something more like the following because setText: expects null terminated input, so its only going to read that far.

self forceModifyText: [

self

clearAll;

addText: value]

I have not played around much with glyphs.  What is there is the default scintilla behavior.

We have the APIs wrapped.

I just inspected the editor with the Null char in it and called 'self clearRepresentation: (String with: (Character value: 0))' which seemed to remove the glyph and do something more like what notepad would do.

I'll put in a case for the truncation issue.  Thanks!

-- Seth

On Friday, March 6, 2015 at 11:48:21 AM UTC-5, Louis LaBrunda wrote:

Hi Richard,

On Thursday, March 5, 2015 at 7:18:52 PM UTC-5, Richard Sargent wrote:

Workspaces (and text panes in general, I believe) stop displaying once they encounter a NUL character. This means that opening a file with an embedded NUL results in a substantial amount of the file being hidden from the reader, as if it did not exist.

For example, I have a stack dump which includes the following lines:
xmNmnemonic
        client = {0} $NUL

where NUL represents the NUL character.

Notepad++, for example, proceeds to show me the remaining ~6,000 lines. VA Smalltalk, on the other hand, pretends there are only 2,900 and no more.


(As an aside, I really like the glyphs Notepad++ uses for non-printable characters. In this case, it was a reverse video of the word "NUL" with attractively rounded corners. I have recently encountered something along these lines for non-printing Unicode characters, in which the glyph shows 4 or 6 miniscule hex digits. Yes, you need really good glasses!)
Thank you!

I replace the NUL with $Ø in a window where I am displaying data to a user.  I don't love the solution but it isn't too bad.  I wouldn't mind getting rid of it in favor of something better.

Lou

Thank you!

On Friday, March 6, 2015 at 12:29:06 PM UTC-8, Seth Berman wrote:

There are a few other APIs that will also need to be fixed up to handle embedded nulls so I will include this work in case 57412

On Friday, March 6, 2015 at 2:27:47 PM UTC-5, Seth Berman wrote:

Case 57412 opened for handling truncation of text with nulls

On Friday, March 6, 2015 at 2:23:43 PM UTC-5, Seth Berman wrote:

Hello all,

The issue with truncation has to do with using the wrong compatibility method in CwScintillaEditor>>setString:.

It should be something more like the following because setText: expects null terminated input, so its only going to read that far.

self forceModifyText: [

self

clearAll;

addText: value]

I have not played around much with glyphs.  What is there is the default scintilla behavior.

We have the APIs wrapped.

I just inspected the editor with the Null char in it and called 'self clearRepresentation: (String with: (Character value: 0))' which seemed to remove the glyph and do something more like what notepad would do.

I'll put in a case for the truncation issue.  Thanks!

-- Seth

On Friday, March 6, 2015 at 11:48:21 AM UTC-5, Louis LaBrunda wrote:

Hi Richard,

On Thursday, March 5, 2015 at 7:18:52 PM UTC-5, Richard Sargent wrote:

Workspaces (and text panes in general, I believe) stop displaying once they encounter a NUL character. This means that opening a file with an embedded NUL results in a substantial amount of the file being hidden from the reader, as if it did not exist.

For example, I have a stack dump which includes the following lines:
xmNmnemonic
        client = {0} $NUL

where NUL represents the NUL character.

Notepad++, for example, proceeds to show me the remaining ~6,000 lines. VA Smalltalk, on the other hand, pretends there are only 2,900 and no more.


(As an aside, I really like the glyphs Notepad++ uses for non-printable characters. In this case, it was a reverse video of the word "NUL" with attractively rounded corners. I have recently encountered something along these lines for non-printing Unicode characters, in which the glyph shows 4 or 6 miniscule hex digits. Yes, you need really good glasses!)
Thank you!

I replace the NUL with $Ø in a window where I am displaying data to a user.  I don't love the solution but it isn't too bad.  I wouldn't mind getting rid of it in favor of something better.

Lou