Re: [Nmh-workers] Relative Message Numbers
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 more way we haven't added yet'. :-) Agreed. In general, I think it's best to minimize the feature set, and therefore testing and documentation. And it helps reduce confusion between what might some day be similar features given some other enhancement. And reduce the likelihood of unintended interactions between features, always a concern with nmh. okay. i've removed the stuttered syntax support, and pushed the changes. enjoy. paul -- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 61.0 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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 Shift and fingers are used to typing it before a digit or two. I've happily got along with lp:-3 for years without wishing for a shorter method, and double-tapping the same key isn't particularly quick, unlike the rollover of `=-'. Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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'. :-) Agreed. In general, I think it's best to minimize the feature set, and therefore testing and documentation. And it helps reduce confusion between what might some day be similar features given some other enhancement. And reduce the likelihood of unintended interactions between features, always a concern with nmh. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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 cleanup test as well. E.g.: % make check TESTS=test/inc/test-inc-scanout test/cleanup (and, for some reason the slocal test always fails for me. different topic.) Errr ... it's not a dbm problem, is it? :-) If you post the output to that test we'd be glad to take a look at it. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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 test/test-slocal, in case it's useful: http://dev.laptop.org/~pgf/z/pb1366291691.txt at the point where diff reports .../N.actual:No such file or directory it seems that the file was never created. i verified this by changing cmp -s to just cmp in check(), and cmp complains about the missing file as well. so it looks to me like this command: /home/pgf/src/pdom/nmh/nmh.git/test/testdir/inst/usr/local/nmh.git/lib/slocal -maildelivery /home/pgf/src/pdom/nmh/nmh.git/test/testdir/Mail/maildelivery should have produced the .actual file, but didn't. the contents of that maildelivery file is: * 1 qpipe A /usr/bin/tee /home/pgf/src/pdom/nmh/nmh.git/test/testdir/13697.actual paul -- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 48.9 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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 selects the single (foo+(n-1))'th message. so given a folder containing these messages: 3 5 7 9 then 'pick cur:3' currently selects 3, 5, and 7, and now 'pick cur=3' will select just message 7. for sequences, just as seq:n currently selects a range of messages from the start of seq through the n'th message in seq, the new seq=n selects the single n'th message of seq. so given a sequence 'seq' containing: 3 5 7 9 then 'pick seq:3' currently selects 3, 5, and 7, and now 'pick seq=3' will select just message 7. negative offsets work similarly. as a convenience feature when typing negative offsets, foo:-n and foo=-n can be entered as foo::n and foo==n respectively. there was no discussion after i described all this last week, so i'll push the changes soon. paul -- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 61.2 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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 the man pages, the pending-release-notes file, and if you feel up to it, maybe some tests? If you have questions about how the test suite works, please speak up ... I think David and I should be able to answer them (Josh Bressers did the original work on the test suite, but I don't know if he's kept up with the changes to it in the past few releases). --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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 your work includes the appropriate changes to the man pages, the pending-release-notes file, and if you feel up to it, maybe some tests? If you have questions about certainly. i've already done man pages and tests. i'll do find the pending notes and do those too. how the test suite works, please speak up ... I think David and I should be able to answer them (Josh Bressers did the original work on the test suite, but I don't know if he's kept up with the changes to it in the past few releases). is make check the only way to invoke the tests? i couldn't see an easy way to invoke just one. (and, for some reason the slocal test always fails for me. different topic.) paul -- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 50.9 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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. make check is the intended route. It installs in test/testdir/inst/ and runs each of the tests against that installation. The final one, test/cleanup, removes the installation. But each individual test can be invoked by just invoking the test script itself, assuming it has the boilerplate that it should have at the top. It will install, if necessary, and then run the test. It does not clean up, so it's most useful when developing the test itself. test/cleanup (or /bin/rm -fr test/testdir) should be used if code needs to be modified and then tested. There's also make distcheck, it's worth doing every once in a while. It checks to see that no files are left where they shouldn't be. (and, for some reason the slocal test always fails for me. different topic.) If you let me know how it fails I'll look into it. It's not a rigorous test. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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 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) i think this turns out to be a good solution, in that it doesn't try to look too much like arithmetic, and it mirrors the existing range syntax. to keep with the bikeshedding vein, it occurred to me that '=' might be a better character to use than '#'. i'm not sure why i think so -- perhaps because of the commentary associations with '#', perhaps because '=' is visually similar to '-', and (for US keyboards at least) it's usually lowercase and right next to '-'. i've implemented the code using '=', but that's clearly still open for discussion, and easily changed. using the new syntax provides a nice predictable relationship between the two expressions: the message selected by '=n' is always the last (or first, if n is negative) message selected by ':n'. so if name:3 gives: 1 2 3 then name=3 will always give 3 as a lazy typist, when i started i was concerned about the foo#-3 string, which i found quite hard to type -- and this is, after all, a convenience feature. i addressed this with a minor syntactical trick: by allowing the '-' to be optionally replaced by a second '=' character, it reduces 4 awkward characters to just 3, i.e., foo#-3 can be entered as foo##3. for symmetry, i added the same trick for ranges, so that foo:-3 can be expressed as foo::3 if you wish. i hope no one thinks that's too terrible an idea. after switching to '=' as the delimeter, typing foo=-3 isn't so bad, but i still prefer the stuttered nature of foo==3. for reference/review, here's a diff of the mh-sequence.man page as my changes currently stand. --- /tmp/oo 2013-04-11 13:42:49.0 -0400 +++ /tmp/nn 2013-04-11 13:42:18.0 -0400 @@ -44,21 +44,30 @@ The specification “name1-name2” designates all currently existing mes‐ sages from `name1' to `name2' inclusive. The “reserved” message name “all” is a shorthand for the message range “first-last”. The specification “name:n” designates up to `n' messages. These mes‐ sages start with `name' if `name' is a message number or one of the reserved names “first” “cur”, or “next”, The messages end with `name' if `name' is “prev” or “last”. The interpretation of `n' may be over‐ ridden by preceding `n' with a plus or minus sign; `+n' always means up to `n' messages starting with `name', and `-n' always means up to `n' - messages ending with `name'. + messages ending with `name'. For typing convenience, “name:-n” may + also be entered as “name::n”. + + Substituting `=' for `:' (i.e., “name=n”) will reduce the selection + from a range of up to `n' messages, to a selection of just the `n'th + message. So for example, while “name:-3” selects the 3 messages ending + with `name', “name=-3” selects just the 2nd previous message. It is an + error if the requested message does not exist (i.e., there aren't + enough messages in the folder). For typing convenience, “name=-n” may + also be entered as “name==n”. In commands which accept a `msgs' argument, the default is either “cur” or “all”, depending on which makes more sense for each command (see the individual man pages for details). Repeated specifications of the same message have the same effect as a single specification of the message. There is also a special “reserved” message name “new” which is used by the mhpath command. User-Defined Message Sequences @@ -80,20 +89,29 @@ of the user-defined sequence `name'. The specifications “name:next” and “name:prev” may also be used, and they designate the next or previous message (relative to the current message) which is an element of the user-defined sequence `name'. The specifications “name:first” and “name:last” are equivalent to “name:1” and “name:-1”, respectively. The specification “name:cur” is not allowed (use just “cur” instead). The syntax of these message range specifications is subject to change in the future. + Single messages (as opposed to ranges) may also be selected by substi‐ + tuting `=' for `:', as in “name=n”. This will reduce the selection + from being a range of up to `n' messages, to being a selection of just + the `n'th message. So while “seq:5” selects the first 5 messages of + seqence `seq', “seq=5” selects just the 5th message of the
Re: [Nmh-workers] Relative Message Numbers
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 https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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, fourth, and fifth. foo#2--2 All but the first and last, potentially none. foo#-5--1 Same as foo:-5. foo#-5-3 Second and third if foo holds six. Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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 feel about this change: The specification “name+n” designates a single message, namely the `n'th message after `name' (or the last message, if not enough messages exist). One might expect the `n'th message prior to `name' to be spec‐ ified by “name-n”, but that syntax denotes a range. Therefore, the character `_' is used instead: “name_n” designates the `n'th message before `name' (or the first message if not enough messages exist). i've implemented the above, to see how it feels (which is okay). i can make the corresponding changes for foobar+3 and foobar_2 if folks think it's reasonable. 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? yeah, well, i'm having trouble with exactly this point. what i thought was obvious when i started implementing is not so obvious after all. consider: $ uip/show first /dev/null# set cur to message 1 $ uip/pick all 1 2 3 4 5 6 $ uip/pick -sequence foo 1-4 1 2 3 4 now we notice that the second message is interesting. there are several ways to address that message: $ uip/pick first+1 2 $ uip/pick cur+1 2 $ uip/pick foo+1 1 oops. this happens because foo is a sequence, and not a message, as are first and cur. as ralph pointed out, this feature relies on the user being able to easily do an on-screen eyeball count to find the message you want in the list. introducing a glaring off-by-one issue seems wrong. the only alternative i can think of is to make the relative counts for sequences start with '0'. so instead of the above, you'd have: $ uip/pick first+1 2 $ uip/pick cur+1 2 $ uip/pick foo+1 2 $ uip/pick foo+0 1 note that in this scenario, 'foo+0' is the only way to refer to the first message in that sequence. and for completeness, 0 could be valid in in non-sequence contexts as well: $ uip/pick first+0 1 $ uip/pick cur+0 1 $ uip/pick last~0 6 $ uip/pick foo~0 4 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 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) $ uip/pick first#1 1 $ uip/pick first#2 2 $ uip/pick cur#1 1 $ uip/pick cur#2 2 $ uip/pick foo#1 1 $ uip/pick foo#2 2 using a non-arithmetic operator lets us hide what's actually going on with sequence references. i haven't thought through this the whole way, though, so there might still be a surprise. (and i haven't even begun to think about ralph's extensions to the '#' syntax. they hurt my eyes. ;-) paul -- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 53.8 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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 sequence on the command line. The point of a sequence is that you don't have to know the constituents. Maybe you have a use case. Many times an hour I do `-sub foo' or something else, e.g. -from, where ~/bin/-sub does a pick and scan, and then spot the one I'm interested in is the third from the top and do `s 3141', with ~/bin/s being show. I'd much rather do `s lp+3' as my muscles' memory is adept at `s lp' already and the `+' followed by the, typically single, digit would come quickly. Note, I don't have to count to know it's the third, I just know, just as old-time vi(1) users know it's 7dd that's needed at a glance. Given it may be easier to see it's five from the end an `s lp_5' mechanism is required. IIRC, `foo-bar' isn't valid for sequence names, even if foo and bar are both single-message sequences? If so, it would seem `-' is available for `foo-5'. I can see that could be confusing though. As a dc(1) user, I'm happy with `_'. `~' suggests something more fuzzy and approximate to me, e.g. awk's regexp matching operator, so would perhaps be better suited to some other use in the future. Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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 not use the Git convention: unseen~3 ? 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). -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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 would do by generating a list of message-id and references headers, then doing a tsort and feeding the whole mess back into scan/show. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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 external scripts? This sounds like something I would do by generating a list of message-id and references headers, then doing a tsort and feeding the whole mess back into scan/show. That's certainly what we do in MH-E. We have talked about threading on this forum in the past so I hope it's somewhere on The List. I don't think it's reasonable to expect users to have to write such scripts themselves to have threading. 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. I agree with you; I definitely prefer these over the underscore which seems more like a word separator than an operator. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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 set or track state on a modeless set of command-line tools? ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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 operate on previous messages. But how do you set or track state on a modeless set of command-line tools? Add a profile entry to the context file? If not, I would reserve ^ and ~ to refer to the message's ancestor and use a different symbol for the relative message number. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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 hooks for the end user to implement their own threading model? I don't accept it's hard as an answer. If someone can only deal with an easy solution, pretty much every other MUA out there already serves their needs. If we are going to fix this, it needs to be done in a way that's programmatically friendly, and which exposes all of the message and folder structure in a way that makes it possible for people to write powerful and complex thread manipulators. And given an expressive interface, it's trivial to write the simple set of tools that most people equate with 'thread' manipulation. (Which is most cases is simple Subject header sorting.) --lyndon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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 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 sequence on the command line. The point of a sequence $ scan unseen ...notice that third-from-end message is spam... $ refile unseen_3 +spam is that you don't have to know the constituents. Maybe you have a use case. If this is for programmatic use, it seems that something like for i in $(mark -list -sequence cur | cut -f 1 -d --complement); do scan $i; done would be clearer. Saaay, it just occurred to me. Maybe we should adopt MH-E's syntax. Norm, please check out MH-E ranges [1]. While it's not identical to your specification, it sure is nifty for MH-E users. If this works for you, maybe applying the same syntax to nmh would mean that many more users would be more familiar with the syntax than with _. http://mh-e.sourceforge.net/manual/html/Ranges.html with the exception of the mh-interpret-number-as-range-flag flag, i think everything described on that page is existing mh behavior. you asked how the syntax norm requested was useful for sequences. as noted, mh already supports the notion of ranges within sequences: unseen:3 is the first 3 unseen messages, and unseen:-5 is the last 5. those are both great if you want to work with a short block of messages. but you can't refer to a single message using that syntax, unless it happens to be the first or last in the sequence (i.e., unseen:-1). the new unseen+3 syntax lets you refer to the (single) third unseen message. paul -- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 30.4 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
$ 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? http://www.pthbb.org/manual/software/MH/vpick.html ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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 years of typing, i find it much easier to to touch-type long strings of alpha than even shortish strings of digits. my inbox has been into 4 digits for a long time, and mairix gives 6 digit message numbers. believe me, p last_4 is much less error prone than p 365530. vpick might also be useful here? http://www.pthbb.org/manual/software/MH/vpick.html no. that's a different tool entirely. paul -- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 37.2 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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 messages might develop a scan format file that includes sequence indices in the output... ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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 mode of specifying messages might develop a scan format file that includes sequence indices in the output... oh, i see. yes -- i only find myself wishing for it for very small values of 'n'. -- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 40.6 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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 ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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... I believe the current format engine doesn't have this capability; you're not given any information about sequence membership when you're in the format engine. Although I had thought about including the index of the message being displayed; e.g.: scan 7-9 15-17 would give message 7 an index of 1, message 15 would have an index of 4 ... you get the idea. I was thinking about that because I wanted to be able to have alternating bold/hilighting on scan output, but you could use it for that as well (with some limitations, of course). But it occurs to me that it you had the message index and you had relative messages, it would make the Previous Sequence a lot more useful. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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 ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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 Git convention: unseen~3 ? but... but... dc predates git! it must be better! :-) i agree that '_' is a little tainted -- i was surprised that it's not legal in sequence names. '_' is more mnemonic, for me at least, but either would be fine. paul -- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 28.2 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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 name.(1 based ordinals. That is, name+1 is the first message of name and name_1 is the last message of name). If name has fewer than n messages then I would prefer an abort with error message. Paul Fox would, I gather, prefer a semantics where name+n and name_n are always meaningful. Norman Shapiro ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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 :-), how would people feel about this change: The specification “name+n” designates a single message, namely the `n'th message after `name' (or the last message, if not enough messages exist). One might expect the `n'th message prior to `name' to be spec‐ ified by “name-n”, but that syntax denotes a range. Therefore, the character `_' is used instead: “name_n” designates the `n'th message before `name' (or the first message if not enough messages exist). i've implemented the above, to see how it feels (which is okay). i can make the corresponding changes for foobar+3 and foobar_2 if folks think it's reasonable. Hm. I'm torn. understandably. it's butt-ugly -- no one should love it. 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? i think that can only mean user-defined sequences, right? (ignoring all for now.) semantics will be similar to those of foo:3, foo:-3, etc. foo+3 will be the 3rd message in foo, foo_3 will be the 3rd message from the end of foo. but in foo:3, 3 is a count, whereas in foo+3, i'm assuming 3 is an index, presumably starting at '1'. you raise a good point. it's worth spelling it all out: given: $ pick -sequence foobar 269-279 $ show 270 /dev/null $ pick foobar 269 270 --- cur 274 276 277 279 $ pick cur # current behavior 270 the semantics for ':n' say that n is a count of messages, i.e., we're asking for two messages starting at cur: $ pick cur:2# current behavior 270 274 $ pick cur:-2 # current behavior 269 270 for sequences, ':n' refers to the n messages at the start/end of seq $ pick foobar:2 # current behavior 269 270 $ pick foobar:-2# current behavior 277 279 for +/_, i think the desired behavior is second message from cur $ pick cur+2# proposed behavior. compare with cur:2 276 $ pick cur_2# proposed behavior. compare with cur:-2 268 and for sequences, nth message from start/end of sequence $ pick foobar+2 # proposed behavior. compare with foobar:2 270 $ pick foobar_2 277 you can see that the switch from n being a count of messages to being an index into the list has interesting semantic effects, but i don't think they're very surprising. norm wrote: If name has fewer than n messages then I would prefer an abort with error message. Paul Fox would, I gather, prefer a semantics where name+n and name_n are always meaningful. actually, i don't have a strong opinion on this, and was mainly following existing practice, in that neither cur:n nor foobar:n will error out if 'n' goes into non-message territory. $ pick foobar:20# current behavior, no error 269 270 274 276 277 279 but perhaps the +/_ versions should cause an error. paul -- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 30.0 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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 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 sequence on the command line. The point of a sequence is that you don't have to know the constituents. Maybe you have a use case. If this is for programmatic use, it seems that something like for i in $(mark -list -sequence cur | cut -f 1 -d --complement); do scan $i; done would be clearer. Saaay, it just occurred to me. Maybe we should adopt MH-E's syntax. Norm, please check out MH-E ranges [1]. While it's not identical to your specification, it sure is nifty for MH-E users. If this works for you, maybe applying the same syntax to nmh would mean that many more users would be more familiar with the syntax than with _. http://mh-e.sourceforge.net/manual/html/Ranges.html -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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 the third message of foobar, would make my life a bit easier. I think Paul Fox accurately summed up the consensus view on that thread: but i admit: i've thought about this quite a bit in the past, and have never come up with syntax that was backward compatible, meaningful, and enough faster to type than the digits themselves to be useful. I don't think the situation has changed. Right now anything with a - in it counts as a range, so there's that to think about. so, i was using 'dc' the other day (is there anything else?), and for the first time in a while, i had to enter a negative number. HP solved this problem on their calculators with a CHS (change sign) button, but the dc authors opted to require the use of the '_' to introduce a negative number. in the face of that long-established and well-recognized precedent :-), how would people feel about this change: The specification “name+n” designates a single message, namely the `n'th message after `name' (or the last message, if not enough messages exist). One might expect the `n'th message prior to `name' to be spec‐ ified by “name-n”, but that syntax denotes a range. Therefore, the character `_' is used instead: “name_n” designates the `n'th message before `name' (or the first message if not enough messages exist). i've implemented the above, to see how it feels (which is okay). i can make the corresponding changes for foobar+3 and foobar_2 if folks think it's reasonable. paul -- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 50.2 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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: The specification “name+n” designates a single message, namely the `n'th message after `name' (or the last message, if not enough messages exist). One might expect the `n'th message prior to `name' to be spec‐ ified by “name-n”, but that syntax denotes a range. Therefore, the character `_' is used instead: “name_n” designates the `n'th message before `name' (or the first message if not enough messages exist). i've implemented the above, to see how it feels (which is okay). i can make the corresponding changes for foobar+3 and foobar_2 if folks think it's reasonable. 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? --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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, forbar+3-5+2 would be meaningful. If foobar has had
a least four messages it would denote the fourth messages of foobar.
It wouldn't be too hard to have something personal that you use with
backticks or $(). A nicer version of
$ M() { local s=${1?} shift pick -list $s | sed -n $*; }
$ pick last:10
10 hits
$ M lp p
6646
6676
6677
6910
6911
6912
6913
6928
6929
6931
$ M lp '1p; 3p; $p'
6646
6677
6931
$ M lp '7,$d; p'
6646
6676
6677
6910
6911
6912
$
(`lp' is the sequence I have pick(1) set by default.)
Cheers, Ralph.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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, since
forbar+3-5 is a message sequence, forbar+3-5+2 would be
meaningful. If foobar has had a least four messages it would denote
the fourth messages of foobar.
I agree with Robert and Ken.
The shell function below is another way to handle the simple
case: pn forbar 3 4
Or, load each of the message numbers into a bash array and do
all kinds of fancy things with those.
I just don't think that native support would be useful enough
to justify the complexity.
David
# first argument is sequence name
# second argument is n'th message of sequence
# optional third argument is number of messages, default 1
function pn {
pick $1 | tail -n +$2 | head -${3:-1}
}
This comes very close to meeting my needs -- much better than the folder trick.
I will try it for a few week to see how it goes. Certainly, at this a point in
my life, I could never have come up with it. Thank you very much.
Norman Shapiro
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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 sequence, forbar+3-5+2 would be
meaningful. If foobar has had a least four messages it would denote
the fourth messages of foobar.
I agree with Robert and Ken.
The shell function below is another way to handle the simple
case: pn forbar 3 4
Or, load each of the message numbers into a bash array and do
all kinds of fancy things with those.
I just don't think that native support would be useful enough
to justify the complexity.
David
# first argument is sequence name
# second argument is n'th message of sequence
# optional third argument is number of messages, default 1
function pn {
pick $1 | tail -n +$2 | head -${3:-1}
}
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
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 folders, they're cheap... refile -link foobar +tempfolder scan 3 +tempfolder (etc) then rmf it when you're done (make tempfolder a sub-folder of the current folder if you like). Sequences have their uses, but attempting to turn them into folders isn't really appropriate. kre ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] relative message numbers?
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. http://rand-mh.sourceforge.net/book/mh/fol.html#RelNam -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] relative message numbers?
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''', '+folder' tells nmh to use ''~/Mail/folder''. '@folder' specifies a path relative to the current folder specified in your ''context'' file e.g; with '''Current-Folder: inbox''', and the same profile, '@folder' tells nmh to use ''~/Mail/inbox/folder''. Is `scan +/tmp/foo' documented anywhere, i.e. the ability to treat any directory as a folder, not just one under Path? And `@..' after that... Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] relative message numbers?
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' or 'last'. with my numeric typing skills,
the fewer digits i need to type the better, so show last--3 or show
cur++2 would be easier than show 321540. (a real example, from my
mairix virtual output folder).
is this possible? anyone else think it's desirable?
It's not possible now with nmh. A simple shell alias could do
it, but use would take a bit more typing than you asked for.
I think last-3 and cur+2 would be sufficient.
I'd probably use it. Though I've been trying to rely more on pick
and less on message numbers.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] relative message numbers?
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 unseen messages, defaults to having messages selected, and creates a sequence named vpick with the marked messages on exit. Thus you can skim your unread messages, unmark those you want to save for later, and then `rmm vpick` ;-) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] relative message numbers?
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
that's very close to 'cur' or 'last'. with my numeric typing skills,
the fewer digits i need to type the better, so show last--3 or show
cur++2 would be easier than show 321540. (a real example, from my
mairix virtual output folder).
is this possible? anyone else think it's desirable?
It's not possible now with nmh. A simple shell alias could do
it, but use would take a bit more typing than you asked for.
okay, that's what i thought.
I think last-3 and cur+2 would be sufficient.
i think not: cur-9 is a valid selection today.
paul
I'd probably use it. Though I've been trying to rely more on pick
and less on message numbers.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
=-
paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 55.0 degrees)
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] relative message numbers?
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 https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] relative message numbers?
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
Re: [Nmh-workers] relative message numbers?
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 purpose... ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] relative message numbers?
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. 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. paul =- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 55.2 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] relative message numbers?
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 Jul 18 03:01:11 1984 Rand MH mail system (agent: Marshall Rose) mh@uci-750a Install the code necesary for the @folder notation, meaning +cwf/folder (TSUBCWF). $ @.. naturally works too and is quite handy. Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] relative message numbers?
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. Volunteers? David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] relative message numbers?
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. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
