Page 4 of 4

Filters

Posted: Mon 28 Oct, 2019 18:24
by HaRT

Latest post of the previous page:

pepak wrote:
Mon 28 Oct, 2019 18:09
Just try it and you will see.
I believe it does so. But that behavior is an obvious error as the encoding line clearly should not affect the result in this case.
So just removing the line looks more like a workaround rather than a fix.

Filters

Posted: Mon 28 Oct, 2019 23:57
by stefanenko
JSON also works weird. The file contains a string

Code: Select all

{"sapcode":"133114"},{"sapcode":"132250"},{"sapcode":"133579"}
After pressing F5 we get

Code: Select all

{
 "sapcode": "133114"
}

Filters

Posted: Tue 29 Oct, 2019 00:08
by HaRT
stefanenko wrote:
Mon 28 Oct, 2019 23:57
JSON also works weird. The file contains a string

Code: Select all

{"sapcode":"133114"},{"sapcode":"132250"},{"sapcode":"133579"}
It is not a valid JSON file, as there must be a single top-level element, but the file has 3.

Filters

Posted: Tue 29 Oct, 2019 05:40
by stefanenko
I guessed, but I did not find this in the description.

Filters

Posted: Tue 29 Oct, 2019 05:42
by stefanenko
I already did everything through external utilities.
XML -> xmllint.exe
HTML -> tidy.exe
JSON -> over "echo json_encode(json_decode(file_get_contents($argv[1])), JSON_UNESCAPED_UNICODE+JSON_PRETTY_PRINT);"

Filters

Posted: Tue 29 Oct, 2019 05:56
by pepak
HaRT wrote:
Mon 28 Oct, 2019 18:24
I believe it does so. But that behavior is an obvious error as the encoding line clearly should not affect the result in this case.
So just removing the line looks more like a workaround rather than a fix.
Agreed.
stefanenko wrote:
Tue 29 Oct, 2019 05:40
I guessed, but I did not find this in the description.
Why should it be there? I mean, it's perfectly understandable that deviations from the standard should be mentioned, but why describe things which adhere to the standard?
stefanenko wrote:
Tue 29 Oct, 2019 05:42
I already did everything through external utilities.
XML -> xmllint.exe
HTML -> tidy.exe
JSON -> over "echo json_encode(json_decode(file_get_contents($argv[1])), JSON_UNESCAPED_UNICODE+JSON_PRETTY_PRINT);"
That's exactly as intended. The internal filters are applicable without any external tools, but they may take some shortcuts due to the ways they are written; however, if a user encounters a case where the internal filters perform bad, they can always switch to external filters.

Filters

Posted: Thu 31 Oct, 2019 08:53
by pepak
I need to perform some more testing and I would like to look into BASE64-decode (the trouble here is, how to deal with the different codepages in the editor), but other than that I am happy to announce that these bugs have been fixed:
  • Incorrect plugin version in the Plugin Information dialog.
  • XML with an "encoding" attribute causes invalid conversions of non-ASCII characters.
  • JSON fails if the top element is an array.

Filters

Posted: Thu 31 Oct, 2019 14:01
by HaRT
pepak wrote:
Thu 31 Oct, 2019 08:53
I am happy to announce that these bugs have been fixed
That's great! I'm looking forward to checking these once the update is published.

Filters

Posted: Sun 03 Nov, 2019 09:21
by pepak
Released version 0.05
  • Fixed an incorrect plugin version info shown by the plugin list in Plugin Information (F3).
  • XML filter: Fixed broken non-ASCII characters in XML files encoded in something else than UTF-8.
  • JSON filter: Fixed a bug which caused a failure to filter in case the top element was an array.
  • Support for selecting filters which don't match the specifications. For example, assuming the default settings for XML filters, only files with extensions such as .xml, .xsd etc. would previously be eligible for processing. In this version, even files with other extensions can be processed; however, these filters would be moved back in the list, leaving the specifications-matching filters in the front. Note that this functionality is only available from the plugin's main menu, not from the macro call - that always requires the specifications to match.
  • Support for built-in BASE64 decoder. Note that the editor's encoding should be set to an 8-bit encoding (e.g. ANSI or OEM) for the best results.

Filters

Posted: Mon 02 Dec, 2019 19:37
by LAT
pepak wrote:
Sat 26 Oct, 2019 04:35
I wish! Looking for one myself.
I found a tool for formatting of the javascript-code: http://clang.llvm.org/docs/ClangFormat.html. It can be downloaded here: http://releases.llvm.org/download.html#git, by link "Windows (32-bit) (.sig)" (size: 139 Mb) or "Windows (64-bit) (.sig)". Next you need to extract the file clang-format.exe by using arclite or observer. Or you may use already extracted x86-version from the attachment.
clang-format.exe-86.7z
(639.66 KiB) Downloaded 13 times

Filters

Posted: Tue 03 Dec, 2019 06:06
by pepak
Looks good, thanks!

Filters

Posted: Tue 24 Dec, 2019 22:27
by HaRT
pepak wrote:
Sun 03 Nov, 2019 09:21
JSON filter: Fixed a bug which caused a failure to filter in case the top element was an array
Thank you!
In general, it works, but there's a small cosmetic issue: if I autoformat an array, e.g. [{"name":"value"},{"name":"value"}], I'm getting

Code: Select all

[
 {
  "name": "value"
 },{
  "name": "value"
 }]
whereas I'd prefer a more common layout

Code: Select all

[
 {
  "name": "value"
 },
 {
  "name": "value"
 }
]
(note the line breaks and un-/indentation after the comma and before the closing bracket).
Are you in control of the formatter? Is it hard to improve this?

Filters

Posted: Wed 25 Dec, 2019 07:45
by pepak
It's not in my code. I suppose I could modify it anyway, but I have no idea how difficult it would be.