|
Yes, absolutely, I had mentioned that in my very first version of my post, then had deleted it (.rtf in this case, Atlantis stores natively in this format).
As said, UR does it all right (even for Atlantis), it's just that some applications - like Atlantis, obviously -, then don't save to a .../temp/... path, so the correct path is correctly transferred to the application by UR, and the file is correctly created over there, but will not be handled for saving, and this may be a specificity of Atlantis indeed, OR then also apply to some other, as exotic as Atlantis is, application, and that was the only reason I left my thread.
I had only discovered the source of the problem after trying with MS Word (which works fine, and which gave me the full path, which I then observed in further tries; the help file states %temp% but that didn't indicate it sufficiently for my, thus the full path in my post above.
"Atlantis" is a hybrid if I may say, it's far more elaborate like the usual "rtf editors", BUT it's lightweight, compared with MS Word, thus it's unfortunate that I had to discover its fail for serving as UR's external editor.
I fully understand that the internal, basic MS editor does NOT find/replace tabs, newlines, etc., and thus replacing them will not be possible internally even if you do something in the line of my "multi-item search-and-replace" suggestions.
Using an external editor here though, item by item, will produce a lot of forth-and-back, so I decided, for my typical use cases, to:
- first get a search result list (for "string ... within project = sub-tree ...")
- work on that list by copying the respective contents, one by one, into the "rtf editor", WHILE putting some special "item end string" (i.e. a special character) after each such copy-and-paste
- do the multiple searches-and-replaces in the external editor, and check / amend the results in there visually / manually (while not "touching" UR, in order to not lose the search results list)
- do the import of the (changed) item contents back into UR, using the search list again, and using the "item end characters" to distinguish the items from each other
Changes in titles being made faster by a (even free) general SQLite interface (second search "titles only" for that), or, if they are in tiny number (i.e. below 10 or 12 or so) manually.
This being said, it's obvious that very few "multi-item" search-and replaces also will demand tabs, newlines, etc. to be replaced
(or created: in the very first version of my post above I brought the example of
something: something else
becoming
something
something else),
so implementing some sort of "internal macro" doing the necessary switches between multiple entries of the search result list and the respective item contents, will obviously be of tremendous help.
|