Plugin - "No Change" option, HTML & XML option, plus possibly additional file with context meta data.

[jasonjac2]

Problem to Solve

Low Tech automation - wanting the page and page info to be able to do my own processing on without ANY danger of damaging the ON page.
This will allow me to safetely and without having to enhance OneMore, have a hotkey (assuming you can assign a hotkey to a plugin) to utilise my page outside OneNote.

I get a couple of hours to tinker with productivity bits and would R&D some features before making suggestions.

Provide a clear and concise description of the problem, e.g. I'm always frustrated when...

Checkbox for additional information to be in an additional file:
Checkbox: Readonly - no write back
Checkbox Or choices: XML / HTML / Both
Page Info in a separate file
Sufficient to build a logical and linking structure:

• Notebook Name / GUID / URI
• Section Name / GUID / URI
• Page Name / GUID / URI
• Possibly indent level and whatever allows you to decide where it lives in the page order

New Feature/Solution

Provide a clear and concise description of what you want to happen.

Alternative Solutions

Provide a clear and concise description of any alternative solutions or features you've considered.

Additional Context

Provide any other context or screenshots about the feature request here.

THE FINE PRINT This is a hobby project that I started for myself. I'm happy to take requests and will promise to
consider each one carefully but offer no guarantees that I will ultimately agree to their
usefulness or have time to implement any of them. If OneNote offers a "close enough" work-around
then I will probably reject the request - you've been warned!

[stevencohn]

After a plugin is invoked, the plugin framework compares the contents of the XML file with the existing XML (page or hierarchy as the case may be). If they are the same, no further action is taken. The OneNote data model is only updated if the XML file has been changed by your user code. So yes, it's up to you to be a good citizen but if you follow the rules, no one gets hurt.

Exporting HTML and then invoking and action isn't something I considered for the plugin framework and am not sure it fits. By definition, you're losing information by converting to HTML so it would need to be a one-way operation - export only. It would likely be better to write a little utility that monitored a folder for new files and went into action when exporting an HTML file using the export or archive feature.

If you look here, you'll see that some page information is conveyed via environment variables, such as PLUGIN_PAGENAME. I could easily expand that list to include PLUGIN_URI and PLUGIN_OWNER (notebook or section ID or path). Note also that the GUIDs are embedded in the given page or hierarchy XML.

[jasonjac2]

Read/Write - Defo, but making it RO would save clock cycles on comparison and make it safer (even if only theoretical). For my use case, as you say, I would just not change the file.

Exporting HTML: I agree about loss, but you have to look at the use case - mine is to use the page info, not change it. To this end (and if it is quick and efficient) if I want to present any information to a user, it is likely to be as close to the ON page and so allowing ON to "render" it to HTML saves me having to do the conversion. Your choice B - write a file monitor is a good idea and I was going to do that, but Export to HTML to a set location is not a hotkey away is it? You have to make choices when you invoke it. I also liked my option as it allowed me to graduate from coarsely hacking a HTML file to elegantly slicing the XML file via the same plugin.

Very happy with adding the environment variables.

Thanks for all your time with this project.