Re: New configuration -- should we...

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Nov 11,  3:12pm, Sven Wischnowsky wrote:
} Subject: Re: New configuration -- should we...
}
} 
} Bart Schaefer wrote:
} 
} > One further thought, at the risk of distraction:  Aren't these tags just
} > describing more contexts?  That is, what we're really trying to do is
} > split the whole system into stages: (1) determine context, (2) generate
} > appropriate matches, (3) organize matches for display.  The farther apart
} > we can drive these, the better; maybe there's even some way to cause the
} > tags to become context-keys for _normal, or the equivalent?
} 
} I'm not entirely sure what you mean by (3). For now I'll take it as
} `say how the matches should be generated'. I.e. things like `always',
} `only if a certain prefix is on the line' `with descriptions if
} possible' (maybe you also meant `how they are sorted in the list' --
} group-wise sorted, that is?). Anyway, this is the stuff I suggested
} the styles for.

For (3) I thought almost entirely of `how groups are sorted in the list'
and `order by rows or by columns' and maybe even `use menu-completion or
menu-selection' and that kind of thing.  `always' or `only if a certain
prefix is on the line' are part of (1); `with descriptions if possible'
is a part of (2).

} [...] for some of these we already have
} special functions (and since some time I've been trying to generate
} more of these -- that's why `_pids' appeared some time ago, for
} example). However, many of the sub-contexts in completion functions
} are so specialised that it doesn't seem to make sense to add separate
} functions for them.

I quote that slightly out of context so that I can say:

The view I was attempting to take in the previous message is that every
context has can be thought of as identifying an action.  If you treat
the action as a function (even if it's not complex enough to warrant one
in actual implementation), you can then think of the style as the set of
arguments to be passed to that function to specify/control its behavior.

Except that really the styles are collections of arguments for something
that might best be described by more than one function call, each of which
uses a different subset of those arguments.

} (I like the word `style' for this even if there may be better words
} for it in your language, so I'll continue to use it; hope that isn't
} too irritating...)

No, that's fine.  This relates directly to what I said about the user's
understanding/expression of his preference being different from how zsh
needs to process it.  The style is a user-expression concept.

} > } There are two ways how we could make that function be called. Either
} > } we do it only on the first call to `_tags' or on every call. The
} > } latter would probably be more general but the first one presumably
} > } would be easier when writing such a config function.
} > 
} > I would think this really boils down to a computation-vs-memory tradeoff.
} > That is, do you want to compute the mapping once and store it forever, or
} > recompute it every time to save the storage?  The function itself should
} > not need to be significantly different either way, should it?
} 
} If it is called for each set, it would have to check which set is
} wanted. Something like `case $attempt in 1) ...;; 2) ....;; esac'.

Oh, I see.  No, I wouldn't recommend calling it for each set.  I was
thinking of something else, which in retrospect wouldn't work anyway.

The rest of what you said makes sense; I don't have any specifc remarks.

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