I've gotten no feedback on repl -convertargs. Either people started
using it and found it so natural that they immediately forgot about
it, or they haven't tried it.
The main enhancement is that content in a replied-to message can be
converted as desired. Content that isn't converted, such as
Andy wrote:
The previous version of nmh on my system didn't bother with
conversion (at least not to my knowledge) and would naively just
output the text/plain portion and let my terminal figure out what to
do with it (which occasionally left some characters unreadable, but
it was sufficient
Paul F. wrote:
really? how do i tell nmh to _prefer_ text/plain over text/html?
i'll be genuinely shocked if there's a way.
You're right, prefer isn't the right word. You can block
showing of text/html, as you have done with your shell functions.
David
Paul F. wrote:
david wrote:
Paul F. wrote:
as an aside, i actually think the sender's ranking is a
highly overrated, and possibly even obsolete concept these
days, RFCs notwithstanding.
I'm not sure about that. My phone seems to handle it
(multipart/alternative)
Paul F. wrote:
as an aside, i actually think the sender's ranking is a highly
overrated, and possibly even obsolete concept these days, RFCs
notwithstanding.
I'm not sure about that. My phone seems to handle it
(multipart/alternative) nicely.
On the other hand, I have been getting emails
Eric wrote:
Bug is when Local-Mailbox is a substring of a From address, scan
(and repl) think it's a message from yourself.
Anyone know how to fix it? :)
The relevant code starts at line 416 of sbr/addrsbr.c, in
ismymbox(). cp is set to the From: address (te...@example.com) in
the message,
Ralph wrote:
It looks like FT_LV_MULTIPLY_L got inserted into a list of #defines,
bumping the numbers after it on by one. Then
sbr/fmt_{compile,scan}.c both changed.
Thanks, Ralph. I built a distribution file and pointed Norm to it.
David
___
I got tired of fighting the bugs in par introduced by
the i18n patches, so I removed them from the Fedora
package. Updates are now available for F20 and F21.
They use just the vintage source code plus the one
patch to fix handling of non-breakable space.
David
Norm wrote:
mh-format constitutes a real barrier to All power to the user, for
all but the most sophisticated of users.
As long as everything works out of the box, I don't think that's
a problem. At least not a problem that should be addressed by
adding more options and code. I agree with
Norm wrote:
David Levine levin...@acm.org writes:
Norm wrote:
I would be content to just ignore the exit status.
I don't think that's a good idea.
If it's not too much trouble for you, I'd like to understand why
this is so.
In general, if something goes wrong, the user should
Norm wrote:
Wouldn't the stderr from the procedure tend to mitigate that?
Yes, especially for compile problems, where the format compiler
issues a warning. For run-time problems, it depends on the
format contents. That gets back to my, and your, point about
how difficult those are to write.
Norm wrote:
Ken writes:
Secondly, when a mh-format program is run, it _cannot_ fail;
literally, there's no facility for it to fail. When it gets
compiled, yes, that can fail. But return an error code? We don't
really have a good way in mh-format to deal with this. I think it
might be
iCalendar attachment support has been committed on the
convertargs branch. docs/contrib/replaliases has some
handy shell aliases (functions, actually). mhical(1)
has been added.
This introduces one change in default behavior: mhshow/show
will display a formatted version of iCalednar (.ics)
I added a new switch to mhfixmsg(1):
[-fixtype mimetype]
The -fixtype switch ensures that each part of the message
has the correct MIME type shown in its Content-Type header.
It may be repeated. It is typically used to replace
“application/octet-stream” with a more
Michael wrote:
okay. I don't want to do this on every email (so I'll want
to use an alias, once I recall how. I think hard/soft link on
mhshow should work).
Or set an MHSHOW environment variable to read files with different
mhshow-show-text/html settings.
I wonder if the mh_profile should
Bill wrote:
mhshow-show-text/html: google-chrome '%f'
In case anyone is still using nmh 1.5 or earlier (:-), that
quoted escape would get expanded to ''%f''. But those
quotes aren't necessary anyway because nmh quotes as
necessary. And properly in 1.6.
The quotes should be removed from
Ken wrote:
[Michael wrote:]
Another solution would extract the HTML into a file, and then
tell my web browser (which, if I'm SSH'into my desktop, is
the browser on the machine I'm SSH'ed *from*) to load that
HTML file.
I'd go with this solution, if it was me.
And explicit extraction
Bob wrote:
By the way, there seems to be a formatting bug with zone
when specifying wide fields with leading zeros. For example,
if you specify the Date: field this way
Date:formatfield=%(nodate{text})%{text}%|%(pretty{text})%(void(szone{t
ext}))%(eq
1)
Lyndon writes:
I would urge you to re-read Robert Elz's comments, and spend a
day contemplating the consequences of this change. He did a
much better job explaining the concerns I have about this.
Agreed.
We also haven't heard from Jon Steinhart.
David
--
Ken writes:
That's fair enough, although the original MH developers did not
think it was useless; the code to get this information existed back
then.
If it's this code:
GMT, BST, 0,
EST, EDT, -5,
CST, CDT, -6,
MST, MDT, -7,
PST, PDT, -8,
JST, JDT, 2,
(and single
Bob wrote:
I'm on the US west coast, so the local time (in parentheses)
should be -0800 (not -480).
Can someone explain why this happens?
That's working as intended, per mh-format(5):
zone dateinteger timezone in minutes
Try this:
tzonedatestring timezone string
Bob wrote:
Ah, okay, that works! My man page is for the older NMH 1.5,
and says something critically different at this point:
zone date integer timezone in hours
tzone date string timezone string
Oh yeah, that was fixed after 1.6 went out. Otherwise, we'd
be asking you
Ken wrote:
[Norm:]
Shouldn't that be the default?
You know ... maybe? What do others think?
No, because date is the sender's context. And it's easy enough
to change how it's viewed.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
I just committed support for repl -convertargs on a new
branch, convertargs. It works pretty much as planned:
http://lists.gnu.org/archive/html/nmh-workers/2014-11/msg00076.html
except that it's not enabled by default. Maybe someday that could
be done by having repl insert
Eric wrote:
Is this the command I run to push up my branch?
git push savannah xoauth
You'll want:
git push -u savannah xoauth
to make it easier to track going forward.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
Eric wrote:
David Levine levin...@acm.org writes:
test-mhlogin failed for me because each line of my actual output
ends with a Ctrl-M. On Linux, so I don't know why.
Did you use git am?
Yes.
Any idea with test-inc and test-msgcheck would fail with:
'inc: POP server does
Eric wrote:
This bug seems to have existed since this code was born. I guess
others have been lucky?
Patch applied, thanks.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
mhdraft and all other nmh environment variables are documented in the
mh-profile(5) man page:
$mhdraft
This is the path to the working draft.
This is set by comp, dist, forw, and repl to tell the
whatnowproc which file to ask “What now?” questions about.
Some form of
Eric wrote:
Ken Hornstein k...@pobox.com writes:
(I have also included a MIME external-body pointer to it below, which
newer versions of nmh should be able to use).
Not in 1.6; this change is not on the branch:
+# This entry is used to retrieve external-body types that use a url
+#
Eric wrote:
OAuth is a very modern thing to bring into nmh.
Wow, cool, thanks!
I enable a libcurl dependency only when configured with
--with-oauth which is off by default. But practically no one has
jsmn installed, so I'm suggesting we include it directly.
I think that might be
Ken wrote:
(I wonder if a sequence can be completely numeric? Maybe)
If I understand your question: sequence names must start with a
letter. Fortunately. That's documented in mh-sequence(5) and
enforced by the code:
$ mark -seq 42 last
mark: illegal sequence name: 42
$ echo $?
Ken wrote:
I was just wondering, since the sequence checking code was first in
m_convert(). I just checked; if you create a numeric sequence by hand,
yes, you totally can use it!
At your own peril. It clearly violates the documentation.
So the default case is you don't need the
second
Ken wrote:
I think we always want to make sure the sequence file is consistent,
right? To me the choice is between two calls to folder_read() and
one call to folder_read() but have it locked during the complete
command run. For a web front end, the latter choice makes more
sense. I would
Ken wrote:
It seems, from what we're hearing, that the caching doesn't help as
much as we'd hope. The real problem seems to be the number of
system calls to getdents() because the readdir() buffer size is
fixed at 32K.
Oh yeah, Ralph brought this up last New Year's eve.
I guess my cache
Erich wrote:
Big request (the one I have only a poor workaround for):
I need a feature in the MIME support (or just help if I'm
totally confused). I have for the life of me not been able
to figure out how to get Content-IDs listed.
The (undocumented) -debug switch to mhlist will
I wrote:
[Eric:]
mhshow: extraneous trailing ';' in message 132's Content-Type: parameter
list
Why the heck should I care about that? Complaining multiple
times, too! Just tolerate it and get on with it.
[Ken:]
I will note that a semicolon at the end of the parameter list
Ralph wrote:
Hi Ken,
Literally, it's just the definition of prefix in uip/mhbuildsbr.c.
I'd be interested to hear marc.info's reply to Anthony when it happens.
I'd rather the Internet be fixed than change something that's correct,
I agree completely.
The prefix has been used since 1992
Ken wrote:
I ... believe you are correct. I say this is fine to commit.
I'm glad it turned out to be a simple fix.
A different issue is that, in this case, mhfixmsg didn't need to
add the text/plain version of the text/html part because the
message already contained one. Here's the original
Joel wrote:
Thus spake Ken Hornstein:
I had proposed a scheme back when I posted about my modules plan; it
did not get any comments (other than Norm saying later that he liked it).
When was that? It's something I might like to revisit.
Paul V. wrote:
David Levine mailto:levin...@acm.org
Tuesday, November 18, 2014 5:02 AM
...
That fix was necessary because this:
mhshow-show-multipart/signed: sigcheck %a '%F'
used to have this effect:
mhshow-show-multipart/signed: sigcheck %a ''%F''
which
Paul F. wrote:
i'm having a bit of trouble understanding how to integrate mhfixmsg
into my workflow.
i'd like to automatically run mhfixmsg on all mail, and, therefore,
keep a backup of messages that it processes. since i kind of abhor
the ,nnn style of mh backups, i'd like to keep the
Ken wrote:
[David:]
That's handled properly (or at least as properly as it ever
was).
I'm wondering if we need to do this differently.
I'm not :-)
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
Paul F. wrote:
david wrote:
Alternatively, something like this (completely untested)?
msgs=`inc -format '%(msg)'`[ -n $msgs ]mhfixmsg $msgs
but then i'd lose the default output of inc.
msgs=`inc -format '%(msg)'`[ -n $msgs ]scan $msgsmhfixmsg
$msgs
inc and
Paul F. wrote:
there's another wrinkle, as well: mhfixmsg leaves cur set to the last
message processed, which means cur is no longer what it was when inc
was finished. so cur needs to be saved and restored, as well.
-[no]changecur? inc and mhlist have it.
David
Oliver wrote:
On 9 Nov, Ken Hornstein wrote:
I have attached. I think it broke with nmh 1.6, it used:
mhshow-show-multipart/signed: sigcheck %a %F
That was probably my fault, but it would be helpful to figure out
exactly how it broke. It begs a larger meta-question: should we allow
Ralph wrote:
Hi David,
Swap the order, /path/first,
Then the arguments couldn't contain file://. (And I didn't
want to require quoting of the filename because Attach: doesn't
and that works out well.)
Think I'm missing something. I thought
nmh-mhbuild-image/png:
Oliver wrote:
David Levine wrote:
2) For each switch, repl puts one pseudoheader in the draft of form:
Nmh-mhbuild-TYPE: [ARGSTRING] file://FILE
What is the URL style file:// syntax needed for? Is it sometimes http or
something?
No, while it looks familiar, it's only used here
Ralph wrote:
Swap the order, /path/first,
Then the arguments couldn't contain file://. (And I didn't
want to require quoting of the filename because Attach: doesn't
and that works out well.)
The more I think about it, the more I like splitting the
filename and arg string into two separate
How about this for a generic reply mechanism?
TYPE = content type/subtype
CONVERTER = external program, and any fixed arguments, to convert
content from request to reply
ARGSTRING = arguments to pass from repl to CONVERTER
FILE = full path of message being replied to
1) Add
Norm wrote:
In my humble opinion, in each such instance you might want to
consider modifying the documentation, or, at least, somehow flag,
the need to modify the documentation.
That's fine, but it's subjective. Let us know how you'd
like documentation to be modified.
The very next
I wrote:
Ken wrote:
I was more thinking about preserving MH's historic flexibility. I guess
my point was I'd prefer something like this (all are aliases to 'repl')
calaccept: -typearg text/calendar accept
calreject: -typearg text/calendar reject
Rather than:
calaccept:
Lyndon wrote:
But the inviteaccept and invitedeny (for a lack of any better
name) scripts would be contrib fodder at best.
As already noted, contrib hasn't worked.
The reason being that calendar processing almost always
includes interaction with external calendaring software.
That's not at
Michael wrote:
I just want to say that I use calendars a lot... mostly I forward
emails to my google account, and sometimes that works, and sometimes
gmail just offers for me to download foo.ics I have yet to
figure out why
I don't know about google calendar, but other calendars I
Ken wrote:
I was more thinking about preserving MH's historic flexibility. I guess
my point was I'd prefer something like this (all are aliases to 'repl')
calaccept: -typearg text/calendar accept
calreject: -typearg text/calendar reject
Rather than:
calaccept: -calendar accept
Ken wrote:
... yeah, I have to agree with you there. I think by now all library
calls that create file descriptors should be setting the close-on-exec
flag, right? That's been around forever. Although I'm not sure
O_CLOEXEC has been around forever, has it? I know the fcntl()
equivalent
Ken wrote:
You know, if I had my druthers I'd rather just write the code to use
the older but more widely supported fcntl() call to set FD_CLOEXEC;
that would avoid an autoconf test and make Lyndon happier :-) Also,
it looks like O_CLOEXEC is not actually part of POSIX? There are
also a
Michael wrote:
It seems to me that icalendar information is very self-contained.
In particular, the email addresses of the organizer and attendees
are contained in the event information. The actual mail header
doesn't have anything in it that can be trusted for response
purposes. For
Lyndon wrote:
But even in today's world, I could probably get 95% of the way back
to the glory days if MH message files were stored on disk (1) in a
decoded format (undo q-p and base64 for all text/* parts), and (2)
all charset encoded text canonicalized to utf-8 (including the
headers, in
kre wrote:
Date:Wed, 12 Nov 2014 13:14:55 -0500
From:David Levine levin...@acm.org
Message-ID: 5112-1415816095.139185@v4jZ.SrI8.S3lW
| It'd be a bit messy to extract the Organizer address and
| still use a components file for the reply.
No, it isn't
Ken wrote:
Okay, you're going to (fairly) point out this makes things harder.
I can't disagree with that. It's just ... we're starting to now
grapple with some truely hard problems, like how exactly a MIME
reply is supposed to work. This is something a lot of MUAs don't
deal with very
Jerry's book mentions scripts to support PGP that were
included with later MH distributions:
http://rand-mh.sourceforge.net/book/mh/remime.html#ReaPGP
http://rand-mh.sourceforge.net/book/mh/senove.html#SenPGP
The scripts are in docs/historical/mh-6.8.5/support/general/
of the nmh git
Ken wrote:
Hrm. It just seems ... if you want to make that more generic, you'd
want to be able to pass switches down to the modules that generate
the reply content. I'm not sure what that would look like. Just
thinking out loud!
Here's an idea. pick allows --component to refer to an
Ken wrote:
Some meta-thoughts:
- What were your thoughts in terms of what the interface would look like
at the repl level? Just a new switch? Did you want to make it more
generic?
Yeah, just a switch, something like:
-calendar accept | tentative | decline | cancel
Is there a way
Ralph wrote:
Hi David,
This behavior of file(1) has been noted in the past:
$ file --brief --mime-type .mh_profile
message/news
Could file(1) be taught about an .mh_profile, --mime-type or not?
Maybe, but given that profiles have the structure of an
email header, it could be
Earl wrote:
Yep, and that is something that nmh should not do. As long as nmh can
provide the charset value to an external program, then nmh has done all
it can do.
Ken, is there a % sequence that gets expanded to the charset of the
entity so it can be passed to an external program?
Yes,
This behavior of file(1) has been noted in the past:
$ file --brief --mime-type .mh_profile
message/news
file looks for a text line starting with Path:, and a few
other tokens that don't matter here, and reports the type as
message/news if it finds it. If I insert a different line,
it
I wrote:
[Ken:]
We'd use the same search algorithm used by mymbox, right? Just
match the address portion?
Right, we'd in fact use the same code. Just return a string
instead of a num.
This isn't quite as simple as I wanted. It's trivial to return a
string. But, that string will be
Ken wrote:
You know, it occurs to me that you actually MIGHT want to return the
entire address. If you had things like this in Alternate-Mailboxes:
Alternate-Mailboxes: Yahoo Tech Support supp...@yahoo.com, Google Tech
Support supp...@google.com, Microsoft Tech Support
Jon wrote:
So, what I really want is the To converted to the From.
Exactly converted? What if To is this?
To: at...@fourwinds.com
Or this?
To: Fubar at...@fourwinds.com
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
Ken wrote:
I guess absent a better solution what you've chosen is probably the
best we can do.
We could add another function that includes the name.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
Ralph wrote:
Hi Ken,
%{delivered-to}%(match k...@pobox.com)
From: Ken Hornstein k...@pobox.com
%(void(num 1))%|(void(num))%%
%(zero)\
From: Ken Hornstein work@address
%
Assuming Jon's addresses are jon-...@hisdomain.com then he might find
%(amatch) useful to match the start of
How about we add a getmymbox function escape? It would do
what mymbox does, except return the user's (first matching)
mailbox name instead of 0/1. It would return null if no
match, to support:
I ... think I see what you're asking. If given a list of addresses,
it would search through
Norm wrote:
I give up. I will never become facile enough with MIME concepts to
meaningfully participate in discussions of nmh that heavily involve
Mime, that is to say, these days, with most discussions about nmh.
I don't agree, FWIW. Questions help the discussions, I think.
And the
Ken wrote:
[Jon wrote]:
1. Most emails have both text and html parts nowadays. If I'm
reading such a message want to store the html part it always
stores it with a .txt suffix. And, because browsers don't
actually look at the contents, they treat itas a text file
Lyndon wrote:
This layout isn't very friendly with 'configure --prefix=/usr/local'.
Fedora customizes that and uses /etc/nmh/ and /usr/libexec/nmh/,
consistent with your plan. It also uses /usr/share/doc/nmh/
for what's in the source docs/.
My only concern is with where the manpages get
Ralph wrote:
Hi David,
Separately, I would like to add a strip (or trim?) flag to mhl to
strip trailing whitespace from non-empty body lines. It's easy to do
and I'd use it. nostrip (notrim) would remain the default.
There already is a leftadjust flag to strip off leading
I wrote:
Ralph wrote:
Hi David,
Separately, I would like to add a strip (or trim?) flag to mhl to
strip trailing whitespace from non-empty body lines. It's easy to do
and I'd use it. nostrip (notrim) would remain the default.
There already is a leftadjust flag to strip
Ralph wrote:
Hi David,
Yeah, I do that a lot because body:component= turns a blank line
in replied text into one with a trailing space.
Yes, that's really icky. Would be nice if mhl supported some kind of
`strip' to prune those off afterwards.
I found where to do this in the code,
Ken wrote:
[Norm:]
Is it true that, that possibly apart from mhbuild, the nmh user does
not have explicit control of the content type of a message?
Well, that's a pretty big exception; with mhbuild you can literally
create any MIME message you can imagine.
attach users can change the
Ken wrote:
[David:]
3) To not break existing user scripts, width would continue to
include the trailing newline. Add support for an optional
profile setting to not include the trailing newline.
I don't think we ever resolved how to handle this: wcwidth()
returns -1 for the
Ken wrote:
I had some free time today, so I decided to simply see if it was
possible to even create an RFC-5322 parser in bison. So I made my
first cut at it and committed it to the tree; it's available in
$(nmh)/sbr/addrparse.y.
Very nice! I think this is worth pursuing.
We might want to
Ken wrote:
[David:]
I see that, too. I'm not as concerned with the case of using the
full terminal width. I think that we're more likely to break
scripts that do something like this:
if [ `scan -format $format -width 20` = $expected_output ]
if we add one back to width now.
I wrote:
1) Instead of callers allocating the space for the fmt_scan()
output, have fmt_scan() do it. Callers would pass a **char
instead of a char array and be responsible for free'ing the
space when they're done.
2) fmt_scan() would use some function of width as the initial
Ken wrote:
[David:]
The parts are stored in reverse order in the message to make
them easier to view with non-MIME-conformant viewers. That is
irrelevant to a user of mhlist/mhstore. Why expose it?
I guess it's all about what you mean by reverse order.
The same as RFC 2046 §5.1.4 means.
kre wrote:
[David:]
| It makes sense to me to list the most preferred
| part first as part 1, the next second as part 2, and so on.
In that case, text/plain would be first, text/html somewhere near last,
and application/msword deleted completely...
That's not right:
1) I use
kre wrote:
Date:Wed, 20 Aug 2014 09:46:18 -0400
From:David Levine levin...@acm.org
Message-ID: 15304-1408542378.667...@nzlb.vy7x.fqve
| 1) I use preferred the same way that RFC 2046 §5.1.4 uses it:
OK, but that's (as you said) from the sender's perspective
Norm wrote:
In order to participate more meaningfully in these discussions I
need to learn more about MIME.
Jerry's book has a no-nonsense intro to MIME:
http://oreilly.com/openbook/mh/tocs/intmime.htm
David
___
Nmh-workers mailing list
Ken wrote:
Looking back at the original thread ... it seems like I misunderstood you.
When you said, mhlist is a counterexample, I thought you meant that was
an example of another program that showed the parts reversed (other than
mhstore).
Right. You said:
# Meh. Everywhere else nmh
Jon wrote:
The message displays just fine, but when I reply to it the original
message doesn't get decoded; it's included as base-64. I also
notice this with some other messages that are quoted/printable with
the = stuff. Is there some way to make this work that I just
haven't taken the
Ken wrote:
[David:]
Best-first has some appeal to me: I start at the top, see
text/html or something else I can handle, and go with that
without bothering to look at the other alternatives.
Meh. Everywhere else nmh presents MIME parts in the order in
which they occur in the message;
Ken wrote:
Meh. Everywhere else nmh presents MIME parts in the order in
which they occur in the message; from what I can tell,
multipart/alternative was reversed just so the display code
would be easier to write. This seems like a lousy exception.
mhlist is a counterexample. And a
I wrote:
Also, replyfilter gets installed without execute permission,
because INSTALL_DATA has -m 644.
I changed dist_contrib_DATA to dist_contrib_SCRIPTS in Makefile.am
and that fixed the permissions. All of the current contribs are
scripts.
David
Ken wrote:
I guess my points are:
- Looking back at the actual implementation, it is clear (to me at least)
that the parts were reversed to make it simpler on the code that displayed
multipart/alternatives; it was easy enough to bail out when it found
the first one that was the best
Norm wrote:
Also, I had to use yum to install several non-standard perl modules.
Yes, that's a drawback of using perl. Long term, we want
to get it into C, so this wouldn't be an issue.
At least, for now, I have decided to not use replyfilter. Instead, I will
continue to do what I have been
Ralph wrote:
Hi David,
Also, is `width' the value of `tput cols' this time, or one less
again?
Currently, it looks like -outsize counts the newline as one, like
-width. If we don't want to change that, then we should call it
something else.
That's what seems wrong.
Norm wrote:
I put a copy of /usr/local/nmh-1.6/share/doc/nmh/contrib/replyfilter,
into /home/norm/lib
with the following two lines inserted just after use Encode;
open CHECK, /t/replfilterLog;
print CHECK hello norman\n;
I inserted the line:
formatproc: /home/norm/lib/replyfilter
Ralph wrote:
Hi Anthony,
Perhaps a new -runes that counts runes/glyphs/codepoints would
sidestep the compatibility issue, -runes trumping -width?
But characters can consist of multiple codepoints (see: accents). And
characters can be double-width. Or zero-width. Or, or, or...
Ralph wrote:
Is -width also only interested in counting bytes? I'm UTF-8 here, but
get
$ scan -format '%{subject}' .
=?utf-8?Q?Po=C2=A3nds.?=
$ for w in {0..9}; do
echo $w:`scan -width $w -format '%(decode{subject})' .`
done
0:Po£nds.
1:
2:P
Ralph wrote:
I know there are few nmh programmers that haven't coded assember,
but -outsize is something only a programmer could like. :-)
:-) I don't care what it's called, I'll leave that up to
you and Ken.
The functionality sounds OK, though it needs to know `Ｆoo' is 2+1+1;
there's no
Ralph wrote:
Aside, it would be nice if scan's -width grew an infinite value as
is a little kludgy. I was thinking `0',
There's an old enhancement request for that:
http://savannah.nongnu.org/bugs/?15274
So then I played a little bit.
$ scan -format '%{subject}' .
701 - 800 of 1394 matches
Mail list logo
