This is mainly an issue with large files.

When device rotation occurs, the page position changes due to many lines becoming wrapped (or unwrapped). This in itself isn't a horrible problem, but what tends to happen is this: 

I am at line 5500, the file is 6200 lines. 

I rotate to portrait. It pegs me at the bottom of the file. This clamps the y-offset.

Now I rotate back to portrait in hopes of returning to line 5500. I am dropped off around line 4000.

This is... not... ideal. 

One great way to fix BOTH issues is to check the line# and return me to that position upon device rotation. 

Note also that having a cursor present will prevent this issue (which is probably why this has not been reported yet). However having a cursor makes over 1/3 of the screen consumed by a keyboard so I *ensure* the keyboard is put away when I use Textastic to read code (as it's hardly practical to do actual coding), but it causes this issue every time (when i am near the bottom of a file).

So since I am JB'd i would use tweaks that let me force specific apps to be portrait-locked, but it's just not ideal because sometimes I do need to go landscape when the line wrapping gets to be overwhelming.

Can you add a button bar for frequenly used text? User assignable and/or script type specific buttons with common code blocks that would paste to the cursor position?

Why can't I preview my html

Is it possible to integrate iOS's mail app so u can email the files?!

In PHP, when you use // for commenting out lines instead of /*, instead of one single line ALL lines are colored gray.. // is used to comment out just one single line in PHP and is often used.. With your app, all lines after // are turned gray, as if it would function the same as /* So, since I start all my files with: //Note:... my entire files are grayed out.. ......Thanks! Great app you're creating here, keep it up! :)

The other day I tried sending a UTF-8 encoded LaTeX file as an attachment, only to find out that when the file arrived, non-ASCII characters (such as German ö, ä, ü and ß) had been replaced by two question marks.

I'm loving Textastic - really handy for editing files locally on my morning commute (with terrible reception) and then upload them on a decent 4G connection at the end.

I've just had one annoyance so far which is that detection of file type appears to go by the file extension only. The problem is that I commonly omit the extension for executable scripts (e.g. Python) so that the language is an implementation detail that can be changed later without needing to change anything that calls them.

It would be great if extensionless files could be detected based on Shebang line. So, if the first line of the file starts with #! and something like "python" or "ruby" occurs after it then the appropriate mode can be chosen. I suggest a loose parsing strategy like that to cope with different paths to interpreters, use of the "env" utility, etc.

I think it would be great if you added support for PAWN. If it was added, I would purchase this app in a heartbeat. I use PAWN to work on SA:MP servers. 

I purchased Textastic for the iPad recently and it has already paid for itself in terms of allowing me to code on go. I love that it supports custom TextMate bundles, since I work with some pretty obscure languages for embedded systems. The local hierarchical file system with WebDAV support and links to remote content is wonderful! It is just what I was looking for and I have recommended it to others at work who have been sitting on the fence about buying a tablet due to their apparent limitations. Apple should thank you for coming out with such a capable editor!