[Coke] should 'rak --ack -w someword' be expected to work? 18:36
lizmat "w" is not listed as a --ack argument 18:39
what should it do ?
[Coke] also: any way to ignore what .gitignore does?
"argument is a word"
lizmat hmmm.. I could add it, but it wouldn't help you now 18:40
rak §someword 18:41
[Coke] -w, --word-regexp Force PATTERN to match only whole words
lizmat would do what you want though
ah, so that would basically do the regexp, and see if the resulting match has word boundaries ? 18:42
Geth App-Rak: coke++ created pull request #65:
Update README.md
[Coke] under the covers, don't know - end result is that -w word gives me hits on ' word ' but not ' someword ' 18:43
lizmat well, then §word would do the trick for you 18:44
and I guess I could map -w to --type-words
[Coke] I'm ok if it's hidden behind --ack 18:45
I will just probably always use --ack because I've got a decade on it.
... I still use 'ack -a' which hasn't been valid since the first big update. :)
lizmat and that's supposed to do?
[Coke] it was "all files" 18:46
and then ack changed the default at some point, and decided that all was invalid, but I had so much muscle memory I still type it when it's an invalid option
(default now is text files that aren't ignorable by default, like .git) 18:47
which brings me to the second part of my question - is there an option to ignore files/dirs that are in .gitignore?
lizmat perhaps --under-version-control ?
that would only search files that are under version control ? 18:48
!
[Coke] nice 18:49
by default searches .xlsx file (and then dies because it's not valid utf8)
Sorry to hit with so many newb questions at the same time 18:51
"Error encoding UTF-8 string: could not encode codepoint 1190209 (0x1229A5), codepoint out of bounds. Cannot encode higher than 1114111 (0x10FFFF)" 18:52
(which then kills the rak that's running) 18:53
lizmat that it tries it at all, is because it looks like a text file oddly enough 18:55
according to Data::TextOrBinary semantics 18:56
[Coke] weird. xlsx is basically a zip file of xml files.
lizmat interesting, care to make an issue for it ? 18:57
Geth App-Rak/main: ba4f8db892 | (Will Coleda)++ (committed using GitHub Web editor) | README.md
Update README.md (#65)

Fix typo
lizmat looks like --ack support is really below par... sorry 18:58
am in the middle of some other stuff, deep-diving in App::Rak is currently not an option :-( 18:59
Geth App-Rak/main: 9f5fbce088 | (Elizabeth Mattijsen)++ | 2 files
Add "w" in --ack mode, and some doc fixes
19:01
[Coke] sure I'll see if I can make it on Data::TextOrBinary 19:03
... Data::TextOrBinary is not already installed. but I was running rak on the command line 19:09
lizmat ah, yes, I incorporated that into path::utils, I believe 19:10
[Coke] doesn't look like that's actually a dep?
ok.
lizmat or somewhere hmmm... 19:11
raku.land/zef:lizmat/path-utils#path-is-text 19:12
[Coke] path-is-text returns 0 on that file
lizmat ah.... weird 19:13
[Coke] my command line was 'rak --under-version-control rc' - does that option override text?
lizmat ah, yes... try adding --is-text ? 19:14
[Coke] much better. 19:15
Probably LTA that trying to search the binary file explodes rak instead of ignoring/warning on the file.
lizmat yeah, I think there is an issue for that already
if not, there should be one :-)
[Coke] heard. ;) 19:17