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 no
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 ?
--l
>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 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
_
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
>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:
> > $ 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 ove
> $ 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
bill wrote:
> n...@dad.org writes:
>
> > Ken Hornstein 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