[Spliff]

Thank you, Kyle, for clarifying SQLite's FTS is the culprit, I hadn't thought of this since in UR, there is a STOP WORD LIST: colum Keyword in table Keyword, which from its content, does NOT contain keywords, but stopwords, i.e. terms which are EXCLUDED from keywords, obviously?

a) Since I can't access that list (except from external front-ends), am I right that with FTS enabled, this stopword list (table) will never used by UR?

b) BUT from all what I assume (not: know), FTS is way better / faster than the "old" alternative, keyword management?

c) Ideally, I might thus find some special char that SQLite's FTS then has not excluded from its indexing (just Alt-0185 wasn't it)? (Technically, it would be possible - considering the user just uses (e.g.) Arial regular, bold and italics fonts - to replace a "char char" (i.e. not - excluded - "symbol char" within those fonts by a special sign (a big dot or square or something), to "deceive" the SQLite FTS...).


The SORT BY... problem

1) The only "sort children by" is (the not-so-obvious) "sort siblings", alphanumerically: This remains persistent, for those "siblings" and any new one later on, i.e. for the parent item's child items, as long as the user doesn't manually moves any item in there, from one sibling position to another.

2) Unfortunately, this is NOT able to recognize numbers or simili-numbers (e.g. calendar dates, e.g. in the form 2021-12-31) if they are BEHIND some text, so if you want to sort your parent item's child items by date, you would have to put the date in FRONT of the title, which is absolutely awful, whilst putting the date at the END of the title would be an acceptable solution!

Is the above here in (2) correct? In Tools-Options-Trees, there is "Alphabetically sort when adding children to new items", but this option will then (presumably) work upon ALL parent items in ALL databases, from then on, and will thus destroy any manual sorting anywhere, with any addition wherever - thus I suppose that almost nobody will ever "check" this (highly destructive) option.

I tried the assertion in (2), created some parent with the siblings:

Item 22
Item 12
Item 202
Item 3
Item 31

Then rightclicked and "sort siblings", result:

Item 12
Item 202
Item 22
Item 3
Item 31

Then, just for the fun of it, I renamed Item 22 to Itemsomething 22, and the item, as expected now, was automatically shifted from third position to last one.

Thus, my assertion above should be right:
- Automatic siblings sorting is strictly alphabetic, not alphanumeric, and ( logically, then, of course: )
- It doesn't identify numbers as such, and doesn't discard, for sorting, any text before the number, so the user can't expect some "ideal" sort in the way of

Item 3
Item 12
Itemsomething 22
Item 31
Item 202

3) Above, I had said that I often put press clippings, from several weeks, into some inbox, in bulk, and thus, they all get the same "creation date", whilst there is more or less disorder in their respective (but quite similar) publication dates; inadvertently, I had left out the much more important problem:

When then, I distribute those "inbox" items, into more appropriate "boxes" (i.e. sub-tree "headings"), I do this "chaotically", from often quite large "inboxes", and afterwards moving items into more appropriate "boxes" again, and this way of processing things will then create total chaos for publication dates, i.e. in the end, not even the publications from some specific week end up, within their final multiple, fine-grained "destinations", near to each other.

Hence the NEED for automatic sibling sorting of SOME kind, and in just SOME database(s), but there then for all parent items, e.g. by some setting as the aforementioned ("Alphabetically sort when adding children to new items"), or even for ALL items, BUT just DB-specific, or even (for users who use one db for "all"), specific for just one higher-up parent-item of a specific, in case quite big / deep sub-tree.

4) I haven't delved into title automation, but it seems whilst titles can automatically get the item creation date, I would have to continue to solve my publication date then by scripting indeed, since - very understandably - there is no AI implemented; on the other hand, external fiddling with UR's item titles is very easy, so the only user "problem" would be to get the (additional, here: publication) data into (i.e. at the end of) the titles, and then, they could visually check, change, etc., without creating db problems by that, since even externally, they would just work on ItemTitle in table Item, and as for FTS, if needed, they would just trigger a new index.

5) Many users, over the years (see those threads), have been asking for "tree children sorting by some other attribute", and I understand that just enhancing the already implemented abc-sort of the titles itself would be quite easy:

- manual sort as default as it is now

- automatic sort for all descendants of specific items, as further attribute values of those items (0 = no sort):

- this automatic sort attribute with two alternatives: 1 = alphanumeric (instead of alphabetic), and 2 = "precedence by 'numeric' sort, for numbers at the end of the title (after a space)" ('numeric' would include digit-strings, even separated by spaces and other special chars like "_", "-" and the like)

For 1 and 2 would then some easy regex code be needed, but I don't think this will slow down the tree display in any recognizable way, i.e. beyond some milliseconds.

6) MY MISTAKE, SORRY:

( other assumptions about Item Attributes pane EDITED out here: )

I was WRONG by asserting that the native UR "user keywords" would only be displayed by their dialogue: When there are such user keywords, then they appear in that pane, so the user will not have to open the dialogue but for setting more of them, not just for checking.