While this isn't exactly an issue, I figured this might be the best place to bring your attention to support for iOS devices (and possibly Android, Windows 7, etc.). Obviously this wasn't possible with CodeMirror 1 and its use of an IFRAME and contentEditable, but with very little modification to codemirror.js I was able to get a functional version on my iPad and iPhone. That said, I think the future of CodeMirror on mobile devices is very promising, but there are a couple issues I immediately noticed that may prove to be very simple to solve.
First, for devices with soft keyboards the hidden textarea needs to gain focus in order for the keyboard to appear on-screen. I was able to work around this by making the text area visible and giving it focus. After it's initial focus, the keyboard responded rather naturally (but not perfectly) to focusing and blurring on CodeMirror itself. Further testing is needed, but I think it would be possible to make the textarea "visible" and position it absolutely off the screen to accommodate this.
The other problem I noticed is that, when the textarea receives input and is out of the viewport, mobile Safari centers the display on the textarea. This seems like it would be easy to fix by setting the vertical position of the hidden textarea to the same line the "cursor" is on.
Let me know what you think, Marijn. And congrats and great work on CodeMirror 2!
I unfortunately do not have time to test and hack and debug on iOS devices at this point. I'm happy to hear things seem to be close to working, and I'd very much appreciate if someone could contribute a patch that makes them really work.
The textarea is already visible, in that it stuffed in an overflow: hidden, zero-width div. Ths div is also already being positioned to prevent the scrolling issue you saw. I'm not sure what mobile safari uses to determine whether something is on screen. For all the big desktop browsers, the inside-zero-width-div thing seems to suffice.
I see...the textarea moves to the cursor location on click. I was under the impression that it was static and didn't move. I think that Mobile Safari is centering on the textarea before it is replaced, which might be worked around by manipulating the focus to occur after the textarea is moved.
If I get the time I'll play around with it some more. In the meantime, maybe a few more folks will jump in with some ideas. It's definitely not far off.
@claviska: you said "with very little modification to codemirror.js I was able to get a functional version on my iPad and iPhone. ". Can you post a fork with your changes? I've played a little with codemirror on the ipad today.
I unfortunately didn't save any of my changes. But to clarify, I didn't intend for "functional" to mean production-ready. The adjustments I made were very simple—if I recall correctly they were making the hidden text area visible and changing it's position just a bit. Once the text area was visible, CodeMirror worked to a reasonable degree in iOS, but it was still buggy at times (see my comment above).
I took a primitive stab at things, and made my experiment available here: www.litech.org/~schanzer/iOS
I haven't bothered with scrolling yet, only mucked about with selection and inserting the cursor.
I've considered doing something with a textarea like that, but it seems like a real can of worms wrt browser quircks. What exactly was not working in iOS before? I played around on my Android and, barring the scroll-bar absence, it seems to work pretty well.
Selection in iOS is great, but hard to fake - a contextual menu appears at the cursor location, and dots appear at the upper-left and bottom-right corner of your selection. Moving these dots extends or shrinks the selected area. You can't select anything outside of the inputDiv, which is a problem unless the inputDiv were to grow and move with the selection boundaries. I spent some time trying to make that happen, and then gave up and tried the alternate approach.
Can I ask what's the quirkiness that makes the other approach so bad? Assuming one restricts font-family and font-weight to be constant (line-height is already restricted), this seems work perfectly on all non-IE browsers. I'd rather have a simple core, with all the faked-cursor and selection code enabled only for IE.
There are multiple issues with keeping a textarea aligned. The biggest one is that it requires the whole document to be present in the textarea, so that clicks are interpreted properly. This gets slow for bigger documents. I simply didn't architect CodeMirror like this, and to change to this model is going to be a lot of work. If someone else does all this work, I'm very interested in the result. But I won't accept a half-hearted patch and then take on the burden of supporting it.
Understood -- for the record, I don't consider my tinkering around to be anywhere close to a patch. I spent a little time mocking something up that seemed to work, and wondered if you'd already gone down that road and deemed it foolish. I'll continue to play, and if anything legit comes back I'll be sure to submit a patch.
OK people, has anyone besides me jumped in and tried an iPad (iOS) with a Bluetooth keyboard? The only thing that did not seem to be working was the left/right/up/down arrows. I tried a number of ways to grab the values without success. Any ideas? I am using this keyboard but since the arrows work in web text boxes it doesn't seem to be a keyboard issue. It seems to be the way safari works on iOS. http://www.logitech.com/en-us/1111/8214?section=overview&tabs=1,3,2,4,5&hub=1
For me it seems most of the rest is up and running. It is in fact the best text code editor I have used on the device to date.
Nice! Possibly, the arrow issue is simply caused by those keys firing non-standard key codes in iOS. Could you go to http://mochi.github.com/mochikit/examples/key_events/index.html and see which (if any) key events are fired when you press the arrow keys?
There are no key events firing. This is strange because the editor works. I was expecting only the arrow keys to not work.
https://groups.google.com/forum/?fromgroups=#!topic/CodeMirror/exGdyp4NTOo is relevant here (an implementation of iOS selection behavior)
Marijnh, Copy and Paste works on standard 2.35 CodeMirror (just double-tap inside editor)! Only selection doesn't work! It's only required to repair select function. The schanzer's version is very large, has really a lot of issues, superfluous function of additional keyboard and works very-very-very slow (can't use it). We only need to repair selection on the CodeMirror to bring iOS support!
Relax, my friend. There's a lot of low-hanging performance fruit to be picked, but I'm working on making all the corner cases work correctly before I start optimizing. Native selection behavior is very difficult to emulate - if you can do it in less than 200 LOC, that would be wonderful!
👍 for better mobile support!
+1. Trying to find a decent code editor that will work on iOS. Ace doesn't support either.
This has landed in 5.0.