Re: PATCH: Re: 3.1.7-pre-1: Problem with scrolled completion listings

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Apr 26, 10:23am, Sven Wischnowsky wrote:
}
} Bart Schaefer wrote:
} 
} > This looks like a case of the doc reflecting the C code in the complist
} > module, but the completion system establishing a different default.
} 
} Maybe we could change the C code to do the same the shell code does
} now. I.e.: we turn LISTMAX back into a integer, remove the `scroll'
} special value and turn list scrolling on only if $LISTPROMPT is set.

Would you then also remove the SELECTSCROLL variable and turn on select
scrolling only if SELECTPROMPT is set?

} That plus the parameter renaming you suggested... would that make
} everyone happy?

It'd be better than the current situation, I think.  As for "happy":

} It would also make $LISTPROMPT more like $SELECTPROMPT: not set = no
} prompt.

Not set == _main_complete sets them for you.  (Or at least that's what
happens now.)  That's the bit I don't like:  The variables are documented,
but unless you also set a style they get clobbered.

} > } We had the suggestion to allow going back in completion lists.
} > 
} > I told you it was a bad idea to start implementing a pager. 
} 
} One idea might be to add something that allows to turn on menu
} selection when the list doesn't fit on the screen.

If we did this, could we -replace- scrolling of listings with it, and get
rid of LISTPROMPT entirely?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com