Komodo is driving me crazy

Discussions
1

Hello again…

I can’t figure out how to deal with Komodo, i’m getting more angry from day to day.

Don’t know what you have done with the editor and auto completion thing, it has gotten so worse i can cry the whole day long.

I have dozens of situations where Komodos “auto code” changing algorithmus is deleting or changing parts of my already written code. For example i’m copying parts of my code to a specific position, press enter for some new lines a,d suddenly Komodo deletes parts of codes i already have written above maybe it thinks it belongs to this block.

The nex thin is the following: I copy some lines of code with an existing bracket “{” and insert it a few lines below.
What does Komodo do? It inserts the lines twice, one time on the cursor, one time above on the next found block. If i don’t have a look above imediately, i’m wondering about the parsing errors on the next page refresh.

This happens all day several times.

Guys, i don’t want to rant but this piece of software has run into so so much essential problems the last major versions that i will definitely change to another IDE. I don’t want to be annoyed with it anymore, since i’m struggling around the last 2 years. This is too much.

I’m really angry and upset because this seem to be a neverending nightmare of bugs.

Versions up to 8 were heaven, since V9 it’s hell.

2

Hi, I’m very sorry to hear of your troubles :frowning: I can understand how frustrating it is to have Komodo seemingly
do unexpected things to your code.

As it stands, unless you can provide us with some sample source code and a list of instructions on how to reproduce the problem, there is nothing we can do to fix the bugs you may be experiencing. Unfortunately, your descriptions are too vague to help us identify the problem(s).

3

Hello mitchell,

i know you are very helpful here at Activestate and problems can happen.
For me and for my personal experience i have reached the point where i will no more participate in solving problems and and helping in improving the product - years of problems and struggling around is enough - since its only getting worse since the new interface and the mozilla framework.

Just ordered PhpStorm because it has very good reviews and my testing was very smooth and the work was very productive with less to nearly no problems. Based in this experience, i will definitely change IDE to start getting productive again which got lost more and more since “re-inventing” Komodo.

4

I also am very frustrated by Komodo. I think there are a number of reasons why it is this way. There’s only one really big issue though, and that K10 seems to be coded in some XUL product, so you’re actually working with something that was designed to be a web browser (renderer) and not a code writer. Many issues I report I think are either because of that, or because people coding against that don’t know how to code it properly. That last one is speculation though, and may have more to do with OSX (i’ll get to that later)

Other than the backend challenge, there seems to be more stress put on adding new features to advertise rather than fixing stuff that is already broken. Maintenance is not sexy and sold licenses are already sold. It is much harder to sell the maintenance stuff than new features, but I think K10/11 is so bad it, that if they fixed the issues, K12 could be great and worth buying.

The big reason why I think it’s so bad from a product standpoint is lack of dog-fooding. Clearly, the Komodo devs don’t use Komodo for their day-to-day work (particularly on OSX).

I’ve mentioned OSX twice now and want to say that on Linux Komodo does much better. I am not sure why, but I’m definitely thinking it’s a platform thing. Remember XUL? I think it all traces back to the XUL engine not being used heavily on OSX, where Webkit reigns supreme. The komodo team should be forced to use OSX since that seems to be the worst possible experience.

I am trying out K11 again on OSX, and the new code completion is terrible. It’s supposed to be better but I can’t see what I’m typing because of all of the popups and none of them are what I actually want.

Let’s take a look at what’s new for K11 and see (what I thought) :
http://docs.activestate.com/komodo/11/get/relnotes/?_ga=2.48745510.1666734700.1518448546-1321762067.1504038814
Revamped Code Intelligence: (Would have been good, it it was intelligent)
Print Debugging: (Never thought my IDE should do this)
DevDocs.io Integration: (DK,DC Don’t know, don’t care)
Live Previewing: (DC)
Project/Folder/File Templates: (DC)
Dependency Detector: (DC)
Universal Package Manager: (DC)
Clipboard Manager: (DC)
Auto-Formatting: (This I like, but it’s a 1-time conversion)
Updated Publishing: (DC)
Other Mentionables
-Asynchronous remote files - work with remote files way faster (Could be interesting, but who isn’t using git for this?)
-JSHint 2.9.5 linting for enhanced JavaScript (ES6) support (DC, Why is this an IDE thing?)
-SDK availability (DC)
-Project template for Komodo add-ons (DC)
-User interface enhancements (Ok, this I care very much about but it was far too little)

The only reason why I am here is because Nathanr is responsive, and seems to care, but there is far too little for progress on my outstanding issues for me to keep using it. I’ve bought a license twice and been given one once (because that was easier than supporting K9 on Sierra!)

In the end, unless ActiveState’s management shakes things up and reprioritizes working features over shipping new ones (and starts really supporting OSX rather than an afterthought) I will not be buying another Komodo license.

I have had to neuter K10/11 and turn it back into a dumb text editor on OSX because it’s so terrible. The fundamental problem is if you leave K10/11 open for multiple days it starts beachballing and keystrokes lag by seconds. It’s done this since Yosemite, which is when I started using it on OSX. There’s clearly a problem with the XUL engine on OSX, but no one uses it enough to care to track it down and fix it. I think it’s because it’s in XUL, and ActiveState is not interested in actually fixing XUL, just using it. Nathanr and others play dumb about seeing this issue, but I’ve seen it on all 3 macs, on all versions of Komodo. I think if they dogfooded it they’d see what I mean.

As more and more devs get Macs, this will be a bigger and bigger issue. It might be too late, and Komodo is likely doomed. IMHO, their only options are to either fix the XUL engine they depend on or replace it outright. Between those two, there’s only one feasible solution. It’s far easier for me to just buy a license for something else and forget about Komodo, which I think the rest of the industry will eventually conclude.

And Petewulf, I’m at the same place… I keep filing report after report… of things that shouldn’t even make it out into the wild. But even so, the stuff I report never gets fixed.

5

XUL is not opinionated, and while we definitely have some problems with it the fact that it was originally designed to make a web browser is irrelevant.

Coding against it isn’t really the problem, the problems with XUL are inherent to XUL itself and sadly the maintainers of XUL (Mozilla) have expressed they will be moving away from it. We are doing the same, but this is not a short process. That said, OSX definitely has a tendency to throw a wrench into your codebases, especially if that codebase is cross-platform.

Sadly this is very true. We won’t have money to maintain Komodo if we don’t sell licenses. That said though we are very aware of this and are working towards a solution that should fully alleviate this. But again this isn’t a problem that can be solved quickly.

This just isn’t true, all devs and our QA team use Komodo on a daily basis on all three major platforms. That said we are small teams, so this doesn’t have as big of an effect as I’d like.

Frankly the reason is simple. Apple doesn’t give a damn about non-native apps. We had a huge bug a while ago that we reported and were told that basically this was introduced in some macOS update but the chances of this being resolved were slim to none so we should instead fix it on our end. Every time macOS is updated we’re crossing our fingers hoping they don’t introduce some new changes that will break something important. Linux largely doesn’t have this problem because backwards compatibility is actually important to the Linux ecosystem, and to a lesser extend this can also be said about Windows.

You are most likely running into a bug where completions become slightly unpredictive when working on large codebases. We are preparing Komodo 11.1 to address this. I do apologize for the inconvenience. The CodeIntel implementation for Komodo 11 was a large rewrite and in many ways is much better, but sadly it is taking a while to get it just right for all different use cases.

I’m sorry you do not care about many of the changes in 11, end of the day this is subjective and we cannot please everyone. I promise we’ll get CodeIntel fixed for 11.1.

I can’t say too much about what we are doing to address these issues, we have a lot of moving parts internally and a lot of them are frankly still to be nailed down. But many of the issues raised here are ones we are aware of and frustrate us as much as they do you. I want nothing more than to give you the product you want, that’s what I’ll continue to strive for.

6

Thanks for the insights Nathanr! I guess hindsight being 20/20 Webkit instead of XUL would be the way to go.

BTW, I managed to get cap of the most annoying code intel bug so far, this one should be trivial:

Here, and everywhere I type, it is showing me a variable is defined on the line as I type it (line: 805… while typing on 805), and it’s misspelled. (My bad) It should be ‘count’. I think this would be useful if it was telling me that if it wasn’t on the screen. (A line or two before would also not be helpful)

(Of course, I’m also missing a . ‘var’ in the for/of statement, but that’s another issue.)

FWIW, I am liking Qt, which might be up your alley if you’re looking to ditch XUL. They have Webkit and plenty of other framework choices… Fun story bra, Qt’s Text widget was turned into KHTML, which was taken up by Apple and turned into Webkit for Safari, and now Qt ships with Webkit. I’m not sure what QtCreator is in, but I recently did a document markup thingy exporting to JSON, and was able to do that in just over a day.

7

There is no way HTML would have been adequate back when XUL was invented though. And XUL definitely has its use-case. It just needs a maintainer that is dedicated to it, which sadly isn’t going to happen.

This is a good point, please consider filing it on the bug tracker.

Qt is definitely nice, although I’m not convinced it has everything we need. Then again if you don’t want HTML (because of performance implications) it’s probably about as close as you’re gonna get.

8

Just want to add my thoughts to this thread:

The new codeintel is not working out for me (particularly the CSS). Version 10 worked much better. Everytime I hit return / enter for a new line I get "-moz-appearance: " inserted for me. This issue was reported in guthub (and closed), which kind of improved in v11.02, but still doesn’t work flawlessly like it did before. I have to hit the ESC button now before I hit return. I still don’t see any advantages in the new codeintel.

On top of that the selector codeIntel doesn’t work either (https://github.com/Komodo/KomodoEdit/issues/3377), and I understand that it will be low priority to fix at the moment, most people wont know about or know how to use that, but that is the 1 feature Komodo had and no other IDE does (as far as I know), which really made me love version 10.

The SFTP crash I still get although I don’t use VM’s that often anymore (thanks to bash on windows) but occasionally I have to fire one up and Komodo still crashes when I try to connect to a VM.(https://github.com/Komodo/KomodoEdit/issues/1758).

Last point I want to make is JSX syntax highlighting & linting is not good in Komodo as it stands, I’m hoping it will improve in the next update - if the ESLint update will be included (https://github.com/Komodo/KomodoEdit/issues/3421).

I just find it difficult to find information on when the plans / dates for next update will be, what fixes / features & updates will be included etc.I would like to see more frequent updates / fixes / improvements. New features can wait a bit longer, but I don’t know how you plan your releases. I would love to know more about the future plans and roadmap.

Other than that, I still enjoy using Komodo, and I don’t want to change IDE. I have bought 3 licenses (Since version 9) and want to continue the support, but I would really like to see the above issues fixed before buying the next licence for the next version.

Hope that helps. Thanks, and keep up the good work.

9

People get really weird about XUL!

XUL was the absolutely correct choice at the time. It’s an IDE focused on web technologies using web technologies from a company that helped make the web technologies a thing on said companys platform that they pushed, aggressively, to everyone who would listen, as the solution to cross-platform, web-enabled apps.

That XUL didn’t age as well as everyone hoped is an accident of fate, not a failure of design. It was the correct decision at the time it was made, and it continued to be a good decision right up until Mozilla decided they didn’t need XUL any more.

WRT Apple, I like to phrase it a little differently than “they don’t care”. They do care, immensely! It’s just that their internal dev process is opaque and the product owner(s) are working “in service of something larger” which means that even if your app has 10 million users, whatever bug you need fixing might get ranked pretty low, because some other thing will serve some larger, long-term purpose. (probably related to something on the iPhone, but that’s another rant)

1 Like
10

Unfortunately this is something we simply cannot do beyond the communication we share here on the forums because our planning is always subject to change. Rather than burdening our users with this constant change and fielding complaints like “but you said feature X would be available by Y” we prefer to simply leave the planning vague until it has completely solidified. That also means we can delay releases if the quality doesn’t feel right to us without having to worry about community backlash about a delayed release.

11

Fair enough, that’s understandable :slight_smile: