Cranioscopical, if I'm not very mistaken, I even trialled that editor, and it does not display all occurrences of a search string at the same time. If I'm mistaken, please rectify.
NoteCase Pro is what they call an outliner, right?
And then a wiki even.
I had not thought of such alternative software forms. So here the task would be "display all items which have one or several key words/strings in them" - I currently do not see their advantage over a more traditional database, all the more so since the latter could be queried by simple sql queries, and a general translation problem would subsist.
In fact, I have tried to do some planning for exporting my text files into a database, and I have found that this task is not that easy, because, as described, I currently organize my data into "pages", for - 3-column - printing and also for searching/looking up on the screen: When I see some entry, it's within a vicinity of similar entries, and all of which are below some title or some title/subtitle titling/header hierarchy (1-3, sometimes 4 only).
If I put my data into a database, this titling/subtitling will be lost, or I will have lots of work to do: For every text line/record, I need the hierarchy of its respective titles in additional fields - or spread over several several tables, with foreign keys -, and if then I want to look at some record together with similar records, I would need an sql query with the respective titles AND subtitles, OR I refine the titles/subtitles in a way that I need less hierarchy for these, or in other words, I could try to replace my title hierarchy by flat tagging, with some tag combinations when necessary, in order to simplify the queries and especially in order to simplify the "typing" when searching for some group of entries.
In other words, I had not been aware before that if I want to transfer my titling hierarchy into a database, my queries would become very worded, since I the subtitles are neither unique nor do they come with sufficient info, that info being within the titles higher-up. In other words, I become aware of a difference in the organization of a hierarchical text file and a database: The database can select by many more criteria, but the criteria in your subtitles will be lost if you don't recode all info which has been in your titling hierarchy, now optimized for database usage - it's simply not realistic to put, and then into a mobile device, sql "where" strings which add up to 150 characters, while in title/subtitle combinations, that many characters do no harm.
So I will have to find very short codes/tags instead, but which I can memorize at the same time, or/and even reorganize my current titling hierarchy and with that the textlines grouped by them. This is fascinating, but comes totally unexpected.
If I put my data into an outliner or a wiki instead, these titles/(sub)categories were either lost, or then, instead of putting each line into an outliner/wiki item - as I would put each current line into a distinct database record then -, I would need to create the titles/subtitles as items, and put multiple textlines into those items, in other words, they would remain grouped as they are now in the text files. This would be quite messy, as it is now - but with better search IF the outliner or wiki displays lists of search results - and I would not take advantage of what databases could do additionally.
SQL allows for searching/grouping of any records that contain value x in field a, value y or z in field b, and so on, and at the very least value x or/and value y in LINE a; RegEx search provides the latter functionality at least also for text files. But if I put my textfiles into an outliner or a wiki, I even lose this functionality of combining values x and/or y in the same line, meaning the same record, since the records in an outliner or wiki are not the text lines in an item, but the items, and "search for value x and/or y within item a" would NOT display just the corresponding textlines then, but any outliner/wiki item in which ANY of the textlines/records would comprise these values, which is obviously not the needed result.
So outliners/wikis seem to be an alternative, but a lesser one, or then, you put every text line into its own item, which technically would be possible I suppose, but which probably doesn't make too much sense since these instruments seem to have been created for more developed texts, not for single text lines - but for processing text lines, editors are a very natural solution.
Of course, there is always the problem of currently having combined info in ONE text line, an example from just one of my files being one author for several book titles but which are separated by ";" which do not occur otherwise, so technically it should be possible - if not easy - to distribute this info into several text lines, each with its own, repeated author information, there being a ":" after the author. Then, often, there are several authors, in my example file, but here again, RegEx probably could help, since in other cases, there is no "," before the ":".
Similar for other such files: All of them are sufficiently organized (some with special characters like "[]" for example) in order for some automatic reorganization appearing possible, before translation into database.
But it's quite a project.
So in my requirement above for a Android/iPad text editor - just a list for the search results all together -, I mistakenly had left out my requirement for Boolean search, so there should be "or" and "any" and perhaps "not", and all that for the line, not for the file/grouped item.
It's evident that's too much asked for in a mobile editor, and it also brings to light the enormous advantages of a database - or an Excel/spreadsheet file, but to a lesser degree, since as I said above, a flat database would need a descriptions hierarchy to replace current titling, while in a correct database, you would put the descriptions into additional tables, then just put the keys into the core table. I do not know yet what the creation of such a mobile database would imply, but I currently play around a little bit on my desktop, SQLite and several frontends being available. In fact, it's from trying to plan the database that I discover that my source file is far from being database-ready, it's really two very different formats, from the conception on.
