Confirmed users
574
edits
DXR UI Refresh: Difference between revisions
Jump to navigation
Jump to search
→Plans And Priorities: Add "Top of the Heap"
m (→Indexing) |
(→Plans And Priorities: Add "Top of the Heap") |
||
| Line 11: | Line 11: | ||
== Plans And Priorities == | == Plans And Priorities == | ||
=== Top of the Heap === | |||
Here are the first several improvements we'll do. They either make DXR a lot better for some or a little better for all—again biased toward being able to retire MXR. I've attached the high-ROI feedbacks that made them bubble to the top of the list. | |||
These will turn into filed bugs, not necessarily with a 1-to-1 correspondence. | |||
* Squash the last few bugs in multi-tree support, and index more trees. | |||
* Support case-insensitivity. | |||
* Implement [[DXR_Query_Syntax|a real query parser]]. | |||
** (1) Docs (mostly user-facing) about how the query language is spelled and what it means | |||
** (1) Don't require delimiters around a regex when entered into the Advanced Search Regex field | |||
** (1) In the new UI, keep a text-only representation or some other way to be usable from custom search plugins or URL-bar keywords. | |||
** (2) A way to semantically include double quotes in the search string: the parser shouldn't always eat them. | |||
* Indexing and search improvements | |||
** (1) Move to a line-based search, as proposed in https://github.com/mozilla/dxr/pull/161#issuecomment-25201532. | |||
** (3) Stop differentiating between macros, functions, consts, etc.: just find me an *anything* called "fred". People coming up to the Innovation Fair booth were confused that they had to know the kind of target. | |||
** (3) Just typing a filename (or path segment?) without a path: specifier should find files by name or path. | |||
*** [Should be solved by ^^] Trying to find files is hard. (Still haven't figured out how to get easily from the main page to Navigator.cpp on dom/base) | |||
*** [Should be solved by ^^] A basic "file:" keyword hint with simple wildcard globing could do most of it well enough, I think... "file:*.css", "file:nsILogin*", "file:/test*". (We already search for "path" matches as unanchored substrings. We just need to add the globbing. Why this isn't super slow I don't know.) | |||
*** [Should be solved by ^^] As a jump point when I know a filename (eg, "nsILogin", click search, click the particular IDL I wanted). | |||
* Quit auto-focusing the search field [as much]. | |||
=== Decisions === | |||
Here are some decisions the 4 people in the room (jonasf, ErikRose, rhelmer, and Schalk) agreed on at the 2013 Summit, recorded so we don't forget: | |||
* 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. | ||