pepak wrote: ↑Thu 26 Sep, 2019 18:55
What is the source of Plugin Information's dialog data?
Presumably the Version field of the GlobalInfo structure filled in the GetGlobalInfoW function exposed by the plug-in. Formally, it's unrelated to Windows' VERSION_INFO, but ideally should represent the same version. Far Encyclopedia recommends using the MAKEFARVERSION macro to form the version value.
pepak, a bug surfaced: the “JSON format” filter does not show up in *.json files where the top-level element is not an object, mostly affecting JSON files with a top-level array. According to the grammar, object is not the only valid top-level element, and top-level arrays are of particular importance.
How to reproduce: create a file named e.g. json.json with 2 characters: [], invoke Filters.
That is a limitation of the component used, I think. It would be possible to fix by wrapping the array inside an object, but it seems the detection of this case is more complicated than simply creating the wrapper manually. Also, if it really is a major issue for someone, they can easily set up an external JSON formatter instead of the built-in one and that will take care of any similar issues immediately.
Last edited by pepak on Mon 07 Oct, 2019 16:22, edited 1 time in total.
pepak wrote: ↑Mon 07 Oct, 2019 16:21
That is a limitation of the component used, I think.
What's the component? Those I used myself just had a separate method to handle top-level arrays.
If it turns out to be a limitation indeed, please document this to save people like me from spending time trying to figure out why the plug-in does not work in their case.
Last edited by HaRT on Mon 07 Oct, 2019 16:31, edited 1 time in total.
pepak wrote: ↑Mon 07 Oct, 2019 16:21
That is a limitation of the component used, I think.
What's the component? Those I used myself just had a separate method to handle top-level arrays.
Henri Gourvest's SuperObject.
If it turns out to be a limitation indeed, please document this to save people like me from spending time trying to figure out why the plug-in does not work in their case.
Frankly, it never occurred to me that this might be a problem in the component. Maybe it can even cope, somehow.
stefanenko wrote: ↑Mon 28 Oct, 2019 07:11
XML is read as windows-2151 and encoded in utf-8. When pressed again, the conversion 1251-> utf-8 again occurs and all non-English text goes bad!
Nope. XML is read in the editor's encoding and written also in editor's encoding.
<?xml version="1.0" encoding="windows-1251"?>
<phpunit>
<env name="TEST" value="тестовая строка"/>
</phpunit>
stefanenko wrote: ↑Mon 28 Oct, 2019 07:11
XML is read as windows-2151 and encoded in utf-8. When pressed again, the conversion 1251-> utf-8 again occurs and all non-English text goes bad!
Hmm. Seems like the encoding attribute is the problem. Once you remove it, everything is fine. I will have to remove it before the filter starts its work, I guess. Or something like that.