[schferk]

I

I've mentioned the problem under the rubrum "Homework to do". In short, if you edit an item, in UR, then (want to) go to another item, UR updates the index, and on a slow machine (netbook, etc., any modern device optimized for battery life instead for processing power, this can take (many) seconds.

So, if, e.g., you have an assembly of clippings you want to distribute into other (existing or to-be-created) items, you either wait after each cut (in order to be allowed to open the "other" item and paste, finally), or you look after work-arounds:

- Instead of cut and paste, you do copy and paste: You don't "touch" the source item, in order to prevent index updating here at least, whilst the index updating for the target, the "paste" item, in most cases is less of a burden since, hopefully, your target items will be rather tiny (but not necessarily so, and then you'll get the same problem as for the source item, here without a workaround). It goes without saying that your copy, instead of cut, will cause you much trouble re "what did I transfer already, what is to transfer?", hence your need, more or less, to do only SOME such copies, then delete the transferred passages (and accept the wait) - no such work-around if you shuffle around not paragraphs in a row, one after another, but a passage here, a passage there - if you try to copy instead of cutting, you'll create the utmost chaos in your source text.

- You try to divide your source text as much as possible, i.e. cut it up from 1 item containing 200 clippings into 10 items containing about 20 clippings each (but do real cut and paste instead of copy and paste). As before, this doesn't resolve your target items problem, and as before, it cannot be done in most instances where you need to transfer disparate passages. (For both alternatives, you can try to cut up too big target files, too, which only will augment your chaos.)

So, these work-arounds can reduce your waiting, but will heavily increase your processing time, for creating divided files, re-combining these files afterwards, etc., etc. It is evident this is unacceptable, and as I said in this forum, my main reason for leaving UR was indeed the fact that for heavy editing my texts, UR did make me wait much too long - the waiting deeply affected the quality of my editing, on top of the annoyance, so...

In reviews of (or just opinions on) UR in the web, many people mention the fact that UR is "more apt for text storage than for text processing", and of course, this "wait-for-the-index-to-be-updated" problem is behind this observation, more than any other possible factor.

II

I also said, other IMS do not make you wait in the same circonstances, and I mentioned MI. Of course, if a program doesn't have an index and only saves your files when you say so, as in AO, no problem with waiting, and indeed, AO is VERY apt for such editing tasks (but doesn't even have a search result grid, let alone Boolean search).

As I said before, MI seems to have intermediate indexes, that are very well updated after leaving any item, and the processing time for these is minimized (but not absent, as in the case of absent processing, as in AO), and then, whenever you "save" the file (or close down the program), these intermediate, additional indexes seem to be consolidated, and indeed, the saving time can be several minutes, for several files in which you did lots of changes.

This MI solution does NOT seem to me to be a superior solution, with respect to UR, since those intermediate indexes do NOT work without fault, and I got lots of stability problems in heavy duty work in MI, whilst I did NOT encounter such in the same type of work in UR. I'm only guessing, but I think that MI's way of updating indexes is just the kind of solution the developer was able to create, with the minimized wait time just a non-targeted side effect of his way to do it. (Speaking of experience with 5.07, haven't extensively tried v. 6.)

(It would be interesting to re-trial Treepad: They've got a flat file Business Edition, and a db-based Enterprise Edition. Would be interesting to see if a sw developer doing it BOTH ways, cares about response times, or if in the Enterprise Edition, there are response times being absent from the Business Edition...)

III

So what's the better solution, in order to maintain UR's incomparable stability and robustness, AND to provide people WORKING on their texts a frame for smoothly doing so?

As virtually always, the solution lies in creating an option. In normal run, have everything as it is, but implement the option to DEFER updating the index, very simply.

Deferring meaning here, have a sub-database into which UR writes the necessary info, i.e. the identification codes of the items in question, but do NOT do any intermediary index. Just put "item abc", "item xyz", etc. into a list, indicating that these items are ASYNCHRONEOUS with the index, and if really necessary in order to update the index afterwards, even store any previous content of any item accessed during such a "non-update-the-index" session into doubles of the items, i.e. if the user accesses an item abc, UR makes a copy of that item, abc[IndexedBefore], in order to "deduct" its content from the index later when the item abc (which is in fact abc[NewAndNotYetIndexed]) will be "added" to the index.

Deferring meaning that any index updating will not take place until the user closes down UR, or triggers the command "Update the index (and continue without updating then)", or triggers the command "Update the index (and resume live indexing)", or triggers a search (!) (which will trigger the command "Update the index (and continue without updating then)", and THEN the search only).

As explained above, these commands will trigger the processing of the intermediate db, each "openend" original item then being "deducted" by the index, and its current content being "added" to the index. (And the special db for this is updated, i.e. processed and cleared.)

This way, people wanting to shuffle around things, can do this as easy as they do it in index-free programs like AO, AND they work within an elaborate, high-standard program that delivers lots more than primitive offerings like AO.

For this feature to be implemented, no cost incurred, except, again, some 3 "man days", or make it 4 (ok, a week).

IV

All this has nothing to do with the editor in place... but that's not a reason why the current sub-standard editor in UR should not be replaced by something really good (and which reacts to the mouse wheel, like the tree does, and the editor does, in every other such program I ever trialed).