EdgeViewer - Modern HTML viewer plugin

[rg_software]

Are you sure?

https://pixeldrain.com/u/tZ2d6kDd

I understand that this version of MarkdownView.md needs to be improved/expanded in any case. Something like that - to compile the help of your plugin and its fundamentals - hoedown engine. In the previous version of MarkdownView.md there was, IMHO, just such an attempt.
It just needs to be improved...

I am fine with it, but could you please send me the md readme file? I am puzzled what is there because I frankly don't remember having anything there in addition to the current readme content. There is also a link to the hoedown documentation, covering the arguments.

[AntonyD]

I am fine with it, but could you please send me the md readme file?

I'm terribly sorry - but that's why I gave you the /pixeldrain link - so that you download the full archive-installation of the plugin.
This file is located inside the archive. I can't remember exactly where I downloaded it from - maybe it wasn't from the main site.
BUT nevertheless, the logic of this file is really good - all the information is IMMEDIATELY entered in it. There is no need to follow different links
and copy this information from there by supported initialization string arguments...

[rg_software]

I am fine with it, but could you please send me the md readme file?

I'm terribly sorry - but that's why I gave you the /pixeldrain link - so that you download the full archive-installation of the plugin.
This file is located inside the archive. I can't remember exactly where I downloaded it from - maybe it wasn't from the main site.
BUT nevertheless, the logic of this file is really good - all the information is IMMEDIATELY entered in it. There is no need to follow different links
and copy this information from there by supported initialization string arguments...

Sorry, I thought it's just a screenshot. Well, it's funny I received this readme from one user. It wasn't made by me, and it never was a part of the package.

For the new readme, I incorporated their info on the IE control update (the reg section), but indeed I thought there isn't much reason to include the hoedown section because the same info is in the official hoedown doc (also linked in the readme).

[AntonyD]

the same info is in the official hoedown doc

keyword! And the meaning of this information is to be immediately in the package with the plugin. Because it definitely cannot and will not change in real time - so that there is a need to constantly monitor its edits on another official website. Therefore, it would be very good if all this information were compiled in one place, as it turns out someone did earlier. I told you that I took the file from somewhere and I don't remember when yet - somewhere the file caught my eye so I decided to try.

[rg_software]

the same info is in the official hoedown doc

keyword! And the meaning of this information is to be immediately in the package with the plugin. Because it definitely cannot and will not change in real time - so that there is a need to constantly monitor its edits on another official website. Therefore, it would be very good if all this information were compiled in one place, as it turns out someone did earlier. I told you that I took the file from somewhere and I don't remember when yet - somewhere the file caught my eye so I decided to try.

The hoedown doc in question is also in the Markdown Viewer project on Github, so should be no issue I agree in principle, should be no dead links.

[AntonyD]

2rg_software
question regarding the `Detect` string and reaction on proper files associations from plugins side....

As I see MarkdownView has NO detect string BUT it DOES have some list of extensions inside the INI file.
EdgeViewer - in an opposite - it DOES have the `Detect` string AND it has some list of extensions inside
the INI file. AND these elements are related - all what is listed at the Detect string exists at the INI file.

And these 2 plugins both work correctly with appropriate files. For example MarkdownView can open
and shows SVG file - WHEN I will add this ext. at the HTMLExtensions section of settings of INI file.
SO finally my question - WHICH strategy should be more correct ? And why we have 2 different cases
of supporting the working flow - inside which plugins decide - will they operate with input file or not...

IMHO the working flow of MarkdownView - is much more intuitive - I should only in one place to add
these extensions - which in my opinion this plugin should take care...

[Horst.Epp]

IMHO the working flow of MarkdownView - is much more intuitive - I should only in one place to add
these extensions - which in my opinion this plugin should take care...

Not for me.
The TC plugin config should be the only control what plugin is used for what extension.
Here we set the extensions for every plugin and the priority of all plugins.

[AntonyD]

Here we set the extensions for every plugin and the priority of all plugins.

Okay - and how do you then list ALL available audio and video extensions for the TCMediaInfo plugin for example?
And yes - no need to find fault with the fact that you may not be using THIS plugin.
The essence of the general question does not change:
There is some kind of plugin and in theory it can handle a LOT of extensions. And for starters, there is such a list
inside the plugin - or inside its INI file. BUT if we now have to use only the DETECT string - what extensions
will we have to add to it and when?? Every time a new version of the plugin is released, check whether the list
of extensions it supports has changed? And urgently make changes, if any, to the DETECT line?

