zsh-workers
 help / color / mirror / code / Atom feed
* Re: new menu selection and Re: New compinstall and bindkey
@ 1999-06-29 14:09 Sven Wischnowsky
  1999-06-29 14:20 ` Is current widget system suitable? " Andrej Borsenkow
  0 siblings, 1 reply; 2+ messages in thread
From: Sven Wischnowsky @ 1999-06-29 14:09 UTC (permalink / raw)
  To: zsh-workers


Oliver Kiddle wrote:

> I've now looked at the new selection for menu completion. Firstly,
> thanks Sven: it's great. There is one thing I don't like. When I move
> the cursors to highlight the string I want to complete to and press
> return, the highlighting is removed but menu-completion continues so if
> I press tab again, it cycles through the selections as opposed to
> accepting my selection and going on to complete whatever is next.

This once was intentional, when menu-select was intended as a
menu-completion add-on. Now that it is more of a replacement we should 
probably change this. Since I don't use it that much, I'll have to
ask: do all of you agree that it should be changed?
If we change it we should probably give another widget a special
meaning in menu-select so that we have one for the current behaviour
and one for `leave menu-selection and accept the current match'. With
that users could do a `bindkey -M menuselect ...' to get their
prefered behavior. So: any suggestions for which widget we should use?
(Remember that one couldn't use this widget to leave menu-select,
then.) And what should be the default?

> I also have problems with an aixterm where the next item on the left is
> highlighted in addition to the one on the right in some circumstances.

Hm. Never seen this, so I can't help here (we don't have AIXes here).

Bye
 Sven


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


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

* Is current widget system suitable? RE: new menu selection and Re: New compinstall and bindkey
  1999-06-29 14:09 new menu selection and Re: New compinstall and bindkey Sven Wischnowsky
@ 1999-06-29 14:20 ` Andrej Borsenkow
  0 siblings, 0 replies; 2+ messages in thread
From: Andrej Borsenkow @ 1999-06-29 14:20 UTC (permalink / raw)
  To: Sven Wischnowsky, zsh-workers

> If we change it we should probably give another widget a special
> meaning in menu-select so that we have one for the current behaviour
> and one for `leave menu-selection and accept the current match'. With
> that users could do a `bindkey -M menuselect ...' to get their
> prefered behavior. So: any suggestions for which widget we should use?
> (Remember that one couldn't use this widget to leave menu-select,
> then.) And what should be the default?
>

I wanted to write about this anyway. Unfortunately, current widget system is not
well suited for programming (in user-defined widgets). Currently widgets mostly
are "high-level" ones, that do fairly complex tasks. That was fine when all
widgets were builtin ones. But now more of a low-level, primitive widgets are
needed - that do some well defined atomic action. Good example is completion.
What is needed is probably such primitives as next-match, previous-match,
insert-match, exit-menu etc. Using these most of other tasks could be easily
porgrammed with user-defined widgets - and if some prove universally useful,
they could be implemented as builtin.

This assumes, that user-defined widgets work. As my recent example shows, not
quite :-)

/andrej


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

end of thread, other threads:[~1999-06-29 14:20 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-06-29 14:09 new menu selection and Re: New compinstall and bindkey Sven Wischnowsky
1999-06-29 14:20 ` Is current widget system suitable? " Andrej Borsenkow

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).