david wrote:
Ralph wrote:
Hi Paul,
as a convenience feature when typing negative offsets, foo:-n and
foo=-n can be entered as foo::n and foo==n respectively.
I dislike this. Must be my preference for Python's `one way to do it'
over Perl's `there must still be one
Hi Paul,
as a convenience feature when typing negative offsets, foo:-n and
foo=-n can be entered as foo::n and foo==n respectively.
I dislike this. Must be my preference for Python's `one way to do it'
over Perl's `there must still be one more way we haven't added yet'.
:-) `-' doesn't need
Ralph wrote:
Hi Paul,
as a convenience feature when typing negative offsets, foo:-n and
foo=-n can be entered as foo::n and foo==n respectively.
I dislike this. Must be my preference for Python's `one way to do it'
over Perl's `there must still be one more way we haven't added yet'.
is make check the only way to invoke the tests? i couldn't see
an easy way to invoke just one.
As David pointed out, a lot of the tests can be invoked directly, but you
_can_ use make to invoke just one test. Just set the TESTS argument as
part of make check. Well, you probably want to run the
ken wrote:
% make check TESTS=test/inc/test-inc-scanout test/cleanup
ah, good.
two pastes -- the first is the normal output of running the test:
http://dev.laptop.org/~pgf/z/pb1366291618.txt
the second is the result of adding
set -x
exec 2/tmp/test-slocal.out
to the top of
i've implemented and tested the relative message selection code
as i described it earlier. thanks to all who contributed to the
design.
if foo denotes a single message, then just as foo:n currently
selects a range of n messages from foo to the (foo+(n-1))'th
(inclusive), the new syntax foo=n
i've implemented and tested the relative message selection code
as i described it earlier. thanks to all who contributed to the
design.
Paul,
I think it looks great; thanks for your hard work on this!
If you don't mind ... could you make sure that your work includes the
appropriate changes to
ken wrote:
i've implemented and tested the relative message selection code
as i described it earlier. thanks to all who contributed to the
design.
Paul,
I think it looks great; thanks for your hard work on this!
you're welcome!
If you don't mind ... could you make sure that
Paul F. wrote:
certainly. i've already done man pages and tests. i'll do find the
pending notes and do those too.
Thank you for paying attention to those details.
(docs/pending-release-notes)
is make check the only way to invoke the tests? i couldn't see
an easy way to invoke just one.
i wrote:
... a bunch of stuff about the semantics of relative msg numbering...
...but now that i'm writing this, i think i see that the way out might
simply be to stop using a syntax that looks like arithmetic. so johan
viklund's suggestion might be right on the money:
What about
Ahh, bikeshedding :).
What about foo#3 and foo#-3? This would mirror the : in sequences,
foo:-3 (three messages from end of foo)
foo#-3 (third message from foo's end)
/Johan
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
Hi Johan,
What about foo#3 and foo#-3? This would mirror the : in sequences,
foo:-3 (three messages from end of foo)
foo#-3 (third message from foo's end)
That's quite nice. `#3' as in `number 3'. And it's not a shell comment
character as it doesn't start a word.
foo#3-5 Third,
ken wrote:
Minor nit; your character set was utf8, but technically it's supposed
to be utf-8 (with the dash). Ralph also might be getting this wrong,
I keep meaning to mention that. Anyway ...
in the face of that long-established and well-recognized precedent :-),
how would people
Hi Bill,
Then name+n is the nth message of name; name_n is the nth to last
message of name.(1 based ordinals. That is, name+1 is the first
message of name and name_1 is the last message of name).
Hey Norm, how is this useful? I can't see anyone manually referring to
the nth item in a
Lyndon Nerenberg lyn...@orthanc.ca writes:
On 2013-04-03, at 5:25 AM, Paul Fox wrote:
$ scan unseen
...notice that third-from-end message is spam...
$ refile unseen_3 +spam
I don't think '_' is a very good choice. It's too commonly used as a word
separator in text strings. Why
On 2013-04-06, at 4:28 PM, Bill Wohler wrote:
At first I was going to go along, but perhaps we want to reserve the git
terminology in case we do threading which would be a closer analogy
(parent relationship).
Wouldn't threading be handled by external scripts? This sounds like something
I
Lyndon Nerenberg lyn...@orthanc.ca wrote:
On 2013-04-06, at 4:28 PM, Bill Wohler wrote:
At first I was going to go along, but perhaps we want to reserve the git
terminology in case we do threading which would be a closer analogy
(parent relationship).
Wouldn't threading be handled by
On 2013-04-06, at 6:13 PM, Bill Wohler wrote:
Actually, now that I think of it, since threading is usually a toggle,
we can use ~ and ^ whether threading is enabled or not. If it's enabled,
these characters operate upon the thread; if not, they operate on
previous messages.
But how do you
Lyndon Nerenberg lyn...@orthanc.ca wrote:
On 2013-04-06, at 6:13 PM, Bill Wohler wrote:
Actually, now that I think of it, since threading is usually a toggle,
we can use ~ and ^ whether threading is enabled or not. If it's enabled,
these characters operate upon the thread; if not, they
On 2013-04-06, at 6:31 PM, Bill Wohler wrote:
But how do you set or track state on a modeless set of command-line tools?
Add a profile entry to the context file?
It still gets very complicated. Where is the use case that mandates this be
supported in the core tools, vs. providing the
bill wrote:
n...@dad.org writes:
Ken Hornstein k...@pobox.com writes:
Hm. I'm torn. So, it looks like it's okay in terms of syntax; _ is
not a valid character in a sequence. But what are the semantics if
'name' refers to more than one message?
Then name+n is the nth
$ scan unseen
...notice that third-from-end message is spam...
$ refile unseen_3 +spam
Seems delightfully error-prone and inefficient.
Scan includes message numbers, rmm the specific
message and there's no need to count lines of output.
vpick might also be useful here?
jerrad wrote:
$ scan unseen
...notice that third-from-end message is spam...
$ refile unseen_3 +spam
Seems delightfully error-prone and inefficient.
Scan includes message numbers, rmm the specific
message and there's no need to count lines of output.
even after over 30
digit message numbers. believe me, p last_4 is much less error
prone than p 365530.
Sorry, I wasn't clear. The error-proneness wasn't due to typing,
but in gauging which line of the displayed sequence was the message
you cared about. Although I suppose those who love this mode of
specifying
jerrad wrote:
digit message numbers. believe me, p last_4 is much less error
prone than p 365530.
Sorry, I wasn't clear. The error-proneness wasn't due to typing,
but in gauging which line of the displayed sequence was the message
you cared about. Although I suppose those who love this
On Wed, 03 Apr 2013 12:27:14 -0400, Paul Fox said:
oh, i see. yes -- i only find myself wishing for it for very small
values of 'n'.
Amen, brother...
% folder +linux-kernel
linux-kernel+ has 237249 messages (5-284323); cur=279067.
pgps_Ifw6HWk7.pgp
Description: PGP signature
Sorry, I wasn't clear. The error-proneness wasn't due to typing,
but in gauging which line of the displayed sequence was the message
you cared about. Although I suppose those who love this mode of
specifying messages might develop a scan format file that includes
sequence indices in the output...
On 2013-04-03, at 5:25 AM, Paul Fox wrote:
$ scan unseen
...notice that third-from-end message is spam...
$ refile unseen_3 +spam
I don't think '_' is a very good choice. It's too commonly used as a word
separator in text strings. Why not use the Git convention: unseen~3 ?
lyndon wrote:
On 2013-04-03, at 5:25 AM, Paul Fox wrote:
$ scan unseen
...notice that third-from-end message is spam...
$ refile unseen_3 +spam
I don't think '_' is a very good choice. It's too commonly used as a word
separator in text strings. Why not use the
Ken Hornstein k...@pobox.com writes:
Hm. I'm torn. So, it looks like it's okay in terms of syntax; _ is
not a valid character in a sequence. But what are the semantics if
'name' refers to more than one message?
Then name+n is the nth message of name; name_n is the nth to last message of
ken wrote:
Minor nit; your character set was utf8, but technically it's supposed
to be utf-8 (with the dash). Ralph also might be getting this wrong,
I keep meaning to mention that. Anyway ...
fixed, i think.
in the face of that long-established and well-recognized precedent :-),
n...@dad.org writes:
Ken Hornstein k...@pobox.com writes:
Hm. I'm torn. So, it looks like it's okay in terms of syntax; _ is
not a valid character in a sequence. But what are the semantics if
'name' refers to more than one message?
Then name+n is the nth message of name; name_n is the
ken wrote:
A while back, there was a discussion about
relative message numbers. For example,
http://lists.nongnu.org/archive/html/nmh-workers/2012-10/msg00048.html.
But I don't believe there was a resolution. Was there?
If foobar is a message sequence then something like foobar+3, for
Minor nit; your character set was utf8, but technically it's supposed
to be utf-8 (with the dash). Ralph also might be getting this wrong,
I keep meaning to mention that. Anyway ...
in the face of that long-established and well-recognized precedent :-),
how would people feel about this change:
Hi Norm,
If foobar is a message sequence then something like forbar+3, for the
third message of foobar, would make my life a bit easier.
Even better, would be to allow forbar+3,4 and foobar forbar+3-5. Then,
recursively, and perhaps a bit fancifully, since forbar+3-5 is a
message sequence,
David Levine levin...@acm.org writes:
Norm wrote:
If foobar is a message sequence then something like forbar+3, for
the third message of foobar, would make my life a bit easier.
Even better, would be to allow forbar+3,4 and foobar
forbar+3-5. Then, recursively, and perhaps a bit fancifully,
Norm wrote:
If foobar is a message sequence then something like forbar+3, for
the third message of foobar, would make my life a bit easier.
Even better, would be to allow forbar+3,4 and foobar
forbar+3-5. Then, recursively, and perhaps a bit fancifully, since
forbar+3-5 is a message
A while back, there was a discussion about relative message numbers. For
example,
http://lists.nongnu.org/archive/html/nmh-workers/2012-10/msg00048.html. But I
don't believe there was a resolution. Was there?
If foobar is a message sequence then something like forbar+3, for the third
message
Date:Fri, 22 Mar 2013 08:19:21 -0700
From:n...@dad.org
Message-ID: 201303221519.r2mfjmcf054...@shell0.rawbw.com
| If foobar is a message sequence then something like forbar+3,
| for the third message of foobar, would make my life a bit easier.
Just make new
Jerrad Pierce belg4...@pthbb.org writes:
Perhaps Jerrad was referring to `@' being used instead of `+' for
relative folders.
You are correct sir.
If it's not in the man pages, it must have been something
I picked up from the Jerry's MH book.
Yep.
Hi Jerrad,
Commands which take a folder name (inc, refile, scan, sortm, ...)
will accept the folder name in two formats: '+folder' and
'@folder'. '+folder' specifies a folder underneath the Path
defined in your nmh profile e.g; with the default '''Path:
Mail''',
i know ('man nmh') about 'cur:-3' and 'prev:3', which will pick
the 3 previous messages (including cur, or not). is there a way to
refer to _just_ the Nth message before or after cur?
i often look at a scan listing and realize i want to see a message
that's very close to 'cur' or 'last'. with
Paul wrote:
i know ('man nmh') about 'cur:-3' and 'prev:3', which will pick
the 3 previous messages (including cur, or not). is there a way to
refer to _just_ the Nth message before or after cur?
i often look at a scan listing and realize i want to see a message
that's very close to 'cur'
I'd probably use it. Though I've been trying to rely more on pick
and less on message numbers.
You might vpick useful for certain use cases
http://pthbb.org/manual/software/MH/vpick.html
I find the following incantation especially useful:
vpick -seq unseen -cull -new
That only shows you
david wrote:
Paul wrote:
i know ('man nmh') about 'cur:-3' and 'prev:3', which will pick
the 3 previous messages (including cur, or not). is there a way to
refer to _just_ the Nth message before or after cur?
i often look at a scan listing and realize i want to see a message
Paul wrote:
i think not: cur-9 is a valid selection today.
pick: bad message list cur-9
Apparently it is, but what is it supposed to do?
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
Apparently it is, but what is it supposed to do?
It's a bad list because your cur was 9. Try:
pick 1; pick cur-9
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
I don't really understand how relative numbers are useful, but if they are to be
introduced why not use the same signifier as for folders? i.e; @
cur@2 = cur+2 cur@-4 = cur-4
This could also prevent some confusion as to why we are using something with a
clear meaning (+) for such an odd
ralph wrote:
Hi Paul,
jerrad wrote:
I don't really understand how relative numbers are useful, but if
they are to be introduced why not use the same signifier as for
folders? i.e; @
cur@2 = cur+2 cur@-4 = cur-4
...
i'm also not sure how '@' relates to folders.
Hi Paul,
folder +inbox
refile @example last# Means +inbox/example.
huh. i believe you, but you might have just found a bug in the man
pages. :-) i can find no mention of such a feature.
Me neither. Historically,
$ g -B3 TSUBCWF docs/ChangeLog_MH-3_to_MH-6.6
Wed
Perhaps Jerrad was referring to `@' being used instead of `+' for
relative folders.
folder +inbox
refile @example last# Means +inbox/example.
huh. i believe you, but you might have just found a bug in
the man pages. :-) i can find no mention of such a feature.
folder +inbox
refile @example last# Means +inbox/example.
huh. i believe you, but you might have just found a bug in
the man pages. :-) i can find no mention of such a feature.
volunteers?
I can try to tackle this tomorrow evening.
52 matches
Mail list logo
