Community

Hi,

TextPad has a 'status' line at the bottom. When I open a file a few important properties of the file appear in this line, left aligned. Something like:

File: your.css, 12726 characters, 2383 lines, PC, UTF-8

This info is very useful. Especially the 'UTF-8' encoding.

The annoying thing is that this information disappears as soon as I place the cursor in the document, and it doesn't come back. Why have it at all?

Has anybody else noticed this? I would like this information to be always visible.

I am using Windows 10, TextPad 8.1.1.

In the menu choose View > Document properties or just hit ALT+ENTER and the tab "Document" will give you just that information. Proof:



However, the "characters" amount differs - I guess this is more or less a caption bug, as the amount in the status bar always shows the file size instead of the character count.

AmigoJack wrote:In the menu choose View > Document properties or just hit ALT+ENTER and the tab "Document" will give you just that information. Proof:



However, the "characters" amount differs - I guess this is more or less a caption bug, as the amount in the status bar always shows the file size instead of the character count.

I agree with kikosoft2. It's still much more convenient to have this information already present on the status bar, and it's a shame it disappears.

kikosoft2: As a workaround, you can get it back by double clicking on the status bar, itself.

DrX

You can also get it back by pressing Ctrl+F1, but yes it still disappears as soon as you do something else.

If the status bar would be configurable then you could get a permanent panel in there. However, I disagree with all of you: in 10+ years I never needed to always know which encodings the file has, and it didn't matter until I would (re)save it. So can you give me a few examples on why you need this permanently? I mean: characters and lines will change almost instantly (unless Textpad is not an editor to you but rather only a viewer).

Thanks for all the replies.

The 'double click on status bar' and 'Ctrl-F1' are really useful. I wasn't aware of those. I did, of course, know that the document properties window existed.

The reason I (sometimes) want to see the character encoding on the status page is twofold:

1. I keep finding files that don't work properly because they use the ANSI encoding. Even files I originally made in UTF-8, and have Polish in them, appear in garbled ANSI after a while. I have set the default encoding of the used file types to UTF-8, and checked a lot of other thing, like setting the default document type to UTF-8, and still it occurs. I cannot put my finger on it.

2. When you save for the first time, or choose 'Save as...' you can choose the encoding, which is very nice, but by default it is set to 'default', and you cannot see what that default is. Why doesn't it work like the 'line ending', also present in 'Save as...', which actually shows you what it is going to use?

Having the character encoding visible on the status line just helps me getting the encoding under control when working with, what are now many hundreds, of files. I could just walk through the document selector, and see what is what, if the status line works.

kikosoft2 wrote:still it occurs. I cannot put my finger on it

Because Textpad still guesses the encoding when there is no indicator. And from case to case it either guesses right, or wrong. Read this and then consider saving your files with a BOM, so Textpad is able to always recognize them as UTF-8.

AmigoJack wrote:However, the "characters" amount differs

for some reason unknown to me, line feed and carriage return are not in the character count.

Because Textpad still guesses the encoding when there is no indicator.

That could very well be the cause it changes back to ANSI. I'll try out the BOM.

I never used a BOM because in PHP you're not allowed to output anything before the headers, and the BOM does that. It used to be a well-known problem, so I left out the BOM.

https://www.w3.org/International/questi ... k#problems

You should ensure that the included files do not start with a BOM.

I can find this remark in several places, some dated later than this one, and I cannot find that it is solved. See the bottom of this:

https://bugs.php.net/bug.php?id=22108
https://bugs.php.net/bug.php?id=74312

I will do some tests to see what the situation is now.

Ok, I tested it with PHP 5.6 and I don't get errors. Seems like it is no longer a problem. I am still very hesitant to include a BOM in all my PHP files, until I can find written prove that PHP ignores it.

You never mentioned PHP files - that's a different thing.

kikosoft2 wrote:PHP 5.6 and I don't get errors. Seems like it is no longer a problem.

No, this is still a problem: BOMs are considered direct output (as with everything that comes before <?php), and depending on what you want to achieve this can be ignored or can lead to erroneous output.

It's far easer to condition TextPad's encoding recognition by using non-latin comments. The first line of any PHP file of you could look like this:

Yes, adding a weird unicode character at the beginning of PHP files makes sense, and it is much easier to do than adding BOM's. I'll try that.

AmigoJack wrote:If the status bar would be configurable then you could get a permanent panel in there. However, I disagree with all of you: in 10+ years I never needed to always know which encodings the file has, and it didn't matter until I would (re)save it. So can you give me a few examples on why you need this permanently? I mean: characters and lines will change almost instantly (unless Textpad is not an editor to you but rather only a viewer).

Who said anything about need? It's convenient. You disagree, so what? That's what options are for. I don't feel the need to give you examples of my preferences.

DrX

Drxenos wrote:I don't feel the need to give you examples

While I'm "doomed" to not understand why it's "convenient" to you all others (including those programming TextPad) might not see a good reason to implement your requests either. It's not entirely about me - this is a topic, not a private message.