zsh-workers
 help / color / mirror / code / Atom feed
* Question
@ 2000-04-10  8:05 Sven Wischnowsky
  2000-04-10  8:09 ` Question Andrej Borsenkow
  2000-04-11 20:19 ` Question Peter Stephenson
  0 siblings, 2 replies; 14+ messages in thread
From: Sven Wischnowsky @ 2000-04-10  8:05 UTC (permalink / raw)
  To: zsh-workers


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


^ permalink raw reply	[flat|nested] 14+ messages in thread
* RE: Question
@ 2000-04-10  8:24 Sven Wischnowsky
  2000-04-10 16:49 ` Question Oliver Kiddle
  0 siblings, 1 reply; 14+ messages in thread
From: Sven Wischnowsky @ 2000-04-10  8:24 UTC (permalink / raw)
  To: zsh-workers


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


^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: Question
@ 2000-04-11  8:13 Sven Wischnowsky
  2000-04-11  8:22 ` Question Andrej Borsenkow
  0 siblings, 1 reply; 14+ messages in thread
From: Sven Wischnowsky @ 2000-04-11  8:13 UTC (permalink / raw)
  To: zsh-workers


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


^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: Question
@ 2000-04-12  8:51 Sven Wischnowsky
  2000-04-12  8:56 ` Question Andrej Borsenkow
  2000-04-12 16:06 ` Question Bart Schaefer
  0 siblings, 2 replies; 14+ messages in thread
From: Sven Wischnowsky @ 2000-04-12  8:51 UTC (permalink / raw)
  To: zsh-workers


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


^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2000-04-12 16:07 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-04-10  8:05 Question Sven Wischnowsky
2000-04-10  8:09 ` Question Andrej Borsenkow
2000-04-11 20:19 ` Question Peter Stephenson
2000-04-10  8:24 Question Sven Wischnowsky
2000-04-10 16:49 ` Question Oliver Kiddle
2000-04-11  8:13 Question Sven Wischnowsky
2000-04-11  8:22 ` Question Andrej Borsenkow
2000-04-11  8:36   ` Question Sven Wischnowsky
2000-04-11  9:51     ` Question Sven Wischnowsky
2000-04-11 10:03       ` Question Andrej Borsenkow
2000-04-11 15:45         ` Question Bart Schaefer
2000-04-12  8:51 Question Sven Wischnowsky
2000-04-12  8:56 ` Question Andrej Borsenkow
2000-04-12 16:06 ` Question Bart Schaefer

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).