headers
Rado S | 2 Jun 2006 14:37
Picon
Favicon

vars naming scheme concerns

Moin Thomas (Roessler),

when we talked about the issue last time on IRC, your main concern
was that it breaks compatibility with the currently installed user
base. Let's see what this is:

"dev" users who already have cried about the "alternates" change
(you didn't mention it, but "use_envelope_from" breaks it the same
way).

"stable" users, who _still_ have to go through the very same
(painful) change when they finally upgrade to the next official
stable release.

Do you want those "stable" users to go through the same pain,
suffering, crying?
I hope not, or why would "dev" users be more important to you than
"stable" users? (Are there so many less "stable" than "dev" users?)

So, to save or rather ease the pain for and crying from the
"stable" users, let them benefit from big announcements (at the
end of build process as well as eye-catching notes) and a
script which automatically converts their old configs.
When we already have that script for the "stable" users, the
number of changes doesn't matter, so it would be no extra cost to
introduce the naming scheme.

As for "dev" users who would have to apply this script extra:
it is the very nature for them to live with changes, they have to
deal with them with every patch that comes along. Among those
(Continue reading)

Permalink | Reply | 9 comments |
headers
Rocco Rutte | 2 Jun 2006 15:02
Picon

Re: vars naming scheme concerns

Hi,

* Rado S [06-06-02 14:37:44 +0200] wrote:

[...]

>Summarizing, this makes:
>- no extra cost,
>- while meaningful names are a gain for the manual users (and
>those who don't use them but go via adapted examples first).

>Where fails my logic?

Personally I think you assume that people read, which I doubt somehow. 
At least we should be pessimistic enough to assume people don't read 
announcements and upgrading notes.

As the debate continues and as I read some votes, most people don't seem 
to wonder _if_ to change but _how_ a good way could be (since they're 
afraid of the abrupt change). And for a really good way, we need to be 
very pessimistic and give people (users, admins, ...) plenty of time to 
prepare.

My idea so far (to make it more concrete): make this change along other 
re-structuring public in mutt 2.0 which follows 1.6. In the announcement 
for 1.6 we already have to note that this release will be the last one 
in the 1.x series with the old naming scheme. The first commit to the 
1.7 (or whatever devel branch will lead to 2.0) branch should be to do 
the change. Also I think since mutt is quite popular (since the muttng 
fork made it to the media), mutt 2.0 will be worth a news article. Maybe
(Continue reading)

Permalink | Reply | 7 comments |
headers
Paul Walker | 2 Jun 2006 15:06
Picon
Picon

Re: vars naming scheme concerns

On Fri, Jun 02, 2006 at 02:37:44PM +0200, Rado S wrote:

> "stable" users? (Are there so many less "stable" than "dev" users?)

Almost certainly, due to the very very slow release cycle. ;-)

--

-- 
Paul
Permalink | Reply | 0 comments |
headers
Rado S | 2 Jun 2006 15:37
Picon
Favicon

Re: vars naming scheme concerns

