How dynalist organises the suggestions in the move item dialogue

[Stephen_Dewitt]

I chose the bug category for this, but it’s a bit of a grey area …

Anyway, I am interested here in how dynalist does this within the current document (I know it prioritises the current document over others and this seems to work for me so I’m not concerned about that).

Let’s start with the below nodes:

If I initiate the move dialogue on the ‘item’ node I get the below, which seems to suggest that the suggestions in the dialogue are ordered from top to bottom according to their order in the document rather than e.g. alphabetically - - it also doesn’t seem to matter where the test item is (e.g. in the below I have it in the middle of the list).

I am therefore a little confused why this same behaviour isn’t occurring in another context, my diary. I created a test version of this in its own completely separate document which looks like this:

If I try to move an item using the ࿂ symbol I get the following:

other searches give the same thing e.g. ‘Monday’:

So why aren’t these items being suggested in order, like in my test example? Can anyone from dynalist explain why this might be (all these suggestions are in the same document)? It would be really nice to figure this out as, firstly, when sending items to a day, it’s much quicker and easier if they are in their natural order. Furthermore if (as it seems) your general intention is for suggestions to appear in their natural order, this seems to be a bit of a bug.

[BigChungus]

Hmm is there a Feature Request on trello for improving Move query results?

Right now priority seems to be:

1. Regex match character by character (with any characters allowed in between) like query abc will regex .*a.*b*.c.* and bring up anything like sabgdcl

2. Scramble sort the list order randomly, maybe due to using some unordered list like a Python Set that helps efficiency by not storing the order

3. Group by (in current document) first then (not in current document)

That seems to be the extent of the sorting.

Feature request would be:

4. Subgroup by exact substring matches first

5. Subgroup those groups by bookmarked items first

6. Subgroup those groups by heirachy level, level 1 then level 2 etc

7. That’s probably good for order

[BigChungus]

Another annoyance: Completed items (a.k.a. strikethrough and pseudo-deleted) will show up before normal items with the same name, when they should be dead last in the results.

[Patrick_Barry]

I can add some details to this bug report, as it is a daily pain point for me in both the Move & Jump to autocompletes.

I have a simple reproduction of the basic problem of result order being pretty random and also changing even as you type characters that don’t change which results are valid:

Above, you see that the order of results doesn’t match the document structure. And then after typing the next character:

The results themselves haven’t changed, but their order DID change. The order here looks like the desired order.

I talked with Shida on the Dynalist discord and he said the current expected behavior is:

Every matched item is given a score based on how many pieces your query breaks into (lower is better), how far apart are the match hits (closer is better), where the first match hits (earlier is better), and how long the matching item is (shorter is better).
Those 4 scores are combined into a single score which is used for sorting the results.
I think if their score is identical then they get to keep the order they were in the document originally, since javascript uses stable sort

So this is definitely a bug.

I can also clarify what the secondary bug is that causes completed items to show up in the autocomplete results: it happens when the item itself is NOT completed, but it is a child of completed items. For example:

While understandable, I believe that is still a bug, and children of completed items should NOT be included in these autocomplete results.

I’ll make a separate feature request for making a better sort order. I agree with BigChungus that an item being at hierarchy level 1 should appear before an item at deeper levels even if the deeper item occurs earlier in the document.

[Alan]

Move needs work. There are far too many times when I cannot use Move because I cannot find the target. I could find the target with Search, but I can’t find with Move because it’s too limited.

[Jayden_Navarro]

I made a suggestion for improved weighting that I think would improve results, at least when displaying multiple direct matches within different folders/documents/hierarchies: Weigh items in same folder (or ancestor folder) higher in search results

[Shida]

Hmm I’m doing some testing and weirdly enough using the exact same document structure, I cannot reproduce this issue anymore. It seems to he the results are sorted correctly.

In general, I’m reluctant to add additional weighting adjustments, mostly because preferential adjustments (like by document closeness) will interfere with match-level scoring - you might be searching for “test”, and “test” might show up much later because the “closer” document had “tedious time” which also matches.

[Patrick_Barry]

Are you using the webapp? For the first example of searching for “3” I see the mac app doing the bad behavior while the web app on chrome sorts correctly as you show.

I can see how ranking complexity could grow quickly, but what about treating children of completed items as if they are completed themselves? This second example of having strikethroughed 567 as the top result doesn’t feel right to me.

[Alan]

My experience is I will type test and see plenty of lines with ‘test’ all of which are nowhere near where I am. In your example, Shida, whole word match should Always be preferable to letter matching.