Question

Question

[Sven Wischnowsky]

Currently, if a completion list is too long, the completion system
asks if onw wants to see all <n> matches. This is not only ugly in
cases like _complete_help with styles-output -- it askes if one wants
to see all `0' matches.

Should we change it to mention the number of lines needed? I think it
would always be more interesting.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

RE: Question

[Andrej Borsenkow]

Is there any way to scroll/page output? It would be even more
interesting ...

-andrej

>
>
> Currently, if a completion list is too long, the completion system
> asks if onw wants to see all <n> matches. This is not only ugly in
> cases like _complete_help with styles-output -- it askes if one wants
> to see all `0' matches.
>
> Should we change it to mention the number of lines needed? I think it
> would always be more interesting.
>
> Bye
>  Sven
>
>
> --
> Sven Wischnowsky
> wischnow@informatik.hu-berlin.de
>
>

Re: Question

[Peter Stephenson]

Sven Wischnowsky wrote:
> Currently, if a completion list is too long, the completion system
> asks if onw wants to see all <n> matches. This is not only ugly in
> cases like _complete_help with styles-output -- it askes if one wants
> to see all `0' matches.
> 
> Should we change it to mention the number of lines needed? I think it
> would always be more interesting.

Yes, it would.  I suppose this is too deep to be able to use a style.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@CambridgeSiliconRadio.com
Web: http://www.pwstephenson.fsnet.co.uk

RE: Question

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> Is there any way to scroll/page output? It would be even more
> interesting ...

No there isn't. I have a very faint memory of this question having
come up before. I think the discussion stopped when we were thinking
about everybody wanting her/his favourite pager key bindings being
supported.

And I'm not sure I want to think about the amount of changes needed in 
the listing code to support this. Hm, although...

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Question

[Oliver Kiddle]

Sven Wischnowsky wrote:
> 
> Andrej Borsenkow wrote:
> 
> > Is there any way to scroll/page output? It would be even more
> > interesting ...
> 
> No there isn't. I have a very faint memory of this question having
> come up before. I think the discussion stopped when we were thinking
> about everybody wanting her/his favourite pager key bindings being
> supported.

I would have thought it would be far better to allow people to use their
favourite pager (as taken from $PAGER) instead of trying to write a
simple pager. How compilcated would it be to make the listing code
output to a pipe instead. There is actually a few times when I would
have liked to pipe completion listings through a command so if this
implemented, it would be useful to be able to specify another command
(such as grep) to pipe the listing into.

Oliver

Re: Question

[Sven Wischnowsky]

Oliver Kiddle wrote:

> Sven Wischnowsky wrote:
> > 
> > Andrej Borsenkow wrote:
> > 
> > > Is there any way to scroll/page output? It would be even more
> > > interesting ...
> > 
> > No there isn't. I have a very faint memory of this question having
> > come up before. I think the discussion stopped when we were thinking
> > about everybody wanting her/his favourite pager key bindings being
> > supported.
> 
> I would have thought it would be far better to allow people to use their
> favourite pager (as taken from $PAGER) instead of trying to write a
> simple pager. How compilcated would it be to make the listing code
> output to a pipe instead. There is actually a few times when I would
> have liked to pipe completion listings through a command so if this
> implemented, it would be useful to be able to specify another command
> (such as grep) to pipe the listing into.

A matter of replacing `shout' in several places with the pipe. But
then there is the issue of starting the external command... And what
to do with menu-selection? And the terminal codes used by complist?

Oh my, and I only asked if it would be better to mention the number of 
lines needed for the list when asking if it should be displayed... ;-)

And noone has answered that yet (unless Andrej meant that it would be
better).

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

RE: Question

[Andrej Borsenkow]

>
> A matter of replacing `shout' in several places with the pipe. But
> then there is the issue of starting the external command... And what
> to do with menu-selection? And the terminal codes used by complist?
>

Yes, exactly for this reason I'd really prefer built-in solution if at
all possible. Keybinding is not an issue here (not really). But, of
course, not in this release.

> Oh my, and I only asked if it would be better to mention the
> number of
> lines needed for the list when asking if it should be displayed... ;-)
>
> And noone has answered that yet (unless Andrej meant that it would be
> better).
>

I have not answered because I do not actually care. What matters to me
is the ability to see the full list. If I'm on X11 I can scroll - and if
I'm on tty, it does not help anyway.  May be, something like "output
does not fit on screen" would be nice - currently, it is not obvious.
That is, there are two cases

- list can be shown in full, but user set it to small value
- ilst does not fit at all

To distinguish between them is nice.

The problem is, with all power of Zsh completion, I'm getting in habit
to simply press TAB and see list of command options :-) And it is
exactly this case, when output mostly does not fit on a screen.

-andrej

RE: Question

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> > A matter of replacing `shout' in several places with the pipe. But
> > then there is the issue of starting the external command... And what
> > to do with menu-selection? And the terminal codes used by complist?
> 
> Yes, exactly for this reason I'd really prefer built-in solution if at
> all possible. Keybinding is not an issue here (not really). But, of
> course, not in this release.
> 
> > Oh my, and I only asked if it would be better to mention the
> > number of
> > lines needed for the list when asking if it should be displayed... ;-)
> >
> > And noone has answered that yet (unless Andrej meant that it would be
> > better).
> 
> I have not answered because I do not actually care. What matters to me
> is the ability to see the full list. If I'm on X11 I can scroll - and if
> I'm on tty, it does not help anyway.  May be, something like "output
> does not fit on screen" would be nice - currently, it is not obvious.
> That is, there are two cases
> 
> - list can be shown in full, but user set it to small value
> - ilst does not fit at all
> 
> To distinguish between them is nice.