IMHO it's better to go the other way around - you suddenly updated a plugin and accidentally saw that it began to open a file - which couldn't before, but you liked another plugin for this extension and you've already done everything to support it. And now it's much easier for the DETECT string to add an exception of this new extension to the updated plugin! Thus, you left the support of everything old on the old plugin and in the new one you got support for something new, which do not interfere with your habits.

And please also note that for some reason there is more than one plugin in the world that works with a completely empty DETECT line - and at the same time handles all the files it supports that are declared for its functionality! YES, there are difficulties when you need to turn it on - but the main thing is basically: an empty DETECT line does not interfere with it. And it doesn't bother the user either.

[rg_software]

Detect string is the topic that caused quite a debate here. I tend to think that in most cases it isn't really necessary. However,

1) without it, you can't switch off some extension if you don't like how the given plugin handles it unless the author is kind enough to let you do it via the ini file.
2) without it, you can't even tell which extensions are handled by which pluigns when you just look at the list of plugins.

In EdgeViewer the detect string is formed by gathering all enabled extensions found in the ini file during setup. I can't remove extensions from the ini, because I use this configuration also to distinguish markdown from html from url, etc.

In MarkdownViewer I simply do what HTMLView does (no detectstring). Probably, I'll add it there eventually.

[AntonyD]

1) without it, you can't switch off some extension

wrong - as I said: I CAN if I want to disable some extension for the plugin:
EXT!="HTML"

2) without it, you can't even tell which extensions are handled

Taking into account how unfriendly the dialog in Total is - how INCONVENIENT it is to perform this simple function -
to find out the list of supported extensions from list of plugins - then no, this is not an argument)))
After all, in that dialog, you can't see the list in a whole, you can't scroll, you can't zoom in enough to see everything.
Alas, it is not a help, but a torment to work with plugin lists with the built-in tools of Total.

[AntonyD]

In EdgeViewer the detect string is formed by gathering all enabled extensions

So definitely there is no needs to fill it - if the main action was done with help of INI content?
Coz: MarkdownView has NO detect string BUT it DOES have some list of extensions inside the INI file.
And MarkdownView can show SVG file for ex. - WHEN I will add this ext. at the HTMLExtensions
section of settings of INI file. and DETECT string was not involved in this flow...

[petermad]

You can always set the DETECT string to "FORCE", then the plugin will never be first choice when pressing F3, but only be used when pressing 4 one or more times or by using Lister's "Plugins" menu.

Or you can use Lister's "Define view method by file type" - then you have 100% control over which plugins are used and in which sequence when pressing 4

[rg_software]

So definitely there is no needs to fill it - if the main action was done with help of INI content?

Yes, it is true, and that's why I personally believe a plugin may get away without using a detect string. To me, detectstring is a leftover of times when every CPU tick mattered, and the documentation explicitly says that the point is to optimize: extensions are checked in the TC, and no need to load and call the plugin to figure out whether a certain file type is supported.

However, I got a few complaints for not supporting it, so here it is. If you don't like it, just make it empty. Detectstring is only formed when you install the plugin, so it's okay to modify it manually afterwards. In this case you'll handle the stuff specified in the ini file.

[AntonyD]

2rg_software
for the plugin MarkdownView may I suggest to add in supported extensions by default MHTML (you already included btw MHT!) and SVG?
and I did not understood - finally will you change the documentation that comes with the software?
I mean still markdown-viewer-2.4.zip does not have a proper Readme.md as I suggested earlier.

[rg_software]

2rg_software
for the plugin MarkdownView may I suggest to add in supported extensions by default MHTML (you already included btw MHT!) and SVG?
and I did not understood - finally will you change the documentation that comes with the software?
I mean still markdown-viewer-2.4.zip does not have a proper Readme.md as I suggested earlier.

My view is that the "proper" readme is the same as mine + some parts of the hoedown documentation. The current project has my readme + full hoedown documentation. So I don't think I need to change the readme. However, I can include hoedown.html and Readme.md into the zip, of course.