ActiveState Community Site - Some thoughts on how to further improve the great Komodo IDE - Comments

Thanks for the update

Lord_Bad — Thu, 22 May 2008 12:16:19 -0700

Thanks for the update, Eric(and for the fix of course). I'm looking forward Komodo IDE 4.4 and I'm hoping you'll have the time to fix more bugs from the list for it.

Best Regards,
Bozhidar Batsov a.k.a. Lord Bad :)

I remembered a bug being

bcorfman — Thu, 15 May 2008 05:43:51 -0700

I remembered a bug being filed for side-by-side diffs quite awhile back ...
http://bugs.activestate.com/show_bug.cgi?id=20732

Just a Komodo user's comment here ... Honestly, it's probably better for a Komodo developer just to drop a shortcut to their own favorite diff tool in the Toolbox. (Getting a diff tool right is, of course, a whole project in itself.) My favorite diff tool is SourceGear's DiffMerge, which is a free download for Windows, Linux and OS X.

http://www.sourcegear.com/diffmerge/

One request done for 4.4

ericp — Wed, 14 May 2008 15:20:02 -0700

Hey Lord Bad, we haven't forgotten the list, just been working on a mess
of different items.

Bug http://bugs.activestate.com/show_bug.cgi?id=74487 is now fixed -- this
is the one where when you type something like

@array.each do<|>

Komodo will place 'end' on the line underneath. That fix will be out
in the next 4.4 alpha ("<|>" denotes the cursor position).

I've added support for auto-insert of 'end' after 'do'

ericp — Sat, 15 Mar 2008 15:45:34 -0700

Hey, Mr. Bad,

Please see http://bugs.activestate.com/show_bug.cgi?id=74487

It's a big enough change that it needs a review before getting checked in.

If you can apply the patch and let me know if it works, great. Otherwise
I'll send you an updated koRubyLanguage.py and get you to try it out.

More thoughts on the ruby remarks

Lord_Bad — Mon, 28 Jan 2008 05:24:51 -0800

Hello, Eric,
Thanks for the quick response. I was very pleasantly surprised by your desire to respond to a user's feedback. Many companies ignore their products users totally, that's why I wrote my thoughts on the community forum instead of submitting them as bugs directly. Anyways - I'll know better for the future.

About your comments...

I totally agree about the numbers part. I thought that things were connected with floating point numbers, but your point on the issue of style(no magic number floating around) is even stronger argument for them to remain the way they are.

About the soft char "|" - it should be considered soft not only after a "{", but also after a "do". I'll add it as a comment in the bug.

About adding some default var name between || - I was thinking this to optional. You pop CI with ctr+j for example and you see "do", "do ||" and "do |item|" for instance. This adds some extra lines to CI list though so doing "|" after "do" will probably be enough to avoid clutter in CI list of suggestions.

- please, revisit this old bug. It would be very nice to have this feature.

Thanks again for considering my feedback and suggestions.

Focusing on point 4 (ruby suggestions)

ericp — Sun, 27 Jan 2008 16:55:10 -0800

Bozhidar, that is excellent feedback. Thanks a great deal.

Addressing each point...

* Numeric constant code-completion

> 4. Although the completion of Komodo is one of the best in business, I
> noticed some problems in it - particularly for ruby. Notions like
> 10.times seem to unrecognized for example. I think that | should be
> added to the soft characters for ruby as well, but enough of that, I'm
> deviating from my main line of thoughts. What I wanted to say is that
> although the code assist is very good it need a little polish.

The reason why we don't present a dropdown when you type "10." is
that it would annoy people trying to enter a floating-point constant.
If you press Ctrl-J (Windows/Unix) after the "." you'll get the
menu. We do present a dropdown after a second period, as in "10.0.",
because the second dot is not ambiguous.

As a coding style issue, if you assign 10 to a constant or variable,
you'll get the dropdown on ".", and you'll have one less "magic number"
in your code. On the other hand, we _could_ add a preference to present
the menu on the first period, but we try to avoid adding too many prefs. There
are other IDEs out there I'd rather <cough>ecl<cough> not name
which have tons of prefs.

* Soft char bar

Soft characters for "|" immediately after a "{" or "do" is a great idea.

http://bugs.activestate.com/show_bug.cgi?id=74485

* do: add an end

> - when a developer types "do" end should be auto inserted. Currently
> this is not the case. Examle arr = [1, 2, 3] arr.each do end

> Currently when I type "do", the cursor marker indents properly but no
> "end" is added so I have to write it manually which is tedious.

I've been doing more Rails work lately, and completely agree.

http://bugs.activestate.com/show_bug.cgi?id=74487

> It would be even better if besides "end" typind "do" would add
> something like |item|, since code blocks are generally used with yield
> passing value to them.

> arr = [1, 3, 4]
> arr.each do |item|
> print item, " "
> end

> Adding an |item| to single line blocks like

> arr.each { |item| print item, " " }

> would be valuable as well. Since in Ruby the analysis about what is
> method and what is not will probably be far from trivial, maybe it
> would be good idea if methods that can take blocks as arguments showed
> in the completion tool tip with or without a block associated with
> them and them you select "each" with a block, the block will be
> appended after the method call.

