> The cursor navigation wheel does not currently interact with touches on the code editor itself.

Then please, let it interact with them! All you need is to select all the text between the start and the end markers. 
In other words, the user should have two ways to move a START or END selection marker:
 
1. Using the arrows on the wheel (like now)
2. Touching any character in the text
 
Doing so will make the navigation wheel a very useful tool!

You can put a video of selecting using the navigation wheel that 2nd way on the app store, and people will surely be impressed (I know I would!).

> Hold shift on the on-screen keyboard

That is good to know, but it will still require the keyboard to stay open and not to close itself. But when you are searching for the END point of the selection, you always need to SCROLL, SEARCH, ZOOM OUT, etc. All those operations cannot be done without the keyboard closing automatically.
The navigation wheel instead, stays on top while you can do all those actions, and it will not close and will not make the selection disappear or reset if you touch the text or search for a certain line of code. 
That is what makes the navigation wheel (potentially) a very useful tool. 

Please just implement this so that finally Textastic will be great at selection too.🙏🙏🙏🙏

This bug is surely related to this:
https://feedback.textasticapp.com/communities/1/topics/3414-selection-improvement

This is the biggest BUG in Textastic: SELECTION OF LONG SECTIONS OF TEXT IS IMPOSSIBLE.  
    

BUG 1 - THE GUTTER SHIFT
If you use the keyboard, you cannot select multiple lines with shift+TAP on the line number.

Instead of selecting the entire intervening text between the insertion point—or the current selection—and the line whose number is clicked or tapped on in the gutter while holding down shift, only that particular line is selected. The app actually tries to do the right thing at first, but then it glitches and selects just the one line. It is sad.  
 

BUG 2 - THE NAVIGATION WHEEL

But if you don’t have a keyboard attached (that is, 9 out of 10 times), it is even worse!
No such "shift" option exists, not even as a button. You look around and only find that a special selection mode appears when you double tap the screen! But turns out it is useless!
Ironically there is such a big and shiny gadget to select text, but it behaves exactly like the manual selection!

In other words: when you click with the START OF SELECTION icon selected, it marks the beginning of the selection correctly. But if you scroll to the line where you want to END the selection and you touch it with the END OF SELECTION icon selected, instead of selecting all the text in between, it deselects the start marker and adds a new start! Why?!

Why it doesn’t just select all the text between the start marker and the current cursor position??
I really hope this is a bug. Otherwise, what is that gadget good for? Surely not for selecting small snippets. That is easily done by dragging the standard iOS selection with the finger. 

PLEASE FIX THOSE BUGS. CUT AND PASTE BIG SECTIONS OF CODE IS SOMETHING WE DO ALL THE TIME. THOSE 2 BUGS ARE REALLY TROUBLESOME. 🙏🙏🙏🙏

I agree. It is really stressfull.

When changing the encoding in the Document Panel Textastic should always ask the the user if he want to save (or save as..) the file in the new encoding (always alerting the user that the current text displayed will be encoded 'as is' in the new encoding), or if he wants to reload the current file using the selected encoding to open it (always alerting the user that doing so will discard all unsaved changes and reload the file). Also when opening the file it should autodetect the encoding (now it doesn't detect chinese GB18030 and open the file as garbage).

Two suggestions:

- If an non standard UTF-8 encoding is detected when opening a file, Textastic should show the detected encoding (for example chinese (GB18030) and ask if the user wants to use a different encoding to decode the text, (clarify that internally Textastic works in UTF-8 ) or if the user wants to preserve the original encoding when loading or saving this file (always converting internally to and from UTF-8). Textastic should be able to detect and display the characters of any encoding (this does not happens now.. chinese encoded in GB18030 is not detected and shown as garbage).

- If you switch the encoding from the Document Properties the app should ask if we want to encode the current visible document in the selected encoding (so that it will be saved as it is shown but in the new encoding) or if we want to reload the original file using the selected encoding (with a warning that doing that will discard any unsaved changes to the file). 

I agree.

Two suggestions:

- If an non standard UTF-8 encoding is detected when opening a file, Textastic should show the detected encoding (for example chinese (GB18030) and ask if the user wants to use a different encoding to decode the text, (clarify that internally Textastic works in UTF-8 ) or if the user wants to preserve the original encoding when loading or saving this file (always converting internally to and from UTF-8). Textastic should be able to detect and display the characters of any encoding (this does not happens now.. chinese encoded in GB18030 is shown as garbage).

- If you switch the encoding from the Document Properties the app should ask if we want to encode the current visible document in the selected encoding (so that it will be saved as it is shown but in the new encoding), or if we want to reload the original file using the selected encoding (with a warning that doing that will discard any unsaved changes to the file).