What is your pet peeve in the IDE?
Mine are:
Thomas Tempelmann created an IDE script creating a useful history as a proof of concept. You can read his understandable rant about being ignored (in many ways) on his blog.
To add one: Currently the scrolling speed again. I spend a lot of time waiting for Navigator to stop, and I often hate myself for scrolling too ambitiously because that will add another five seconds easily.
Autocomplete is one of the best things about the IDE, except when it isn’t.
Where I find it falls down is in a namespaced environment. For example, if you instantiate a class that is defined within a module from outside that module, unless you fully qualify the class at instantiation time with it’s containing module, the autocomplete engine fails to work for any of its methods. Adding Using whateverModule at the top of the method doesn’t help the autocomplete engine either.
Example (assume we have a module named MyModule that contains a class called MyClass with a method named DoSomething()):
// This code is not in the module, let's say it's in `App.Open`.
Using MyModule
Var c As MyClass = New MyClass
c.DoSomething() ' <-- `DoSomething` doesn't autocomplete.
Now try this:
Var c As MyModule.MyClass = New MyModule.MyClass
c.DoSomething() ' <-- This will now autocomplete.
Do you have a link to this?
I wish that the IDE’s support for notes was more robust. I like to add notes (especially to interfaces where there is no code to document) but there are two issues with notes:
MarkdownKit!).Views of a Coder: Understanding bugs in Xojo, or not getting them fixed for the description.
I am not sure if the project is available somewhere. So sadly no.
That article is a great read. Depressing but great nonetheless. Thanks.
Xojo’s current history implementation is way better than it used to be
But it still doesnt have a notion of “this was open in a new tab” and so history is per tab
Some bugs remain but they are fixable
As for autocomplete its big issue is that it looks up symbols one way and the compiler does them differently. So syntax that is perfectly legal and understood byt the compiler is not understood by autocomplete - hence why it needs a fully qualified path before things work again
Writing a duplicate of the compilers name lookup in Xojo code isnt realistic - that alone was a several month project in the llvm based compiler. Duplicating it would be longer in Xojo code alone. And therein lies the rub - the RIGHT way would be to have the compiler constantly exposing names and such to the IDE but thats again is a big change from how things work currently. It would have been even when Joe was there and could have helped. Now ? I expect it wont get worked on as the right skill sets arent there to do it. Specifically Joe.
Urgh. I knew you’d say that.
unfortunately
I posted an internal case some time ago for me and joe to work on revising all this but …
the only other option would be to rewrite autocomplete inside the IDE using a completely different mechanism than it uses now
Fundamentally the main issue is that it uses the wrong algorithm for doing what it needs and that causes slowness and also some of the issues with resolving things that are not fully qualified
Its not impossible - just a really big job and then you’d have to keep the IDE implementation and the compiler one in sync
This is why it was thought that if the IDE could leverage the compiler to do this then it would not need its own implementation of the symbol lookup code
The trouble is that while it would be really nice the payback for such a huge investment of time may not be worth it. That would be why I would think it would not get worked on - it’s perceived as only having small benefits where other things that time could be spent on might have much higher perceived payback.
Tabs however could be made to be much better as that does not rely on the compiler and shouldnt be a huge rewrite at all
I do understand Xojo Inc’s argument here, particularly with a small dev team but it would be one of those projects that would make the entire Xojo app more of a joy to use. I guess joy <> 
.
It’s a tricky balance, isn’t it? When you’ve got customers screaming for features that their businesses depend on (AHEM Android AHEM) then it doesn’t make sense to dedicate scarce resources to something like this, but I’m sure we’ve all had customers jump ship when their minor frustrations with a product build up to a point that they’re no longer willing to deal with.
Also: hello, and thank you for creating this new forum!
Yup, the balance is tricky. But the bugs in the IDE are so annoying. Then you get a new feature like the macOS options in the FileTypes editor. Now I can’t open and close the filetypes anymore. And the scrolling isn’t quite correct.
Indeed it would be much like Y2K - lots of work to get something that you mostly perceive as being the same (maybe a tiny bit better)
With limited personnel, money, etc they do have to pick and choose
With it being such a big overhaul for an incremental benefit that was the trade off and I would presume still is
stuff like this makes me sad 
Couldn’t agree more. In a way that was one of the appeals of Apple products back in the day (less so now) in that there was quality in every corner of the products. Fixing the autocomplete issues would also have other benefits such as making using third party modules easier/more pleasant.
Hello and you’re welcome!
Dont get me wrong - i would have LOVED to have worked on this and made it so much better.
The triage that has to go on in any organization about where to dedicate scarce resources just determined that this was NOT high on the priority list. The cost benefit just wasn’t there to say it was a must do.
I would be fascinated to see how the autocomplete engine is implemented. I’m curious why the Using statement has no effect on it though - are the symbols within the namespace too expensive to add to the trie structure or something?
no tries
its ancient code and mostly uses a visitor pattern that is exhaustive (which is why its so damned slow sometimes)
like I said “it uses the completely wrong algorithm for what it needs to do” and is 100% backwards from what the compiler does
Doesn’t automatically show Syntax Help for object I just typed or autocompleted. You have to either move the editing cursor back or move the mouse pointer to get the Syntax Help to appear.
This request as been in Feedback for a couple of years.