LineBreakInfo - Content plugin for information about line break type, BOM type, number of CR/LF/CRLF occurrences

[Fla$her]

I could change "None" to "None/Unknown" but that would look kind of silly, especially for ANSI and binary files.

And why is there "None"? It's better to return an empty string. If it's so important for you to combine signatures with another fields, you can turn them on in silent mode, using only as an absence indicator. I.e. the plugin will know about the presence of BOM, but will return "Undefined" for encodings that are not involved in other tags.

Well, whatever I do, it's wrong for some people...

In this case, we are talking about non-doing. It's just a matter of choice.

Yes, that's what I meant.

Your answer only added confusion. You yourself rejected my question about simplicity and speed.

[Dalai]

Well, I got to ask - will you manage to separate UTF16 LE and UTF-32 LE recognition?

Yes, of course. That's one of the reasons.

Considering that piece of C++ code I suggested you try?

I was aware how to detect UTF-32 before. The code path is different because the bytes are read in one step within the same function, i.e. each file is opened and closed only once, but the result is the same.

And why is there "None"? It's better to return an empty string.

You can't search for an empty plugin field in TC's search function.

Your answer only added confusion.

If you're referring to the original statement, petermad understood it alright. Sometimes sentences must be read as a whole to get the context.

You yourself rejected my question about simplicity and speed.

I chose to not answer it because I explained my reasons extensively now.

Regards
Dalai

[Fla$her]

You can't search for an empty plugin field in TC's search function.

I can. Never had a problem with that. Could there be a problem in the data type?

If you're referring to the original statement, petermad understood it alright. Sometimes sentences must be read as a whole to get the context.

Are you seriously reproaching me for reading only part of the sentence I have given?
Trying to get into the essence of what is written, people reread the message several times. It didn't help me.
I have highlighted in red letters what you have designated as a prerequisite. And now, after your answer, I already doubt that it's just a matter of BOM detecting.

I chose to not answer it because I explained my reasons extensively now.

I am not talking about the answer to it, but about the fact that you rejected these details as an answer to my question.

[Dalai]

I can. Never had a problem with that. Could there be a problem in the data type?

Unfortunately I can't remember the details of the search parameters right now. There was something with empty strings that made it impossible to find anything or it found all files.

Anyway, it's a multiple choice field and I'm not going to change that.

Are you seriously reproaching me for reading only part of the sentence I have given?

Sorry, I meant to write "Sometimes several/multiple sentences must be read as a whole to get the context."

I am not talking about the answer to it, but about the fact that you rejected these details as an answer to my question.

I didn't reject anything. You can maybe interpret it as ignoring it. I suggest we leave it at that as all arguments have been given and we're running in circles now.

Regards
Dalai

[Fla$her]

Anyway, it's a multiple choice field and I'm not going to change that.

And how does multiple choice differ from a single one in this relation? The interface doesn’t allow an empty string?

Sometimes several/multiple sentences must be read as a whole to get the context.

It's not necessary for the interlocutor to bring the entire text of the post so that you can make sure that he has read it in its entirety. Otherwise it looks stupid.

I didn't reject anything. You can maybe interpret it as ignoring it.

I seem to have made it clear that this was not about ignoring but about contradictions in your statements. Do I understand correctly that you are now retracting your previous statement "detecting BOMs is a prerequisite for counting line breaks", and your answer to my question should be "speed and simplicity is a prerequisite for counting line breaks"?

[Dalai]

And how does multiple choice differ from a single one in this relation? The interface doesn’t allow an empty string?

Each choice of a multiple choice field is either shown for all files or for none at all because the choices are returned in the Units variable in ContentGetSupportedField function of the WDX interface.

Do I understand correctly that you are now retracting your previous statement "detecting BOMs is a prerequisite for counting line breaks", and your answer to my question should be "speed and simplicity is a prerequisite for counting line breaks"?

No, it's not and it wouldn't make any sense either. I'm not going to continue this particular discussion since it's going nowhere.

[Fla$her]

Each choice of a multiple choice field is either shown for all files or for none at all

Hmm. For some reason, the list doesn't say about an empty string:

The field may not contain the following chars: . (dot) | (vertical line) : (colon). You may return a maximum of maxlen characters, including the trailing 0.

