* Re: PATCH: completion for file descriptors
@ 2000-04-20 7:18 Sven Wischnowsky
2000-04-20 9:19 ` Oliver Kiddle
0 siblings, 1 reply; 8+ messages in thread
From: Sven Wischnowsky @ 2000-04-20 7:18 UTC (permalink / raw)
To: zsh-workers
Oliver Kiddle wrote:
> ...
>
> If put _file_descriptors in Core because
> it will be used by _redirect and because other things like _options is
> there - it can always be moved.
Yes, function moving and ordering before 4.0...
The directories we have now have mostly historical reasons and several
functions could sensibly be moved in other directories even now.
What I would like is a more logical ordering. I haven't really thought
about this yet, but maybe a Core with some of the functions it
contains now, a directory with functions like _arguments (not really
generating completions, only helping to add them), one directory with
all those functions that generate a certain type of matches (options,
jobs, pids, file-descriptors, etc.). And then certainly one for the
builtin commands.
The other stuff is harder to decide. _rpm, for example can also be
useful on non-Linux systems. I don't know debian, but I guess the
commands from that directory can be useful elsewhere, too. So maybe we
should package the functions in a way that reflects what the commands
do (network, package-managers, ...).
I'd like to hear suggestions about all this. (And now Andrej comes and
says that we should put all the GNU commands on the side... which
wouldn't work with the ordering-by-what-they-do, of course. I still
think there should be only one function per command and we try to find
out what to complete by investigating the environment inside the
functions.)
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PATCH: completion for file descriptors 2000-04-20 7:18 PATCH: completion for file descriptors Sven Wischnowsky @ 2000-04-20 9:19 ` Oliver Kiddle 2000-04-20 9:31 ` Thomas Köhler 2000-04-24 5:23 ` Completion function directories Bart Schaefer 0 siblings, 2 replies; 8+ messages in thread From: Oliver Kiddle @ 2000-04-20 9:19 UTC (permalink / raw) To: zsh-workers [-- Attachment #1: Type: text/plain, Size: 2118 bytes --] Sven Wischnowsky wrote: > Yes, function moving and ordering before 4.0... What you suggest for the basic stuff sounds good to me. > The other stuff is harder to decide. _rpm, for example can also be > useful on non-Linux systems. I don't know debian, but I guess the > commands from that directory can be useful elsewhere, too. So maybe we > should package the functions in a way that reflects what the commands > do (network, package-managers, ...). That is a bit more diffcult. I think I would prefer to stick to directories which group together commands which users will generally have all or none of as it is easier to specify whether you want a whole directory than to pick and choose from specific commands taking each on their own. I expect that it is fairly rare for someone to use rpm on something other than Linux. Would there be problems involved in making the installation of the functions intelligently only pick out completions for commands which exist on the system? > (And now Andrej comes and > says that we should put all the GNU commands on the side... which > wouldn't work with the ordering-by-what-they-do, of course. I still > think there should be only one function per command and we try to find > out what to complete by investigating the environment inside the > functions.) I agree with you on this. It keeps things all together better than if we say had 10 different completions for the same command on different systems so it is easier to make useful changes affect all the different systems where they have commonality. It is common for GNU stuff to be installed alongside originals, sometimes in a different directory and sometimes with a different name and it would be important to me that completion for these works. I've attached my AIX specific completions. I haven't put them in cvs or anything but when you (or whoever) come to sort out the directories, a place could be found for them (and those FreeBSD ones someone sent yesterday). I've actually got a few more AIX (and IRIX) completions but they are very old (pre-_arguments) and could really do with a rewrite. Oliver [-- Attachment #2: Aixcomps.tgz --] [-- Type: application/x-unknown-content-type-WinZip, Size: 1662 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PATCH: completion for file descriptors 2000-04-20 9:19 ` Oliver Kiddle @ 2000-04-20 9:31 ` Thomas Köhler 2000-04-24 5:23 ` Completion function directories Bart Schaefer 1 sibling, 0 replies; 8+ messages in thread From: Thomas Köhler @ 2000-04-20 9:31 UTC (permalink / raw) To: zsh-workers [-- Attachment #1: Type: text/plain, Size: 1849 bytes --] On Thu, Apr 20, 2000 at 11:19:50AM +0200, Oliver Kiddle <opk@u.genie.co.uk> wrote: > Sven Wischnowsky wrote: > > > Yes, function moving and ordering before 4.0... > What you suggest for the basic stuff sounds good to me. > > The other stuff is harder to decide. _rpm, for example can also be > > useful on non-Linux systems. I don't know debian, but I guess the > > commands from that directory can be useful elsewhere, too. So maybe we > > should package the functions in a way that reflects what the commands > > do (network, package-managers, ...). > That is a bit more diffcult. I think I would prefer to stick to > directories which group together commands which users will generally > have all or none of as it is easier to specify whether you want a whole > directory than to pick and choose from specific commands taking each on > their own. I expect that it is fairly rare for someone to use rpm on > something other than Linux. Would there be problems involved in making > the installation of the functions intelligently only pick out > completions for commands which exist on the system? Well, yes. I'd see a problem if zsh wouldn't install ssh completion because there is no ssh installed (just because someone forgot to install it), ssh gets installed later, and the completion is not there. (anything besides ssh may be used as an example) One could argue "then do a make install again", but what about people who are low on disk space and just have deleted the source tree again? Download again. Bad. CU, Thomas -- Thomas Köhler Email: jean-luc@picard.franken.de | LCARS - Linux <>< WWW: http://jeanluc-picard.de | for Computers IRC: jeanluc | on All Real PGP public key available from Homepage! | Starships [-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Completion function directories 2000-04-20 9:19 ` Oliver Kiddle 2000-04-20 9:31 ` Thomas Köhler @ 2000-04-24 5:23 ` Bart Schaefer 2000-04-27 7:59 ` Andrej Borsenkow 2000-05-01 2:43 ` PATCH: Spelling corrections in Etc/ files Oliver Kiddle 1 sibling, 2 replies; 8+ messages in thread From: Bart Schaefer @ 2000-04-24 5:23 UTC (permalink / raw) To: zsh-workers On Apr 20, 9:18am, Sven Wischnowsky wrote: } Subject: Re: PATCH: completion for file descriptors } } What I would like is a more logical ordering. I haven't really thought } about this yet, but maybe a Core with some of the functions it } contains now [...] I'd prefer that to be named something other than "Core" ... } a directory with functions like _arguments (not really } generating completions, only helping to add them), one directory with } all those functions that generate a certain type of matches (options, } jobs, pids, file-descriptors, etc.). And then certainly one for the } builtin commands. This sounds OK, too. I also wonder whether we shouldn't move "compinit" and related functions (anything not starting with an underscore, really) up into the Completion directory itself. } The other stuff is harder to decide. _rpm, for example can also be } useful on non-Linux systems. I don't know debian, but I guess the } commands from that directory can be useful elsewhere, too. So maybe we } should package the functions in a way that reflects what the commands } do (network, package-managers, ...). I don't think categorizing them that way is especially useful. For one thing, it means deciding on a list of categories, which is a potentially deep rat-hole. For another, it's no help when deciding which completions to install; if I'm not going to install everything, then I'm probably going to want all of the "networking" completions but only one of the "package manager" completions, etc. I'm not sure that it's even possible to divide things up in a way that helps much with that, but the point is to avoid making arbitrary divisions simply for the sake of dividing. The main things I think we need are (1) to rename the Commands directory (whatever meaning that name once had has long been lost on me) and (2) break the User directory into two directories, one for helpers like _user_at_host and _tilde_files and another for functions that handle commands (which I think ought to be in a directory named Commands, but what do I know). And then if we're going to keep the system-specific directories like AIX and even X, maybe we should subdivide them further into the same two directories that we break User into, and eliminate the system-specific level of hierarchy at install time. So we'd end up with something like Helpers Commands AIX/Helpers AIX/Commands Bsd/Helpers Bsd/Commands etc. etc. (with probably a better name than "helpers"). Things like _diff_options still end up in a fuzzy space, I know ... On Apr 20, 10:19am, Oliver Kiddle wrote: } Subject: Re: PATCH: completion for file descriptors } } I think I would prefer to stick to directories which group together } commands which users will generally have all or none of as it is } easier to specify whether you want a whole directory than to pick } and choose from specific commands taking each on their own. I expect } that it is fairly rare for someone to use rpm on something other than } Linux. That's less true that it would have been even a few months ago -- and even if it's still true, it's silly for _rpm to be the only thing in the Linux directory. Might as well give it back its own, or put it in one named RedHat; after all, almost-but-not-quite everything in the Debian directory is related to the Debian package management system. My general feeling on that specific issue is that we shouldn't worry about it too much -- the packagers of the various linux distributions will pick the completions that are appropriate for their own dists when they build their zsh RPMs or dpkgs or whatever, and their end users will never know or care otherwise (in the main). Any division we make should be either for our benefit as developers or to assist packagers in making the right choices. (Further, note that we -could- use a .distfiles-type mechanism or some such to make the install structure differ from the distribution structure.) Much earlier, Sven wrote: } [...] Andrej comes and says that we should put all the GNU commands } on the side... This brings up a a question of whether we should have helper functions for setting/testing the _is_gnu assoc, like happens now in _make and _diff_options, or to set up the "standard completion environment" like in _main_complete and _complete_help. I thought briefly about doing the latter, but then I noticed this problem: function unfortunate () { setopt NO_localoptions ... } function unsuspecting () { setopt localoptions ... unfortunate } Unsetting localoptions in a nested function has some rather peculiar effects depending on which options change state where. It's not exactly nondeterministic, but it surely can't be determined from the context of the function that unsets localoptions, and probably not from the context of the function that calls that other function. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Completion function directories 2000-04-24 5:23 ` Completion function directories Bart Schaefer @ 2000-04-27 7:59 ` Andrej Borsenkow 2000-04-27 22:09 ` Bart Schaefer 2000-05-01 2:43 ` PATCH: Spelling corrections in Etc/ files Oliver Kiddle 1 sibling, 1 reply; 8+ messages in thread From: Andrej Borsenkow @ 2000-04-27 7:59 UTC (permalink / raw) To: Bart Schaefer, zsh-workers > > Much earlier, Sven wrote: > } [...] Andrej comes and says that we should put all the GNU commands > } on the side... > > This brings up a a question of whether we should have helper functions > for setting/testing the _is_gnu assoc, like happens now in _make and > _diff_options, or to set up the "standard completion environment" like > in _main_complete and _complete_help. I am not sure I understand what do you mean under "standard completion environment" in this respect. I believe, in all cases when it is possible we need automatic test for GNU utilities so, that completion really works "out of the box". And only when it's not possible - last resort like styles for particular command. -andrej ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Completion function directories 2000-04-27 7:59 ` Andrej Borsenkow @ 2000-04-27 22:09 ` Bart Schaefer 0 siblings, 0 replies; 8+ messages in thread From: Bart Schaefer @ 2000-04-27 22:09 UTC (permalink / raw) To: zsh-workers On Apr 27, 11:59am, Andrej Borsenkow wrote: > Subject: RE: Completion function directories > > > > Much earlier, Sven wrote: > > } [...] Andrej comes and says that we should put all the GNU commands > > } on the side... > > > > This brings up a a question of whether we should have helper functions > > for setting/testing the _is_gnu assoc, like happens now in _make and > > _diff_options, or to set up the "standard completion environment" like > > in _main_complete and _complete_help. > > I am not sure I understand what do you mean under "standard completion > environment" in this respect. The two lines of setopts that have to appear at the top of each of several of the completion functions to be sure all the globs and parameter refs work as expected in all the rest of the functions those call. My idea was to write a function: _standard_completer_setopts () { unsetopt localoptions # This is the problem part setopt nullglob rcexpandparam extendedglob unsetopt markdirs globsubst shwordsplit nounset ksharrays } Then there's only one place to edit if we ever need to change the setopts used by all the completion scripts -- but the present unpredictable behavior of `unsetopt localoptions' makes this idea unworkable. > I believe, in all cases when it is > possible we need automatic test for GNU utilities so, that completion > really works "out of the box". And only when it's not possible - last > resort like styles for particular command. Following the same sort of suggestion as above, we'd have something like _detect_gnu () { (( $+_is_gnu )) || typeset -gA _is_gnu if (( ! $+_is_gnu[$1] )) then if [[ $(_call version "$@" </dev/null 2>/dev/null) = *GNU* ]] then _is_gnu[$1]=yes else _is_gnu[$1]= fi fi [[ $_is_gnu[$1] = yes ]] } And then _make would use if _detect_gnu $words[1] -v -f /dev/null; then and _diff_options would use if _detect_gnu $cmd -v; then and so on for any other completion functions that needed to notice GNU. ^ permalink raw reply [flat|nested] 8+ messages in thread
* PATCH: Spelling corrections in Etc/ files 2000-04-24 5:23 ` Completion function directories Bart Schaefer 2000-04-27 7:59 ` Andrej Borsenkow @ 2000-05-01 2:43 ` Oliver Kiddle 1 sibling, 0 replies; 8+ messages in thread From: Oliver Kiddle @ 2000-05-01 2:43 UTC (permalink / raw) To: zsh-workers I've fixed a few typos in some of the files in the Etc directory. I have also removed the comment in the zsh-development-guide about how future tests of interactive features may require external software like expect because I would imagine that any such tests would now be done using zpty. If anyone disagrees, I'll put the comment back. On the subject of Completion function directories, Bart Schaefer wrote: > And then if we're going to keep the system-specific > directories like AIX and even X, maybe we should subdivide them further > into the same two directories that we break User into, and eliminate > the system-specific level of hierarchy at install time. > > So we'd end up with something like > > Helpers Commands AIX/Helpers AIX/Commands Bsd/Helpers Bsd/Commands > etc. etc. > > (with probably a better name than "helpers"). Things like _diff_options > still end up in a fuzzy space, I know ... The completion-style-guide seems to refer to the `helpers' as utility functions so 'Utilities' would be one suggestion for a different name. I can't think of many other options though - thinking of similar things in various programming languages: 'Generic', 'Library'. I think your suggestion on how to reorganise the completion directories is very good. Oliver Index: Etc/MACHINES =================================================================== RCS file: /cvsroot/zsh/zsh/Etc/MACHINES,v retrieving revision 1.2 diff -u -r1.2 MACHINES --- Etc/MACHINES 2000/04/16 19:02:13 1.2 +++ Etc/MACHINES 2000/05/01 03:39:53 @@ -64,7 +64,7 @@ Should build `out-of-the-box', but --enable-zsh-mem will not work. On 3.2, for 64-bit integer support you need to compile with gcc, as - the native compiler does not support ANSI simulataneously with + the native compiler does not support ANSI simultaneously with `long long'. On 4.1, there appear to be problems using --enable-dynamic (the default) with gcc (version was 2.7.2.3) in 4.1, though native cc works. More information about this problem @@ -107,16 +107,16 @@ and CDS/CDS++ compiler. SIEMENS: SINIX - MX (Intel) plattform: SINIX-L/M 5.41 + MX (Intel) platform: SINIX-L/M 5.41 Builds out-of-the-box with EGCS. Neither dynamic loading nor - 64-bit integers are suported. Native compiler was not tried + 64-bit integers are supported. Native compiler was not tried mostly because GCC/EGCS builds out-of-the-box as well. If you succeed with native compiler, send a patch for this file to zsh-workers. - RM (MIPS) plattform: SINIX-N/Y 5.42 + RM (MIPS) platform: SINIX-N/Y 5.42 Should build out-of-the-box but it was not tested. Neither - dynamic loading nor 64-bit integers are suported. + dynamic loading nor 64-bit integers are supported. Note, that this version is obsolete and users are expected to update to Reliant UNIX. Index: Etc/NEWS =================================================================== RCS file: /cvsroot/zsh/zsh/Etc/NEWS,v retrieving revision 1.2 diff -u -r1.2 NEWS --- Etc/NEWS 2000/04/30 21:04:55 1.2 +++ Etc/NEWS 2000/05/01 03:39:56 @@ -5,14 +5,14 @@ New features in zsh version 3.1.7 --------------------------------- Further enhancements to new completion system: - - Comprehensive context-sensitive configuration vai `styles', which - can be set by the menu-driven front end in compinstall. + - Comprehensive context-sensitive configuration via `styles', which + can be set by the menu-driven front end in compinstall - General mechanism for setting patterns to be ignored in a completion; overriding of patterns to be matched for functions - New completers: _prefix to complete word before cursor, _ignored to complete using words so far ignored (like $fignore but more powerful), _history to complete words from shell history - - Multiple use of completers with different options, similalry splitting + - Multiple use of completers with different options, similarly splitting of different types of completion (`tags') so they are considered with different styles - Many more supplied completions for standard commands which work out of @@ -68,7 +68,7 @@ matches, e.g. [[ $foo = (#b)(*/)[^/]* ]] stores the part of $foo up to the last / in $match[1] and the indexes of - the match in $mbegin[1], $mend[1]. (#m) is also availabel to set $MATCH + the match in $mbegin[1], $mend[1]. (#m) is also available to set $MATCH to the entire match and corresponding $MBEGIN, $MEND: useful in parameter substitutions like ${.../.../...}. - (#s) and (#e) match start and end of pattern like ^ and $ in regular @@ -88,7 +88,7 @@ zsh subdirectory, so zle becomes zsh/zle etc.; aliases supplied for compatibility for existing code, but the new format should be used in future. - - zmodload is more consistent between dynamicall and statically linked + - zmodload is more consistent between dynamically and statically linked shells - zsh/zftp and its function suite support multiple sessions (zfsession command); zftransfer allows transfer of files between two ftp sessions @@ -286,7 +286,7 @@ ------------------------------- Trailing "/" in a glob pattern now works like in other shell thus it -can no longer be used as a sorthand for "(/)". +can no longer be used as a shorthand for "(/)". Much improved sh/ksh emulation. When zsh is invoked as sh it mostly conforms to POSIX 1003.2. Index: Etc/completion-style-guide =================================================================== RCS file: /cvsroot/zsh/zsh/Etc/completion-style-guide,v retrieving revision 1.4 diff -u -r1.4 completion-style-guide --- Etc/completion-style-guide 2000/04/25 09:48:09 1.4 +++ Etc/completion-style-guide 2000/05/01 03:39:59 @@ -2,7 +2,7 @@ --------------------------- The completion system keeps track of the current context in the -parameter `curcontext'. It's content is the hierarchical name for the +parameter `curcontext'. Its content is the hierarchical name for the current context sans the `:completion:' and the last colon and the tag currently tried. The tags represent different types of matches. So, whenever you are about to add matches, you should use a tag for them @@ -98,13 +98,13 @@ The `_all_labels' function implements the loop over the tag aliases and handles the user-defined description, using (in the example) the -parameter `expl' to store options to give to the command. These option +parameter `expl' to store options to give to the command. These options are inserted into the command line either directly before a single hyphen if there is such an argument or after the first word if there -is no single hyphen. Since using `_all_labels' is so much more conveient +is no single hyphen. Since using `_all_labels' is so much more convenient than writing the loop with the `_next_label' function (see below), but -some function called to generate matches don't accept a single hyphen -as argument anywhere but want the options built as their last arguments, +some functions called to generate matches don't accept a single hyphen +as an argument anywhere but want the options built as their last arguments, `_all_labels' will *replace* the hyphen with the options if the hyphen is the last argument. A good example for such a function is `_combination' which can be called like: @@ -157,7 +157,7 @@ _tags friends users hosts while _tags; do - _requested friends expl friend compad alice bob && ret=0 + _requested friends expl friend compadd alice bob && ret=0 _requested users && _users && ret=0 _requested hosts && _hosts && ret=0 @@ -207,7 +207,7 @@ For the names of the tags: choose simple (short, if at all possible) names in plural. Also, first have a look at the tag names already used by other functions and if any of these names seem sensible for the -type of matches you are about to add, the use those names. This will +type of matches you are about to add, then use those names. This will allow users to define styles for certain types of matches independent of the place where they are added. @@ -233,7 +233,7 @@ Users can associate patterns for hierarchical context names with certain styles using the `zstyle' builtin. The completion code should then use these styles to decide how matches should be added and -to get user-configured values. This, too, is done using the builtin +to get user-configured values. This, too, is done using the builtin `zstyle'. Basically styles map names to a bunch of strings (the `value'). In @@ -327,7 +327,7 @@ _description tag expl <descr> compadd "$expl@]" - <matches ...> -Note that this function also accepts `-V' und `-J', optionally (in the +Note that this function also accepts `-V' and `-J', optionally (in the same word) preceded by `1' or `2' to describe the type of group you want to use. For example: @@ -373,7 +373,7 @@ change the way these things will be completed everywhere by just using their own implementations for these functions. 4) Make sure that the return value of your functions is correct: zero - if matches where added and non-zero if no matches were found. + if matches were added and non-zero if no matches were found. In some cases you'll need to test the value of `$compstate[nmatches]' for this. This should always be done by first saving the old value (`local nm="$compstate[nmatches]"') and later comparing this with @@ -397,7 +397,7 @@ documentation for `_arguments' and `_values' for two functions that may help you with this. 8) If a completion function generates completely different types of - completions (for example, because the comamnd has several + completions (for example, because the command has several completely different modes), it should allow users to define functions that separately override the behavior for these different types. This can easily be achieved by using the Index: Etc/zsh-development-guide =================================================================== RCS file: /cvsroot/zsh/zsh/Etc/zsh-development-guide,v retrieving revision 1.2 diff -u -r1.2 zsh-development-guide --- Etc/zsh-development-guide 2000/04/06 16:44:03 1.2 +++ Etc/zsh-development-guide 2000/05/01 03:40:02 @@ -73,8 +73,7 @@ tests for basic syntactic features, builtins, options etc. which you know to be flakey or to have had difficulties in the past. Better support for testing job control and interactive features is expected - to follow eventually (this may require additional external software - e.g. `expect'). + to follow eventually. * The directory is not part of the usual process of building and installation. To run the tests, go to Test and `make check'. Please @@ -146,7 +145,7 @@ The declaration itself should be all on one line (except for multi-line initialisers). -* Preprocessor directives thst affect the function/variable declarations must +* Preprocessor directives that affect the function/variable declarations must also be preceded by a "/**/" line, so that they get copied into the prototype lists. @@ -178,12 +177,13 @@ Each module is described by a file with a name ending in `.mdd' somewhere under the Src directory. This file is actually a shell script that will -sourced when zsh is build. To describe the module it can/should set the +sourced when zsh is built. To describe the module it can/should set the following shell variables: - name name of the module - moddeps modules on which this module depends (default none) - - nozshdep non-empty indicates no dependence on the `zsh/main' pseudo-module + - nozshdep non-empty indicates no dependence on the `zsh/main' + pseudo-module - alwayslink if non-empty, always link the module into the executable - autobins builtins defined by the module, for autoloading - autoinfixconds infix condition codes defined by the module, for @@ -361,7 +361,7 @@ function is non-zero if the the num'th string from the array taken as a glob pattern matches the given string. -Registering and de-resgitering condition codes with the shell is +Registering and de-registering condition codes with the shell is almost exactly the same as for builtins, using the functions `addconddefs()' and `deleteconddefs()' instead: @@ -504,7 +504,7 @@ `STRMATHFUNC' get the name of the function, the string between the parentheses at the call, and the last argument from the macro-call. -Both types of functions return an mnumber which is a descriminated +Both types of functions return an mnumber which is a discriminated union looking like: typedef struct { @@ -737,7 +737,7 @@ } Inside these wrapper functions the global variable `sfcontext' will be -set to a vlue indicating the circumstances under which the shell +set to a clue indicating the circumstances under which the shell function was called. It can have any of the following values: - SFC_DIRECT: the function was invoked directly by the user @@ -758,13 +758,13 @@ be unloaded immediately since the wrapper function is still on the call stack. The zsh code delays unloading modules until all wrappers from them have finished. To hide this from the user, the module's -cleanup function is run immediatly so that all builtins, condition +cleanup function is run immediately so that all builtins, condition codes, and wrapper function defined by the module are de-registered. But if there is some module-global state that has to be finalized (e.g. some memory that has to be freed) and that is used by the wrapper functions finalizing this data in the cleanup function won't work. -This is why ther are two functions each for the initialization and +This is why there are two functions each for the initialization and finalization of modules. The `boot'- and `cleanup'-functions are run whenever the user calls `zmodload' or `zmodload -u' and should only register or de-register the module's interface that is visible to the @@ -810,7 +810,7 @@ `item()' list structure, then the instruction `nofill(...)', which simply turns off filling should be used; as with `indent(...)', explicit font changing commands are required. This can be used - without `indent()' when no identation is required, e.g. if the + without `indent()' when no indentation is required, e.g. if the accumulated indentation would otherwise be too long. All the above should appear on their own, separated by newlines from the surrounding text. No extra newlines after the opening or before the ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Completion function directories
@ 2000-04-28 9:07 Sven Wischnowsky
0 siblings, 0 replies; 8+ messages in thread
From: Sven Wischnowsky @ 2000-04-28 9:07 UTC (permalink / raw)
To: zsh-workers
Bart Schaefer wrote:
> On Apr 27, 11:59am, Andrej Borsenkow wrote:
>
> ...
>
> > I believe, in all cases when it is
> > possible we need automatic test for GNU utilities so, that completion
> > really works "out of the box". And only when it's not possible - last
> > resort like styles for particular command.
>
> Following the same sort of suggestion as above, we'd have something like
>
> _detect_gnu () {
> (( $+_is_gnu )) || typeset -gA _is_gnu
> if (( ! $+_is_gnu[$1] ))
> then
> if [[ $(_call version "$@" </dev/null 2>/dev/null) = *GNU* ]]
> then
> _is_gnu[$1]=yes
> else
> _is_gnu[$1]=
> fi
> fi
> [[ $_is_gnu[$1] = yes ]]
> }
>
> And then _make would use
>
> if _detect_gnu $words[1] -v -f /dev/null; then
>
> and _diff_options would use
>
> if _detect_gnu $cmd -v; then
>
> and so on for any other completion functions that needed to notice GNU.
Hmhm. Does anyone see if and how we could turn this into a more
generic `_check_type' function? Something like:
local type
_check_type type $words[1] ... # args?
case $type in
GNU) ...
AIX) ...
*) ...
esac
Would that be possible withou making _check_type too expensive?
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2000-05-01 3:44 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-04-20 7:18 PATCH: completion for file descriptors Sven Wischnowsky 2000-04-20 9:19 ` Oliver Kiddle 2000-04-20 9:31 ` Thomas Köhler 2000-04-24 5:23 ` Completion function directories Bart Schaefer 2000-04-27 7:59 ` Andrej Borsenkow 2000-04-27 22:09 ` Bart Schaefer 2000-05-01 2:43 ` PATCH: Spelling corrections in Etc/ files Oliver Kiddle 2000-04-28 9:07 Completion function directories Sven Wischnowsky
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).