In message <201203160209.q2g29b1w019...@darkstar.fourwinds.com>,
Jon Steinhart wrote:
>Please excuse my ignorance here. What killed x-?
If anybody happens to know, I'd also like very much to find out who killed
Rosie Larsen.
Regards,
rfg
___
Nmh
In message <201203160200.q2g20jwt032...@hedwig.cmf.nrl.navy.mil>,
Ken Hornstein wrote:
>>Full disclosure: I am using NMH version 1.3. Alas, version 1.4 has not
>>been ported to FreeBSD yet. (Is this the real root of the problem?)
>
>When you say "not ported" ... do you mean, "It doesn't work
In message <201203160123.q2g1nay7018...@darkstar.fourwinds.com>,
Jon Steinhart wrote:
>valdis.kletni...@vt.edu writes:
>> --==_Exmh_1331860781_2149P
>> Content-Type: text/plain; charset=us-ascii
>>
>> On Thu, 15 Mar 2012 18:02:48 PDT, Jon Steinhart said:
>>
>> > And yes, having defaults for c
> >I agree (with the re-write, I've never witnessed the problem).
>
> I assume you mean WITHOUT the rewrite, because nobody's re-written
> m_getfld last time I looked :-)
Right.
> Looking at things ... it may be a simple fix, actually. I wasn't
> envisioning any changes to m_getfld(), that's for
>I agree (with the re-write, I've never witnessed the problem).
I assume you mean WITHOUT the rewrite, because nobody's re-written
m_getfld last time I looked :-)
It's sort of Steve's setup that triggers it; not only does he have a bunch
of Received: headers, but a huge spam score report, a coupl
>>> Punt until the m_getfld() re-write
If this was a five-9s thing, like 99.999% working, then I'd be down for that.
But it's not, and maybe the fix is fairly simple?
>> If we guess wrong, that would result in one extra read in some cases.
Do I understand correctly that we're wringing our ha
Ralph wrote:
> Punt until the m_getfld() re-write. It's annoyed me for years, it can
> continue a while longer.
I agree (with the re-write, I've never witnessed the problem).
The code after Ken's excerpt goes directly into the io buffer.
It's in the caller, not m_getfld().
David
_
Hi Ken,
> Thoughts?
Punt until the m_getfld() re-write. It's annoyed me for years, it can
continue a while longer.
Cheers, Ralph.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
>Since I started using mh-v, for about two months, I've been keeping a
>pretty close eye on making sure scan and mhshow work perfectly. This
>week collected four msgs where the decoding %{body} is truncated after 6
>to 16 characters with v1.2 and v1.4!
Okay, Steve was nice enough to give me a tes
> Could someone forw me one of the affected messages? I'll be glad to track
> it down. Also, if you could include an MD5/SHA1 checksum of the message
> I can be sure on this end to recreate it exactly?
Will do, off list, in a sec.
steve
--
___
Nm
> Been seeing this, haven't had a chance to track it down. Looking at exmh's
> .xmhcache files, I have 145,141 total messages listed in .xmhcache entries,
> and
> the bug is affecting 3,266 of them. So there's an anectodal value for the
> frequency.
...but isn't the body sometimes smaller
>Wow. So I'm not hallucinating (at least not this time :)
>
>Been seeing this, haven't had a chance to track it down. Looking at
>exmh's .xmhcache files, I have 145,141 total messages listed in
>.xmhcache entries, and the bug is affecting 3,266 of them. So there's
>an anectodal value for the= freq
On Fri, 16 Mar 2012 16:46:46 CDT, ra...@hep.wisc.edu said:
> Can someone/anyone replicate? Test with the msg from Ken to this list today,
> March 16 2012 at 11:35:44 -0400?
Wow. So I'm not hallucinating (at least not this time :)
Been seeing this, haven't had a chance to track it down. Looking
Since I started using mh-v, for about two months, I've been keeping a pretty
close eye on making sure scan and mhshow work perfectly. This week collected
four msgs where the decoding %{body} is truncated after 6 to 16 characters
with v1.2 and v1.4!
See examples (300, 500-502) after my sig.
Can
Ken Hornstein writes:
> Watching Ronald Guilmette struggle through making the attach command
> work, I decided that this stuff should be cleaned up. I understand
> Jon Steinhart's initial reluctance to make attach turned on by
> default, but it's been in there for a decade now and I haven't seen
>
Watching Ronald Guilmette struggle through making the attach command
work, I decided that this stuff should be cleaned up. I understand
Jon Steinhart's initial reluctance to make attach turned on by
default, but it's been in there for a decade now and I haven't seen
any complaints about it (other
On 2012-03-16, at 8:28 AM, David Levine wrote:
> If we prefer to default to the current behavior (@ enabled)
> but deprecate that default, OK by me.
How about we add the switches in 1.5 but leave it on and mark the feature as
obsolete in the release notes. In 1.6, disable it by default. And the
>If we prefer to default to the current behavior (@ enabled) but
>deprecate that default, OK by me.
I actually just wrote the code :-) But I'm fine with saying that we're
going to deprecate creating @ as a default.
--Ken
___
Nmh-workers mailing list
N
Ken wrote:
> Because ... I'm writing the code, and I get to make the decision? :-)
>
> In all seriousness ... it's a balancing act between "move nmh forward"
> and "keep around existing interfaces". So I have to make a judgement
> call, and my judgement is to add switches. If someone ELSE wants
>Rather than proliferate switches, why not begin deprecating it, by first
>making it something that must be explicitly enabled in build?
Because ... I'm writing the code, and I get to make the decision? :-)
In all seriousness ... it's a balancing act between "move nmh forward"
and "keep around ex
Hi,
Jerrad Pierce wrote:
> Rather than proliferate switches, why not begin deprecating it, by
> first making it something that must be explicitly enabled in build?
I've known of ./@ for many years and have only rarely used it, and it
does make other users ask why they can see a file called ./@.
>forever (and like Valdis said, exmh might use it). AFAICT, this has
Then it should be updated to use $EDITALT, n'est-ce pas?
(The dox use lowercase, but isn't convention for environment vars all-caps?
Rather than proliferate switches, why not begin deprecating it,
by first making it something th
>Better mime handling in repl/forw ? Ok, maybe that is too much to ask.
>But an option for repl/forw which simply drops attachments shouldn't
>be too complicated. Unfortunately I can only hope this request is
>category a) stuff.
Sadly, it's complicated. See previous discussions on the list. I w
On 03/15/12 01:31, Ken Hornstein wrote:
So I guess what I'm asking is ... does anyone else think that there is
something that should be in 1.5? Note that these suggestions should either
be a) simple or b) come with an offer to write the code :-). I know
Paul Vixie wants to kill m_getfld() and
> >If it's not used by exmh (and mh-e and xmh?), how about if we
> >disable it by default?
>
> OK. I can assure you that exmh doesn't use it (at least not in any
> critical way) because it's broken for multiple concurrent replies,
my ol' exmh setup creates ~/@ when doing repl.
but keep in
David Levine writes:
>If it's not used by exmh (and mh-e and xmh?), how about if we
>disable it by default?
OK. I can assure you that exmh doesn't use it (at least not in any
critical way) because it's broken for multiple concurrent replies,
and I frequently reply to many messages concurrently w
26 matches
Mail list logo