What will happen in the case of maxlen=0?

No, it's not and it wouldn't make any sense either.

Last attempt: "fast and easy detection of BOM is a prerequisite for counting line breaks." Right? Otherwise, it is impossible to read the phrase with which you agreed.

I'm not going to continue this particular discussion since it's going nowhere.

Not quite. This will lead to my peace of mind and a better understanding of your formulations on the forum.

[Dalai]

Update to version 0.3.0:

Code: Select all

Version 0.3.0  [2023-12-01]
[*]  Rewritten most of the core detection and processing algorithm
[*]  Files with more than a single line break type are now always detected
     as "Mixed" (except CRLF). Previously, only CRs and LFs were considered
     for the line break type.
[+]  Added support for UTF-32 LE/BE
[-]  Removed "Binary" choice from field "Line Breaks" as the field
     "Binary Count" provides the same kind of information.
[*]  Updated Readme with information on how the plugin works and on what
     the plugin does and doesn't do
[+]  Added Danish translation, thanks to petermad!
[+]  Added Russian translation, thanks to AntonyD!
[+]  Added French translations, thanks to oOoZEUSoOo!

Download links available in the first post.

Regards
Dalai

[beb]

2Dalai
So finally you did the deed in your way. Congratulations!
In its turn, here is the Ukrainian translation:

Code: Select all

[ukr]
;--- Line Breaks
Line Breaks=Маркер нового рядка
N/A|LF|CR|CRLF|Mixed=Нема|LF(\n)|CR(\r)|CRLF(\r\n)|Мікс

;--- BOM Type
BOM Type=Тип BOM
None|UTF-8|UTF-16 LE|UTF-16 BE=Нема|UTF-8|UTF-16 LE|UTF-16 BE

Binary Count=Число керівних символів
CR Count=Число CR
LF Count=Число LF
CRLF Count=Число CRLF
FF Count=Число FF
VT Count=Число VT
Bytes Read=Зчитано байт

Thank you.

[Dalai]

In its turn, here is the Ukrainian translation

Thanks. At first I thought you forgot to include some strings regarding the line breaks and BOM types. After checking it I saw that it was me who forgot to include them in the English template in the first place . Not sure how that happened, but I fixed that now (for all languages) and reuploaded the archive (only the .lng file really changed).

Regards
Dalai

[beb]

... Not sure how that happened, but I fixed that now (for all languages) and reuploaded the archive (only the .lng file really changed)...

2Dalai
I'm not sure what you had to fix and why -- I just took the existing LineBreakInfo.lng file and translated its [eng] section into the [ukr] one (reading readme.htm as the reference), at the same time seeing that all the other available sections seemed to be pretty consistent. Nevertheless, glad if this somehow helped to perfect the plugin's documentation

Sehr aufmerksam.
Thank you.

Edit.
Ah, checked everything with the comparing tools, and now I see.
LineBreakInfo.lng had some entries missing.
Image: https://i.imgur.com/1hvIBli.png

[Dalai]

I'm not sure what you had to fix and why

In the .lng file the field "Line Breaks" was missing the FF and VT choices and the field "BOM Type" was missing the UTF-32 LE/BE strings. The plugin returned these choices but apparently I didn't add them to the .lng file for some reason. That's what I've changed so that these strings can be properly translated.

I just took the existing LineBreakInfo.lng file and translated its [eng] section into the [ukr] one

That's completely fine, in fact that's how it's supposed to be done.

Thanks again for the translation.

Regards
Dalai

[beb]

2Dalai
Thank you again.

[AntonyD]

2Dalai
So if we have such changes I would like to ask you to fix this "fixed" line in a such way:
not this:
N/A|LF|CR|CRLF|FF|VT|Mixed=Нет данных|LF(\n)|CR(\r)|CRLF(\r\n)|FF|VT|Смесь типов
but so:
N/A|LF|CR|CRLF|FF|VT|Mixed=Нет данных|LF(\n)|CR(\r)|CRLF(\r\n)|FF(\f)|VT(\v)|Смесь типов
made changes are colored.

[Dalai]

2AntonyD
I can do that, though I'm not sure how common these abbreviations are. Are they mentioned somewhere? Just want to make sure they're not reserved for something else.

Regards
Dalai