Do any of you have a working example that uses troff/groff (mm macros?) to
print four column output? I'll bet someone does.
Or perhaps a troff expert would kindly whip up an example that correctly
uses the mm MC and MULN macros??
Rawr, ye dinsaours.
happy new year,
steve
--
Hi steve,
Do any of you have a working example that uses troff/groff (mm
macros?) to print four column output? I'll bet someone does.
Best off asking on the GNU groff mailing list, even if you're not using
groff but an alternative, e.g. Heirloom troff. That's where us troffers
hang out, and
Greetings all,
I'm been thinking about Markus's master's thesis, and it's motivated me to
remove some old crud sitting around in nmh. I'd like to get some feedback
about it.
- Remove ALL the traces of UUCP support. I'm assuming that the only response
here will be, nmh still has UUCP
- Remove rcvtty completely. This works in conjunction with slocal or
I would not be happy with that, I use slocal and rcvtty for
(user-configurable) new message notification.
My .maildelivery is:
#Field Pattern Action Result String
X-Spam-Flag NO qpipe R
I would like to see the Content-MD5 bits stay. I can import a license-friendly
set of MD5 routines to eliminate the external dependency.
The rest can go in the bin.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
- Remove rcvtty completely. This works in conjunction with slocal or
I would not be happy with that, I use slocal and rcvtty for
(user-configurable) new message notification.
Wow, ok ... I didn't think anyone used that, but I stand corrected. It
looks like what we did for OpenBSD was simply
Wow, ok ... I didn't think anyone used that, but I stand corrected. It
looks like what we did for OpenBSD was simply make rcvtty not work. Are
you fine with that? I'm not really interested in dealing with OpenBSD's
brokenness here.
Fine with me, I usually run some flavor of Linux.
Although it
I would like to see the Content-MD5 bits stay. I can import a
license-friendly set of MD5 routines to eliminate the external
dependency.
Well, it's not an external dependency exactly (but there is one for
the test suite). We have the library routines already. My real question
is: why keep it?
I have used it in the past, and plan to again on an upcoming project. It is a
fast and simple way to identify identical content when scanning large message
archives.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
Jerrad Pierce writes:
Wow, ok ... I didn't think anyone used that, but I stand corrected. It
looks like what we did for OpenBSD was simply make rcvtty not work. Are
you fine with that? I'm not really interested in dealing with OpenBSD's
brokenness here.
Fine with me, I usually run some
I have used it in the past, and plan to again on an upcoming
project. It is a fast and simple way to identify identical content when
scanning large message archives.
Fair enough; as long as someone's using it, that's good enough for me.
Although ... how does that work, exactly? You add
...
Ken Hornstein
Tuesday, January
01, 2013 8:56 AM
Greetings
all,...- Remove dbm/ndbm dependency. The ONLY reason
nmh has a dependency on a db library is for duplicate suppression
in slocal; if slocal finds a duplicate Message-ID, it discards it.
I didn't think
Please don't remove rcvtty -- I use it too -- and on OpenBSD no less,
with a tiny patch that brings back utmp support (so few lines, was it
really necessary to remove it?).
Yes. We made a decision to migrate to POSIX, and I wouldn't call the
amount of code removed small (look at the revision
ken wrote:
- Remove dbm/ndbm dependency. The ONLY reason nmh has a dependency on
a db library is for duplicate suppression in slocal; if slocal finds
a duplicate Message-ID, it discards it. I didn't think getting a dbm
library was so hard, but apparantly it is under Linux; the
Ken Hornstein writes:
Please don't remove rcvtty -- I use it too -- and on OpenBSD no less,
with a tiny patch that brings back utmp support (so few lines, was it
really necessary to remove it?).
Yes. We made a decision to migrate to POSIX,
I mentioned that utmpx is not required by POSIX,
15 matches
Mail list logo