Awesome, looks pretty good to me! 👍

@sjtringali So I just noticed a fairly hilarious bug that I think started in this PR :-P.

I added a "zoom" feature to nedit-ng (Ctrl++ or Ctrl+-, or Ctrl+ScrollWheel) which basically increments or decrements the font size...

But I think after the size increment tweak, now the window also changes size when it do it, LOL.

I'll take a look into it, but if you can help with a proper solution, that would also be great :-).

Ah. Historically nedit has kept the same row/cols through font changes, like changing the font size in a terminal preserves the row/cols. I like the behavior.

But maybe that doesn't make sense anymore or when using your feature. It should be easy enough to take the geometry, recompute it, and store the new row/cols. Maybe only do this when it's full screen, or it would make it larger than the current screen.

What behavior do you want?

You know, I just tried it and it works as you expect with marco on xfce, the window stays the same size. Maybe it's window-manager dependent?

On my Mac the window size stays the same when I zoom the text, which is the behavior I prefer.

The window does resize (gets wider) when I open another file if necessary to accommodate the number of open tabs (tabs can only get narrower down to some minimum width). On Linux some scroll buttons appear when the tab bar is too narrow, but not on the Mac.

Do we have document mode enabled for tabs (they look like terminal tabs, not dialog box glossy).

I hadn't really noticed before but yes, they do look just like the tabs on the Apple Terminal:

@sjtringali I may roll back the the fontChanged bit because it does make the "zoom" kinda unusable on a KDE desktop.

What particular issue did that code address for you? If it's a matter of WM hints being used to show the size of the window in characters, there's also an undocumented config settings to have nedit-ng show that info on resize itself.

I also agree that we should run it in a separate thread, I'll look into it.

I think the key think it'll need to make sure it's done right is a reliable cancel ability, which isn't always trivial with threads, but I think we can pull it off :-)

Oh, I see what the code is for. It makes the window resize in increments of characters according to the current font.

I have no idea why Qt is choosing to resize the window when that setting is being updated :-/ I'll have to look into it.

@sjtringali what I REALLY want to do is work out how to best move macro running to a separate thread, and possibly eventually, a separate process.

If we ever get it to the point of being a process, we get a few benefits. Mostly that if a macro somehow crashes or otherwise misbehaves, it won't take down the whole thing losing your work. But it will also mean that it's easier to do things like implement alternate scripting language support like python or lua.

I can say that ctag loading is now much faster thanks to the efforts of @tksoh !