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 :

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.

So far I've only encountered non-breaking spaces in text that I've pasted from another App on the iPad.

I don't know if there's a way to enter those characters, such as by an external keyboard. Maybe it could be done using a TextExpander shortcut?

\n and \t are a good start -- can you add a sequence for non-breaking space.

Textforce is in my workflown regularly for its superior find and replace implementation.

I'm trying to find and replace some non-breaking space characters (A0) but find that the search box does not support those characters if I paste them. They seem to be ignored by the search method.

Alternatively can you treat space and non-breaking space as the same character when searching? So when I enter space (20) it will match A0 and 20.

Thanks very much for the update -- awesome :)

> I found that the row of additional keys is not appearing in the Replace text box (it is present in the Find text box)

I have a more sensible workaround suitable for searching OPML now -> the free app Nodebook is great for that purpose, so this is lower priority for my purposes now.

This feature is lower priority for me now that additional keys and textexpander are supported in the find and replace text boxes.

Thanks for your efforts :)

I see that both features are almost implemented -- Thanks so much for your fast implementation :)

> Although, I found that the additional keys are not displayed on the Replace text box which in my use case is used the same way as the Find text box.

Yep -- I understand replace would be best limited to Code mode only.

What I'm doing is exporting OPML from a mind mapping app that lacks a search feature. The markup is poorly formed -- no line breaks or indenting, so I can only see the hierarchy of nodes in Preview mode.

So, I'd like to use the search feature to find text in the outline rendered in Preview mode, without switching to code view which is not indented.

(I could use search in code view if it was possible to reformat xml-like documents with well formed indenting.)

I just found that the Additional Keys is already planned -- for some reason it didn't show up as a similar idea when I posted this...

Anyway, TextExpander would also be useful -- that's how I was planning to speed up some regular find and replace tasks I perform.