Ken wrote:
> maybe the "right" fix is to properly bubble up read errors from m_getfld()?
I agree, and would be willing to visit that after 1.7. I think that all callers
should be able to handle the error, but I'm not certain.
In the meantime, how about the fix below to parse_mime()? That shoul
Ralph wrote:
> 6.8.5 was right; /tmp can be hardcoded.
I'd be fine with that. We'd have to deprecate the current behavior,
as you noted. The test suite uses MHTMPDIR but that shouldn't be hard
to change to TMPDIR.
David
___
Nmh-workers mailing list
Lyndon wrote:
> > On Mar 5, 2017, at 7:26 PM, David Levine wrote:
> >
> > Not off hand. It looks like $MHTMPDIR was introduced between MH 6.8.5
> > and the entry of nmh into CVS. MH 6.8.5 hard-coded the use of /tmp/.
> >
> > The thread beginning at
> &
Ralph wrote:
> Anyone know why nmh uses ~/mail instead of /tmp? The latter may well be
> tmpfs so no disk is hit, and cleaning it isn't nmh's problem.
Not off hand. It looks like $MHTMPDIR was introduced between MH 6.8.5
and the entry of nmh into CVS. MH 6.8.5 hard-coded the use of /tmp/.
The
Ken wrote:
> And because of changes to email protocols over the past few decades,
> you end up needing more and more knobs for SMTP (controlling TLS, SASL,
> certificate validation, XOAUTH2 parameters, and who knows what else we
> will have in the future). I'm unsure how much of that stuff we wan
Paul F wrote:
> oh: it looks like "mhparam -all -debug" might give everything.
This is kinda interesting. -debug is currently ignored with -all.
It wasn't before commit 234c9cc4, which replaced a badly formatted
conditional statement with an else branch. Instead, it could be
changed to be two
Tom wrote:
> $ folder;command show automount | egrep -i '^(messagename|X-Envelope-From)'
> |head -4
> ipa+ has 4706 messages (1-4706); cur=4706; (others).
> X-Envelope-From: freeipa-users-boun...@redhat.com Fri Apr 29 16:01:46 2016
> X-Envelope-From: freeipa-users-boun...@redhat.com Mon May 2
Tom wrote:
> $ pick automount -list |xargs -n1 show |egrep -i '^messagename' |head
> MessageName: (Message ipa:378)
> MessageName: (Message ipa:437)
> MessageName: (Message ipa:438)
> MessageName: (Message ipa:451)
What's the output from "show automount |egrep -i '^messagename' |head" ?
David
_
hymie wrote:
> But it seems like there is something I'm missing, that will enable
> mhshow to say "Oh, base64 and pgp-encrypted. I should use the
> 'gpg2 -d %F | less' command to show this part"
Here are some pieces, in addition to gpg-agent, that might help:
1) I think you're looking for this
Jon wrote:
> Ralph Corderoy writes:
> > When implementing this, was there a reason whatnow doesn't implement
> > `cd' with chdir, as normal Unix commands that offer cd do, and instead
> > "fake" it for `pwd', `ls', and `attach', but not `mime', etc?
>
> Well, the most honest answer that I can give
Ralph wrote:
> It's very unintuitive, well, wrong, that a `cd' command at a command's
> prompt doesn't change the current working directory as far as all other
> commands are concerned. That's not how other Unix commands that provide
> cd work. If it can't be fixed then whatnow(1) could do with
Paul V wrote:
> that looks like PID.TIME@gethostname. is this something the UUID system could
> help with?
That might be helpful if someone wants to dig in. Though there
still might be a question of true global uniqueness. I was
thinking that the entire email address might be better than the
lo
Ralph wrote:
> my point was that
> Message-IDs can also be poorly produced and that shouldn't weaken the
> cause for either, instead stamp out the poor producers.
My point was that nmh is a poor producer of Message-IDs, given the
global uniqueness requirement.
David
_
Ralph wrote:
> Hi Ken,
>
> > I'm not sure you can, in practice, guarantee that they are globally
> > unique.
>
> Ditto Message-ID?
Right, nmh doesn't have a way to generate a globally unique message
or content ID. The default form is (and has been in MH), by way of
example:
Message-ID: <332
Ralph wrote:
> I've been experimenting with send(1)'s `-msgid -messageid random'
> invocation. If nmh is left to add the MIME headers, the default, then
> Content-IDs get whacked in that look an awful lot like a `-messageid
> localname', the default.
>
> Should -messageid random affect Content-ID
I added a public plug_leaks branch. Most nmh/MH programs are
short running so this isn't high priority. Feel free to merge
from master to the branch at any time if you want to minimize
noise when checking for leaks.
David
___
Nmh-workers mailing list
Laura wrote:
> formatproc: /u/lac/bin/replyfilter
>
> could that be to blame?
I doubt it. I don't think you would have reached the whatnow prompt
if it failed.
I also doubt that procmail would bother anything in your drafts
directory, but you might want to verify by looking in your .procmailrc.
I agree with what Ken said. Also, the annotation in the replied-to
message only happens if the send was apparently successful. That
happens first, then the draft is renamed to the backup.
Both the annotation and the rename follow an explicit check for
success. I can't explain how the send would
Laura wrote:
> I think _after_ the whatnow(1) prompt, as well, but it has long since
> scrolled away. I don't remember the shell complaing about receiving an
> unwanted 'send', so I think that whatnow received it.
So it sounds like you did tell whatnow to send.
Was the draft renamed to a backup
kre wrote:
> la...@larryhynes.com said:
> | So we're 'good to go' with 'sub-folder', not 'sub\-folder'?
>
> Absolutely, the former is correct, the latter would mean sub minus folder.
Committed, thanks all.
David
___
Nmh-workers mailing list
Nmh-wor
Lyndon wrote:
> The date should only be updated if the content substantively changed. Simple
> formatting and wordsmithing changes don't count.
Well, I've been obeying that for formatting changes, but not content changes.
David
___
Nmh-workers mail
Larry wrote:
> Some more simple wordsmithing...
Comitted, thanks!
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Larry wrote:
> This incorporates Ralph's suggestions and David's observation
> re: my ordering of things in previous patch.
Patch applied (and date updated), thanks!
It occurs to me that rcvdist, and rcvtty, don't use .maildelivery
or maildelivery. I confirmed with strace. Should their man
pag
Larry wrote:
> While I was here, I removed two 'empty' paragraphs (.PP) in forw(1).
> They may have been intended as line breaks, but I think they are
> unnecessary; feel free to overrule me!
Patch applied, thanks! I did update the date in each, per previous
discussion (if any content changed, u
Larry wrote:
> Clean up, and change .SS case to Title Case, from UPPER, (hopefully)
> in line with other pages.
I'll leave this for Ken, if he has time. The changes look good to me.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://li
Larry wrote:
> My proposal is 'Default foo', for the foo in %nmhetcdir% and
> 'User foo' for the foo in the user's .
I'm fine with that. Though didn't your rcvdist.man changes
get the following backwards, assuming that files in $HOME
are treated the same as those in the user's ?
$HOME/.maild
Patch applied, thanks!
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Larry wrote:
> My (limited) understanding is that the 'correct' approach is to
> always use .BR in such cases; or, to put it another way, names of
> programs should be bold, and options should be italic.
>From the "Program Names" section of docs/README.manpages:
In running text, nmh program
Larry wrote:
> Add a reference to fmttest(1), delete a superfluous 'the',
> delete the '...is simply...' line.
Committed, thanks!
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Ken writes:
> D'oh! My code didn't work, but only because I didn't move those calls
> down far enough. The attached patch DOES pass your test.
Works for me. Diff for improved test is attached.
David
diff --git a/test/repl/test-repl b/test/repl/test-repl
index 5d0d7de..c406b00 100755
--- a/te
Ken writes:
> Hm. I was actually thinking something more like the attached (note:
> compiles, but I haven't actually tested it yet).
Let me save you the trouble :-/, it won't work. The code that sucks
the Fcc: header field value from the replied-to message is
fmt_addcomptext(name, tmpbuf), afte
Valdis wrote:
> That compiles correctly?
Yes, and does what I want.
> You added a { and I don't see a added } to match.
Another { was removed:
-if (fcc) {
> In addition, do we want to set CF_SUPPRESS for *all* headers, or just Fcc?
> If the latter, the |= CF_SUPPRESS should be inside
Ken writes:
> Hm. I don't think we can figure out, without a lot of work, where
> to place an appropriate format instruction to include a Fcc.
Right, I don't want to change that behavior, anyway.
> I think we're all in agreement that the current behavior where it
> takes the Fcc from the replie
Ken wrote:
> [Paul F wrote:]
> >would it be too terrible to simply add the header, probably at the
> >end, if it's not in the components file?
>
> You mean by calling anno() (or something like that)? Hrm. What do
> others think?
anno() on a temp components file, I assume. Anyway, I'm not fond
Ken wrote:
> Hm. Since most of the time you end up in an editor, will the user
> see the message or will it be erased by the editor when it clears the
> screen?
That could happen, but that's true of any nmh warning message that
appears before the edit. (This isn't a problem with an editor that
I wrote:
> The same thing can happen with the -to, -cc, -from, and -subject
> switches: if the format file doesn't contain the respective
> component, the switch will be silently ignored. It can happen with
> comp, dist, forw, and repl, for those switches that each program
> supports.
>
> I was
Ken wrote:
> Oh, duh, you're right. When I rototilled that code, I was just copying
> the things around it (like "to" and "cc" above it) and I didn't really think
> that fcc should have been treated differently. I see your point; it's
> completely broken now! (Unless you get a message that happe
Larry wrote:
> This is a beast, and we may not tame it at the first attempt.
But a great beginning. Committed, thanks.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
I wrote:
> 1) Support -fcc (and -to and -cc) without having a corresponding
> component in the components file. Adding that support won't
> introduce a backward incompatibility. This is entirely an internal
> implementation relic.
Maybe I wasn't clear with this:
> That kind of dependency shoul
Ken wrote:
> Since it's been around forever, I'm not sure we can easily change it
> without breaking a lot of existing format files.
Two different things:
1) Support -fcc (and -to and -cc) without having a corresponding
component in the components file. Adding that support won't
introduce a bac
Ken wrote:
> That's not exactly correct. It's really there to make the -fcc switch
> to repl work.
That kind of dependency should be removed. Is there any reason not to
add a new component if one (fcc, in this case) isn't found?
David
___
Nmh-worker
Norm wrote:
> 1. How many people on the planet are both smart and knowledgeable enough
> to have done that?
I don't know that smart has anything to do with it. MH/nmh formatting is
documented, and while cryptic, it gets the job done. fmttest(1) is very
helpful when working with format strings.
Larry wrote:
> Replace 'option' with 'switch' in a couple of places, correct
> (hopefully) a few sentences, restore '.SS "Multiple Folders" to its
> rightful place.
Thanks. Committed, and committed your patch to dist.man.
> The line 'If flist is invoked by a name ending with "s" (e.g.
> flists)
Larry wrote:
> I would find '...comp will prompt you for the disposition of the
> draft' to be slightly (only slightly, mind) less obtuse than the
> current version.
I committed your patch to comp.man, thank you!
I'm not wrapping my head around your later thoughts, feel free to
send updates.
Da
Larry wrote:
> The line 'The first, previous, next or last messages, if they exist.'
> doesn't seem to accurately cover the accompanying 'foo:N' listing
> in the following, or am I missing something?
How about this:
:+N
:-NUp to N, where N must be a positive number, messages
Larry wrote:
> The following is the beginning of an attempt to clean up the manual
> pages somewhat.
Patches applied, thank you!
I added one change to each: there is a last-changed date at the
top of each .man file.
> grep tells me that 'switch' is used 193 times, whereas 'option' is
> only us
Norm writes:
> Thank you, but that doesn't have a "From:" header.
Oh, right, for messages that don't contain one of your addresses
in one of To:, Cc:, or From:. I do that in order to reply from
the message that was used to send to me, and use an editor macro
to fill in From: if there was no such
Norm writes:
> Would somebody be willing to please send me a replcomps that does
> not do an fcc, but that does do a:
> cc: %(localmbox)
>
> and which also "updat[es] the In-Reply-To header", as Ken Hornstein suggested
> above.
How about the attached? It also adds References. And with
th
Norm wrote:
> David Levine writes:
> >
> >> I wonder if, for 1.7, that simple syntax and semantics could be guaranteed?
> >> That way, it would be possible for *proc commands to be always uptodate.
> >
> >I'm not sure how. For example, if a new switch
Norm wrote:
> I observe that, ignoring all lines not beginning with exactly two ' '
> characters, the outputs of nmh's commands' -help, seem to be extremely
> regular and simple.
Yes, because they're generated from the switch definitions in the code
of each program.
> I wonder if, for 1.7, that
Valdis wrote:
> This is probably going to be a *total* joy to debug.
I'm hoping that I fixed this on Oct 21. Please tell me that
your code is from before then. The weak link was in nmh's MIME
parser, and needed help from m_getfld() for the fix.
> I admit being totally unclear as to where the \
Ralph wrote:
> Can mh-tailor get the chop if the references get switched over too?
I'm OK with that. Though it would upset the consistency of:
Files Used by nmh Commands
mh-alias(5) alias file for nmh message system
mh-format(5)format file for nmh message system
Hi,
I'd like to change docs/COMPLETION-BASH in the following ways:
1) generate it from man/mh-chart.man (which in turn is generated)
2) move it to etc/bash_completions_nmh (because autoconf doesn't
like generated files in docs, and to use a filename that
I think better fits usage)
3) Remo
Norm wrote:
> When I do a dist, the message goes to a /dev/null somewhere. I don't know
> if the problem is with my MH setup or somewhere else.
I don't see why the message wouldn't have been delivered. The -snoop
output shows that your STMP server accepted it.
> Ken Hornstein never Emailed me.
Ralphwrote:
> Has my fledgling git-fu failed me, or is test/mhbuild/test-mhbuild
> missing?
You're right, it was missing, but has since been fixed.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh
Ken wrote:
> You know, just out loud ... it wouldn't surprise me if it only happens
> with lines that start with "#"; I bet even though directives are turned
> off, it's seeing a backslash as the directive line continuation character.
That was it. I committed a fix to disable erasing a trailing
Tom wrote:
> Ordinarily, and in every previous version of nmh, that would have
> been transmitted as-is. But today, something decided that it needed
> to be transmitted as quoted-printable, and that seems to have included
> a decision that backslash-newline sequences should be deleted.
Really?
Hi,
I just committed a fix to replace non-ASCII bytes in headers
with ?'s, only when attempting to use EAI (RFC 6532) with a
non-UTF8 locale.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-worker
Ken wrote:
> How does that work for a binary RPM? If the answer is, "it doesn't", then
> that's fine; just trying to understand.
The Fedora RPM spec includes w3m as a dependency, maybe that's
what you're looking for.
David
___
Nmh-workers mailing lis
Ken wrote:
> If you install it the "normal" way, it download a pre-built binary
> distribution that doesn't know about things you installed like w3m that
> might be useful for displaying HTML content.
The RPM spec generates it through "make install". /etc/mhn.defaults
is a make target. (So it w
Ralph wrote:
> It occurs to me that it may be quicker to write tests that aim to
> increase coverage rather than test actual output against expected, etc.
> That would then give valgrind more to chew on. They could then be
> fleshed out separately, especially if they were marked in some way, to
>
Lyndon wrote:
> But how much code coverage do we actually get?
82% of the lines that Ralph touched recently are covered. (Based on join of
git blame and gcov outputs.) Not 100%, so your point is well taken, but higher
than I expected.
David
___
Nmh-
Lyndon wrote:
> All I will make noise about right now is: valgrind valgrind valgrind!
Great idea. I just ran it, all clean for Ralph's work. My last MIME
parser fix introduced an anomaly, I just fixed.
David
___
Nmh-workers mailing list
Nmh-workers@
Ralph wrote:
> No, I mean `(y|n)'. Or is `yes' required? Etc. :-)
Oh, I missed that. Good idea, done.
And I forgot to mention earlier, your config contained:
TLS support: no
OAuth support : yes
While that's fine from the nmh point of view, in practice,
Ralph wrote:
> Returning to that Mac OS X box to try it, I again went with the
> defaults.
>
> $ sh build_nmh
> Install prefix [/usr/local/nmh]:
> Locking type (dot|fcntl|flock|lockf) [determined by configure]:
> MTS (smtp|sendmail/smtp|sendmail/pipe) [smtp]:
> SMTP server(s
Ralph wrote:
> I found the build on Mac OS X failed. build_nmh prompted `[n]' for TLS,
> which I accepted with Enter. That stopped --with-tls getting to
> ./configure; good. But configure defaults to yes, I think,
Yes, it did. I just committed a change to do this:
By default (with_tls='
Ken wrote:
> I dunno, I think we'd need to think carefully if a particular use of
> strncpy() really warrants an abort vs a truncate. I mean, just crapping
> out on a really long line that other MUAs handle just fine seems rather
> unfriendly to me. What do others think?
I'm not a fan of abort,
Ralph wrote:
> Hi David,
>
> Worked well on a machine where I hadn't built it before, but was likely
> to have some of the optional development packages installed.
Yeah, the script doesn't check those dependencies in advance. The build
doesn't take very long on modern machines so I think that's
I wrote:
> Ralph wrote:
> > Minimal effort by those buildman, giving them a script to run.
>
> build_nmh, with a few other additions (curl or wget, showbuildenv)?
This now works:
wget http://git.savannah.gnu.org/cgit/nmh.git/plain/docs/contrib/build_nmh &&
sh build_nmh
Good enough? I didn'
Norm wrote:
> The send man page says "Most of the features attributed to send are actually
> performed by post.". That leaves me guessing as to the exact division of
> responsibility between send and post.
>
> I'm guessing, but am not certain, that the answer is in the next paragraph
> about mhbui
Tom wrote:
> David Levine writes:
> > Ralph wrote:
> >> I've since overridden configure's CFLAGS to add `-pedantic
> >> -ansi', but I wonder if m4/cppflags.m4 should attempt these
> >> and add them if they work?
>
> > We used to do t
Ralph wrote:
> I've since overridden configure's CFLAGS to add `-pedantic
> -ansi', but I wonder if m4/cppflags.m4 should attempt these
> and add them if they work?
We used to do this, but I removed them in commit 987b10b3. My
thinking was that CFLAGS is up to the user. I still think that's
the
Lyndon wrote:
> I'll add it when if/when I need it.
How bout I change the LC_ALL in the setlocale() to
LC_CTYPE? Then you can override with $LC_ALL.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/n
Lyndon wrote:
> The overhead of $NMH_LANG isn't even measurable, and the code path is trivial.
Yes. But, I just don't want to burden the maintainers, and add
roughage to the documentation and test suite, for a feature that
I don't think will be used. It's easy to add later if we need,
hard to t
Ken wrote:
> You mean setlocale(LC_ALL, "")? Which really means "Just take everything
> from the environment", right?
Right. More accurately, set everything based on the first of LC_ALL,
LC_CTYPE (that's all we care about), and LANG that is set (though
implementation dependent, that seems commo
I committed the locale profile component support.
Ken wrote:
> Turning this around ... all we really care about is LC_CTYPE.
Historically, MH and nmh have set LC_ALL. Should we just set
LC_CTYPE instead?
David
___
Nmh-workers mailing list
Nmh-worker
Paul F wrote:
> (in the interests of sampling all the dogfood, i guess :-)
Have you tried the following?
repl -filter mhl.replywithoutbody -convertargs text/html '' -convertargs
text/plain '' "$@"
That mhl file includes the attribution line. mhn.defaults
uses sed to insert the leading '> '.
Ralph wrote:
> That's just been updated to not be generated and use the single identity
> array I mentioned.
Cool.
As far as getting automake to create the etc dir, I think there should be
a way to do it by moving mhn.defaults to a variable that automake will
recognize.
David
_
Lyndon wrote:
> I.e., the standard (MH-modified) UNIX model is:
>
> 1) command line (-locale)
> 2) mh-command-specific profile entry (.mh-profile)
> 3) environment ($NMH_LANG)
> 4) profile default override (.mh-profile)
> 5) OS environment default (locale())
>
> It's arguable about the ordering of
Laura wrote:
> And, of course, I do use attach at the What Now? prompt.
So, another approach to get what you want (8-bit message even if
it contains no 8-bit characters) would be to do all this:
1) Add support for locale profile component to nmh.
2) Use latest nmh (HEAD of master) or upcoming nm
Ralph wrote:
> OK, I'll add a check-programs target to Makefile.am then so I can do
> `make all check-programs' without running all the tests.
Thanks.
> I've been going for lots of little commits to help bisect.
Thanks!
> Poking around etc/gen-ctype-checked.c and the related code, I've found
>
Ralph wrote:
> I'm not sure why script(1) is run in the background and then immediately
> wait'd for; is it to just get byte or few of input without wait-ing? echo | ...
The test originally did that, but 1) the man page on Linux cautions against
it, as shown by the excerpts that Ken posted, an
Ken wrote:
> I noticed that test/install-mh/test-version-check is hanging for me
> on MacOS X. Specifically, the "script" command on MacOS X seems to be
> the problem; for reasons I don't understand quite yet when "script" is
> run the input is set to /dev/null, and it turns out when THAT happens
Laura wrote:
> I don't know about Tom, but my problem isn't that I want to send valid
> US-ASCII emails, but that I _never_ want to send valid us-ascii emails.
> And the last thing I want to happen is for nmh to not be able to
> tell what I want, stick in us-ascii (because the thing needs a
> con
Lyndon wrote:
> > On Oct 17, 2016, at 6:13 PM, David Levine wrote:
> >
> > I'm not a fan of environment variables when there's an alternative.
> > The profile seems like a good home.
>
> $NMH_LANG -> <.mh_profile> -> locale() seems like
Lyndon wrote:
> What about an $NMH_LANG environment variable that the runtime
> could look for *very* early on, and use to seed $LANG.
I'm not a fan of environment variables when there's an alternative.
The profile seems like a good home.
> Seems like minimal impact to the rest of the code that'
Ken wrote:
> >[Tom wrote:]
> >I thought Laura's suggestion was to be able to put something like
> >
> >locale: en_GB.utf8
> >
> >into ~/.mh_profile, which seems eminently sensible to me.
>
> Sigh. I won't object if someone does this work ... but it's not something
> I want to tackle, for the afor
Ralph wrote:
> Whatever would be most useful for you that refer to it.
Doesn't matter, I'll put it in a separate sandbox. Branch
sounds like a good idea, so we add to it.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu
Ralph wrote:
> Can't you all just have a checkout of the last git with MH
> to look at for reference? :-)
I'd prefer putting it into a separate repo. But OK, if we
tag it and promise not to remove the tag. I don't feel
strongly about it.
David
___
Ralph wrote:
> I've noticed things like test/fakepop only get built on a
> `make check' because that needs to use them. OTOH, it would be nice to
> see compilation succeeds along with everything else in the `all' target.
Maybe add a phony target that would build the test programs?
Then either sp
Ralph wrote:
> I'm moving all the headers into nmh's domain, the ones it cares about in
> drafts, anyway. This is only talking about draft processing. So
> `Received' isn't in the set. In effect, all draft headers become nmh
> directives, none of them are wire headers any more. Directive `To'
Ralph wrote:
> Rather that re-tread worn ground, how about a considered reply to my
> suggestion that all headers be known to nmh and the user having to add
> to that list,
Is "user having to add to that list" in your original proposal?
I'm missing it. Is it a profile entry to allow the user to
Paul wrote:
> david wrote:
> they're no more "internal" than "Fcc". so pleasing the eye, is,
> actually, not unimportant.
If you want to talk about typing them in, I could understand. Pleasing
the eye, I just don't get it. Nmh-Attach doesn't look that much different
to me than Attach. (And i
Ralph wrote:
> Hi Norm,
>
> > While developing and debugging a postproc, I want to use nmh to send
> > mail without using the postproc that I'm debugging, but to use it
> > sometimes when I do a send.
>
> Keep toggling the name of the postproc entry?
>
> sed -i '/^x*postproc:/!n; s/^x/y/; s/^p
Oliver wrote:
> I prefer that we don't have Nmh- prefixes on our headers. Apart
> from it seeming ugly
Don't look at them :-) I am serious. These directives are for
internal nmh use, not to please the eye unless that can be done with
no drawbacks. Note the two distinct purposes described earli
Ralph wrote:
> Thanks, that helped quite a bit. I've pushed a trivial fix to master.
> If I've done anything wrong, e.g. not configured my ID properly, then
> let me know.
Looks fine.
One thing that we should add to README.developers, the buildbot results
are available at http://orthanc.ca:8010
Ralph wrote:
> Hi David,
>
> :-) Through a cunning bit of social engineering the other day,
I don't want to know :-)
> I did apparently gain access to nmh's git repository. Is there
> anything that documents conventions in using it for the project,
> e.g. whether to check in directly on master
Ralph wrote:
> Hi David,
>
> > Might Ken's commit adfed5f72bc07ac7de8dfc62188338d4d4f25a38 have fixed
> > this?
>
> Yes, indeed.
Great! We'll get you to the bleeding edge yet.
> IOW, it seeks to 4Ki and reads 4Ki - 1 so it's left in the right place
> to read the one byte, that we already have,
Norm wrote:
> But I wonder how much additional clarification is wise. Perhaps nmh
> documentation is reaching, or has reached, the law of diminishing returns. The
> more man pages that are added and the longer man pages become, the harder it
> will be to find something, and the less likely it woul
Ralph wrote:
> > 1.6's mhshow(1) says
> >
> > mhshow: unable to convert character set to gb2312, continuing...
>
> I meant to draw attention to that. It was converting *from* gb2312 (to
> UTF-8).
Fixed, thanks.
David
___
Nmh-workers mailing list
501 - 600 of 1610 matches
Mail list logo
