On 9/1/06, Martin Bähr <[EMAIL PROTECTED]> wrote: > On Fri, Sep 01, 2006 at 02:25:25PM +0200, Axel Liljencrantz wrote: > > I implemented this and I can't say the new mode is a new improvement. > > As you point out, startin at 0% means you don't know how many more > > completions there are. But if the position indicator has a minimum > > that is above 0%, then when scrolling back up a completion list, you > > have no idea how near the top you are. > > i'd disagree on that: you do have an idea because you have seen the > top already and you know how many pages you went down and back up. > > scrolling back up is less likely to happen than scrolling down. > so the current way would be more often a problem than the new one.
True. On the other hand, starting the pager position at e.g. 23% is pretty unintuitive. I don't think it's meaningful to try and decide which of these systems is the worst when we could simply try to find an actually good system, though. > > > page 1 of 4 > > page 2 of 8 > > i like that. > that is generally the info i want to know. i could care less if it is 20% > or 23% but i want to know how often i have to hit space to get to the end. > Yes, it might be that giving less information is better here. > > while we are talking about the pager: > > in general i find any scrolling in completions irritating, > and i'd like to see the choices reduced to one screenful if at all > possible. Try using the fish pager to display 1.5 pages of completions. You'll find it harder than you'd expect. fish_pager will try to shorten long completions and descriptions as well as reducing the length of the prefix shown before each completion in order to make everything fit on one page if even remotely possible. If it fails, then the paged output will be given much more room again. > a way to do this could be that if tabexpansion does not fit on screen > only list the choices for the next character (and possibly the > continuation for each, with a count of remaining choices) > > so in the worst case (assuming most files have characters from the > alphabet and numbers) there would be maybe 70 choices that should all > fit into one screen. > > each choice could have a number behind it indicating how many choices > start with that character. > > if there is only one choice beind a character, write it out. > or complete the characters after the first one until there is a choice: > > ls <tab> in the fish source directory would give something like: > > builtin (8) e (13) INSTALL p (7) u (3) > c (12) f (8) k (3) reader.h w (6) > _darcs gen_hdr (2) m (3) README x (13) > doc_src h (8) Makefile.in s (7) > Doxyfile (2) i (9) output. (2) t (3) > > if there is not many choices it could be expanded to show not only the > first character but the first 2 or more until the screen is full... I think that might be taking it too far. For example, I often use the fish completions for 'man' as a sort of interactive version of the whatis command. If I'm looking for a function and know what it does, I can often guess roughly what the name of the function begins with. For example, almost all C functions dealing with wide characters start with 'wc'. So I type 'man wc<TAB>' and brows the help files. This generates ~3 pages of whatis descriptions that I can browse through looking for the right function. Another thing that would brake is when I want to use some switch for e.g. gpg that I suspect exists, but I have no idea what the name of the switch is. I then type 'gpg -<TAB>', and get a description of all the switches accepted by gpg, which fill about 9 pages on my system (gpg is insane...). This type of workflow would be impossible if the pager was hellbent on always fitting everything onto a single screen. > > that would make navigating completions much easier than scrolling down > and up. (on my notebook scrolling up is very hard to do because [pgup] > requires the [Fn] key and this can not be done with one hand :-( > (something like shift-space to scroll up would be nice here) Good point. Unfortunatly, the sequence for shift-space and space are the same. Terminals seem to send \e + Space on Alt-Space, as you'd expect, though. Control-Space seems to generate a 0 byte, but it is not alone in that, so it is not ideal. Alt-Space could be implemented with no trouble. Or Alt-Up and Alt-down. > > it would also be nice if the pager could ask if it is going to show more > than a screenful of choices. Why would that be useful? If you don't want the completions, you can just keep on typing, since pressing any normal key will exit the pager and pass the keypress on to fish which will insert the key into the commandline. If your terminal emulator supports it, fish_pager will even restore the terminal contents from before running fish_pager on exit. Asking the question just means that regardless of whether you want to browse the completions or not, you still have to press one more key than otherwise. > > greetings, martin. > -- > cooperative communication with sTeam - caudium, pike, roxen and unix > offering: programming, training and administration - anywhere in the world > -- > pike programmer travelling and working in europe open-steam.org > unix system- bahai.or.at iaeste.(tuwien.ac|or).at > administrator (caudium|gotpike).org is.schon.org > Martin Bähr http://www.iaeste.or.at/~mbaehr/ > -- Axel ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Fish-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
