DXR UI Refresh: Difference between revisions

Jump to navigation Jump to search
→‎Decisions: We can do live-ish feedback between advanced and textual search.
(→‎Blame/VCS integration: Preserve the spirit of Georg Fritzsche's "carrying over the line numbers from the URL to the blame link".)
(→‎Decisions: We can do live-ish feedback between advanced and textual search.)
Line 40: Line 40:
* We'll write a search query parser that supports Python-style quoting for regexes and everything else. Use double quotes or single quotes. Each can contain the other. If you really need to go crazy, you can backslash-escape the kind of quote you're using.
* We'll write a search query parser that supports Python-style quoting for regexes and everything else. Use double quotes or single quotes. Each can contain the other. If you really need to go crazy, you can backslash-escape the kind of quote you're using.
* Regex search will support barewords. If you need to use a pattern that contains a space or quotes, put it in single or double quotes (see above). There's no reason to require quotes all the time, since we don't need to hang a "replace" pattern off the end a la vi.
* Regex search will support barewords. If you need to use a pattern that contains a space or quotes, put it in single or double quotes (see above). There's no reason to require quotes all the time, since we don't need to hang a "replace" pattern off the end a la vi.
* Advanced search on a separate page OR modally mutually exclusive with textual search (so we don't immediately need a JS query parser, though we could add one later and remove the modality). We'll have examples of what each advanced field takes in dimmed text in the field, demonstrating a few of the interesting features: for instance, '"main(const int, ...)"'. Upon submitting an advanced search, you'll get a search results page with the equivalent textual search, a la Google. That'll teach you the textual syntax so you can go faster next time. (It also saves display space, which our users are rabid about.)
* Advanced search and textual search should either be mutually exclusively shown (in which case we'd act like Google's advanced search, snapping back to textual mode when showing results), or we can have server-side code send back the textual equivalent to the advanced search (or the advanced equivalent to the textual search) along with the search results. That way, we don't immediately need to write a JS query parser, though we could add one later and get better latency. We'll have examples of what each advanced field takes in dimmed text in the field, demonstrating a few of the interesting features: for instance, '"main(const int, ...)"'.
* Improve our filter names so they're shorter and more memorable ("subclass" vs. "derived").
* Improve our filter names so they're shorter and more memorable ("subclass" vs. "derived").
* Take the "l" out of line-number URL fragments. It looks like a 1. You can just start them with numbers.
* Take the "l" out of line-number URL fragments. It looks like a 1. You can just start them with numbers.
Confirmed users
574

edits

Navigation menu