Komodo Edit support
In the early 1980s I learned the joy of programming computers. While other kids were engaging the the novel human experience of playing video-games (¿remember the Atari 2600?) I was engaging the novel experience of writing software for personal desktop computers. Starting with Microsoft’s Color BASIC®, I quickly learned its limitations; so I started writing in Assembly Language, the only real solution for doing anything substantial on those old machines with their limited memory and slow CPUs. Both languages came with an editor that matched the interpreter/compiler. Although I was working with the very first desktop computer to offer a color graphics display, the other fundamental limitations of the machine meant that these code editors displayed their text in monochrome with no code-highlighting. With BASIC, this meant code-soup; but with Assembly Language, the code was formatted with tabs into specific columns, so reading it was not so bad. The editor was so so poor, though, that I wrote my own (still no highlighting, though) in Assembly Language, which also required a new keyboard driver…ah the good ol’ days…and I included in that package “extended character” keybindings, similar to what I am presenting here, for the 120+ extended characters which that computer’s video-chip could produce (yes, the inherent text-display was not only monochrome, but had fixed-width characters at 80 columns with limited “2×2 block graphics”).
Jumping to 2004, I began to create websites, for my hobby at first. I made the mistake of using Microsoft’s products initially to create/edit/write the code. Oh, the garbage that produced! Then I found tsWebEditor. Wow, now this is a real “code” editor! And it was designed specifically with PHP, HTML, CSS, JavaScript™, and SQLs in mind (although it comes with support for many more programming languages). It does a superior job highlighting PHP and JavaScript™ when I compare it to any other (free) editor I can find. The main problem with it is it has no spell-checking. And now in 2014, since it has not been in development for many years, it does not support HTML5. Its worst bug is that it adds a random number of extra spaces to the end when you paste to the end of a line; just annoying enough to motivate me to move to a more modern editor under current development.
So now at the beginning of 2014, I’m trying to convert my workspace and workflow to using
Komodo Edit from Active State.
Its code highlighter is 2 or more steps down from tsWebEditor, noting only primary keywords and lumping
native functions, user functions, and constants, etc. into one other highlighting group,
with no error highlighting for & for & or
© for © — don’t cover the gamut of Unicode characters.
You could use “numerical entities,” but who wants to remember almost 300 different non-consecutive numbers
that associate with symbols, most of which that are only used maybe once a year?
HTML has no limitation on using extended characters directly in the text
(as does XHTML which requires using only ASCII characters).
UTF-8 is the strongly recommended character encoding for HTML5,
and there is usually no solid reason (see below) to avoid extended characters if you have access to them.
The resulting code is much easier to read, and even someone stuck with “MS Wordpad®” can read it
and at least copy and paste these extended characters to move them around the page if needed.
You can always still use HTML “entities” anytime you want or need.
Just be sure to remember to include a <meta charset="UTF-8"> tag at the top of the head of your
HTML document.
The only reason to avoid extended characters and use only
HTML “entities” is when you can’t guarantee that meta-line.
If you are writing a content-section of a page which will be included dynamically on a large website
with content maintained by many people, the issue of the charset is fundamentally important.
When exclusively using HTML “entities,” all characters are in ASCII,
so there is never a character-encoding conflict.
It only takes one unaware or forgetful person to
add a page-framework to the website which grabs extended-character-content from a database,
only to use the wrong character-encoding
(perhaps by using the default in Windows®
which is windows-1252 vs. UTF-8)
for the framework…
But under those circumstances, the website framework should “sterilize” any content added to the database
with a tool that converts all extended characters to HTML “entities,”
and then displays the sterilized content to the submitter for either approval or a charset-encoding-change
before saving it into the database
(see our PHP RegulateText class
for such a tool).
That then frees the content-producer to use quick ’n’ easy extended-character keybindings.
Komodo Edit allows keybindings, and takes them a couple of steps further.
It allows binding a string of characters (not just one) to multiple-keystrokes
(not just one modified key, but a distinct series of them), a drastic improvement over tsWebEditor.
This allows more total characters to be bound;
also now I have room to include some common HTML “snippets” for some “entities” that
either are non-printing or otherwise can’t be seen or distinguished, or commonly don’t have a glyph in any
actual font (browsers know the entity and create the character without a font-file); and I also included
some other common/often used ones including “<br>Return↵”
and “<br />Return↵”.
I spent several days programming them all into Komodo, reviewing them, fine-tuning the associations between
the extended Unicode characters and the keys they are bound-to, and documenting them.
This process required me to become aware of the default “command-action” keybindings for Komodo Edit.
Komodo Edit will list them by category, but I needed to keep track of them by key.
So I also wrote a
PHP program to convert Komodo’s output
of “listing by category” to an HTML page “listing by key” (see below to use this program).
I intended to share all this (with you, my friend, the reader of this page) from the beginning.
I actually tried out Komodo about a year ago, initially only to spell-check, and have been putting off
this keybinding project…but now here it is!
First you should take a look at the table of UTF-8 & HTML keybindings. This will show the matrix of extended characters as they relate best to each-other and to the characters on the keys to which they are bound; and it also shows the HTML snippet keybindings. I hope this format makes it easy to see, understand, and remember at least the most important extended characters and how to access them with just a keystroke (or 2). The table notes a few conflicts between the default “command-action” keybindings for Komodo Edit which my scheme overwrites with the UTF-8 keybindings. Mostly I never use any “command-action” keybindings, so this didn’t bother me too much at first, but then I thought “these really are useful to have,” so I modified the default keybinding scheme to move these “command-action” keybindings to the hardly-used Function keys (F1…F12). My worry is whether the Komodo IDE uses these Function keys, but I have no use for it (I run Apache), so I doubt I’ll ever install it, but if you do and want to use my schemes, please be aware of this.
The UTF-8 & HTML keybindings table also notes that the first 20 keys listed, when bound with the Shift+Alt and the Shift+Ctrl+Alt modifiers, do not generate the extended characters shown in the table to these bindings, at least when using Windows® 7 & 8; however they do work on Linux (Ubuntu at least). This table was adapted from the table of keybindings I set up for tsWebEditor, so I think the fact that these keys can be bound by Komodo but don’t generate is a bug. As noted in the instructions for the keybindings table, these “buggy bindings” can be alternatively generated using the Insert key in a two-keystroke process. I bound these extended characters to both the single and double keystroke processes, so if the bug is fixed in future editions, then you can use the quicker, easier single-keystroke.
installing it all into Komodo
You can grab the extended-character UTF-8 keybindings,
HTML keybindings,
and the Unicode friendly “command-action” keybindings and install them
into your copy of Komodo in a mere minute, where it took me several days.
The “command-action” keybindings come packaged in a zip-folder along with a high-contrast color-scheme for highlighting
PHP, HTML, CSS, & JavaScript™
that I call “SoftMoonWeb EZeye” that you may choose (or not) to install into Komodo also.
After grabbing and unzipping the keybindings, open Komodo Edit, and make sure the right-toolbar is open;
then right-click in the toolbar and choose “Import/Export” → “Import Folder from file system”
(make sure you choose import “folder” not “file”) and select the unzipped folder “UTF-8_snippets.”
Do the same for the unzipped folder “HTML_snippets.”
Installing the “command-action” keybinding scheme and the “SoftMoonWeb EZeye” highlighting-colors scheme
becomes a little more complicated, as Komodo does not seem to support saving, loading, and transporting these natively…
First you need to find the folder where Komodo Edit normally stores them;
this is of course different for Windows vs. Linux.
For Windows, open Komodo Edit and from the main menu, choose “Edit” → “Preferences” → “Environment.”
Look in the list of variables for “LOCALAPPDATA” to find the “base” folder where you will install the schemes.
This folder is C:\Users\user\AppData\Local\ on my Windows7® system,
and AppData\ is a hidden folder; so you must go to the Windows®
“control panel” and select “folder options” and check the box for “show hidden folders.”
From this base folder you must navigate your way to Komodo’s “schemes” folder; the complete path is
C:\Users\user\AppData\Local\ActiveState\KomodoEdit\10.2\schemes\ on my system.
(Note that the user\ folder will be named to match your Windows® user-name.)
For a Linux system, I'm not sure how to identify the correct folder for sure,
but it seems to be in the lib/support/schemes/ sub-folder of the folder you installed Komodo in;
the complete path on my system is /usr/ActiveState/lib/support/schemes/
With Komodo Edit closed, unzip the schemes that you grabbed, and copy the files to Komodo’s “schemes” folder;
then open Komodo, and from the main-menu choose “Edit” → “Preferences” → “Editor” → “Key Bindings” and then in the
pull-down for “Key Binding Schemes”, choose “Unicode Friendly”.
If you copied the “SoftMoonWeb EZeye” highlighting-colors scheme into Komodo’s folder also,
from the main-menu choose “Edit” → “Preferences” → “Colors Schemes” and click the “open Color Schemes Editor” button;
and then choose “SoftMoonWeb EZeye” from the “Schemes” pull-down.
Then click the “apply” button and do not choose “apply to interface” or “apply to widgets” —
only choose “apply to editor” — there is no going back (seems to be a bug in Komodo Edit 10) even if you choose another color-scheme,
and the scroll-bar, line-numbers, menu bar, etc. will all be hard to read instead of easy!
listing key-bindings by key
Even if you don't want to use the UTF-8 keybindings or the
Unicode Friendly “command-action” keybindings, if you have access to a PHP interpreter,
you can still use the
PHP program to convert
Komodo’s keybinding-by-category listing output table to a
keybindings-by-key listing table.
Just copy and paste the program text to an editor (like Komodo Edit), and save it to the appropriate folder
where PHP can access it.
Be sure to save it with UTF-8 character encoding.
Next, as noted in the program’s comments, from
Komodo Edit’s main menu → “help” → “list key bindings”
(this will open a browser window showing keybindings by category).
Generally, right-click on the page → “save as file”
|or| “view source” → “select all” → copy&paste to a text-editor and save.
¡¡ If you save the resulting HTML file via a text-editor,
be sure to save it in =its= native charset encoding
(windows-1252 on my system at the time of this writing) !!
Save the resulting HTML file in the same folder as the PHP file, and name it “keybindings_by_category.htm”,
then run the PHP file.
Note that Komodo Edit processes and generates the output for the resulting
“keybindings by category” HTML file,
and in doing so pays no attention to charset encoding; many (but not all) extended characters may then
unfortunately output as a ? or as an “ASCII alternative” by Komodo.
The final resulting “keybindings by key” program output not only provides an organized list as such,
but also highlights conflicting key bindings when two or more different
Komodo commands, macros, and/or snippets are bound to the same keystroke.
It can also include a “groomed” version of the original “keybindings by category tables” that is easier to read,
and also shows all the conflicting keybindings,
as well as diverging keybinding schemes when comparing (see below).
There is even an option to filter the output by keybinding categories…see the code comments for more info.
comparing key-binding schemes
You can use the same PHP program that lists keybindings by key to compare two different keybinding schemes; for instance, if you want to know the difference between my “Unicode Friendly” and the “Default” schemes. The resulting “keybindings by key” program output listing will highlight the keybindings that are unique to each scheme, as well as any conflicting keybindings, all in one. See the comments in the PHP program file on how to access this feature.
enabling virtual white-space
Remember the old Microsoft DOS® “edline” full-screen line-editor?
It created “lines” that were strings of characters terminated with an end-of-line sequence (specifically for use
with writing code), but you could click anywhere on the screen and start typing and it would automatically extend the
line with spaces to the position you clicked on; as opposed to a word-processor which is designed for writing
paragraphs of text, so that when you click on a screen-line past the end of the text on that screen-line, the cursor
is placed directly after the last character on that screen-line.
For writing code, I strongly prefer the old-skool “edline” concept, writing code-lines with no word-wrap,
and having the ability to click anywhere and start typing.
Quite often code lines are indented, and I want to just click and start typing the code, not worry about padding the
beginning of the line with tabs or spaces.
Also, quite often I have a line of code that needs a comment pointing out some little thing in mid-line,
and the best way to do that is with a comment on the line above or below, and again I don’t want to have to hold down
the space or tab key.
When I place my cursor at the beginning of a line, indented “x” number of characters,
I want my cursor to remain at that indent-position when I press the up or down arrows
and move it around the file, because I’m writing code, not plain text.
When I asked about this, I was told it’s an undocumented option available by macro.
Simply open the toolbar, right-click and choose “Add” → “new Macro.”
Choose the JavaScript™ language and for the macro enter the line:
komodo.view.scimoz.virtualSpaceOptions = 2;
To revert to static whitespace, use this one-liner:
komodo.view.scimoz.virtualSpaceOptions = 1;
I bind the macros to F10 and Shift+F10.
It kind-of sort-of works…
You can move the cursor up and down into virtual whitespace, but not left or right.
You can click anywhere in virtual whitespace and start typing, but you can not drag and drop to virtual whitespace.
However, the left-right problem can be fixed using macros.
It seems that the native internal code for processing the left & right keys
is different from a macro’s native internal code for processing the “move cursor left/right” functions.
We can easily fix the first problem by creating one-line macros:
ko.views.manager.currentView.scimoz.charLeft(); and
ko.views.manager.currentView.scimoz.charRight();
bound to the ← left and → right keys accordingly.
Don’t worry too much when it says you are over-riding the native command, it all works the same as before when
not using virtual whitespace; but when creating snippets and macros, these keys will not work in the “definition”
input box, but will when typing in the title. …ahh the little details of software engineering…
horizontal and floating scroll
In the default keybinding scheme, pressing Crtl+↑ Up
or Crtl+↓ Down makes the file scroll vertically, up or down.
To get the file to scroll horizontally, create two macros (see the last paragraph) with the following code:
ko.views.manager.currentView.scimoz.lineScroll(-1,0); for scroll left, and
ko.views.manager.currentView.scimoz.lineScroll(1,0); for scroll right;
I bind these to Alt+◄ Home and
Alt+► End.
I also create additional command-keybindings for “scroll file up/down” in Komodo’s
Preferences → Editor → Key Bindings window,
and bind them to Alt+▲ Page Up and
Alt+▼ Page Down keystrokes, to create a “matched set” of 4 similar functions.
“Floating scroll” means that the file seems to “float” behind the cursor, moving the cursor and scrolling the file in the same direction in one keystroke. This works both with and without virtual whitespace enabled. I bind them to Alt+(↑ Up|↓ Down|← Left|→ Right), over-riding the default “Editor: go back” & “Editor: go forward” keybindings, since that functionality seems to duplicate “General: previous file” & “General: next file” bound to other keys. The code for these floating scroll keybindings:
- Alt+←
- ko.views.manager.currentView.scimoz.lineScroll(-1,0); ko.views.manager.currentView.scimoz.charLeft();
- Alt+→
- ko.views.manager.currentView.scimoz.lineScroll(1,0); ko.views.manager.currentView.scimoz.charRight();
- Alt+↑
- ko.views.manager.currentView.scimoz.lineScroll(0,-1); ko.views.manager.currentView.scimoz.lineUp();
- Alt+↓
- ko.views.manager.currentView.scimoz.lineScroll(0,1); ko.views.manager.currentView.scimoz.lineDown();
You can simply grab these virtual whitespace & scrolling macros and install them into Komodo’s toolbar in a mere minute, or create them yourself manually in just a few…