UI looks ugly as sin
There are lots of chainsaws that look prettier than Husqvarna's and Stihl and yet those are the ones that most professionals will use.
Really, you are putting way too much effort into this argument. I learned how to program on 40x25 and consider what I have today an incredible luxury, if you want you can customize Leo to look better but to me it isn't worth the time, I would rather spend that time on my work.
Also, if you ever actually use a chainsaw, please do look at it as you are using it.
I would put glasses, ear defenders, gloves and boots higher on that safety gear list, when cutting firewood, doing minor pruning and lopping etc.. Wear a helmet when doing anything bigger, although wood is very dense and you shouldn't expect a helmet to save you if a decent size limb comes your way. Technique is everything - learn from an expert before trying it yourself.
Chain sharpening is a mystical, ancient art, all the experts I talk to have a different view on the right technique, ranging from bench grinders to intricate jigs to simple "file and feel". I've tried them all and it basically comes down to experience. Just as important is the even wear of the bar itself, once its worn more on one side than the other the cuts bend like bananas and you can only cut so deep before the saw gets no purchase on the wood at all.
I think chainsaws are as pretty as IDEs - which maybe isn't saying much, but I love 'em both anyway...
> Joseph Buford Cox invented what is now known as the chipper type chain for chain saws. He based his design on the C-shaped jaws of the larva of the timber beetle. > He only reached the fifth grade in his formal education.
from https://en.wikipedia.org/wiki/Joseph_Buford_Cox
If you think that sharpening is complicated now, think again, it must have been impossible before this guy.
This app is on most parts pure gargabe. Most things are just hacked together as pet features to satisfy urgent needs on the spot, and then forgotten as things "work". And those things have grown over the last 20 years, while the dev has no real clue about modern software development or UX, leading to the mess this software is today.
But if you reach the point where you accept defeat to this monster, and ignore all features, it can become quite useful.
I'd be interested to gain some insight into why you find Leo's UX pure garbage and how it should have grown over the years.
The key F1 opens the help-widget, which is an area with text, located besides the editor. This area is just there, has now controls, no way to move it or close it. There is some text in it that explains this area can be closed with some shortcut, except it does not work. I don't even know whether it's a problem with my setup, because leo,has no way to check this. Just broken by design. Notable is that this hacked-in area seems to be used by several other functionalitys and plugins. All with the same fails.
Another strange quirk of leo is the minibuffer. It's something people knowing emacs will understand, for the rest, it,s just a strange line at the bottom of the window not explaing what it does, what purpose it has or how they can use it. But ok, that's how it is, just following some fade of unrelated culture. Really interessing is the usage. You enter some text, then hit tab to invoke autocompletion and surprise..in another part of the application, unconnected to the textwidget of the minibuffer switches a tab and some new widget appears presenting a list of possible candidates. Not that Qt hasen't a way to present autocomplete-lists, but thats just how it is. Quirky hackish, ugly. And of only working as ling as the tablist is not hidden.
Another funny part is the menu. Just look up what is weitten in them, what name, what order they have, and how this compares to the established names and positions in pretty much every other application.
Or let's take the configuration. Nodes with some directives in the outline. No actual documentation or discoverability in the app itself. No support to prevent failures. Not even instant-loading of changed settings. Restart the program, good enough 20 years ago, good enough today.
Or let's take the API: Single letter variable names. Objects with hundreds of unrelated methods and no documentation. Plugins which are just python-modules imported from the python-path, and not real plugins with actual structure and API.
Oh, and the worst, plugins which just don't work and functions which have no obvious result because someone forgot to refresh the outline. Though, this is probably just one of the endless number of obvious bugs one encounters at some point.
I'm relatively new to it, but I did do a stress test once. Loaded several hundred (over a thousand?) files of source code. Apart from the initial conversion to nodes, it was fairly performant. Doing a cff on the whole code base was pretty fast.
I did have to disable the setting to poll for file changes, though. When you have so many files open, that will seriously slow things down. I believe this was over a network too (i.e. the files I was opening were on a remote machine).
On my old rusty system I usually experienced lags starting with some 10k nodes. Editor usually lags when content with longer lines (some hundred characters) or content with many lines (some hundred or thousand lines) is loaded. Directives in the content are influencing behaviour, as also the used syntax highlighting. Even activated features are influencing things of course. The declutter-code for example seems horrible ineficient and called way to often I think, but I haven't digged deeper there yet.
Though, it should be noted that in the last months some improvments were in progress, and the actual developer-version seems to behave a bit better on certain aspects. So version is also a factor.
My personal rule is to slim down leo-files when they go >10 MB.