zsh-workers
 help / color / mirror / code / Atom feed
* Re: Styles that aren't :completion:* ...
@ 2000-05-16  7:58 Sven Wischnowsky
  2000-05-16 15:05 ` Bart Schaefer
  0 siblings, 1 reply; 4+ messages in thread
From: Sven Wischnowsky @ 2000-05-16  7:58 UTC (permalink / raw)
  To: zsh-workers


Bart Schaefer wrote:

> I notice that the nslookup function uses a context of ':nslookup', whereas
> assorted zftp components use ":zftp$curcontext".

Yes, but it's not the completion-$curcontext, it's the zftp-one.

> Yet incremental-complete-word uses ":completion:incremental${curcontext#*:}"
> and similarly insert-and-predict uses ":completion:predict${curcontext#*:}".
> So these functions actually strip off part of the context and replace it.

I considered i-complete-w to be a completion thing. And since in
completion it uses `:completion:incremental:...' I thought it would be 
easier to understand if it used that for all styles. But yes, now that 
I think of it again, maybe it it should look up its own styles with
`:incremental'. And the same for `:predict'. Because...

> What's the idiom supposed to be, again?

(although this was never really defined; maybe we should do that and
write it down in the devel-guide) ... something like: every `system'
uses its own prefix and whatever hierarchy it needs below that. Not a
very exact description, I'm afraid.

> Here's the specific reason that I ask:  I'm thinking of adding some more
> styles to predict-on/off and to the functions they bind to keystrokes.  For
> example, there's a comment in delete-backward-and-predict to the effect
> that some people might prefer that it call predict-off.  That seems like
> an ideal thing to control with a style, but it feels funny to use a style
> that starts with ":completion:" because no completion is happening during
> delete-backward-and-predict.

Right.

> Similarly I was thinking of adding a "verbose" style to predict-on, to have
> it call "zle -M" when prediction goes into effect.  That's called directly
> from a keystroke.  What's the context?

`:predict', I'd say.

Bye
 Sven


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


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

* Re: Styles that aren't :completion:* ...
  2000-05-16  7:58 Styles that aren't :completion:* Sven Wischnowsky
@ 2000-05-16 15:05 ` Bart Schaefer
  0 siblings, 0 replies; 4+ messages in thread
From: Bart Schaefer @ 2000-05-16 15:05 UTC (permalink / raw)
  To: zsh-workers

On May 16,  9:58am, Sven Wischnowsky wrote:
} Subject: Re: Styles that aren't :completion:* ...
}
} Bart Schaefer wrote:
} 
} > I notice that the nslookup function uses a context of ':nslookup', whereas
} > assorted zftp components use ":zftp$curcontext".
} 
} Yes, but it's not the completion-$curcontext, it's the zftp-one.

Ah.

} I considered i-complete-w to be a completion thing. And since in
} completion it uses `:completion:incremental:...' I thought it would be 
} easier to understand if it used that for all styles.

Yes, that's what I'm struggling with here.  One question is, is there any
way $curcontext could have a value at the time i-c-w or i-a-p are called?
They'd have to be getting called *inside* the completion or zftp systems,
wouldn't they?  Which they shouldn't ... so it doesn't make sense to e.g.

  zstyle ':completion:predict:*:-math-:*' cursor complete
  zstyle ':completion:predict:*' cursor key

because insert-and-predict doesn't know that it's in math context.  (On
the other hand, it might be nice to be able to do that ...)

But it's still necessary to at least set curcontext=predict::: so that the
right function field will be present when `zle complete-word' is called.

} > What's the context?
} 
} `:predict', I'd say.

Then we'll have to remove the i-c-w and predict documentation from the
completion system sections.  Where should it go instead?

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


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

* Re: Styles that aren't :completion:* ...
@ 2000-05-17  6:41 Sven Wischnowsky
  0 siblings, 0 replies; 4+ messages in thread
From: Sven Wischnowsky @ 2000-05-17  6:41 UTC (permalink / raw)
  To: zsh-workers


Bart Schaefer wrote:

> ...
> 
> } I considered i-complete-w to be a completion thing. And since in
> } completion it uses `:completion:incremental:...' I thought it would be 
> } easier to understand if it used that for all styles.
> 
> Yes, that's what I'm struggling with here.  One question is, is there any
> way $curcontext could have a value at the time i-c-w or i-a-p are called?

I was thinking about wrapper functions around i-c-w. Not that I really 
expect that there will be such things anytime...

> They'd have to be getting called *inside* the completion or zftp systems,
> wouldn't they?  Which they shouldn't ... so it doesn't make sense to e.g.
> 
>   zstyle ':completion:predict:*:-math-:*' cursor complete
>   zstyle ':completion:predict:*' cursor key
> 
> because insert-and-predict doesn't know that it's in math context.  (On
> the other hand, it might be nice to be able to do that ...)

The old `problem' that most of the context is set up relatively
late... maybe I'll try again to write a utility function that sets up
$curcontext as far as it can sometime.

> But it's still necessary to at least set curcontext=predict::: so that the
> right function field will be present when `zle complete-word' is called.
> 
> } > What's the context?
> } 
> } `:predict', I'd say.
> 
> Then we'll have to remove the i-c-w and predict documentation from the
> completion system sections.  Where should it go instead?

Urgh. Hadn't thought about that. Maybe a `styles.yo' (comparable to
options.yo and params.yo), but where to place it? Next to the options
and parameters would be logically wrong because zstyle is defined by a 
module. Hm.

Bye
 Sven


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


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

* Styles that aren't :completion:* ...
@ 2000-05-16  6:28 Bart Schaefer
  0 siblings, 0 replies; 4+ messages in thread
From: Bart Schaefer @ 2000-05-16  6:28 UTC (permalink / raw)
  To: zsh-workers

I notice that the nslookup function uses a context of ':nslookup', whereas
assorted zftp components use ":zftp$curcontext".

Yet incremental-complete-word uses ":completion:incremental${curcontext#*:}"
and similarly insert-and-predict uses ":completion:predict${curcontext#*:}".
So these functions actually strip off part of the context and replace it.

What's the idiom supposed to be, again?

Here's the specific reason that I ask:  I'm thinking of adding some more
styles to predict-on/off and to the functions they bind to keystrokes.  For
example, there's a comment in delete-backward-and-predict to the effect
that some people might prefer that it call predict-off.  That seems like
an ideal thing to control with a style, but it feels funny to use a style
that starts with ":completion:" because no completion is happening during
delete-backward-and-predict.

Similarly I was thinking of adding a "verbose" style to predict-on, to have
it call "zle -M" when prediction goes into effect.  That's called directly
from a keystroke.  What's the context?

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


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

end of thread, other threads:[~2000-05-17  6:41 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-05-16  7:58 Styles that aren't :completion:* Sven Wischnowsky
2000-05-16 15:05 ` Bart Schaefer
  -- strict thread matches above, loose matches on Subject: below --
2000-05-17  6:41 Sven Wischnowsky
2000-05-16  6:28 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).