Filters

Here you can discuss about your favorite plug-in.
citRiks
Posts: 899
Joined: Fri 25 Oct, 2019 18:18
Has thanked: 274 times
Been thanked: 47 times

Filters

Post by citRiks »

Latest post of the previous page:

pepak wrote: Sun 25 Oct, 2020 11:36 have no way of knowing whether that byte sequence is a BOM or an actual binary data that needs to be returned.
To may way of thinking,
if we work on editor selection, it can be only text data, or supposed to be text data, not binary.
I would say what those first two bytes of text have very easy detectable signature.
It is always first two bytes, and always only very certain bytes.
Detecting of UTF8 strings is necessary for any text handling nowadays.
Here is the Lua-code for it, can be easily translated to Pascal.
it is simple and bug-free (er.. well, should be),
handling any kind of unicode (not only UTF8):

Code: Select all

local fnc_det_bom_str = function(str_head)
        local boms = {
	        {name = "ASCI", code = ""},
	        {name = "32LE", code = '\255\254\0\0'}, -- utf32le
	        {name = "32BE", code = '\0\0\254\255'},	-- utf32be
	        {name = "16LE", code = '\255\254'},	-- utf16le
	        {name = "16BE", code = '\254\255'},	-- utf16be
	        {name = "UTF8", code = '\239\187\191'}	-- utf8
	        	}
	local str_bom
	local res = 1
	for	ii = #boms, 3, -1
	do	str_bom = string.sub(str_head, 1, #(boms[ii].code))
		if str_bom == boms[ii].code
		then	if ii == 4 and str_bom == boms[2].code then ii = 2 end
			res = ii
			break
		end
	end
	return boms[res].name, boms[res].code
end

local fnc_read_header_text = function(file_name)
	local	fp = io.open(filename)
	if not	fp then return end
	local s = fp:read(512)
	fp:close()
	return s:gsub("%s+", " "):match("[%w_].*")
end

local fnc_det_bom_file = function(file_name)
	local str_head, bom_name, bom_code
	local	fHnd = io.open(file_name, "rb")
	if	fHnd
	then	str_head = fHnd:read(4) or ''
		fHnd:close()
		bom_name, bom_code = Xer0X.fnc_det_bom_str(str_head)
	end
	return bom_name, bom_code
end
Last edited by citRiks on Sun 25 Oct, 2020 20:59, edited 2 times in total.
А кто не поверит в наше миролюбие, / Тот кровью умоется. / И будет такая борьба за мир, / Что камня на камне не останется.
citRiks
Posts: 899
Joined: Fri 25 Oct, 2019 18:18
Has thanked: 274 times
Been thanked: 47 times

Filters

Post by citRiks »

By my quick check, apllying on selection is working Ok for now,
but it inserts BOMs, on every check i did.
BOMs appear as a strange square symbol
image.png
image.png (2.32 KiB) Viewed 474 times
Last edited by citRiks on Sun 25 Oct, 2020 21:30, edited 1 time in total.
А кто не поверит в наше миролюбие, / Тот кровью умоется. / И будет такая борьба за мир, / Что камня на камне не останется.
pepak
Posts: 519
Joined: Sun 13 Jul, 2008 11:18
Has thanked: 13 times
Been thanked: 42 times

Filters

Post by pepak »

citRiks wrote: Sun 25 Oct, 2020 20:52 if we work on editor selection, it can be only text data, or supposed to be text data, not binary.
Wrong. Consider the BASE64 filter.
I would say what those first two bytes of text have very easy detectable signature.
Sure, and I already detect and remove those if the encoding is set to one of the UTF encodings.
pepak
Posts: 519
Joined: Sun 13 Jul, 2008 11:18
Has thanked: 13 times
Been thanked: 42 times

Filters

Post by pepak »

citRiks wrote: Sun 25 Oct, 2020 21:29 By my quick check, apllying on selection is working Ok for now,
but it inserts BOMs, on every check i did.
BOMs appear as a strange square symbolimage.png
I will need specific reproducible steps for that. If I can reproduce the problem and if it is caused within the plugin, then I will of course fix it. But I am pretty convinced that the problem is in your speficic filter - e.g. you use sort, which does not support UTF, but you pass the UTF8 BOM to it. That is treated as any text, sorted and put in the middle of the data. And I don't and won't remove BOMs except if they are the first character of the filtered output.
pepak
Posts: 519
Joined: Sun 13 Jul, 2008 11:18
Has thanked: 13 times
Been thanked: 42 times

Filters

Post by pepak »

Version 0.07
  • An empty line in the editor used to be interpreted as the end of the selection, but after the filter was done, the whole selection would get replaced, possibly causing a loss of data.
vodek
Posts: 28
Joined: Sat 12 May, 2012 09:29
Has thanked: 3 times

Filters

Post by vodek »

pepak,
Hello!
What's the dot in the ".release" file name for?
This is evil!
I have a network attached storage with the ext4 file system and in this system (and in all *nix) the dot at the beginning of the filename automatically makes the file hidden.
So. I update the FAR along with the plugins using Renewal, copy it to NAS, then the .release file automatically becomes hidden.
I copy the folder with Far from NAS to another computer and after that I have .release with the "Hidden" attribute, and in this computer I just can't update Far without error! I have to go into the plugin folder and remove the "Hidden" attribute manually...

For WHAT need the dot?!

P. S. The same in FRename3
Last edited by vodek on Sun 01 Nov, 2020 22:30, edited 1 time in total.
pepak
Posts: 519
Joined: Sun 13 Jul, 2008 11:18
Has thanked: 13 times
Been thanked: 42 times

Filters

Post by pepak »

vodek wrote: Sun 01 Nov, 2020 22:16 pepak,
Hello!
What's the dot in the ".release" file name for?
To mark that file as special.
So. I update the FAR along with the plugins using Renewal, copy it to NAS, then the .release file automatically becomes hidden.
I copy the folder with Far from NAS to another computer and after that I have .release with the "Hidden" attribute, and in this computer I just can't update Far without error! I have to go into the plugin folder and remove the "Hidden" attribute manually...
I fail to see why should a "hidden" flag prevent updates.
P. S. The same in FRename3
The same is in all my plugins, as it is a part of my build process. There is no particular reason for using dot and not, say, an underscore, but at the same time I don't see why I should change the build process all of a sudden. Wouldn't it be a better idea to modify your update process so that it doesn't get confused by hidden files, or so that it would unhide files copied from your NAS?
Last edited by pepak on Mon 02 Nov, 2020 05:30, edited 1 time in total.
vodek
Posts: 28
Joined: Sat 12 May, 2012 09:29
Has thanked: 3 times

Filters

Post by vodek »

pepak wrote: Mon 02 Nov, 2020 05:27 "I fail to see why should a "hidden" flag prevent updates."
"...but at the same time I don't see why I should change the build process all of a sudden. "
Because it was a bad idea to put a dot at the beginning of the file. Nobody does that. No one plug-in for FAR has such problems with updates.
But FAR is used not only under Windows FAR can be launched on *NIX under Wine.

The problem isn't in my NAS. The dot at the beginning of the file as a hidden attribute exists possibly earlier than me and you were born. ;-)

By the way. Another one problem with update Filters to last version 0.7. As I'm understand it's not connected with "dot". But everything possible. See screenshot.
изображение.png
Last edited by vodek on Mon 02 Nov, 2020 10:35, edited 2 times in total.
2useven10
Posts: 4115
Joined: Mon 07 Sep, 2009 10:40
Has thanked: 5 times
Been thanked: 195 times

Filters

Post by 2useven10 »

vodek wrote: Mon 02 Nov, 2020 10:24 As I'm understand it's not connected with "dot".
It is rather Renewal plugin problem. Do you use latest version?
You should use custom Renewal.xml for Filters plugin. Can you show it?
And (to avoid offtopic) maybe Renewal page is more suitable...
Last edited by 2useven10 on Mon 02 Nov, 2020 11:51, edited 3 times in total.
pepak
Posts: 519
Joined: Sun 13 Jul, 2008 11:18
Has thanked: 13 times
Been thanked: 42 times

Filters

Post by pepak »

Sorry, but neither of the errors you report is a bug in Filters. You need to take it up with Renewal.

You are quite free to believe that a dot at the beginning of a filename is a bad idea. My opinion is different, though. The claim that "nobody uses dot at the beginning of a file" is manifestly false; to the contrary, many developers use it the same way I do.
vodek
Posts: 28
Joined: Sat 12 May, 2012 09:29
Has thanked: 3 times

Filters

Post by vodek »


pepak wrote: Mon 02 Nov, 2020 11:40 Sorry, but neither of the errors you report is a bug in Filters. You need to take it up with Renewal.

You are quite free to believe that a dot at the beginning of a filename is a bad idea. My opinion is different, though. The claim that "nobody uses dot at the beginning of a file" is manifestly false; to the contrary, many developers use it the same way I do.
Of course, the dot at the beginning in the filename is used a lot of especially в *nix.
But I have not seen a single plug-in for Far manager where there is a similar one. Only in Your plugins.
Is it really that difficult to change the file name, it will solve the problem. Would You please!
Last edited by HaRT on Mon 02 Nov, 2020 15:03, edited 1 time in total.
Reason: Спрятан офтопик
pepak
Posts: 519
Joined: Sun 13 Jul, 2008 11:18
Has thanked: 13 times
Been thanked: 42 times

Filters

Post by pepak »

vodek wrote: Mon 02 Nov, 2020 12:26But I have not seen a single plug-in for Far manager where there is a similar one. Only in Your plugins.
Well, there are many things you will only see in my plugins :-)
Is it really that difficult to change the file name, it will solve the problem. Would You please!
It's not difficult, but:

