[PATCHv2 2/2] attr: drop C/C++ default extension mapping

The point of this mapping is largely to get funcname support. However, there's been some indication that our C funcname pattern produces worse results than the default pattern, so let's leave it unmapped for now.

If and when it improves, this commit can be reverted.

Signed-off-by: Jeff King <peff@peff.net>
---
Obviously this could just be squashed into the first patch. But I think
I'd rather leave a more explicit note in the history.

When writing the justification for this commit message, though, I did notice that my reasoning is slightly flawed. The complaint is that the C funcname pattern sucks, and therefore a user who hasn't configured anything has a worse experience with patch 1. But enabling that sucky experience is a two-step process:

  1. map *.c, etc to the diff driver "cpp"

  2. diff driver "cpp" has a funcname (which is reportedly bad)

Since this series is about tweaking extension mapping, the natural thing to do is not enable (1).

But when you think about it, if our funcname pattern is bad, shouldn't preventing (2) be the right thing? That is, if our funcname pattern is really worse than the default language-agnostic match, wouldn't we be doing everybody a service to simply remove the builtin diff.cpp.xfuncname pattern?

Then you're not only not causing a regression for users who haven't configured anything; you're actively helping people who have set "diff=cpp" themselves.

Of course you're causing a regression to people who _like_ the current diff.cpp.xfuncname. But if they are so widespread, then why is there so much opposition to turning it on by default? My theory is that people aren't actually using the builtin diff.cpp.xfuncname.

 attr.c |    6 ------
 1 files changed, 0 insertions(+), 6 deletions(-)