This is done by the value of $LISTMAX:

- zero: ask if list is bigger than screen
- positive: ask if more matches than that
- negative: ask if more lines than that

Hm, maybe if we turn it into a scalar and make a value of `scroll' (or 
`page') allow a very simple pager, builtin (which I, too, definitely
prefer), that is used if the list doesn't fit on the screen, with a
few keys:

- space: next screen (surprise!)
- return: next line
- q: stop listing
- <any>: stop listing and process key as usual

Going back in the list is a problem...

> The problem is, with all power of Zsh completion, I'm getting in habit
> to simply press TAB and see list of command options :-) And it is
> exactly this case, when output mostly does not fit on a screen.

I like to hear that. The first sentence, that is ;-)

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Question

[Sven Wischnowsky]

I wrote:

> Oliver Kiddle wrote:
> 
> > Sven Wischnowsky wrote:
> > > 
> > > Andrej Borsenkow wrote:
> > > 
> > > > Is there any way to scroll/page output? It would be even more
> > > > interesting ...
> > > 
> > > No there isn't. I have a very faint memory of this question having
> > > come up before. I think the discussion stopped when we were thinking
> > > about everybody wanting her/his favourite pager key bindings being
> > > supported.
> > 
> > I would have thought it would be far better to allow people to use their
> > favourite pager (as taken from $PAGER) instead of trying to write a
> > simple pager. How compilcated would it be to make the listing code
> > output to a pipe instead. There is actually a few times when I would
> > have liked to pipe completion listings through a command so if this
> > implemented, it would be useful to be able to specify another command
> > (such as grep) to pipe the listing into.
> 
> A matter of replacing `shout' in several places with the pipe. But
> then there is the issue of starting the external command... And what
> to do with menu-selection? And the terminal codes used by complist?
> 
> Oh my, and I only asked if it would be better to mention the number of 
> lines needed for the list when asking if it should be displayed... ;-)
> 
> And noone has answered that yet (unless Andrej meant that it would be
> better).

Err, wait. You almost certainly want to use different commands for
different lists, so we would have to read the command line to use for
piping first. Isn't that getting a bit too complicated?

Hm, make isearch work in menu-selection and the (proposed,
vapour-warish) pager? Ouch.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

RE: Question

[Andrej Borsenkow]

>
> Hm, make isearch work in menu-selection and the (proposed,
> vapour-warish) pager? Ouch.
>

Not sure, what this "Ouch" applies to ... but, yes, paging the list only
without menu-selection supporting multi-page lists would be ehhh ... a
pity :-)

One more argument in favour of built-in implementation.

-andrej

Re: Question

[Bart Schaefer]

On Apr 11, 10:13am, Sven Wischnowsky wrote:
} Subject: Re: Question
} 
} Oh my, and I only asked if it would be better to mention the number of 
} lines needed for the list when asking if it should be displayed... ;-)

Like Andrej, I think it makes only a very small difference either way.

I was going to reply to a lot more of the remarks in this thread, but I
think it comes down to:  I don't think we should be "in the business" of
implementing pagers, but some alternate ideas come to mind ...

In a later message, Sven went on:
} 
} Err, wait. You almost certainly want to use different commands for
} different lists, so we would have to read the command line to use for
} piping first. Isn't that getting a bit too complicated?
} 
} Hm, make isearch work in menu-selection and the (proposed,
} vapour-warish) pager? Ouch.

Here are two possible suggestions; I haven't actually attempted either
of them.

(1)  Format up the completion listing as if it were going to shout, but
stuff it all into a string instead.  (That's probably happening already,
I didn't look.)  Then point a parameter at that string and invoke vared.
ZLE already takes care of paging up and down.

With some diddling of key-bindings, you can move around on the current
"screen" just as in menu-selection and arrange to exit from vared with
the parameter set to the substring the cursor was over when accept-line
was pressed.

(2) Use a "select x in ..." loop over the values.  As of some while ago,
select already knows how to page through screenfuls of choices.  You
can't go backwards, but it cycles to the top after reaching the bottom.

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

Re: Question

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> I was going to reply to a lot more of the remarks in this thread, but I
> think it comes down to:  I don't think we should be "in the business" of
> implementing pagers, but some alternate ideas come to mind ...
> 
> ...
> 
> Here are two possible suggestions; I haven't actually attempted either
> of them.
> 
> (1)  Format up the completion listing as if it were going to shout, but
> stuff it all into a string instead.  (That's probably happening already,
> I didn't look.)  Then point a parameter at that string and invoke vared.
> ZLE already takes care of paging up and down.
> 
> With some diddling of key-bindings, you can move around on the current
> "screen" just as in menu-selection and arrange to exit from vared with
> the parameter set to the substring the cursor was over when accept-line
> was pressed.

I agree that this sounds very interesting, but there are two things
I'm worried about:

The first one is a real problem that can't be avoided with this
solution: the colouring that's possible with complist would be lost. I 
guess you don't use it, but I at least have become quite fond of it. I 
especially like the look of a process listing in menu-selection with
the `cursor' in red, spanning the whole line. Much better `readable'
then the typical single-character cursor on a all black-on-white (grey 
for me) style vared could give us.

