Russ Hyde

Simply because it finds _dup_licates; and the name dupree had an R in it. Thanks, though :)

Have added a single example file that is used in the `dupree::dupree()` examples. Further extension of the docs would be valuable

Note that the LCS algorithm in {stringdist} only computes the length of the LCS, it doesn't return the longest common subsequence. I can't find a good LCS implementation within CRAN...

? include an LCS implementation with dupree (can still use {stringdist} for computing the distances, but local LCS for computing the duplicated strings)

[Could call to {textreuse} with the original code strings, rather than integer vectors] - but would require r-textreuse to be pushed to conda-forge for me to use this locally

Just print the contents of the two (+) blocks for now. Can implement finding the actual LCS at a later stage

This appears to be fixed in the first-edition-update branch ( https://github.com/hadley/adv-r/tree/first-edition-update ) but the website for the first edition hasn't been updated.

That's interesting, I hadn't considered the environment where precommit/lintr is running. This might be something better handled on our (lintr's) end - for example, having a way to selectively deactivate...

This seems reasonable (I'll change *.default to *.environment and then push the *.environment code into the *.Cache methods); I wasn't sure what the type of the 'cache' input was in...

Thanks, yes that was the plan. The tests would need rewriting before that can be done, so it's not a straightforward refactoring. It will come together soon.