Zettelkasten Forum


[SOLVED] [BUG]: v1.0.9 in search bar, after 2 letters, app starts inserting text into file

edited August 4 in The Archive

So:
command-l
"cr" or any two letters
the following letters are then inputted into the highlighted file

This happens 100 percent of the time.
anyone else?

Sorry if I'm posting this in the wrong place.

Comments

  • You're right: the condition is that a file starts with these letters and is displayed in the editor. Will investigate and fix!

    Author at Zettelkasten.de • http://christiantietze.de/

  • Same here, I just didn't have the time to post about it yet, because I knew my reply would have to be a bit more extensive.

    The bug actually only happens when "Highlight search terms in editor" is turned on, and sometimes you need to type more than 2 letters, seemingly depending on the the titles of the other notes.

    Since fixing this bug might have a decent chance of breaking The Archive's previous behavior for "Highlight search terms in editor", let me preemptively write the following:

    Search in The Archive is used in two fundamentally different ways:

    1. For quickly switching to notes that you know the (beginning of the) title of (e.g., I type "omn" to switch to my "OmniFocus" note, "reg" to switch to my "Regular Expressions" note, etc.). This is extremely useful and makes up something like 90-95% of my "searches".
    2. For actually searching for particular search terms, when you don't know in advance which note(s) would be relevant.

    In the first scenario, you just want to switch to a particular note as fast as possible, and the note should ideally be scrolled to the place you edited last, or, if that is not possible, the note should be shown from the beginning. Since what you entered is merely the first couple letters of the note title, you definitely don't want the note to scroll to the first occurrence of those first couple letters inside the note.

    In the second scenario, you want the search term you entered to actually be found inside the note's content, so in this scenario, it is highly desirable for The Archive to scroll to the first occurrence of the entered search term.

    v1.0.7 and before de faco worked the way I described above:

    • When there is no exact title match, the note gets scrolled to the first occurrence of the search term
    • When there is an exact title match, only the first one or two of the entered characters are considered for Find (in Note), and since it is extremely rare for a note to not contain those on the first page/screen, the note basically always gets shown from the beginning

    I'm not sure if the behavior for exact title matches was fully intended or not (the fact that Find would search for 1 or 2 letters always felt slightly off), but the resulting behavior was extremely useful and I would hate for it to get broken by a fix for the current bug.

    The only way, the previous behavior could get improved, in my opinion, would be if:

    • the Find field would not get filled at all for exact title matches
    • instead of showing a note from the beginning, The Archive would scroll the note to the place where it was shown the last time you viewed it whenever you jump to it using an exact title match
  • Interesting; to make sure I follow:

    1. exact title matches (search for "ba", select note "Banana") should scroll to the last edited location
    2. non-exact/fuzzy/content-based matches (search for "ba", find note "201807211353 Fruits", contains "banana") should jump to the finding inside the text
    3. (Bonus: keep in mind the recurring request to display non-exact matched notes when there's only 1 search result, scrolling to the line of the find like (2))

    In any case, there's v1.0.10 waiting for you to check out, essentially just fixing the selection bug I introduced.

    Author at Zettelkasten.de • http://christiantietze.de/

  • you guys are awesome

  • edited July 21

    Looks like my spidey senses were correct: v1.0.10 does fix the bug mentioned in the OP, but it also changes the way The Archive behaves with exact title matches when "Highlight search terms in editor" is turned on.

    @cietze, your summary is absolutely accurate, and props for remembering the request to display the content a non-exact match when it is the only result left.

    I had to turn off "Highlight search terms in editor", because the new behavior is a bit too irritating when using search for switching between notes, which I do a ton.

    If jumping to the last edited/viewed location was more difficult to implement, a great stop-gap measure for the meantime would be to simply not populate the Find box for exact matches, so that those notes are always shown from the beginning.

  • I'll work on this; it's just that the external change pickup thing put a few existing processes on their heads. I just noticed that parts of the app's behavior are formally under-specified and thus not tested to not change automatically, so it's good to have check lists like these to ensure I don't introduce regressions in app behavior in a totally different place than the one I'm working on. Ah, the merits of complex systems :)

    Author at Zettelkasten.de • http://christiantietze.de/

  • Yes, those 3rd order interactions can be a big pain in the tuchus. Thanks a lot for staying on top of it, though. :smile:

  • Was fixed in 1.0.10 already :+1:

    Author at Zettelkasten.de • http://christiantietze.de/

  • edited August 4

    Sneaky... :wink:

    Just to clarify:
    Now the original behavior is restored (which is a huge improvement, thanks!), but the v1.0.11 release notes make it sound like in the case of an exact title match, the previously viewed location is restored (which would be the ideal behavior), but this is not happening for me: On my Mac, The Archive always shows the beginning of a note when there is an exact title match, but it does not restore the previously viewed location of that note.

    Is the wording of the release notes just a little misleading or am I missing something?

  • Oh, you're right, I promised too much for that release: it jumps to the last cursor position only when you tab into the editor. I'll adjust the release notes accordingly.

    Author at Zettelkasten.de • http://christiantietze.de/

Sign In or Register to comment.