TextEdit also supports lots of emacs short cuts 
Most of this comes for free from the text input system on OS X so I’m trying to find the OS X std reference for what they are since we didn’t add any over whats there by default
But its always a pain in the butt to find this list
I hijacked this thread, sorry. Please see: https://forum.xojo.com/11309-keyboard-shortcuts-for-xojo to continue any discussion on shortcuts, if you don’t mind.
On my Linux Mint 16 (petra) cinnamon 32-bit install… I tried the following:
Opened System Monitor to view the CPU resources as I tested some scenarios…
I opened ‘gimp’, which is a fairly large application.
I moved my mouse all over the user interface… and the CPU usage never went over 8%.
I opened ‘LibreOffice Writer’, which is also a fairly large application.
I type stuff into the writer, as it did its checks and balances, etc. on my text… and the CPU usage never went over 11%.
I opened ‘Xojo’.
I moved my mouse over the UI… the CPU jumped to over 58% just from that.
I went to the IDE code editor and started typing… the CPU stayed ABOVE 90% THE ENTIRE TIME!
I simply opened a blank desktop project, opened the IDE code editor for the ‘open’ event handler of the window… and just held down the ‘Backspace’ key (not typing anything)… and again, 100% CPU.
This explains the extreme slow response issues with Xojo. There has to be a better way to optimize your IDE code for checks and balances on mousemove and typing events. It simply just doesn’t work great (works hardly at all) in the current state.
One drawback on the Mac is that it closes off an avenue for AppleScript. Normally, with a standard control, I can go through the app “System Events” to get or change a UI element, but it simply doesn’t see the code editor.
Yeah. With my code formatter for Xojo, I really wish I could do some more advance scripting, but I’m stuck.
Because standard text behavior would work and standard shortcuts would work, i.e.:
Command-g = find next occurrence
Command-Shift-g = find previous occurrence
Command-e = enter search string
This way you can select a string, Command-e, Command-g, and find all occurrences of the string without ever opening a search dialog. Works in any standard OS X app, even browsers, which are not even text input fields.
In Xojo, you have to open the Find pane, and use the mouse to click & scroll your way through the results.
<https://xojo.com/issue/12310>
“Not reproducable” 
<https://xojo.com/issue/12311>
“will not be implemented in a short term”
I guess I know what that means… 
Or Drag & Drop of text: No transparent text, no insertion point for the drop point. No problem for me, but it was irritating when I started with RB.
Or non-continous multiple text selection: Not possible. Also no big deal, but could be handy for example if you want to cleanup the ordering of code lines.
[quote=92264:@Christian Vick]Because standard text behavior would work and standard shortcuts would work, i.e.:
Command-g = find next occurrence
Command-Shift-g = find previous occurrence
Command-e = enter search string
This way you can select a string, Command-e, Command-g, and find all occurrences of the string without ever opening a search dialog. Works in any standard OS X app, even browsers, which are not even text input fields.
In Xojo, you have to open the Find pane, and use the mouse to click & scroll your way through the results.
<https://xojo.com/issue/12310>
“Not reproducable”
<https://xojo.com/issue/12311>
“will not be implemented in a short term”
I guess I know what that means…
Or Drag & Drop of text: No transparent text, no insertion point for the drop point. No problem for me, but it was irritating when I started with RB.
Or non-continous multiple text selection: Not possible. Also no big deal, but could be handy for example if you want to cleanup the ordering of code lines.[/quote]
FYI - None of those require it NOT be a canvas or work just because its a text area
A text field/area simply won’t let us do some of the custom things we need to do
So a canvas it is
And that means code to handle all the cases you’ve outlined
Ah, Norman, I’m not complaining that it is a canvas. I understand that you want more functionality than a text field/area can provide. I’m just moaning that it lacks standards functions/behavior. 
Thanks for updating the Feedback case. At least now it is a feature request.
[quote]Most of this comes for free from the text input system on OS X so I’m trying to find the OS X std reference for what they are since we didn’t add any over whats there by default
But its always a pain in the !@#$% to find this list
[/quote]
I tried to find in the dev docs, but found it finally in Apple Support:
http://support.apple.com/kb/HT1343?viewlocale=en_US&locale=en_US
Under “Application and other OS X shortcuts” there are lot’s of text related shortcuts, also Command-F/G.
Btw, when I look how Xcode does code folding, I could imagine they have a plain NSTextView for the editor with a canvas on the left side for the code folding/breakpoints drawing. If code is folded they add a tiny graphic (the dotted yellow bar) into the editor (RTF with images?), and do the arrow drawing on the left canvas.
Behind the scenes the folded text lines are tracked, with the folded text stored.
Speculation, but this is roughly how I would approach it.
[quote=92564:@Christian Vick]Btw, when I look how Xcode does code folding, I could imagine they have a plain NSTextView for the editor with a canvas on the left side for the code folding/breakpoints drawing. If code is folded they add a tiny graphic (the dotted yellow bar) into the editor (RTF with images?), and do the arrow drawing on the left canvas.
Behind the scenes the folded text lines are tracked, with the folded text stored.
Speculation, but this is roughly how I would approach it.[/quote]
This is sort of how they do it. WWDC 2010 had a good talk on how the Cocoa text system fits together (?Advanced Cocoa Text Tips and Tricks) and briefly touches on line numbering and folding.
The ironic part of this entire conversation is that EVERY thing in a modern “GUI” based system (and by that I mean anything NOT running on a VT-100(ish) terminal) is for all intents and purposes a “Canvas” [sure each development environment calls it something different, and encapsulates the functionality a different way). But ever since we left those “terminals” behind, there was no such a thing as “TEXT”… everything is graphics… everything is drawn (sure the terminals “drew”, but a totally different paradigm)
TEXTEDIT, BBEDIT, every IDE you can think of… they all fall under this same category… “GUI” = Graphic User Interface… it is all a matter of semantics and packaging
Dave, you’re right, but it is a bit philosophic. The point is why/why not using native text views/inputs with their built-in bells and whistles, whatever they called on each platform.
The same as the reason you are driving a modern car. I mean after all… a Ford Model-T has 4 wheels, and an engine…
The point being, each solution has different requirements, different functions they wish to provide. If all we needed to do was drive from Point A to Point B, and nobody had the need for more speed, air-conditioning and FM Radio… the Model T would still be on the road and in your driveway.
[quote]Why is the code editor a canvas?
[/quote]
Because it is like it is.
There isn’t always just one way of doing things. It works for us and is well developed. If you have another/better well developed solution than make it public here.
Just my two cents
Its been a canvas for nearly 9 years