Comments (19)
where for example you can use the following ignore: *.t, t/*, inc/*
so inc/*
becomes a special case of the ignore rules list
note: if we give one checkbox to inc, what other should we consider? ppport.h
, *.md
, *.PL
, ... ?
from metacpan-grep-front-end.
would you do inc or would you do other common paths too?
from metacpan-grep-front-end.
I would add local/
from metacpan-grep-front-end.
I'll have a think about other directories, but the thing with inc/ is that it contains modules that are almost certainly already on CPAN, so you can get a hit on one file over and over.
Given the discussion on #toolchain, I think have a checkbox for "ignore inc/ directory", and have it unchecked by default.
from metacpan-grep-front-end.
this is a dupe of #61 (or the reverse)
I m currently working on a prototype to ignore files or directories from the grep
itself
from metacpan-grep-front-end.
This wasn't originally intended to be a duplicate. I think inc
should just be ignored (that's this issue), and #61 is to give the end user the ability to ignore things. It could be an option like [x] ignore auto bundled stuff
. Most of the time it's going to be the right thing to ignore it, and people should have to know about a feature to ignore things, and that they should specify inc
.
So I guess you can see this as a specific instance of a general capability, but I don't think that's the right user experience / interface.
from metacpan-grep-front-end.
I can see the checbox as being some extra sugar to avoid typing /inc
in the ignore path list I'm currently adding.
Reopening it, for now we will see once we have the ignore feature in place.
from metacpan-grep-front-end.
Seems like you could just filter it out of the git grep -l
result when you do the actual grep?
from metacpan-grep-front-end.
@oalders asked for local/
from metacpan-grep-front-end.
note: if we give one checkbox to inc, what other should we consider?
I think this is the critical question. we need an interface that allows people to say what they want but I'm not sure how to go about it. If we make it too open, do we allow them then to inject command line flags or bobby tables us?
from metacpan-grep-front-end.
What I'm trying to say is that I think it makes more sense to leave a field where you can customize and ignore all rules you want rather than adding some pre-set rules, otherwise that list might become extremely long.
I can see adding some extra to the list:
inc/*
local/*
t/*
*.md
*.json
*.ya?ml
*.conf
cpanfile*
LICENSE
MANIFEST
INSTALL
Changes
Makefile.PL
Build.PL
Copying
*.SKIP
*.ini
README
...
but if they are not enabled by default it does not make sense to list them.
Maybe we could consider a shortcut: ignore all cruft
or something similar
from metacpan-grep-front-end.
one person's cruft is the thing another person is looking for :)
from metacpan-grep-front-end.
It might be simpler to have:
ONLY search .pm and .xs/.c/.h files?
from metacpan-grep-front-end.
We already have the option to filter files like *.pm
or *.h
the main value of the negative list would be to exclude ppport.h
for example when performing a *.h
I think we should have both option available: positive and negative filter then we can gather some feedbacks and improve it
but as you said someone request is going to different from another one...
even if we can probably see some useful and common patterns
from metacpan-grep-front-end.
I know you're going for a googlesque minimalism, but I think this would benefit from labels for each input, especially as once something's in the box, there's no indication for what they are. Something like the the following (though the placeholder text in the input elements would obviously change):
Given we don't know what are all the ways people might want to constrain the search, and as Todd says, whether some people might want to include the things that I can't imagine someone ever wanting to include, then I think you should go for the simplest capability that lets people exclude the things that we know some people want to exclude, and then see how that works out.
Two thoughts related to the exclusion:
- Could pre-populate the exclusion list with a default set of things, so that by default people get least surprise / annoyance, but they can always clear out that if they do want to include one or more of those things in the search
- Leave it blank, but have a button to the right for "exclude boilerplate", and clicking on that will put the standard set of exclusions in the input.
from metacpan-grep-front-end.
Two topics here:
A/ add some labels:
good idea it clearly has some value, as previously I had to attach two screenshot for that exact reason
note that I'm not sure how it would/could look like on the search page, probably a good idea to solve
B/ Pre-Set exclusion list
I would lean toward first to add a checkbox to prefil the most common exclusion, until we realize we always need to use them.... and then consider to promote them as default
from metacpan-grep-front-end.
I would lean toward first to add a checkbox to prefil the most common exclusion, until we realize we always need to use them
I reckon pre-fill is the right approach. I would argue that the userbase for this tool is already skewed to the more CPAN-savvy end of the pool, and they'd rather do the most sensible thing by default. If you can poll the room there and come up with a list that everyone agrees with as a default set of things to exclude, then pre-fill with that list.
from metacpan-grep-front-end.
I've added a checkbox which is going to populate a predefine list, this is wip and need some extra rules probably
the current list stand as:
inc/*, local/*, t/*, *.md, *.json, *.ya?ml, *.conf, cpanfile*, LICENSE, MANIFEST, INSTALL, Changes, Makefile.PL, Build.PL, Copying, *.SKIP, *.ini, README
also notice the addition of title
to the input text, which is not perfect but a mitigation before I can get a nice css/UI with the suggested labels
from metacpan-grep-front-end.
Not sure I'd include Makefile.PL
in that list – pretty sure I've come across distributions where their only use of a module was in Makefile.PL
. Less likely these days, with DZ, but there are plenty of dinosaurs still roaming the wild savannah of CPAN.
from metacpan-grep-front-end.
Related Issues (20)
- grep is returning wrong stuff: it's buggy HOT 3
- link to the full source view for each match HOT 5
- Search does not work at all HOT 1
- JS error preventing display of results when using "in distro like" filter HOT 2
- Page and recent searches links are not encoded properly HOT 3
- No results displayed for queries HOT 4
- Regex guessing thinks | is a regular character HOT 1
- Result count is confusing HOT 1
- Set an alarm when running "git grep" HOT 2
- Header bar for grep.metacpan doesn't match metacpan
- test
- Provide a file matching feature to the front end like grep.cpan.me HOT 4
- Add a checkbox to exclude Devel::PPPort matches HOT 5
- Consider using ripgrep instead of git grep HOT 1
- Ability to ignore a particular filename/path HOT 2
- Search says 2 distributions match, but nothing is listed HOT 10
- grep reports more distributions than it lists HOT 2
- first search produces 503 error HOT 6
- repo updates on bm-mc-02 to not seem to be updating grep.metacpan.org. HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from metacpan-grep-front-end.