* On 05 Apr 2016, Vincent Lefevre wrote:
> On 2016-04-05 16:40:14 +0100, Richard Russon wrote:
> > On Tue, Apr 05, 2016 at 04:32:11PM +0200, Vincent Lefevre wrote:
> > > On 2016-04-05 14:43:15 +0100, Richard Russon wrote:
> >
> > > > The limiting machinery doesn't take any parameters
> >
> > > Couldn't ~. be changed internally to ~m<number> at evaluation time?
> >
> > 1 User: 'l' -> OP_MAIN_LIMIT
> > 2 mutt_index_menu()
> > 3 mutt_pattern_func()
> > 4 mutt_get_field()
> > "Limit to messages matching: "
> > 5 User: 'thread' or '~.'
> > 6 mutt_check_simple()
> > transforms 'thread' to '~.'
> > 7 mutt_pattern_comp ('~.')
> >
> > Only the menu object in mutt_index_menu() knows the current email.
> >
> > That means adding a parameter to:
> > mutt_pattern_func (5 users)
> > mutt_pattern_comp (8 users)
>
> Alternatively, couldn't the current message be part of the context?
> It would be a message number, or 0 in absence of current message.
I think either of these is worth the work. One of mutt's unspoken
principles is that leveraging macros and patterns (which are really
recombinable atomic selectors) is preferable to building implicit
selection into the behavior code.
--
David Champion • [email protected]
