feature request: partial tag completion

Tagging an item currently supports auto completion. Typing a string lists all the tags starting with the string in a context menu.

Suggestions for partial strings would be very useful in addition.

i.e. if typing "item" would not only find "item [post string]" but also "[pre string] item [post string]".
  • This feature would be very useful for me as well. For my tags that are several similar words (e.g. story/narrative/fable) I often have trouble remembering which of the words is listed first.
  • Could I nudge a little about partial-tag completion ? It would help tremendously to create and maintain a consistent tagging system.

  • Adding another nudge... partial tag completion would help using tags with more consistency.
  • My understanding (I believe dstillman commented on this in a different thread) is that partial tag completion is massively more demanding in terms of computation, so getting this to work in a way that's reasonably fast enough for a good user experience is, at a minimum, not trivial, so this isn't a simple request.
  • Oh, I didn't realise. Is it not just something like doing a substring match over all tags ? Evernotes Webclipper does this for example, or when you add a link in Obsidian, LogSeq, Discord or apps like this, they show you a list of note titles in which the typed string is a substring.
  • edited February 2, 2024
    It would also facilitate a useful 'lite' version of nested tags, ie a single tag with the name 'parent_tag->child_tag'.
    So when typing child_tag into the tag box, the nested tag 'parent_tag->child_tag' would be amongst the matching suggestions.
  • edited February 3, 2024
    Btw - both the "add note" and the 'add citation" search boxes for Word do this already. The list of items that shows up to select from contains all items that include the search string, not only the items that start with the search string.

    Perhaps there's a misunderstanding of what the suggesting is, or perhaps I'm missing something in the technical implementation - but would doing this for tags (there are fewer and they are shorter than library items, I suppose) really be computationally demanding ?
  • search boxes and auto-complete aren't the same thing. It's OK when search while you type has, say, as 5 second lag. That's not (I, and I assume the devs, would think) acceptable for auto-complete, which needs to be essentially lagless.
  • edited February 4, 2024
    That makes sense. I'm probably not seeing the complexity. Apologies for that.

    Evernote indeed seems to have two different behaviours for this: the Webclipper lists the superstrings instantaneously 'as' you type with each keystroke; the Edit Tag menu waits for typing to pause for a small moment and updates the suggestion box then, I'd say this takes perhaps 100 or 200 ms. To me, the second works fine and adds a lot of value in keeping tags consistent.

    But again, perhaps I'm just not seeing the complexity involved!
  • edited March 20, 2025
    +1 to this.

    I was going to start a new discussion for completion of tags "not beginning with", as I have many tags structured in the way of @tim820 comment https://forums.zotero.org/discussion/comment/454096/#Comment_454096 (for example "R-package:[package name]"), but fortunately I found this one.

    This should be feasible (at least more than some years ago) with current tools. I do not understand the difference commented by @adamsmith in https://forums.zotero.org/discussion/comment/454291/#Comment_454291, but maybe some lag would be acceptable when tag completion does not have any suggestion for tags beginning with completed part.

    An option could be also allowing us to set a collection of strings to search tags beginning with them (for example, for my use given in the first paragraph, I would set the string "R-package:", so tags completion would look for tags starting with completed part or with "R-project:" + completed part)

    WDYT @dstillman?

    Thanks!
  • +1 feature request.

    I am beginning to notice a theme here... Have had Zotero for a week and nearly every thing that annoys me I find a thread for. These are all features that are standard in other software, but have not yet been implemented in Zotero. I say not yet because they will certainly be implemented eventually. What we are asking for is priority. Posting about how something "can't" be done is counter-productive and unless you are a professional software developer, you don't actually know, its just rude to downplay a perfectly reasonable request that many people have over a long period of time.
  • @iagogv, @adamsmith and @dstillman - I'm also puzzling why partial tag completion would be technically challenging, as it would be quite the game changer for tag consistency.

    - All existing tags are already shown in the lefthand sidepane when clicking on "My Library" as collection. And fast
    - So tag completion would need to operate on that list, either create it dynamically evertime or have it stored and maintained somwhere in memory.

    What makes this computationally expensive ?
  • edited 4 hours ago
    @fschuman: The tag selector only has to be generated intermittently, when you switch collections, and the results can appear whenever they're ready. Autocomplete requires searching all tags in the library on every (debounced) keypress, and needs to show up quickly to be useful. A left-bound search is very fast because it uses a database index, whereas a non-left-bound search has to scan every single tag. You might not have enough tags in your library where that would be a performance problem, but some people have hundreds of thousands (and way more tags than they have items, which is why the citation dialog isn't relevant).

    (Years ago, when this was first implemented, slow queries would also hang the UI, but that doesn't happen anymore.)

    But as we've said elsewhere, computers have gotten a lot faster, to the point where it's more realistic to do this for everyone. We're still going to try to optimize it a bit more to keep it as fast as possible. We're working on that now and should have an update soon.
  • Thanks for the explanation, @dstillman. And wonderful to hear, looking forward to an update !

    I very likely can't add anything new to the implementation level here, yet am wondering why, if a reliable database index exists, a left-bound search can use it but a right-bound on every keystroke can not ? Why would one scan every single tag in the entire library at keystroke if there's a database index ?

Sign In or Register to comment.