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

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Apr 26, 11:01am, Sven Wischnowsky wrote:
}
} Bart Schaefer wrote:
} 
} > } 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?
} 
} But SELECTSCROLL doesn't turn scrolling on or off, it says how
} scrolling is done (like Emacs' scroll-step variable).

Ah, sorry, missed that.

} > 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.
} 
} [...]  Hm, we could do this entirely by some style
} magic, i.e. add a style to turn scrolling on and only if that is set,
} are the default prompts used.

That's what I meant in 10921 when I said:
> Since LISTMAX is used by compctl, it'd probably be better to not overload
> it in that way, and instead add another variable (or a style) for scroll.

} > } 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?
} 
} Yes, almost. The only problem is that the prompt may take up more
} lines then there are on the screen so that we can't use menu-selection 
} (or this kind of listing) because there is no space where we could put 
} the list.

?!?! If the screen is so short (or the prompt so huge) that you can't fit
in both the listing and the prompt, you couldn't do anything useful with
list-scrolling as it is now anyway, could you?

If you're worried about the configuration that allows menu-selection to
scroll without printing a select prompt:  I don't think that's at issue.
If menu-selection is invoked, then menu-selection is invoked; don't try
to force a prompt to appear just because it got invoked "in place of" a
listing.

} Oh, and by `getting rid of LISTPROMPT', did you mean getting rid of
} scrolling in completion lists?

I did.

} Scrolling through lists with TAB is
} currently so much easier than moving screen-wise in menu-selection,

How DO you move screen-wise in menu-selection, anyway?  I can't figure
it out.  Obviously that would have to be made simpler.

Hmm, I just tried using {beginning,end}-of-buffer-or-history in a menu-
selection and found that they act like {beginning,end}-of-line.  I would
have expected to jump to the top/bottom of the column instead.

} where it is nice to have TAB go to the next match.

When scrolling is necessary, cycling through many matches with TAB looks
a lot better when LIST_ROWS_FIRST is set -- no jumping from the bottom
of one column to the top of the next, which causes a scroll.

BTW, have we considered having up/down and left/right motions wrap to
the previous/next column/line, as happens in e.g. the Pine mailbox
browser?  To illustrate the effect I mean, in a menu-selection with
LIST_ROWS_FIST, arrow right to the end of the line and then press TAB.
Now imagine that the TAB had just been another press of the arrow key.

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