searching: order should not matter

[w4grfw]

“title #tag” does work, but “#tag title” doesn't.

Bukurow 5.0.2.0 Google Chrome 80.0.3987.132

[samhh]

#tag title will search for a tag that includes the string "tag title", because tags can contain spaces. The only way to allow a title later on in the query would be to provide it its own token e.g.:

title #tag !title title #tag !title

Would you find that feature useful?

[w4grfw]

in the case of spaces i would expect something like #"tag with space" so that #tag with space matches #tag AND title:with AND title:space while #"tag with space" matchs only the tag tag with space

[samhh]

In terms of UX, I think it's debatable whether or not that's more intuitive than the status quo. It also poses the design question of whether a space always means we're entering a new search string - which would change the behaviour of searching through titles like hello world, which currently searches for the string as-is but would now search for hello and world separately, which I'd think unintuitive. I don't like the idea of having to quote searches for titles, descriptions, or wildcards that contain spaces.

In terms of code difficulty, we'd need to think about the ability to escape those double quotes as well. I'd imagine this will increase code complexity - at the moment the queries are obtained with some relatively simple regular expressions.

[w4grfw]

I agree with the problems of escaping and complexity. But i guess the most common use case is refining the search. And there it shouldn’t matter if one search #programming hello world examples or examples hello world #programming. Otherwise one have to remember the whole title.

[Jemi]

