Open Preferences dialog and switch to "Tab bar" section, while checking/unchecking "Show Tabs in Vertical Orientation" and/or "Show Tabs in Multi-line" (same for the context command "Toggle Multi-line with Mouse Wheel" ), the options in the Preferences dialog "Tab bar" section are not checked (or unchecked). So the added context commands make the incoherent behaviour.

@donho

Open Preferences dialog and switch to "Tab bar" section, while checking/unchecking "Show Tabs in Vertical Orientation" and/or "Show Tabs in Multi-line" (same for the context command "Toggle Multi-line with Mouse Wheel" ), the options in the Preferences dialog "Tab bar" section are not checked (or unchecked). So the added context commands make the incoherent behaviour.

I did notice this case when I implemented the feature.
But I do believe in a principle that we shouldn't make any anonymous changes (in the background) to the Preferences window while users are making their own, so I didn't do anything about it.

Remove "Show Tabs in Vertical Orientation", "Show Tabs in Multi-line" /* ... */ commands from the context menu.

Should I add these into the same PR with the "Toggle Multi-line with Mouse Wheel" feature???

and find a way (GUI) less confusing for this feature.

I figured out these 2 solutions for this issue:

1. If the Preferences dialog is open, the context menu will not display when right-clicking on the tab bar.
2. Send a message to the Preferences dialog to prompt it to synchronize changes with the context menu.

Which one do you prefer???

@donho
I've updated all the review changes and made some code modifications.

And I just found an issue:
When you have 2 split-views, if you right-click on this side of the splitter, the menu will pop up.
This also happens with the left-mouse double-clicking; it still opens a new tab even though the clicked point is not on the tab bar.
Do you think we should fix it???

Indeed.
We cannot use SplitterContainer class for notification.
User can make Scintilla editor's border very wide:

But even with the default value 2, it can happen:

I have no solution for it. Even there's one, it won't be trivial.
Since the feature will introduce the bug, it won't be merged in the master.
Thank you for letting me know about this issue.

@donho
Why don't we just keep this PR open until we figure out the solution for it???

For keeping my workflow as cleaner/simpler as possible.

Since the notification must come from the 2 splitterContainer, the only one solution I see is: test the right zone of splitterContainer to send the notification - it won't be trivial but you can try.
You can always do a new PR if you find the solution, I will merge it if it won't make the code more complex.

@donho
There is a missing case that I just found out now.
When clicking on the very left edge of the tab strip, it still creates a new tab.
Actually it's not a big problem, but I'll go ahead and fix it if you want.

I don't consider that a bug, so no fix about that will be accepted.