I'm not adding a bug yet. Features like these have to be somewhat
universal. You'll notice we never insert "standard" variable names,
because having to change one name for another can be more annoying
than having to type in your desired name the first time around.

> I realize stuff like that can added by everyone on their own with say
> snippets, but it's pretty standard construct and most Ruby IDE's would
> have it built in their code assist.

Definitely have a look at our snippets with tab stops.

> -methods like attr_reader, attr_writer, attr_accessor are not auto
> completed, though they are very widely used in class definitions.

http://bugs.activestate.com/show_bug.cgi?id=74491

> -same goes for methods for test cases like assert_equal() and so on.

That's due to a limitation of the Ruby code-completion engine. It's a
known problem, but I couldn't find another bug on it, so I added this one:

http://bugs.activestate.com/show_bug.cgi?id=74492

> Is code intelligence working only for methods from the Kernel module
> and methods from the current project?

No, it follows 'require' and 'include' statements, but doesn't handle
includes in included modules.

> -there is no code assist for instance, class and global variables.

http://bugs.activestate.com/show_bug.cgi?id=65403

> Also local variable seem to be added to the code assist without a
> notion of the scope in which they are valid. For example :

> class SomeClass
> end

> some_var = 5

> If I return to the body of the class and start typing so.. the code
> assist will display a prompt with "some_var" in it, though the
> variable is non existing in the scope of the class definition.

http://bugs.activestate.com/show_bug.cgi?id=74493

Thanks for reporting all these, and please feel free to add
new bugs in the future. A separate bug on each request
or breakage is easier for us to deal with.

Thanks for the response, my thoughts continued

Lord_Bad — Sun, 27 Jan 2008 11:41:15 -0800

Thanks for the super quick response on a weekend day. It is very nice to see for a change that a company takes some time to examine feedback from its products users.
I'll now comment on the points of your reply and more specifically on the version control diffs:

1. Perhaps a total rewrite of the project management system would be one of the great new features in Komodo 5, but for now file-type -> icon mapping and perhaps some more projects templates will suffice. Currently only 3 project templates are being shipped with the Komodo. There are many other web frameworks, besides rails after all and many developers using them.

2. The search improvements for Komodo 4.3 are great news. I'd recommend you to remove the "find function" from the code menu and add it to the unified search as well. Generally everyone expects to find all the search functionality in one place. Btw, when is Komodo 4.3 slated for release?

