RFC: safe pattern matching for problematic encoding

[Adrian Buehlmann]

On 2012-05-25 20:50, Matt Mackall wrote:
> On Fri, 2012-05-25 at 10:53 +0200, Martin Geisler wrote:
>> Matt Mackall <mpm at selenic.com> writes:
>>
>>> http://mercurial.selenic.com/wiki/EncodingStrategy#The_.22makefile.22_problem
>>
>> I honestly don't buy this argument and neither does anybody else that
>> I've discussed it with here. Before you start yelling: this is not
>> trolling, I'm seriously trying to figure out why this is important to
>> you
> 
> Trolling is when you knowingly do something that's annoying and is
> likely to provoke a frustrated response. You should well know that I am
> sick to death of this topic, ergo you are a troll. Being a sincere troll
> doesn't make me love you more.
> 
>>  and if it even works the way you think it works.
>>
>> The basic problem with the argument is that Makefiles that reference
>> non-ASCII files aren't portable to start with!
> 
> You've mistaken the example for the principle. It's not about makefiles,
> per se, it's about the existence of large ecosystems of tools that are
> intentionally encoding agnostic. It affects everything from compilers to
> web servers to typesetters.
> 
>> I've demonstrated this before and I just demonstrated it again with
>> Windows 7 in a VM. Please try cloning
>>
>>   https://bitbucket.org/mg/makefile-problem
> 
> Now try it with GNU Make from msys. I just did. Works a treat on both
> changesets. Also works on Linux and Mac. As it obviously will _with any
> tool that hasn't drunk the UTF-16 Kool Aid_.
> 
> And thus you've proved my point.
> 
> a) important toolchains exist that work JUST FINE across platforms with
> the existing encoding strategy
> b) changing that strategy will cause a REGRESSION and is therefore off
> the table
> c) having standard tools like GNU make work trumps human legibility:
> software that doesn't compile but that you can still read is not
> software, it's merely literature
> 
>> Matt, do you acknowledge that we break tools in other ecosystems by not
>> transcoding filenames?
> 
> Yes. And it simply doesn't matter. I'm not going to trade "breaks ANSI
> C/Unix world" for "fixes Java world". And not because I designed
> Mercurial for the former, nor because it's obviously the closest thing
> to a sane, coherent strategy, but because it would break things that are
> working today. There is obviously no solution that will make everyone
> happy; betraying existing users to please potential users is a strategy
> for eventually having no users.
> 
> Now you've wasted another hour+ of my time and predictably gotten
> nowhere, because there's exactly zero new information in either your
> message or my response that hasn't been repeatedly presented over the
> past seven years. That's an hour I could have used doing something
> useful, or at least spent without elevated blood pressure. In other
> words, you have successfully trolled me. Pleased with yourself, troll?
> 
> If you want to do something useful, go work on the VFS layer.

While we're at it, and for the records, I do find how Matt treated
Martin here totally out of line.

Name calling people like Matt did here is poisonous for a project.

There are clearly other ways to state your opinions.

And the blood pressure thing is absolute kindergarten, IMHO. Why do you
take things that personally? This appears ridiculous to me.

If you don't want to debate things (again), then say so. Possibly with a
pointer to some wiki page with the final decisions and arguments and
plans. And those decisions that are final should be declared as such
(not being wanted to be discussed again).

A final note: This is not a comment about the arguments. And if Matt
believes that Martin should stop debating these things, then he can well
do so. But please not in this tone.

Thank you.