Confirmed users
574
edits
(→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 | * 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. | ||