File-size under status bar

Adil Aleem

Just a suggestion:
It would be great if we can see the file size under the status bar of an already opened file in the Notepad++.!

Terry R

@adil-aleem said in File-size under status bar:

It would be great if we can see the file size under the status bar of an already opened file in the Notepad++

Given the role of Notepad++ is to work with “text based” files it then follows that the length as seen in the status bar (which is a number of characters in the file) should (most likely) equal the file size. Shouldn’t it?

my 2c worth
Terry

PeterJones

@terry-r said in File-size under status bar:

Shouldn’t it?

It matches the length in bytes, not in characters

Or, looking at the long unicode character’s document again, with the View > Summary showing as well:

The Length in that status bar is the number of bytes in the file. It isn’t in the accuracy-reduced “456kB” format that @Adil-Aleem suggested, because it’s showing the full number of bytes, not divided or rounded to show K, M, G, etc.

Terry R

@peterjones said in File-size under status bar:

It matches the length in bytes, not in characters

I stand corrected, thanks @PeterJones . But as it’s a byte length, then it should still be very close to file size, no?

Another thought I had was once a file is loaded for editing, even if the original file size at load time was to be shown, after editing the length may well be a more accurate “measurement” of (current) file size.

I’m not sure why having file size shown is even helpful. You would (generally) see that when loading the file (if doing this step manually). Of course if having lots of files open at once and tabbing through them, the size might (?) be helpful. I’m sorry but I just can’t see what benefit it would have.

Terry

PeterJones

@terry-r said in File-size under status bar:

But as it’s a byte length, then it should still be very close to file size, no?

More specifically, the information that @Adil-Aleem requested to be added to the status bar is already there: the “length” field is the (equivalent) file size, so it is already the field requested.

guy038

Hello, @peterjones, @terry-R and All,

Peter, you said, in your last post :

the “length” field is the (equivalent) file size …

it’s quite a good approximation !

Here is what the length field, located in the status bar, represents, depending on the current encoding :

For an ANSI encoded file : the size of current file
For a UTF-8 encoded file : the size of current file
For a UTF-8 BOM encoded file : the size of current file - 3 bytes ( the BOM )
For a UTF-16 BE BOM encoded file : The displayed number is erroneous ! It should be the total number of characters of current file × 2 - 2 bytes ( The BOM )
For a UTF-16 LE BOM encoded file : The displayed number is erroneous ! It should be The total number of characters of current file × 2 - 2 bytes ( The BOM )

Remainders :

With the UTF-16 BE BOM or UTF-16 LE BOM encodings, do not use characters over the BMP ( so, with Unicode value > \x{FFFF} )
In this regard, the names of these two encodings is quite misnommed. We should roll back to the old N++ names of UCS-2 BE BOM and UCS-2 LE BOM

Indeed, in a true UTF-16 file, characters are coded with two bytes if its Unicode code-point is <= \x{FFFF} and coded with four bytes if its Unicode code-point is > \x{FFFF} ( using the two surrogate pairs )

While, in a UCS-2 file, characters are always coded with two bytes ( chars of the BMP only ) and the surrogate zone ( from D800 to DFFF ) is not used

In addition, for a UTF-16 BE BOM or UTF-16 BE BOM encoded file, N++ oddly displays, in the length zone, the bytes count as it were an UTF-8 encoded file :-((

The moral of this story is to stick to the UTF-8 encoding, in all circonstances !

Best Regards

guy038