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.
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);"
Last edited by stefanenko on Tue 29 Oct, 2019 05:42, edited 1 time in total.
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.
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.
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.
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.
(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?
Added a support for unconfigured filters. This solves a common situation where the plugin had already been configured with some filters and then a new version with additional filters is introduced: In prior versions, the new filters would not become available until the user configured them. Now these filters are added automatically to the list of available filters. They should still be configured to allow their automatic execution through the "Autoselect" filter, but they will work manually without any configuration.
Updated the plugin to a newer version of Dialog API. Among other things, this allows the plugin to properly react to resizing of the FAR's window.
Minor fixes for compatibility with Delphi 10.1 and newer.
BASE64 decoded was only available in debug builds (copy&paste error).
Added a condition that the plugin is available to the Autoselect macro.
pepak wrote: ↑Wed 14 Oct, 2020 18:27
Seems to work fine for me as well. Note though that Filters is only applicable to regular blocks, not vertical blocks.
Yes, it is a trivial part, and it's Ok to me.
pepak wrote: ↑Wed 14 Oct, 2020 18:27
Could you maybe be a bit more specific. I actually think that I designed the plugin precisely with the idea of supporting blocks.
Great, so i go to TPlugin.ReplaceSelectedContent (am i on the right way to see the implementation?)
from there i understand that the Content cimes from TPlugin.GetEditorInfo(EditorID: TIntPtr; out EditorInfo: TEditorInfo; out FileName, Content: string)