[=- Rocco Rutte wrote on Fri  2.Jun'06 at 13:02:09 +0000 -=]

> >Summarizing, this makes:
> >- no extra cost,
> >- while meaningful names are a gain for the manual users (and
> >those who don't use them but go via adapted examples first).
> 
> >Where fails my logic?
> 
> Personally I think you assume that people read, which I doubt
> somehow. At least we should be pessimistic enough to assume
> people don't read announcements and upgrading notes.

Well, but then they (stable users) will meet the pain anyway.
Once their attention is brought to the conflict -- no matter whether
it was through reading ahead of time or by personal experience of
mutt barking -- at least then they must check what has changed.

> As the debate continues and as I read some votes, most people
> don't seem to wonder _if_ to change but _how_ a good way could
> be (since they're afraid of the abrupt change).

That's my observation, too, given how "dev" users have been
"burnt".

> And for a really good way, we need to be very pessimistic and
> give people (users, admins, ...) plenty of time to prepare.

Fine with me.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Thomas Roessler | 2 Jun 2006 15:44

Re: vars naming scheme concerns

On 2006-06-02 15:37:41 +0200, Rado S wrote:

> Well, but then they (stable users) will meet the pain
> anyway.

Those who use the things that have changed will meet the pain
anyway.  With a new variable name scheme, basically everybody
will meet this pain, plus you invalidate a lot of advice that's
available online, just because it uses the old configuration
scheme.

I continue to believe that there is a lot more value to
sticking to the existing configuration file format than to
changing it.

--

-- 
Thomas Roessler · Personal soap box at <http://log.does-not-exist.org/>.
Permalink | Reply | 5 comments |
headers
Rado S | 2 Jun 2006 19:36
Picon
Favicon

Re: vars naming scheme concerns

[=- Thomas Roessler wrote on Fri  2.Jun'06 at 15:44:29 +0200 -=]

> > Well, but then they (stable users) will meet the pain
> > anyway.
> 
> Those who use the things that have changed will meet the pain
> anyway.  With a new variable name scheme, basically everybody
> will meet this pain, plus you invalidate a lot of advice that's
> available online, just because it uses the old configuration
> scheme.

I see you are still pulling the "numbers" card.

Let's see:
- How many people _having_ customized configs will _not_ use
"alternates"?
- How many really hit with _extra_ config change does it take to
block development?

- How many on-line docs being outdated does it need to block
changes? 10? 5? 2? 1?

Imagine that since mutt came to world there have been docs for it.
Some of them maybe never have changed, applying to versions prior
1.0 . They _are_ already outdated, and I don't mean just the
recent changes of "dev".
But the world continued without stopping just for those
unmaintained sites. Did it hurt? Sure, those unlucky still hitting
on those. But did it hurt mutt or the user who hit the wrong page
first?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Paul Walker | 3 Jun 2006 00:33
Picon
Picon

Re: vars naming scheme concerns

On Fri, Jun 02, 2006 at 07:36:23PM +0200, Rado S wrote:

> - How many people _having_ customized configs will _not_ use
> "alternates"?

Which is a single, easily made change. Bringing it up is something of a
distraction.

--

-- 
Paul
Permalink | Reply | 1 comment |
headers
Rado S | 3 Jun 2006 12:13
Picon
Favicon

Re: vars naming scheme concerns

[=- Paul Walker wrote on Fri  2.Jun'06 at 23:33:15 +0100 -=]

> > - How many people _having_ customized configs will _not_ use
> > "alternates"?
> 
> Which is a single, easily made change. Bringing it up is
> something of a distraction.

It was not my idea to bring it up... Thomas mentioned this, see
quote on /Discussion. I'm just picking it up and providing "less
crying producing" means. Once you have it, the amount doesn't
matter.

--

-- 
© Rado S. -- You must provide YOUR effort for your goal!
Even if it seems insignificant, in fact EVERY effort counts
for a shared task, at least to show your deserving attitude.
Permalink | Reply | 0 comments |
headers
Rado S | 3 Jun 2006 12:33
Picon
Favicon

Re: vars naming scheme concerns

[=- Rado wrote on Fri  2.Jun'06 at 19:36:23 +0200 -=]

> [=- Thomas Roessler wrote on Fri  2.Jun'06 at 15:44:29 +0200 -=]
> 
> > > Well, but then they (stable users) will meet the pain
> > > anyway.
> > 
> > Those who use the things that have changed will meet the pain
> > anyway.  With a new variable name scheme, basically everybody
> > will meet this pain, plus you invalidate a lot of advice that's
> > available online, just because it uses the old configuration
> > scheme.
> 
> I see you are still pulling the "numbers" card.
> 
> Let's see:
> - How many people _having_ customized configs will _not_ use
> "alternates"?
> - How many really hit with _extra_ config change does it take to
> block development?

Let's break this down even a little bit further.

- "mustfix": have config but not have "alternates" nor
"envelope_from".
- "dontfix": will stop upgrading or using mutt altogether because
of broken config.
- "cantfix": despite being willing to fix it and given
instructions, unable to fix.
- "rest": mustfix - (dontfix + cantfix)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alain Bench | 4 Jun 2006 18:13
Picon
Favicon

Re: mutt/2201: wish: <view-attach> a message/rfc822 applies $display_filter

Synopsis: wish: <view-attach> a message/rfc822 applies $display_filter

**** Comment added by ab on Sun, 04 Jun 2006 18:13:58 +0200 ****

    Hello Luis, and thank you for this report.

    The issue #1 is not a Mutt bug, but a problem in your
Perl script which doesn't work correctly even alone.

    Issue #2 seems true: $display_filter is not applied when
in attachments menu one <view-attach> a message/rfc822 part.
I'm not really sure if it's bug or feature lack, but it
could seem to make sense: After all things like $weed,
ignore, hdr_order, auto_view, mailcap, and such do apply
there. Why not $display_filter? So I turn this bug into a
wish to make use of $display_filter in attachments menu.

    Only for message/rfc822, or also for text/* parts?

> I tried to configure my .mailcap with:
>| message/rfc822; cat %s | mutt-display.pl ; copiousoutput

    Can't work: Mutt displays message/rfc822 itself
internally, without mailcap. Furthermore it's a useless use
of cat %s |

Bye!    Alain.
Permalink | Reply | 1 comment |

Gmane