Re: PSA: HTML fragment mode interaction between Chromium, Clipboard & Notepad++

Maria Sophia wrote:
> I have to force Notepad++ to rebuild the macro action list.
> 1. Open Notepad++ without shortcuts.xml in any editor.
> 2. Go to Macro  ->  Modify Shortcut / Delete Macro
> 3. Find the macro in the list & select it.
> 4. Click "Delete" & then close Notepad++ completely 
> 5. Open shortcuts.xml in gVim (or any editor that is NOT Notepad++).
> 6. Paste the original macro back into shortcuts.xml.
>    Make sure the U+2060 removal block is the very first Action
>    in the entire macro, before any other Action.
> 7. Save the file making sure nothing else related is running.
> 8. Start Notepad++ again and re-run the grueling test.

OMG. Give me a gun. I want to shoot Scintilla's developers! :)
(just kidding)

But I am frustrated... as they wasted my valuable time. 

I finally figured out WHY Notepad++ wasn't running the macros 
in the order I wrote them. 

I had to FORCE Notepad++ to rebuilt the entire macro from scratch!
Then it worked fine in the same testcase it's been failing on.

Jesus Christ. That's NOT intuitive. 
It's only intuitive AFTER you realize Notepad++ is rewriting
the shortcuts.xml (keeping only your comments of what you add).

Who knew?
Not me. 
Now I do!

Notepad++ does NOT execute macros directly from shortcuts.xml.
Once I forced it to read macros from shortcuts.xml... 
 Apostrophes are working.
 Zero-width characters too.
 Combining marks also.
 Double quotes, dashes, symbols and diacritics are working.
 So are invisible operators.
 Soft hyphen & line separators
 Even the Multi-word stress test is working.
 As is the mixed-chaos jumbled test.

And yet, I changed nothing in the shortcuts.xml file!
Jesus Christ. 

There was nothing wrong with the programming on my side.
It was all because Notepad++ doesn't do what we think it does.

Sheesh. Drives me nuts when I can't solve a problem.
As I almost never fail - so it was driving me nuts.

Mainly because I didn't understand what was happening.
My "logic" was fine (as I'm extremely logical).

It was simply that I was blindsided by Notepad++ changing the order.
Without telling me it changed the order.

By deleting the macro, the macro was finally rebuilt internally.
Notepad++ finally loaded the new action order
U+2060 finally executed first!

When Notepad++ starts, it reads shortcuts.xml ONCE.
It loads all macros into an INTERNAL ARRAY in memory.
After that, the XML file is ignored.

Only when we edit shortcuts.xml while Notepad++ is closed,
does the next startup load the new version... but... but... 

But... 

If the XML structure is malformed,
 or the macro is outside the <Macros> block,
 or the <Macros> block is empty,
 or Notepad++ rewrites the file,
 or the macro name changes,
 or the macro is deleted and not recreated,

then Notepad++ will:

 silently discard the macro,
 rebuild the XML in its own structure,
 and load the LAST VALID INTERNAL VERSION it had.

This looks like"Notepad++ is using an old cache.
 But it's not a cache.
 It's the internal macro array

Deleting the macro inside Notepad++ clears the internal array.

I'm out of energy for today, but I will try to build a 
version 4.0 (v4p0) that Notepad++ cannot reorder internally.
-- 
The problem with computers is we humans are trying to beat them.