Komodo Edit 4.0.2 bug and suggestion list on 2007-03-24 ################################################################################ My system and installation (for information) ================================================================================ - CPU: P4 3C. - RAM: 1GB. - OS: Gentoo Linux. - sys-libs/glibc-2.5 USE="-build -glibc-compat20 -glibc-omitfp -hardened (-multilib) +nls +nptl +nptlonly -profile (-selinux)" - sys-libs/lib-compat-1.4.1 USE="+sdl" (note that on Gentoo, this version supports both C++ libc-5 and libc-6 compatibility) - x11-libs/gtk+-2.10.6 USE="+X -debug -doc +jpeg +tiff -xinerama" - I used package Komodo-Edit-4.0.2-275451-linux-libcpp6-x86.tar.gz (with the official installer, for the problems not related to the Gentoo Linux ebuild) Komodo Edit 4.0.2 bug and bug-like problem list ================================================================================ - By default, my AltGr key was moving my cursor back one character, like the left arrow key. In the configurations, there was only mention to the left arrow key. I removed the shortcut, restarted Komodo, then readded the shortcut to the left arrow key, and restarted Komodo again. Now, the AltGr key works correctly (and the left arrow key too). - By default, the "Komodo resources toolbar" is visible, though the checkbox, in the preferences, is unchecked... If I check the case, and then uncheck it, the toolbar is then, correctly, not visible. - In the preferences, if I check "Show Open/Find toolbar", "Show macro toolbar", "Show Komodo resources toolbar" (and maybe others, and maybe for other kind of options too), and then, without clicking on "ok", I uncheck them all, then, when I click on "ok", the toolbars are shown... if I go back to the preferences, the checkboxes are checked... if I uncheck them, the toolbars are properly not shown anymore. - There does not seem to be syntax highlighting (bold font, by default), in PHP, for variables with full UTF-8 names (like "$月" -Japanese kanji character for "moon"). PHP allows any letters, so it should be supported (even if it is not quite clear in the documentation, as they give only examples with ASCII letters...). Well, maybe it is just my font which does not have bold style for these Japanese characters, or that the bold style for these characters is not bold enough... in this case, well, I guess you cannot do anything about it... - The line feed (and carriage return, when using Windows new line sequence) symbol is too visible... it should be changed to light gray, maybe with a dark gray -not too dark- text (the "LF" text), maybe as an option (use a separate color highlighting rule), as some people, when doing very precise work, might want to have very visible new line symbols (well, maybe...?). The same goes for tabulation symbols, though it should not be as light as LF/CR symbols, as the arrows are already quite thin. In the preferences, for common syntax color rules, there is a "stringeol" element type, but it does not seem to work, or maybe it is not for the EOL symbol...? - In the line feed (and carriage return, when using Windows new line sequence) symbol, the characters are one pixel too low, so, for example, the bottom of the 'L' letter is not easily readable, on a white background... (note it would not change much to use a darked color for "LF" -it would still feel awkward-, as suggested in the previous note, as it is a different matter...). It should be centered vertically, with at least two pixels of padding. (Note that I use "DejaVu Sans Mono", as my font, and the text of your "LF" and "CR" symbols depend on the font used, but I get mostly the same result with other fonts -the text is not vertically aligned). - The color of the line feed (and carriage return, when using Windows new line sequence) symbol, depends, in some cases, on the text color... for example, it is generally black in the normal context, but it follows the color of the comments, in multiline comments (strangely, not in single-ligne comments), which is not good. It should be of a unique color. When indenting multiline comments, the arrows to signify tabulations are also in the color of the comment, which is bad too. As for space symbols (the thin middle dot -which should be kept thin, to avoid confusion with the real middle dot -\xB7), I think it should be kept black, to stay as visible as ever (if using light colors, it becomes too light). - In the preferences, the first time, I selected the "DejaVu Sans Mono" font, instead of the default "Bitstream Vera Sans Mono" font... Komodo asked me to specify a new name for the scheme, I inputted some name, confirmed the name, but then, the font (the font name in the select field) turned back to the default font. I changed it again, and changed the proportional font too, but after having confirmed all this, after having set other options in other categories, by clicking on "ok", when I came back to the preferences, the font was, again, set to the default "Bitstream Vera Sans Mono" font... I put back my fonts, I clicked, directly, on "ok", and when I came back to the preferences, my fonts were, at last, properly set. - By default, there was "Bitstream Vera Sans Mono", for the fixed-space font, but also for the proportional-space font (instead of "Bitstream Vera Sans"). - There is a delay of like two-three seconds, after having started `komodo`, without any information about what is going on (and when launching it from a terminal, the executable detach itself from the terminal, silently, so we might think it crashed silently). Then, there is another delay, about two seconds too, when a session has to be restored, after the main interface (menus, icons, panes) are loaded, before the previously opened files are reopened (and it does this even when only one file, of only a few lines, has to be restored). - I cannot reproduce it, but I think I remember there was some delay, when there was a need for some completion, in PHP... maybe it was just a very short delay, before the completion list was shown, and it surprised me a bit, so I couldn't continue typing without looking at the completion list... I'll tell you if I encounter this again... - The default color for comments, in PHP, is too dark (too close to the black color, used elsewhere, like for variables). The lighter gray, one step lighter, in the preferences, is better. - In PHP, when I start a multiline comment ("/*"), possibly input some text, then go to the next line, and, without writing anything on this line, close the multiline comment ("*/"), the automatic indentation inserts around ten tab characters, before the closing symbol. The correct behaviour would be simply to not do anything (the automatic comment symbol completion -which add "*" symbols, properly indented, on new lines-, already align everything, so we only have to add the '/' symbol, after an automatically inserted '*' symbol, to close the comment). - The panes are named "tabs", in the menu "View" => "Tabs", and named "Pane", in the tooltip of the workspace toolbar... and then, on the same toolbar, named, again "Tab", in the "Show Tab" button, at the far right of the toolbar... (a button which is strangely redundant, and does not seem to work for me...). Or maybe all this is in prevision of supporting the possibility to move tabs accross panes...? If so, you should have waited, and even when it will be supported, it will be a bit confusing, so care should be taken. - In PHP strings, quoted with double quotes, variables can be included... they are indeed identified by Komodo, as variables, but not when using the full syntax, that is "${Foo}bar example" (curly braces after the '$' sign, around the variable name). Komodo 4.0.2 suggestion list ================================================================================ - The automatic comment symbol completion -which add "*" symbols, properly indented, on new lines-, should also close multiline comments, on the next line (both after having inputted "/**\n", and "/*\n*"). - Round corners (notably on tabs and buttons), and general related light eye candy (nice box/pane/borders), like in Eclipse. Probably as a separate skin, for people who don't want it. (Can all this be modified by a generic GTK theme? -well, in all cases, if you can use a custom theme, it would be nice to include one (possibly a well-separated theme, if the theme is global, which could be used for other GTK apps, and modified for other systems... -so some free license should be used)). - Close button on tabs (and keep the one on the far right, and the tab menu, and the file menu, and the keyboard shortcut... a good example of good redundancy :)). Certainly make it an option (activated by default, though), because some people will freak out about the twelve-pixel per tab "wasted". - Add a tiny bit of vertical and horizontal margin on tabs (a bit more on the horizontal, than on the vertical), so the text is better separated from other tabs. As above, certainly make it an option (like "Wider tabs" -but not too wide, right, 2px above and below the text, and 5px on the left and right, seems quite ok (if you add a close button on the tab, be careful that the spacing around the button is ok too)). - The text on the tabs is misaligned vertically. On unselected tabs, the text should be two pixels higher. On selected tabs, one pixel higher. However, if, when selecting the tab, the text seems to jump down one pixel, you shouldn't do it. In this case, you should probably modify your tab styles for select tabs (the one pixel white line at the top of select tabs gets in the way... if it cannot be put one pixel higher, maybe you should just change the way you signify that the tab is select -if you create an Eclipse-like theme, you would just have to change the tab color saturation, or something like this, without worrying about 3d effects). I looked at a screenshot of the Mac version of the Komodo IDE (http://www.activestate.com/_images/untour/screenshots/find_problems_fast.png), and if you want to keep the current theme, the active tab on this version is better... (though on the screenshot, the tab text is heavily misaligned horizontally, and I don't like the vertical bars between the tabs -you can't mix 3D effects on inactive tabs, and flat style on active tabs). - "~/.komodoedit/4.0/host-localhost/XRE" takes 3.5MB, and "~/.komodoedit/4.0/host-localhost/codeintel" takes 26MB... though I don't care at all about the size, when I'm at home (well, it does complexify backup a bit, because I don't want to backup 30MB of mostly temporary files -I guess some files must be kept, in the XRE directory), there are some people, on public computers, notably in some educational organizations, which might sometimes heavily limit the user account maximum space (and might not accept to increase it by 30MB -some system administrators, in these organizations, love to torture students), and this might become a problem. If they get to the main interface, I guess they could deactivate the option, and remove the files manually, if they are not recreated at startup, but they might not even be able to get there. Maybe you could permit a command line option, to use /tmp (or nothing, if optional -it would sure mean deactivating some functionalities, but it's better than nothing), for large temporary files (though the directory might get cleaned regularly, but that's not that big a deal, to have like one minute of loading, when you are on a public computer, and will be working for some time). When first launching Komodo, maybe there could be some alert box asking the user where to put these files... (maybe only if the space left on the account, before installing the temporary files, is about less than twice the needed space -like 60MB). - By default, the "" sequences should be bold, black. It's more visible, which is important, because it is the limits of a PHP script, so it has a huge signification. - In HTML, tags should be bold (the name, and the '<', '>', '' sequences, when used as part of the tag -though to be perfect, we should be able to set a different color for these characters), by default (it makes them far more readable). - By default, maybe you could use orange for PHP comments (well, for all languages), instead of gray. Generally, there are too kind of people. People who think comments are here only as documentation for others, who don't know the project, and people who think comments should generally be read *instead* of the code, before checking how it is implemented, if needed. For the first kind of people, gray comments are indeed what they expect, because it makes them less visible... For the second kind of people, orange comments (the orange with 3,3 coordinates, starting at 1,1, from the top-left corner of the color selector) are far better. As you allow to easily change the color scheme, maybe you can keep gray comments, and let others set the comments as orange... AFAIC, I think orange is better, by default, because comments are so important for readability, but I understand you might not want to change your default color scheme too much. - By default, PHP variable names should not be black... light or dark blue (in bold, whatever the color), is better, and more common (be careful it is distinguishable from quoted strings... notably strings quoted with double quotes, as variables can be included in them). - Strings quoted with single quotes, and with double quotes, should be distinct (we must be able to set them in different colors), at least in PHP. In many languages, they do not work the same (most escape sequences, and variables, do not work in stings quoted with single quotes -and you properly do not colorize variables, in strings quoted with single quotes), and it would be nice to be able to set different colors for them. In PHP and some other languages, you can also use heredoc markers (`$Foo = << [Comment]", "@Tag [Comment]", "@Tag ", etc.). Note that they should also be supported in XML/HTML... (taking into account the various possibilities for comment opening/closing symbols). - When creating a new file ("File" => "New" => "New File..."), the extension of the template files is not shown in the file list... While the directory structure, and file basename could be enough, it is always good to be able to check the file extension... Same for project templates, even though the extension is standard... (I don't think Komodo is oriented to the kind of people hiding file extensions under Windows).