1) It doesn't fix the error, it just avoids it. But the error will still be there, waiting for another victim. If something should be fixed, it's Renewal (or whatever is performing the update), then it will be a real fix once and for all.

2) It will break any previous code that might depend on the marker file. I don't know if there is any, but my plugins have been using this marker for quite some time, so I can't discount the possibility.

3) I don't update the plugins all that often, which makes the benefit of auto-update dubious (in my eyes, anyway).
vodek
Posts: 28
Joined: Sat 12 May, 2012 09:29
Has thanked: 3 times

Filters

Post by vodek »

I explained. The point is not in Renewal, the point is that the dot at the beginning of the file name is treated as a "hidden" attribute in many file systems other than FAT/NTFS. And this is your oversight in the assembly of plugins. This is what I originally wrote about.
The dot in the filename brought my attention to a bug in updating your plugins. This is primary, the bug in Renewal is the secondary.
And I do not understand your persistence in admitting an error in the decision to name the file using a dot at the beginning of the name. Many people have NAS, not only me, I also already mentioned about Wine.
In general, Your reaction in the form of a refusal to change the file name is, to put it mildly, strange, because it cannot become worse by definition.
vodek
Posts: 28
Joined: Sat 12 May, 2012 09:29
Has thanked: 3 times

Filters

Post by vodek »

Remove the dot from the file name, you are creating a problem from scratch!
изображение.png
изображение.png
User avatar
HaRT
Moderator
Posts: 9601
Joined: Tue 30 Aug, 2005 17:21
Location: Санкт-Петербург
Has thanked: 114 times
Been thanked: 233 times

Filters

Post by HaRT »

vodek, your screenshots clearly state that the error is “Access denied”, so it's not the dot in the file name to blame but your NAS file system. The plugin author has answered you already, please stop bugging.
Фар есть инструмент, а не нянька. © 2009 DrKnS
vodek
Posts: 28
Joined: Sat 12 May, 2012 09:29
Has thanked: 3 times

Filters

Post by vodek »

Last edited by HaRT on Fri 13 Nov, 2020 12:08, edited 1 time in total.
Reason: Hidden offtopic
Post Reply

Return to “General Plug-In Discussions”