Eike, On Fri, Aug 26, 2016 at 01:50:40AM +0200, Eike Rathke wrote: > Hi, > > On Tuesday, 2016-08-23 12:18:42 -0500, Derek Martin wrote: > > > On Tue, Aug 23, 2016 at 11:04:57AM +0200, Eike Rathke wrote: > > > Well, I think removing the $locale variable was a stupid change ;-) > > > Whether to add $attribution_locale I don't really care, fine for me > > > as long as $locale is an alias for $attribution_locale. > > > > Aliases are bad. They make the code needlessly more complex, and can > > lead to confusion when things don't quite work as expected. > > Alias for the configuration I meant. If both are used the last one wins. > Simple.
Yes, I know what you meant. Do you run Mutt because it is easy to configure (HA!) or because it is good software? Aliases make the code more complicated, require that maintainers remember that things may need to be updated in more than one place (which they won't), and increase the likelihood of bugs that are confusing. Mutt is good software precisely because, to the extent we've been able to, the community has kept the code small, and has kept this kind of corruption out of the code base. Aliases should be avoided, unless there is a very, very compelling reason to create one. And this isn't that. > > > Also the change to not switch back and forth the locale for LC_TIME > > > is good. But making $locale a) not work, and b) complain everytime > > > a hook uses it is ugly and unnecessary. > > > > With the new behavior, it's clear that the ONLY reason to set this is > > if you want to change the dates in your attributions. > > But that's exactly how I use it and it is broken now, The old behavior absolutely IS broken. That's what we're trying to fix. The proposed patch set is NOT broken. It's just different. Different != broken. > I can't use the same configuration with different mutt versions. I understand, but your objection is not reasonable. Taken to extremes, this logic means that no change can ever modify config behavior, no matter how broken it may be. Development must not be stunted by such an attitude. Besides, it reaks of the mentality, "I want all the new functionality of new Mutt, but none of the responsibility of configuring it." At the very least, I think it should strike you that that thought process is selfish. In Mutt, when the minor version changes is where things are EXPECTED to break. For the time being at least, mutt-dev has abandoned the notion of stable and unstable releases, so there's really no other way to deal with such a change. If you want to continue to run multiple versions across that sort of a milestone threshold, why should anyone BUT YOU bear the cost of doing that? Besides, if you REALLY want to run both versions, and can't handle dealing with multiple configs, it's actually not THAT hard to make some config that does the job. In your .muttrc: set my_muttvers=`mutt -version |head -n 1 |sed 's/^Mutt 1.\([0-9]\+\).*$/1.\1/'` source .muttrc-$my_muttvers The shell command gets the major and minor versions of Mutt. Now, create .muttrc-1.7 and .muttrc-1.whatever and put the correct locale settings in them. Now you don't need different configs in different places. [I don't love this solution, because it requires each user to have similar hackery, and may require updating if the versioning changes substantially. Better if Mutt provided something that did it, but for now, IT WORKS.] > > > But forcing the pile of existing muttrc reply-hook "~f '...'" 'set > > > locale="..."; set attribution="..."' to change is awkward, > > > especially if the same configuration is used on several machines of > > > which some run mutt tip and some don't. > > > > This, by itself, is never a good reason to avoid making an otherwise > > justifiable change. Old stuff breaks when you cross major milestones. > > I'm using mutt since ~20 years. Config things broke rarely. Small wonder... between 2002 and 2015, Mutt only had TWO minor releases. JUST THIS YEAR, we've had two. And in those two, here is only just one more "breakage" of config, and so... still, only rarely. Development has picked up again. Things are changing. Get used to it. =8^) > > That's a fact of continued development. If you don't want old stuff > > to break, don't run new code. > > Haha. Very funny. Hey... It's not a joke. With any software, some old features get retired, some are improved, and configurations change accordingly. New features means new config. Fixing old brokenness sometimes means old config breaks, and old features don't work. Welcome to software. Technology changes quickly and you should be prepared to change with it. Mutt has been fairly stagnant; I think you should see the recent increase in the rate of change as a good thing. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
pgp7wK3zQwgLT.pgp
Description: PGP signature
