[snipage out of order]
> > I honestly don't mean to be insulting, but I just can't see how this
> > is a real issue, except for people who are excessively lazy or
> > excessively brain-dead, or people who just oppose change for the sake
> > of being obstinate.
>
> Here I could say that I don't mean to be insulting and then proceed to
> call you an idiot -- but I was taught that in a debate it is not only
> unnecessary, but hinders debate.
You're absolutely right, and I owe everyone an apology. Sorry for
that.
On Thu, May 25, 2006 at 09:32:42PM -0700, Martin Swift wrote:
> On Thu, May 25, 2006 at 08:52:51PM -0400, Derek Martin wrote:
> > > I was sceptical of the move from the beginning and have to admit that,
> > > though there are some good ideas out there, I don't think they
> > > outweigh the frustration of broken setups that plenty of (mostly
> > > non-technically oriented) people will face.
> >
> > I don't think this argument holds any water.
>
> The part you quoted does not contain even a part of an argument.
Yes it does. The argument you are making is that any benefits of any
good ideas are outweighed by the frustration of broken setups...
Specifically, this is the PREMISE of your argument, which is indeed
a part of an argument. Colloquially speaking, the premise of an
argument is very often referred to as the argument itself.
> It is a summary of my viewpoint which is based on arguments which
> have already been presented.
You are using too narrow a definition of "argument." It has many
meanings, including:
3.
a. A summary or short statement of the plot or subject of a
literary work.
b. A topic; a subject: “You and love are still my argument”
(Shakespeare).
[American Heritage Dictionary]
But this debate is not about the semantics of argumentation...
> > As I've already said, I believe if the transition is handled properly,
> > the impact to users is very nearly zero.
>
> But even if the impact is small, it isn't worth even this discussion
> if there isn't sufficent reward.
You are making subjective judgements. It may not be worth it TO YOU,
but there is an objective reward to Mutt which is greater than your
subjective reward. You just don't happen to care about it. But,
since no one is asking you to do the work, the conversion would
(should) be automatic, so there is no effort required on your part.
As such, there seems to be no basis to your objection.
> I really believe this is a small issue which will affect no-one much
> either way it goes (which is why it is ridiculous that we are spending
> so much effort on this). Would the time we are waisting not be better
> spent on contributing to the project?
What we are discussing is whether or not a specific contribution will
be allowed to occur; the contribution can not happen until those with
the keys to the woodshed say it's ok. That's more likely to happen if
people can be made to see that there really is a benefit to doing it,
and get behind it.
The trouble is, as we've all pretty much been saying all along, there
is virtually no benefit to existing users, nor any serious downside,
so this debate really should not be conducted on mutt-users...
Involving existing users only confuses the issues. This discussion
really should have only been conducted on mutt-dev, amongst people who
care about how Mutt is developed. Users will always oppose any change
that makes something familiar become unfamiliar; that is an inherent
part of human nature. But that natural opposition MUST be discounted,
if the change is for the better, because it is a given. Compatibility
must never be allowed to hinder improvement.
But (since Thomas is not already behind such a change) the discussion
is necessary; this is a fairly big task (in relation to the size of
contributions, generally), so the work is not worth doing if it will
not be made part of mutt proper. Thus discussion must occur before
contribution can be allowed.
Frankly, IMNSHO Thomas has outlived his usefulness as maintainer of
Mutt. His work is fine, and no one can argue that he doesn't know the
code well... But he has himself said he doesn't have a lot of time to
work on Mutt, and he is closed-minded about making major changes to
mutt, which is getting in the way of making Mutt better. He has in
the past often balked at even small changes that genuinely make Mutt
better. I don't think that's the right attitude for the role of a
maintainer.
The addition of Brendan has made things better... and Brendan will
admit to you as freely as I do that a lot of things in Mutt need a lot
of improvement. Big, big changes. But he can't do it himself, and
besides which Thomas is apparently in opposition. The response is
always, "go write the code" -- but doing so requires an organized
development effort, and a leader for people to get behind. Thomas
has the clout to be that leader, but he obviously doesn't want that
role, for whatever reason. But he also won't step away and provide
the opportunity for someone who might want the role to take over.
> Did you read the bit about the bicycle shed that I sent in my last
> message?
Yes I did, though I don't remember the bit nor why it is relevant at
this point.
> Do you really think the names of variables will make or break this
> project?
No, I don't. That isn't the point. The point is it will make Mutt
better, and someone is willing to do the work. The impact to existing
users is minimal if done well, and the impact to new users is small
but positive. The impact to the overall quality of Mutt is positive.
Therefore it should be done (and allowed to be done). It's simple
logic.
> How much time will you spend on writing emails about this? Is all
> this really worth it?
As long as it takes, and yes... It's worth it to me, if the
conversation makes people think about ways that Mutt can continue to
improve, and drive people to strive to make Mutt better. It's an
idealistic viewpoint.
> You can do all this and advertise it on CNN and go to peoples houses
> and do it for them ... but it is still going to have to be done, some
> might have minimal trouble, some documentation will be outdated and
> other will have to be written or rewritten. For what? Different names
> of variables?
No, it's more than just different names of variables... that's the
problem; you are not looking at this from a big-picture perspective.
It's about making Mutt's interface cleaner, more consistent, and
easier to use, especially for new users. The naming of the variables
is only one part of this which needs improvement, and I admit it is a
relatively small aspect of what needs improvement in Mutt. But it
does need improvement, and there is someone willing to do it, so it
should be done. Again, simple logic.
> > As for re-learning variable names, this also seems like a silly
> > argument. Here's why:
>
> I agree, but the following are also an argument *agains* the change.
>
> > 1. Most variable names are just simply not remembered by the vast
> > majority of users -- there are way too many of them -- and need to
> > be looked up each time they want to make a change.
No it isn't. It is a statement of reasoning as to why the change
SHOULD NOT MATTER to EXISTING users, as you yourself have already
admitted. It is not actually a reason why it should or should not be
done. It is offered to dismiss opposition, not prove merit.
> > 2. If you've got a commented sample .muttrc, and a conversion script
> > to change your existing configuration, 95% of the battle is won --
> > you will already have what you need, PLUS a reference to the
> > variables which you already had to change (the converted
> > configuration), PLUS a documentation file which maps all the rest of
> > the names to their new names.
>
> Great, we'll have a reference and a documentation file for a change
> that some would argue is mostly useless. Really, how about putting
> that documentation effort into improving the existing documetation?
It's not a useless change, it makes Mutt's interface cleaner and more
consistent, which in turn makes it easier to maintain and easier to
document. And yes, the documentation is ANOTHER aspect of Mutt which
needs to be improved, probably more so than the variable names. The
great thing is, we can do BOTH. Imagine that? The wonders of Open
Source software...
Incidentally, Rado originally stated that part of the reason to do
this was indeed to make the documentation better. It's even still
part of the subject line of this thread.
> > 3. Additionally, for people who are particularly obstinate about not
> > changing, there is no reason both names can't be used
> > simultaneously.
>
> Exactly which is what I proposed as a compromise. Did you read my
> email?
Absolutely. I was agreeing with your point, it was good!
> > I imagine the percentage of people who genuinely know the mutt command
> > interface well, and would genuinely be significantly inconvenienced by
> > such a reorganization of variable names, is extremely small. Those
> > rare few people are mutt's uber-users, and such people should, I
> > think, expect to be inconvenienced by changes in the name of making
> > better software.
>
> I agree on the numbers here. I, however, think it is the experienced
> that will be the least inconvenienced by this. Thanks for your
> concern, though.
I don't see how it could be... inexperienced users haven't had any
time to get used to anything, and new users don't know anything. Both
groups pretty much have to look up everything anyway. Only
experienced users who are familiar with the old interface will stumble
over using the correct new variables, which are unfamiliar to them.
How would such a change inconvenience newbies?
I agree that I didn't do a very good job of making the case for this
change in my previous message. I also think mutt-users is not the
place to do so. I will post the argument in concise form on mutt-dev,
where it belongs.
--
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. Sorry for the inconvenience. Thank the spammers.
Attachment:
pgpoXOO2VsFDE.pgp
Description: PGP signature