3. Diffs. What I meant when I said that the diff in Komodo are basic is that they look just as the output of the diff -u command(and I guess that's exactly the case since the source control has an section named diff options). This is perfectly sufficient for someone with a experience in diff and patch, but new developers tend to be frustrated by such comparison between files. Most newer IDE's present the diff info in two side by side frames for the two versions of the file. The removed content in the one shows greyed for example, the new in some other color and the intersection of the code is of the same color. Some tools like smart cvs, meld, eclipse's version control plugin even show arrows from the old file to the new one showing where changes occurred. Personally I think that this is an overkill, but nevertheless even if Komodo's diffs remain in a single frame I think that their representation should be improved for the sake of clarity and of course to attract more customers acustommed to using a more descriptive diff info. If I were to implement it I'd chose a single frame approach with the lines of source code from the previous revision colored grey and scratched with a thin line and the new code colored green with the intersection colored black(color scheme like always will be adjustable, I just like those colors). Depending only on a color scheme makes things more intuitive then depending on pluses and minuses.

4. Could you forward to Eric some other remarks about the Ruby support:
- when a developer types "do" end should be auto inserted. Currently this is not the case. Examle
arr = [1, 2, 3]
arr.each do
end

Currently when I type "do", the cursor marker indents properly but no "end" is added so I have to write it manually which is tedious.

It would be even better if besides "end" typind "do" would add something like |item|, since code blocks are generally used with yield passing value to them.

arr = [1, 3, 4]
arr.each do |item|
print item, " "
end

Adding an |item| to single line blocks like

arr.each { |item| print item, " " }

would be valuable as well.
Since in Ruby the analysis about what is method and what is not will probably be far from trivial, maybe it would be good idea if methods that can take blocks as arguments showed in the completion tool tip with or without a block associated with them and them you select "each" with a block, the block will be appended after the method call.

I realize stuff like that can added by everyone on their own with say snippets, but it's pretty standard construct and most Ruby IDE's would have it built in their code assist.

-methods like attr_reader, attr_writer, attr_accessor are not auto completed, though they are very widely used in class definitions.

-same goes for methods for test cases like assert_equal() and so on. Is code intelligence working only for methods from the Kernel module and methods from the current project?

-there is no code assist for instance, class and global variables. Also local variable seem to be added to the code assist without a notion of the scope in which they are valid. For example :

class SomeClass
end

some_var = 5

If I return to the body of the class and start typing so.. the code assist will display a prompt with "some_var" in it, though the variable is non existing in the scope of the class definition.

5. Thanks for the tip, I'll try it right away, but I still think that you should consider per language editor settings for future versions of Komodo.

I don't want my post to sound like criticism, I love Komodo and wouldn't trade it for any other IDE, but I want users of other IDE's to trade theirs for Komodo and the things that I suggest are one way to make something like that happen.

Best Regards,
Bozhidar

Great feedback

jeffg — Sat, 26 Jan 2008 15:55:51 -0800

Thanks for all the feedback, I'll to respond to each of your points:

1. Projects

The current project system is quite old and is suffering for its age. We've done a few things in Komodo 4 to hot-rod projects a bit ( Live Folders and Project templates mostly ) but we tend to agree that projects need a re-think and possible a re-write from scratch.

As for some sort of file-extension -> file-type -> icon mapping, that's a pretty good idea and may not be too difficult to implement.

In short, we agree generally, but making projects better implies a significant amount of work and likely won't happen for Komodo 4.

2. Currently search doesn't tie into the Code Intelligence data, however we are improving search in Komodo 4.3 in a couple of related ways. There is a new unified find/replace dialog that folds in 'find in files', adds 'find and replace in files' and also allows you to restrict searches to the current project.

3. Diffs. Do you have an example of what you're talking about? The diff window in Komodo is quite basic, but I guess I'm used to it by now and haven't used many other tools.

4. I've forwarded this post to our internal dev list, and I'll bug Eric ( our Ruby guy ) to see if your points can be addressed.

5. "It would be nice of the editor could be configured on language basis. For example the standard php indentation is 4 spaces, but in ruby it is 2."

We've had people ask for this and are considering per-language editor prefs, but this work isn't slated for 4.3. There are ways around this limitation using a simple Macro:

try {

  doc = ko.views.manager.currentView.document;

  filetype = doc.language;

  doc.useTabs = false;

  switch(filetype) {

    case 'Ruby':

      doc.indentWidth = 2;

      break;

    default:

      doc.indentWidth = 4;

      break;    

  }

  var msg = "Set indentWidth to "+doc.indentWidth;

  ko.statusBar.AddMessage(msg, 'editor', 3000, true);

} catch(e) {

  alert(e);

}

try {
  doc = ko.views.manager.currentView.document;
  filetype = doc.language;
  doc.useTabs = false;
  switch(filetype) {
    case 'Ruby':
      doc.indentWidth = 2;
      break;
    default:
      doc.indentWidth = 4;
      break;    
  }
  var msg = "Set indentWidth to "+doc.indentWidth;
  ko.statusBar.AddMessage(msg, 'editor', 3000, true);
} catch(e) {
  alert(e);
}

To use this code:

- go to ToolBox / Add... / New Macro
- paste in the above text and call the macro 'set indent' or somethign similarly sensible.
- on the Triggers tab, set the Macro to trigger on file open.

You can add additional cases in the switch statement.

--
JeffG

Some thoughts on how to further improve the great Komodo IDE

Lord_Bad — Sat, 26 Jan 2008 11:01:31 -0800

First I'd like to congratulate the staff of ActiveState for the amazing work that they have been doing for so many years in the field of dynamic languages. You're really great - keep those great tools rolling.

Now on my thoughts on the Komodo IDE. I have been a professional developer for quite some time now. In my career I have worked on C, C++, PHP, Java, Perl and Ruby projects among others and every now and then I have tried to find the perfect working environment. In the very beginning I thought that this was emacs, later on - eclipse and netbeans, but more recently as I find myself working mostly with Ruby and PHP I think that the perfect IDE is Komodo. I think so for a number of reasons - its lightweight(compared to eclipse or netbeans), it looks great in GNOME, it is highly customizable, it's extendable, it's highly integrated and it's makes doing your job fun. Last, but not least - it has a great name(unlike netbeans) and a neat mascot.:)

But even the best has always some room for improvement. Here follows my list of suggestion for improving Komodo, based on my humble experience:

1. Project creation/management can be somewhat improved. It would be nice to see in Komodo some notion of workspaces - current way to create a project asking you for some folder for the project is not very intuitive. Also it would be great if different file types had different icons associated with them in the projects tab - a .rb file could have a little ruby in it's icon, a .php file could have the php logo... You get my idea...
2. Search can be improved. I would be nice to have the option to search for a class definition, a method definition or a variable definition across an entire project. Also - the find function option in the code menu seems somewhat misplaced.
3. cvs diffs are really primitive - it's ok if one is used to working with diff and patch, but this might confuse some new developers.
4. Although the completion of Komodo is one of the best in business, I noticed some problems in it - particularly for ruby. Notions like 10.times seem to unrecognized for example. I think that | should be added to the soft characters for ruby as well, but enough of that, I'm deviating from my main line of thoughts. What I wanted to say is that although the code assist is very good it need a little polish.
5. It would be nice of the editor could be configured on language basis. For example the standard php indentation is 4 spaces, but in ruby it is 2.
6. There should be some built-in ability to reformat source code or at least an official extension. Code reformatting is very valuable, especially if you are working with someone else's code.

That's all from me folks. I hope you'll find some of my thoughts helpful.