w4grfw is basically right. If search MUST be simple, make it greedy and interpret the search string multiple ways (matching tags eagerly). This seems complex because it looks like you have to do a separate search on every possible parse of the search string - but actually it's not. You just need to interpret tags, description, title and url (and any other metadata you'd care to search) of each bookmark as one combined unstructured block of text and run the search on all such blocks (strip out #'s from the matchable tag text, because they are special). Then, as a further refinement, you can make the input box modal so that typing # into it will result in the subsequent text turning a different color e.g. blue (display the # as blue as well so it can be used as an indicator for separating multiple tag terms - #seth mcfarlan = 1 tag term. #seth mcfarlan #family guy = 2 tag terms. #seth mcfarlan #family guy #stewie = 3 tag terms). esc leaves the mode. Backslash can be used to escape special characters like # or to escape another backslash. This scheme means that you don't have to quote your tags, but you still have to implement multiple search functions underneath the hood - so you will have non-tag searches matched by the greedy unstructured method, but tags will match using a non-greedy, structured tag search whose results get refined by the non-tag text using the greedy method - so you'll be implementing two different search methods under the hood and you'll have some cross reference issues to work out because you're going to have one search method refining another search method. Nevertheless, I believe it solves this problem.

[samhh]

Can anything requiring memorising proprietary keybinds really be described as simple?

I don't think you can use the Escape key in a WebExt popup as it's hardcoded to close it.

[Jemi]

SamHH, when I said "modal", I was not talking about vi. I was only referring to having a "mode" that you enter (by hitting #) which will trigger the tag search system, and the user can see this with feedback (e.g. tag query terms in blue). As for escape, you could check for an override (BTW, when you say 'it's hardcoded' it's not clear whether you mean firefox, chromium or both), find another WebExt way of achieving the needed popup functionality, or you could choose a different key. I would just bet that there's an override though - or possibly even that the 'escape closes popup' functionality has it's scope limited in a way that you're not seeing. Otherwise it would be hard to call WebExt anything but 'gimped', because WebExt developers clearly need their own escape mechanisms, and the escape key is the most usual way of implementing these.

I also feel I need to clarify what I was proposing - because I probably wasn't clear enough. I edited my comment a few times and it never came out quite right. I'll start at the beginning. Let's just say you're reimplementing a brand new BM search:

Step #1 - implement search over metadata elements converted into an unstructured text format - descriptions, tags, titles, URL's (any and all relevant data/metadata you can find in the BM's) - all become unstructured text in this initial and most basic mode. User facing interface is perfectly simple.

Step #2 - add a mode (user will notice just a little and not care very much that it's a mode) that the user enters by typing #. User is informed that he or she is in a new mode because the query text he or she enters while in the new mode turns blue. Escape leaves the mode and the user can can enter additional text available to the unstructured portion of the query - but at this point I need to clarify what I said before. I used the phrase 'cross reference' above, and that was wrong terminology and could be confusing. I should have instead used the phrase 'narrowing'. Any tag queries in the search field will trigger a structured search of tag fields. Each such structured search will narrow the set of returnable results. After these structured searches are completed, these nodes can then be searched using the remaining non-tag query terms - and this last search will be performed using the unstructured search outlined in Step #1.

As far as # being modal, that only satisfies the need to avoid the user needing to enter annoying quotation marks to preserve the structure of a tag. Basically # is being used as an open quote and <Esc> is being used as a closed quote, except that a 'literal escape' (whatever that is) will not necessarily enter the data stream. You can use whatever you want under the hood - an obscure unicode character for example - and a syntax is permitted like #the simpsons #bart simpson <Esc> - while also acceptable is #the simpsons <Esc> #bart simpson <Esc> where # clearly corresponds to open quote and <Esc> clearly corresponds to closed quote.

The former syntax should be transformable to the latter, so however you want to implement it under the hood - do it that way. But the point is, the user never has to deal with those icky open and close quotes, and the search remains simple in the simple case, and in the slightly less simple case - it becomes only slightly less simple .

The other point I made before was regarding 'backslash' for escaping literal #'s (and anything else that could possibly need to be made literal later including other 'backslashes'). This is only necessary because of using '#' as a special character - and the user is in fact probably more likely to need a literal '#' then a literal backslash. Users hardly ever enter a literal backslash unless they're using a windows command prompt. So this is an appropriate character. This is used the same way in bash and many other unix shells - although those shells overcomplicate things WRT their overall syntax. You can just implement 'backslash <character> - including another backslash - yields a literal version of <character> - even if <character> is another backslash. The user is unlikely to need a string of two or more literal backslashes, so the escape rule can be simple.

I hope I've been more clear. I guess I got a little tongue tied in my last comment, and I hope I am less so now...

[samhh]

I'm not sure if I documented it anywhere, but I remember really struggling to implement something like this before - basically where you've rich content within/atop an input. I think I might have hit this issue when trying to implement preexisting tag suggestions.

I'm somewhat attached to the idea of a "clean" query string which can be copy/pasted without having to worry about formatting. Ideally, for me, there'd be some sort of clear formatting to demonstrate how the query is being interpreted, but it'd still be fundamentally plain-text.

[Jemi]

The user is not going to want to deal with quotes just to input a multiword tag is what I would say. Modes for special characters fixes this. Now, in my comment on #98 I mention the possibility of using autocompletion.

Autocompletion would obviate in many cases the issue of the user having to enter the quotation marks, but wouldn't obviate the user having to see the quotation marks, unless the autocompletion also moved the autocompleted tag queries to the end. The user is unlikely to ever want to see #"barney rubble" Because it's ugly and the quotes are distracting. So the modal idea works - but there's also another idea. Instead of autocompleting multiword tags and putting them in quotes, those autocompleted multiword tags could leave the search box entirely, and get populated into a special area with a #fred flintstone #barney rubble type tag list (or it could be in the format #fred flintstone,barney rubble for example), and hovering over those tags could generate an 'x' to kill it from the tag list. Right click could still generate a popup with "copy" and "paste". But then that's not going to work as well for people with a keyboard centric workflow.

I still like the modal idea, and when I read "fundamentally plain text" it sounds like you mean plain ascii. One solution for this, is to comma terminate multikeyword tags. This goes somewhat well with conventions already established, but leaves a dangling comma.

If order doesn't matter, and #"barney rubble" looks too terrible (which it does), then something is going to have to give. There's lots of options though. You can zap tags to the end of the input box, zap them down below the input box, etc. - but in my view input order shouldn't matter, and #"barney rubble" is just awful.

[michaelbeaumont]

Just commenting to say the current behavior of searching titles for exact matches is, for me, very unintuitive. It also doesn't match buku's behavior, I don't think. If I have a bookmark "build a boat" and I type "build", see a bunch of other "build" results, I don't want to have to type "a boat", my intuition is to be able to type "boat".

[samhh]

@michaelbeaumont That's more a matter of fuzzy finding not being supported, see: https://github.com/samhh/bukubrow-webext/issues/121