The second one is mostly a fear, I haven't fully checked: the
completion listing code is currently a bit like a separate system,
separated from the sorroundings, that is. I'm not sure what could
happen when we allow something like vared (with possible user defined
widgets being called) while the completion list is displayed.
Especially for menu-selection, I think. Maybe that isn't really a
problem, though. But it would also mean that the prompt wouldn't be
visible during a menu-selection.

And then: all the changes needed to build the string (which may also
get pretty large). Urgh.

> (2) Use a "select x in ..." loop over the values.  As of some while ago,
> select already knows how to page through screenfuls of choices.  You
> can't go backwards, but it cycles to the top after reaching the bottom.

I never liked select and fiddling with numbers in completion lists
seems weird to me. But then: `select already knows how to page' and `I
don't think we should be "in the business" of implementing pagers'.

If select does pages, why shouldn't the completion code do that,
too. There were times when they were implemented by the same function, 
almost.


I've played with implementing some of the stuff yesterday evening and
it's surprisingly small and menu-selection with scrolling looks funny.
Can't show you the patch yet, though, because it's incompatible with
the current CVS and there are some things missing/untested.

And never fear: I certainly won't commit the patch without showing it
to the list first.

A final thought: complist is intended as the module to allow fancy
completion list handling... would it be acceptable to add this
scrolling stuff only to it? Well, some basic functions would need to
be in the complete module...

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

RE: Question

[Andrej Borsenkow]

> 
> A final thought: complist is intended as the module to allow fancy
> completion list handling... would it be acceptable to add this
> scrolling stuff only to it? Well, some basic functions would need to
> be in the complete module...
> 


I find it reasonable.

-andrej

Re: Question

[Bart Schaefer]

On Apr 12, 10:51am, Sven Wischnowsky wrote:
} Subject: Re: Question
}
} > (1)  Format up the completion listing as if it were going to shout, but
} > stuff it all into a string instead.  (That's probably happening already,
} > I didn't look.)  Then point a parameter at that string and invoke vared.
} > ZLE already takes care of paging up and down.
} 
} The first one is a real problem that can't be avoided with this
} solution: the colouring that's possible with complist would be lost.

I suppose so.

} I'm not sure what could
} happen when we allow something like vared (with possible user defined
} widgets being called) while the completion list is displayed.

Yes, I wondered about the warnings that cna be printed about not using
zle recursively.  You might have to save and restore the whole state of
the completion system to be entirely safe, which could get ugly.
 
} > (2) Use a "select x in ..." loop over the values.  As of some while ago,
} > select already knows how to page through screenfuls of choices.  You
} > can't go backwards, but it cycles to the top after reaching the bottom.
} 
} I never liked select and fiddling with numbers in completion lists
} seems weird to me. But then: `select already knows how to page' and `I
} don't think we should be "in the business" of implementing pagers'.

There's a difference between pausing after N lines and implementing a
pager.  A pager implies being able to scroll one or a few lines at a
time, not by whole screenfuls, and being able to move backwards as well
as forwards (or at least that's what it implies nowadays).

Is the following a pager?

	integer i=0
	while read -E
	do
	  (( ++i == LINES-2 )) &&
	    { i=0; read -q '?Continue? [no] ' </dev/tty || break }
	done

(The above reveals a possible bug:  "read -q" prints a prompt only if
standard input is a TTY, but it always reads from the TTY if there is
one.  So I had to throw in that redirection.)

} A final thought: complist is intended as the module to allow fancy
} completion list handling... would it be acceptable to add this
} scrolling stuff only to it?

If it's getting added, that's the place for it.

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