Open RiedleroD opened 3 years ago
Current repo parser has no information on what is inside the usercss file, so it will require an additional request to the GitHub API for file contents.
Why do you think it should be implemented? At the moment algorithm searches by repo name, custom name, repo owner name, and tags, and it seems that search results are relevant now.
Why do you think it should be implemented?
For more specific searching. Imagine searching for "docker.com" and nothing gets shown because people put it as "docker" into the tags, then searching "docker" and a whole lot of irrelevant repos get shown that happen to be made by someone named "docker user 1200".
Solutions I though of would include adding advanced search (where "search in owner names" could be disabled, and similar stuff) or adding a kind of "search by url", which would also be pretty convenient and would increase the likelyhood that the stylus inline search includes your site.
I'm not sure how easy or hard this would be to implement since I have absolutely 0 knowledge of Node.js, but something I would do, regardless of programming language would include these steps:
@-moz-document +(regexp|url|url-prefix|domain) *\(([^)]+)\) *{
http://
or https://
, either should be prepended because many styles just assume that it's always present and build their rules around that.If this is added, could you also parse @description as well? Since it is now possible to add multiple styles from one repository, and not have that same repository description set for all the styles in that repo
Edit: You could add version numbers, support URL's, etc. just from the metadata to the style pages
Metadata parser was added in 3.4.0. Since then style's title, description, and license are being set from the metadata.
As for sites to which the style is applied, I will need some help with a regex that gets the hostname from the regex rule. So far, I have no idea how to deal with such expressions:
@-moz-document regexp("https?:\/\/.*wik(i|t).*(org|jp).*") {
@-moz-document regexp("^https?://((gist|guides|help|raw|status|developer)\\.)?github\\.com/((?!generated_pages/preview).)*$") {
@-moz-document regexp("^https?://((gist|guides|docs|lab|launch-editor|raw|resources|status|developer|support)\\.)?github\\.com/((?!generated_pages/preview).)*$") {
@-moz-document regexp("moz-extension:\/\/.*"), regexp("chrome-extension:\/\/.*") {
For a start, I could parse only domain()
rules.
well I can show you how I would do it in pseudocode:
when the style gets parsed:
@-moz-document(?: +(regexp|domain|url|url-prefix) *\((.+)\))? *{
regexp
:domain
:https?:\/\/(\w+\.)*
and postfix it with (\/.*)?
url
:url-prefix
:.*
(rule1|rule2|[…])
["abc","def","15","ghi"]
, then the concatenated string would be (abc|def|ghi)
If you're stuck somewhere, please ask.
should be easy enough to parse – urls are always between
@-moz-document
and{
, so you would only have to get the string in-between and see if it's a regex, a direct url, a prefix or a domain rule. From there, you can just take the rule. Maybe let the user be able to change it & rescan it when the style updates.Then, add it to the searching algorithm. Idk if that's too heavy for the server, but you could try checking the regex on search.
I don't know how easy or hard this would be to implement since I have no idea what your project does in the backend, but I think the people would love that feature.