Support local links to "external" files opened with iCloud Drive

Well, I added external files that are opened through the "Open…" command to the recent files list exactly for that reason. If the file does not exist anymore, it is not displayed in the list of recent files.

I figured it would only confuse the user if external files shows up next to iCloud files, especially if you have a lot of files in iCloud.

I would also like to display more information in the recent files list (like the file path or external app name), but this information is not available with the current iOS APIs.

External files is a nice way to interact with Working Copy -- but it would be good to have some structured representation of those external files outside of the recent files UI.

(I notice the recent files list has duplicate entries each time I re-open a file)

I find myself wanting something like the Local Files functionality for external files, particularly the remote server links, making it easier to FTP an edited external file up to a test web server.

Currently I make edits in Textastic to Working Copy external storage, then just use Copy All and paste the contents into a Local version of that Git file and then use the "Upload this file".

It shouldn't have duplicate entries for the same file in the same folder. It could display duplicate entries if you have two files with the same name in different folders.

Yes, currently you cannot easily use FTP with external files, but I haven't found a good solution for this problem yet.

There is only 1 instance of the file re.php and print.php in this repository.

I will clear the list and see if it continues to happen with my current workflow.

Expanding the way the data that makes up the "Recent Files" list is visualised would be a great help when working with a Git client like Working Copy.

Currently, external documents are treated like second class citizens, which has made me spend less time in Textastic and more time in Working Copy and Transmit for file upload functions.

I now use other text editors, which I hadn't considered until I realised Git is more important than any of Textastic's features, meaning the way the editor integrates with a Git client will drive my choice of editor for that workflow.

The lack of server links for external documents means there is no benefit to opening a document in Textastic as opposed to any other editor that can send a file to Transmit.

If you keep dragging your feet with version control features like Git then you will need to improve the way Textastic works with external files.

I'm currently working with the developer of Working Copy to improve the experience. In Working Copy, you will be able to choose "Edit in Textastic" to open a file from Working Copy in Textastic. You can then make changes in Textastic and choose "Save in Working Copy" in the Textastic action menu which will save back your changes to Working Copy and ask if you want to commit.

In Textastic, files opened like that will have file names like "filename_wc#1A2B3.txt" and will be under Local Files in the Working Copy subfolder. You can upload those files to remote servers and the file will automatically be uploaded as "filename.txt".

With iOS 9 multi-tasking on iPad you can then open Working Copy as a Slide Over which makes it pretty convenient to edit several files in the same repository using Textastic.

That is an interesting workflow and I have played with it in the beta version of Working Copy.

I know Apple has created this mess -- your hands are tied -- and the progressive changes cause extra workarounds, rethinking and inventive solutions.

Unfortunately, that workflow seems to be backwards in realtion to how I need my working copies to be treated by an editor under version control.

By using the external document picker or recent files list, I can get an instant picture of all changed files in the Working Copy file list and easily diff any of my uncommitted changes without needing to manually track changed files and individuallypush them back to Working Copy.

The Edit in Textastic model creates an unmanaged local file, which is something I've now moved away from, preferring to have the working copy exactly where it should be: in "Working Copy's" file store :)

It's really sad that Apple has made my finger the master of the External Document picker -- and that you and Anders and left to have to fight with shipping documents in and out of file stores!

Thanks for your efforts -- I trust that one day we'll be able to grant permission for cross-developer acess to files -- and that these kinds of issues will be a thing of the past :