37.5 - new nove issues but thanks #4001

New Issue

giteasync · 2025-10-01T16:35:36-05:00

giteasync commented

2025-10-01 16:35:36 -05:00

Originally created by @pcause on GitHub.

First, thanks for adding this feature. It is great.

I have a top level note called articles, it has 2 dozen sub notes, and they each have more notes and subnote. I right clikc move on a note somewhere else in the hierarchy (Journal) and select move. I get the filter box and type Article but then see just 3 possible items. I am misunderstand the search? are titles or content or path being searched? I'd assume path.

Is this a bug or I am misunderstanding what is being searched as I type.

Originally created by @pcause on GitHub. First, thanks for adding this feature. It is great. I have a top level note called articles, it has 2 dozen sub notes, and they each have more notes and subnote. I right clikc move on a note somewhere else in the hierarchy (Journal) and select move. I get the filter box and type Article but then see just 3 possible items. I am misunderstand the search? are titles or content or path being searched? I'd assume path. Is this a bug or I am misunderstanding what is being searched as I type.

giteasync commented

2025-10-01 16:35:37 -05:00

@pcause commented on GitHub:

I kind of disagree with this. I use a note to create a folder hierarchy. I am trying to organize using the hierarchy. COntent of the notes isn't at all relevant to my filing/hierarchy. I think my case is more traditional but see the point of your case. Perhaps an option to select which whay to file.

On your too many choices issue: perhaps the solution is to show the first N matching items. The user can then type more to get a match. So I might type articles and see 10 things and then type "Articles/software" and see that match on top and ten other items, and then "Articles/software/android" and that is on top and others below and I can keep typing or select to put the note as a child of "articles/software/android"

Another approach is to show the N shortest matches that and in the types text in their path. In the above example, typing "software" might show "Articles/software", "Articles/software/android", "Articles/docs/software", etc. To narrow I'd then type "software/android".

Lastly you can allow regex entry. So I could enter *android^ to see all apths that end in android. If there are lots of matches, you just pick N, and I have to narrow my regex.

@pcause commented on GitHub: I kind of disagree with this. I use a note to create a folder hierarchy. I am trying to organize using the hierarchy. COntent of the notes isn't at all relevant to my filing/hierarchy. I think my case is more traditional but see the point of your case. Perhaps an option to select which whay to file. On your too many choices issue: perhaps the solution is to show the first N matching items. The user can then type more to get a match. So I might type articles and see 10 things and then type "Articles/software" and see that match on top and ten other items, and then "Articles/software/android" and that is on top and others below and I can keep typing or select to put the note as a child of "articles/software/android" Another approach is to show the N shortest matches that and in the types text in their path. In the above example, typing "software" might show "Articles/software", "Articles/software/android", "Articles/docs/software", etc. To narrow I'd then type "software/android". Lastly you can allow regex entry. So I could enter *android^ to see all apths that end in android. If there are lots of matches, you just pick N, and I have to narrow my regex.

giteasync commented

2025-10-01 16:35:37 -05:00

@dosubot[bot] commented on GitHub:

Your suggestions for path-based, hierarchical, and regex search in the move dialog line up with feedback from other users who want more control over search results. Right now, Trilium's move/autocomplete search requires at least one word from your query to be present in the note's content or title—not just in the path—to avoid flooding the autocomplete with too many results. The number of results is capped (e.g., 9 in some dialogs), and this limit isn't user-configurable. Regex and path-only search aren't currently supported in the move dialog, though Trilium does support some advanced search features elsewhere, like substring and out-of-order matching, but not in this context yet. The design aims to balance specificity and usability, but there are ongoing discussions about improving search usability, including showing full paths and making note titles stand out more clearly in results. Recent updates (like the new command palette and scoped search) improve navigation but don't add path-only or regex filtering to the move dialog yet. Your feedback is definitely in line with what other power users have asked for, and it's helpful for future improvements.
Source 1 | Source 2 | Source 3 | Source 4

To reply, just mention @dosu.

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

@dosubot[bot] commented on GitHub:  Your suggestions for path-based, hierarchical, and regex search in the move dialog line up with feedback from other users who want more control over search results. Right now, Trilium's move/autocomplete search requires at least one word from your query to be present in the note's content or title—not just in the path—to avoid flooding the autocomplete with too many results. The number of results is capped (e.g., 9 in some dialogs), and this limit isn't user-configurable. Regex and path-only search aren't currently supported in the move dialog, though Trilium does support some advanced search features elsewhere, like substring and out-of-order matching, but not in this context yet. The design aims to balance specificity and usability, but there are ongoing discussions about improving search usability, including showing full paths and making note titles stand out more clearly in results. Recent updates (like the new command palette and scoped search) improve navigation but don't add path-only or regex filtering to the move dialog yet. Your feedback is definitely in line with what other power users have asked for, and it's helpful for future improvements. [Source 1](https://github.com/TriliumNext/Trilium/issues/5174) | [Source 2](https://github.com/TriliumNext/Trilium/issues/3516) | [Source 3](https://github.com/TriliumNext/Trilium/issues/756) | [Source 4](https://github.com/TriliumNext/Trilium/pull/6491)  *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/24ff55bc-ef37-4dfb-af05-6cf7cc3ee63b?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/24ff55bc-ef37-4dfb-af05-6cf7cc3ee63b?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/24ff55bc-ef37-4dfb-af05-6cf7cc3ee63b?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/24ff55bc-ef37-4dfb-af05-6cf7cc3ee63b?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/24ff55bc-ef37-4dfb-af05-6cf7cc3ee63b?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/24ff55bc-ef37-4dfb-af05-6cf7cc3ee63b?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/24ff55bc-ef37-4dfb-af05-6cf7cc3ee63b?feedback_type=other)</sup>  [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/4af773a7-9840-4978-96dc-c436f6f437cf/ask?utm_source=github) [![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot) [![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/TriliumNext/Trilium/issues/706)

giteasync commented

2025-10-01 16:35:37 -05:00

@zadam commented on GitHub:

When you type into note autocomplete, trilium searches the paths, but ... it's more complicated.

In short at least one part (word) of what you type must be present in the actual note and not just in its path.

The reason for that is that otherwise it would be very difficult to find notes with many children because the autocomplete would be overfilled with them.

@zadam commented on GitHub: When you type into note autocomplete, trilium searches the paths, but ... it's more complicated. In short at least one part (word) of what you type must be present in the actual note and not just in its path. The reason for that is that otherwise it would be very difficult to find notes with many children because the autocomplete would be overfilled with them.

giteasync referenced this issue

2025-10-01 16:42:45 -05:00

[PR #4001] [MERGED] Reopen recently closed tab/split in place #5400

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: TriliumNext/Trilium#4001