How dynalist organises the suggestions in the move item dialogue

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:

image

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:

image

If I try to move an item using the ąæ‚ symbol I get the following:

image

other searches give the same thing e.g. ā€˜Mondayā€™:

image

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.

2 Likes

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:

  1. Subgroup by exact substring matches first

  2. Subgroup those groups by bookmarked items first

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

  4. Thatā€™s probably good for order

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.

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.

1 Like

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.

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

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.

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.

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.