Announce of Zsh Navigation Tools

Announce of Zsh Navigation Tools

[Sebastian Gniazdowski]

[-- Attachment #1: Type: text/plain, Size: 1883 bytes --]

Hello,
I would like to announce Zsh Navigation Tools, a set of utilities based on
the tool's main component – n-list, a zcurses based selection list
supporting ANSI coloring and incremental search. The utilities are:

- n-aliases - browses aliases, relegates editing to vared
- n-cd - browses dirstack and bookmarked directories, allows to enter
selected directory
- n-env - browses environment, relegates editing to vared
- n-functions - browses functions, relegates editing to zed or vared
- n-history - browses history, allows to edit and run commands from it
- n-kill - browses processes list, allows to send signal to selected process
- n-options - browses options, allows to toggle their state
- n-panelize - loads output of given command into the list for browsing
- n-preview - a demonstration of running two lists at the same time and of
ANSI colors - syntax highlighted source browser

On GitHub page there is a link to video:

https://github.com/psprint/zsh-navigation-tools

The main idea behind the tools is that it is good to have navigation as
option side to completion.

Features not yet mentioned:
- initial grepping of what is browsed with "$1" given to utility
- making lists with non-selectable elements (to e.g. include headers in the
list)
- counting of how much elements there are (even when there are headers)
- jumping over predefined positions in the list with '[', ']' keys (used to
jump to bookmarks in 'n-cd' and through signals in 'n-kill')
- rich keys close to those of 'less' (like g, G, ctrl-u, ctrl-d, ctrl-p,
ctrl-n, /, j, k, home, end, etc.)

The code uses curses and regex modules. It is clean thanks to Zsh's rich
available math syntax when variable is declared as integer. N-preview will
show colored syntax if there is program "highlight" installed on the system.

Best regards,
Sebastian Gniazdowski

Re: Announce of Zsh Navigation Tools

[Ray Andrews]

On 09/08/2015 05:32 AM, Sebastian Gniazdowski wrote:
> Hello,
> I would like to announce Zsh Navigation Tools,
...

Thanks for those Sebastian, I'm playing with them now, several look very 
useful.  One thing, I had to create 
'/usr/local/share/zsh/site-functions'.  I wonder if there is a location 
for the files that is in keeping with my directory structure.  A trivial 
point: in the files, you call them 'functions' whereas they are scrips, 
I believe.  However, I'm tempted to convert them to functions anyway.

Re: Announce of Zsh Navigation Tools

[ZyX]

12.09.2015, 21:21, "Ray Andrews" <rayandrews@eastlink.ca>:
> On 09/08/2015 05:32 AM, Sebastian Gniazdowski wrote:
>>  Hello,
>>  I would like to announce Zsh Navigation Tools,
>
> ...
>
> Thanks for those Sebastian, I'm playing with them now, several look very
> useful. One thing, I had to create
> '/usr/local/share/zsh/site-functions'. I wonder if there is a location
> for the files that is in keeping with my directory structure. A trivial
> point: in the files, you call them 'functions' whereas they are scrips,
> I believe. However, I'm tempted to convert them to functions anyway.

They will work if located in *any* directory listed in $fpath. And they *are* functions, you need to read about autoload functions in man zshmisc, section AUTOLOADING FUNCTIONS:

       If  the  KSH_AUTOLOAD option is set, or the file contains only a simple definition of the function, the file's contents will be executed.  This will normally define the function in question, but may also per‐
       form initialization, which is executed in the context of the function execution, and may therefore define local parameters.  It is an error if the function is not defined by loading the file.

       Otherwise, the function body (with no surrounding `funcname() {...}') is taken to be the complete contents of the file.  This form allows the file to be used directly as an executable shell script.   If  pro‐
       cessing  of the file results in the function being re-defined, the function itself is not re-executed.  To force the shell to perform initialization and then call the function defined, the file should contain
       initialization code (which will be executed then discarded) in addition to a complete function definition (which will be retained for subsequent calls to the function), and  a  call  to  the  shell  function,
       including any arguments, at the end.

Re: Announce of Zsh Navigation Tools

[Ray Andrews]

On 09/12/2015 12:41 PM, ZyX wrote:
> They will work if located in *any* directory listed in $fpath. And they *are* functions, you need to read about autoload functions in man zshmisc, section AUTOLOADING FUNCTIONS:

I see.  So we very elegantly have it both ways--a script as it appears 
to be, but also as a function via autoload.
>
>         If  the  KSH_AUTOLOAD option is set, or the file contains only a simple definition of the function, the file's contents will be executed.  This will normally define the function in question, but may also per‐
>         form initialization, which is executed in the context of the function execution, and may therefore define local parameters.  It is an error if the function is not defined by loading the file.
>
>         Otherwise, the function body (with no surrounding `funcname() {...}') is taken to be the complete contents of the file.  This form allows the file to be used directly as an executable shell script.   If  pro‐
>         cessing  of the file results in the function being re-defined, the function itself is not re-executed.  To force the shell to perform initialization and then call the function defined, the file should contain
>         initialization code (which will be executed then discarded) in addition to a complete function definition (which will be retained for subsequent calls to the function), and  a  call  to  the  shell  function,
>         including any arguments, at the end.
That clarifies things greatly.  I've had a vague wondering what autoload 
was, just took it on faith that it was important.  What are the pros and 
cons of doing things that way vs. what might seem to be the more obvious 
function definition?  It's more compact, but then requires the special 
calling via autoload.  I expect there will be some substantial difference.

>

Re: Announce of Zsh Navigation Tools

[Bart Schaefer]

On Sep 12,  2:03pm, Ray Andrews wrote:
}
} What are the pros and cons of doing things that way vs. what might
} seem to be the more obvious function definition? It's more compact,
} but then requires the special calling via autoload. I expect there
} will be some substantial difference.

There isn't (intended to be) any execution-time difference.  If you
can find one, it's probably a bug, except for the variations that
are implied by (misapplication of) the -z / -k options of autoload.

The main benefit is that you don't have loaded into memory those
functions that you don't use. The not-yet-loaded form of an autoloaded
function is very small.  You also avoid a lot of the startup time of
parsing all those files.  E.g., the completion system is now nearly
10MB; why read all of that when most of it may never be used?

I suppose, conversely, the drawback is that there may be a delay for
parsing, the first time any such function is executed.

Another drawback is that you can't easily switch among different
emulation modes without taking special precautions, because the parse
will always be applied using the mode at the time of first execution
rather than the mode when the autoload command was issued.  We could
probably stand an autoload option to apply "sticky emulation."

Re: Announce of Zsh Navigation Tools

[Ray Andrews]

On 09/12/2015 03:10 PM, Bart Schaefer wrote:
> On Sep 12,  2:03pm, Ray Andrews wrote:
> }
> } What are the pros and cons of doing things that way vs. what might
> } seem to be the more obvious function definition? It's more compact,
> } but then requires the special calling via autoload. I expect there
> } will be some substantial difference.
>
> There isn't (intended to be) any execution-time difference.  If you
> can find one, it's probably a bug, except for the variations that
> are implied by (misapplication of) the -z / -k options of autoload.
>
> The main benefit is that you don't have loaded into memory those
> functions that you don't use. The not-yet-loaded form of an autoloaded
> function is very small.  You also avoid a lot of the startup time of
> parsing all those files.  E.g., the completion system is now nearly
> 10MB; why read all of that when most of it may never be used?
>
> I suppose, conversely, the drawback is that there may be a delay for
> parsing, the first time any such function is executed.
>
> Another drawback is that you can't easily switch among different
> emulation modes without taking special precautions, because the parse
> will always be applied using the mode at the time of first execution
> rather than the mode when the autoload command was issued.  We could
> probably stand an autoload option to apply "sticky emulation."
>
Ah ...

I load my own functions thusly:

     for aa in /aWorking/Zsh/Source/*;  do source $aa; done

... but as I understand you, autoload only 'really' loads things when 
they are actually called, so that has to be more efficient.  That 
immediately makes me want do something like this:

     for aa in /aWorking/Zsh/Source/*; do autoload $aa; done

... remembering of course that things need to be rewritten to look like 
scripts.  As to emulation, that's still way over my head.

BTW, looking at $fpath, it sure is laborious.  Do we, could wehave some 
sort of automatic subdirectory inclusion? Sorta: 
/usr/share/zsh/functions/**/  ... or something like that?

Re: Announce of Zsh Navigation Tools

[Bart Schaefer]

On Sep 12,  4:03pm, Ray Andrews wrote:
}
} immediately makes me want do something like this:
} 
}      for aa in /aWorking/Zsh/Source/*; do autoload $aa; done
} 
} ... remembering of course that things need to be rewritten to look like 
} scripts.

As long as there is only one function per file, you don't need to rewrite
them, just use

   ...; do autoload -k $aa; done

The "ksh-style" of autoloading is to have one complete function definition
in each file, including the "() { ... }" or "function { ... }" or whatever
wrapping syntax.

(Ksh does it this way because the syntax used to declare the function has
an effect on its semantics.)
 
} BTW, looking at $fpath, it sure is laborious.  Do we, could we have some 
} sort of automatic subdirectory inclusion?

I'm not sure what you mean by this, that is, are you trying to build up
the value of $fpath or are you trying to find all the files in $fpath
to autoload them?

If you're running an installed zsh, of course, then $fpath should have
all the necessary directories already (except e.g. personal ones in your
home dir).

If you're asking about constructing $fpath for a zsh build tree, then it
should suffice to do:

    fpath=( $build_dir/Completion/**/*(/) $build_dir/Functions/**/*(/)
            $fpath )

where you will need to define $build_dir appropriately, maybe it is $PWD.
Just be careful that you get the order right with respect to the default
$fpath -- the default should come FIRST if you are running an installed
shell.

If you're asking about autoloading everything after $fpath has been
defined, then this should work for the default paths:

    autoload $^fpath/*(N-.:t)

However, as I said you may want to add -k for your personal files, which
would need a second autoload command.

Some people also prefer to throw a (*) into the glob flags so as to only
autoload files that have been marked executable.

Putting this together, something like:

build_fpath=( $build_dir/Completion/**/*(/) $build_dir/Functions/**/*(/) )
my_fpath=( ~/zsh_functions/**/*(/) and so on )

autoload $^fpath/*(N-.:t)
autoload $^build_fpath/*(N-.:t)
autoload $^my_fpath/*(N-.:t)
fpath=( $my_fpath $build_fpath $fpath )

-- 
Barton E. Schaefer

Re: Announce of Zsh Navigation Tools

[Bart Schaefer]

On Sep 12,  4:43pm, Bart Schaefer wrote:
}
} build_fpath=( $build_dir/Completion/**/*(/) $build_dir/Functions/**/*(/) )
} my_fpath=( ~/zsh_functions/**/*(/) and so on )
} 
} autoload $^fpath/*(N-.:t)
} autoload $^build_fpath/*(N-.:t)
} autoload $^my_fpath/*(N-.:t)

I meant that to say

autoload -k $^my_fpath/*(N-.:t)

} fpath=( $my_fpath $build_fpath $fpath )

Re: Announce of Zsh Navigation Tools

[Ray Andrews]

On 09/12/2015 04:43 PM, Bart Schaefer wrote:
> On Sep 12,  4:03pm, Ray Andrews wrote:
> }
> } immediately makes me want do something like this:
> }
> }      for aa in /aWorking/Zsh/Source/*; do autoload $aa; done
> }
> } ... remembering of course that things need to be rewritten to look like
> } scripts.
>
> As long as there is only one function per file, you don't need to rewrite
> them, just use
>
>     ...; do autoload -k $aa; done

Shucks, I can do it in a for loop then?  Thought that would be too 
easy.  Nuts, that's down right friendly.  zsh seems less sadistic all 
the time ;-)
>   
> } BTW, looking at $fpath, it sure is laborious.  Do we, could we have some
> } sort of automatic subdirectory inclusion?
>
> I'm not sure what you mean by this, that is, are you trying to build up
> the value of $fpath or are you trying to find all the files in $fpath
> to autoload them?
>
I mean just ...


/usr/local/share/zsh/site-functions
/usr/share/zsh/vendor-functions
/usr/share/zsh/vendor-completions
/usr/share/zsh/functions/Calendar
/usr/share/zsh/functions/Chpwd
/usr/share/zsh/functions/Completion
/usr/share/zsh/functions/Completion/AIX
/usr/share/zsh/functions/Completion/BSD
/usr/share/zsh/functions/Completion/Base
/usr/share/zsh/functions/Completion/Cygwin
/usr/share/zsh/functions/Completion/Darwin
/usr/share/zsh/functions/Completion/Debian
/usr/share/zsh/functions/Completion/Linux
/usr/share/zsh/functions/Completion/Mandriva
/usr/share/zsh/functions/Completion/Redhat
/usr/share/zsh/functions/Completion/Solaris
/usr/share/zsh/functions/Completion/Unix
/usr/share/zsh/functions/Completion/X
/usr/share/zsh/functions/Completion/Zsh
/usr/share/zsh/functions/Completion/openSUSE
/usr/share/zsh/functions/Exceptions
/usr/share/zsh/functions/MIME
/usr/share/zsh/functions/Misc
/usr/share/zsh/functions/Newuser
/usr/share/zsh/functions/Prompts
/usr/share/zsh/functions/TCP
/usr/share/zsh/functions/VCS_Info
/usr/share/zsh/functions/VCS_Info/Backends
/usr/share/zsh/functions/Zftp
/usr/share/zsh/functions/Zle

... one might imagine some shorthand '/usr/share/zsh/functions/**/' 
meaning  to include all those subdirs in $fpath automatically without 
needing to write each one out literally thus fpath would look like:

/usr/local/share/zsh/site-functions
/usr/share/zsh/vendor-functions
/usr/share/zsh/vendor-completions
/usr/share/zsh/functions/**/

... because all the subdirs of /usr/share/zsh/functions would thus be 
included automatically.  I'm just trying to get some mileage out of the 
std. recursive '**' idea as used in globbing already:

     $ ls ./**/

... why not use it in variables too?

even:

/usr/local/share/zsh/site-functions
/usr/share/zsh/vendor*
/usr/share/zsh/functions/**/

... it's a bit easier on the eye.

Re: Announce of Zsh Navigation Tools

[Bart Schaefer]

On Sat, Sep 12, 2015 at 5:41 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:
> I mean just ...
>
> /usr/local/share/zsh/site-functions
> /usr/share/zsh/vendor-functions
> /usr/share/zsh/vendor-completions
> /usr/share/zsh/functions/Calendar
> /usr/share/zsh/functions/Chpwd
> /usr/share/zsh/functions/Completion
(etc.)

This is a result of a "configure"-time option set by whoever built the
zsh package for your software package manager.  For me, it's:

zsh -fc 'print $ZSH_VERSION $fpath'
5.1.1 /usr/local/share/zsh/site-functions /usr/local/share/zsh/5.1.1/functions

> ... one might imagine some shorthand '/usr/share/zsh/functions/**/'

One might, but then the handling of $fpath would be inconsistent with
$path, $module_path, $manpath, etc.; and more importantly, the order
of entries in the array is signficant in case the same file name (with
different implementation) appears in more than one directory.

> ... it's a bit easier on the eye.

You're not really ever intended to need to read that list once you've
assigned it.

Re: Announce of Zsh Navigation Tools

[Ray Andrews]

On 09/12/2015 07:36 PM, Bart Schaefer wrote:
>
> ... one might imagine some shorthand '/usr/share/zsh/functions/**/'
> One might, but then the handling of $fpath would be inconsistent with
> $path, $module_path, $manpath, etc.; and more importantly, the order
> of entries in the array is signficant in case the same file name (with
> different implementation) appears in more than one directory.
>
Quite so.  However tiresome it is to read the variable, I can see that a 
precise order would need to be defined. I had thought that the above 
idea would apply to any variable that references files and directories 
but I see that that wouldn't be a good idea.  A bad idea demolished is a 
particularly effective lesson.  I learned quite a bit today.

Re: autoload

[Ray Andrews]

On 09/12/2015 04:43 PM, Bart Schaefer wrote:

Bart:

Tightening up my understanding of this a bit ...

>      autoload $^fpath/*(N-.:t)
... works fine, but what does the caret do?  Negation is counterintuitive.
Also I think I recognize the '(N-.:t)' as a globbing modifier, and I 
know the '.' and
the ':t' but I can't find any info on the 'N-' -- I don't know what 
phylum of animal it is
so as to research it.


    autoload /usr/local/share/zsh/site-functions/n-*(N-.:t)

... also works and is more literal.  Interesting that autoload must have 
the
path stripped off for it.  Why wouldn't it know to do that automatically?

Re: autoload

[Bart Schaefer]

On Sep 13,  7:14pm, Ray Andrews wrote:
}
} Tightening up my understanding of this a bit ...
} 
} >      autoload $^fpath/*(N-.:t)
} ... works fine, but what does the caret do?

Would it make more sense written like ${^fpath} ?  It's the operator
that causes an array (a b c) to expand to e.g. a/* b/* c/* instead of
to a b c/* -- cf. the rc_expand_param setopt.

} Also I think I recognize the '(N-.:t)' as a globbing modifier, and I 
} know the '.' and
} the ':t' but I can't find any info on the 'N-'

(N) means nonomatch, so empty directories disappear from the result
instead of causing a globbing error.  (-) is follow symlinks, so that
combined with (N) any dangling symlinks also disappear.  These both are
documented in the "Glob Qualifiers" subsection of the manual.

}     autoload /usr/local/share/zsh/site-functions/n-*(N-.:t)

Well, yes, but that only autoloads Sebastian's navigation functions
(and any others whose names happen to start with "n-").

} Interesting that autoload must have the
} path stripped off for it.  Why wouldn't it know to do that automatically?

You don't autoload from a location, you autoload a name and the fpath
is searched for it.  It would be misleading for autoload to discard
a directory which is passed to it in favor of one that appears earlier
in the fpath array, so you have to explicitly do so if that's what you
intend.

(zcompile on the other hand DOES load from locations rather than from
a path search, so if you use zcompile + autoload -w you get the path
stripping.)

Re: autoload

[Ray Andrews]

On 09/13/2015 07:38 PM, Bart Schaefer wrote:
> Would it make more sense written like ${^fpath} ?  It's the operator
> that causes an array (a b c) to expand to e.g. a/* b/* c/* instead of
> to a b c/* -- cf. the rc_expand_param setopt.
Yikes, that's brand new to me, I only know the caret as negation. So 
this is a feature
specific--it seems--to getting useful path expansion.  Just echoing some 
dirs, I get the
point loud and clear. That's powerful.
> (N) means nonomatch, so empty directories disappear from the result
> instead of causing a globbing error.  (-) is follow symlinks, so that
> combined with (N) any dangling symlinks also disappear.  These both are
> documented in the "Glob Qualifiers" subsection of the manual.

Nuts, I scanned that page top to bottom looking at random, and there it 
is near the
very bottom. 'NULL_GLOB' it says.  Thanks for the explanation.
> Well, yes, but that only autoloads Sebastian's navigation functions
> (and any others whose names happen to start with "n-").

Of course, I'm just experimenting for now.  Getting the feel ...
> You don't autoload from a location, you autoload a name and the fpath
> is searched for it.
Ah! ... I'm subconsciously thinking in terms of finding commands. No!

    autoload /usr/local/share/zsh/site-functions/n-*(N-.:t)


... is a kind of trick--we are grabbing the names of files and using 
them as the names of
functions to be found later, but we are NOT actually passing 
definitions.  Yes?

     autoload n-list n-cd n-env n-kill n-panelize n-options n-aliases 
n-functions n-history n-preview

... is actually more 'honest' since all autoload really knows at that 
point is names.  Definitions
will be retrieved later. Yes?

> (zcompile on the other hand DOES load from locations rather than from
> a path search, so if you use zcompile + autoload -w you get the path
> stripping.)
>
Sounds like a good idea, would that not be preferable?  Why not prime 
the pump with both the name and the location?  I'm over my head of 
course, but it seems that the '(...(N-.:t)' style command could notify 
autoload of both name and location in one go thus obviating the need to 
rummage through $fpath.  As always, if that's not done there will be a 
good reason.

Re: autoload

[Bart Schaefer]

On Sep 13,  8:34pm, Ray Andrews wrote:
} Subject: Re: autoload
}
} On 09/13/2015 07:38 PM, Bart Schaefer wrote:
} > Would it make more sense written like ${^fpath} ?  It's the operator
} > that causes an array (a b c) to expand to e.g. a/* b/* c/* instead of
} > to a b c/* -- cf. the rc_expand_param setopt.
} Yikes, that's brand new to me, I only know the caret as negation. So 
} this is a feature
} specific--it seems--to getting useful path expansion.

No; it happens to involve path expansion in the specific example of
appending /* to every element of $fpath, but that's not really what
it means.  The second paragraph of the doc is useful:

${^SPEC}
     Turn on the RC_EXPAND_PARAM option for the evaluation of SPEC; if
     the `^' is doubled, turn it off.  When this option is set, array
     expansions of the form FOO${XX}BAR, where the parameter XX is set
     to (A B C), are substituted with `FOOABAR FOOBBAR FOOCBAR' instead
     of the default `FOOA B CBAR'.  Note that an empty array will
     therefore cause all arguments to be removed.

     Internally, each such expansion is converted into the equivalent
     list for brace expansion.  E.g., ${^var} becomes
     {$var[1],$var[2],...}, and is processed as described in *Note
     Brace Expansion:: below.  If word splitting is also in effect the
     $var[N] may themselves be split into different list elements.

} > (N) means nonomatch, so empty directories disappear from the result
} > instead of causing a globbing error.  (-) is follow symlinks, so that
} > combined with (N) any dangling symlinks also disappear.  These both are
} > documented in the "Glob Qualifiers" subsection of the manual.
} 
} Nuts, I scanned that page top to bottom looking at random, and there
} it is near the very bottom. 'NULL_GLOB' it says. Thanks for the
} explanation.

Yeah, I thinko nonomatch for nullglob periodically, don't know why.

}      autoload n-list n-cd n-env n-kill n-panelize n-options n-aliases 
} n-functions n-history n-preview
} 
} ... is actually more 'honest' since all autoload really knows at that 
} point is names.  Definitions will be retrieved later. Yes?

Yes.

} > (zcompile on the other hand DOES load from locations rather than from
} > a path search, so if you use zcompile + autoload -w you get the path
} > stripping.)
} >
} Sounds like a good idea, would that not be preferable?  Why not prime 
} the pump with both the name and the location?

Compatibility with the implementation chosen by other shells that had
autoloading earlier, mainly.  Less importantly, for .zshrc portability,
so you can autoload things without having to find them yourself in the
fpath first.  The inverse -- wanting to autoload a bunch of things
you know are in the fpath without knowing their function names -- was
not really contemplated as a common case when the command was invented.

Re: autoload

[Ray Andrews]

On 09/14/2015 01:21 PM, Bart Schaefer wrote:
> No; it happens to involve path expansion in the specific example of
> appending /* to every element of $fpath, but that's not really what
> it means.  The second paragraph of the doc is useful:
>
> ${^SPEC}
>       Turn on the RC_EXPAND_PARAM option for the evaluation of SPEC; if
>       the `^' is doubled, turn it off.  When this option is set, array
>       expansions of the form FOO${XX}BAR, where the parameter XX is set
>       to (A B C), are substituted with `FOOABAR FOOBBAR FOOCBAR' instead
>       of the default `FOOA B CBAR'.  Note that an empty array will
>       therefore cause all arguments to be removed.
Ok ... useful for path expansion but not specific to it.  It comes back 
to me that this RC_EXPAND_PARAM sounded great but had a gotcha attached 
to it.  But if the caret
turns it on for one particular expansion then that's very satisfactory.
> } > (zcompile on the other hand DOES load from locations rather than from
> } > a path search, so if you use zcompile + autoload -w you get the path
> } > stripping.)
> } >
>
One more thing if you would Bart: get me started with combining zcompile 
with autoload as you mentioned.  It sounds like a good idea but I can't 
find anything on it.  I know what zcompile is, but it makes so little 
difference in loading speed that I've not really bothered with it.  But 
if it works synergistically with autoload that might be interesting to 
play with.

Re: autoload

[Bart Schaefer]

On Sep 14,  7:48pm, Ray Andrews wrote:
}
} One more thing if you would Bart: get me started with combining zcompile 
} with autoload as you mentioned.  It sounds like a good idea but I can't 
} find anything on it.

I wrote about this in workers/36529 -- but I see that Sebastian had
redirected that thread from zsh-users to zsh-workers, so perhaps it
wasn't seen.  I'll reproduce here (so workers readers can stop now).


Take a look at the "zcompile" builtin and the "zrecompile" utility.
If you zcompile a collection of functions into a .zwc file, you can --

-- add the .zwc file name directly to $fpath and it will be searched
   like a directory at autoloaded-function execution time

-- specify the -z / -k behavior options at zcompile time so they don't
   have to be passed to autoload

-- easily autoload everything in the file:   autoload -w functions.zwc

ZWC files are machine-independent but zsh-version-dependent.  They get
memory-mapped when that's supported so the OS pages them efficiently.
The drawbacks are the version dependency if you frequently rebuild a
bleeding-edge shell (but see zrecompile) and that zcompile doesn't yet
support "sticky emulation" in any meaningful way.  Also, a ZWC file is
not like an archive file (e.g., a ZIP); you can't append or remove
individual functions, the whole file has to be rebuilt.

Finally, for Ray, you can for example replace your entire $fpath with
a single ZWC file:

    # Assume starting here with the default $fpath
    zsh_default_functions=~/.zsh-default-functions.zwc
    if ! zcompile -t $zsh_default_functions >&/dev/null
    then
      # File is missing or out of date.  Rebuild it.
      # Removes the file if any function cannot be compiled.
      zcompile $zsh_default_functions $^fpath/*(N.:A)
    fi
    if [[ -f $zsh_default_functions ]]
    then
      fpath=( $zsh_default_functions )
      autoload -w $zsh_default_functions
    fi

Re: autoload

[Ray Andrews]

On 09/14/2015 08:48 PM, Bart Schaefer wrote:
> On Sep 14,  7:48pm, Ray Andrews wrote:
> }
> } One more thing if you would Bart: get me started with combining zcompile
> } with autoload as you mentioned.  It sounds like a good idea but I can't
> } find anything on it.
Thanks, I'll throw myself at it.  This sounds like very satisfying stuff 
for philosophical
reasons--I prefer directness over convenience most of the time and an 
explicit
statement of where functions actually are turns my crank.  That's the 
reason I liked:

    autoload /usr/local/share/zsh/site-functions/n-*(N-.:t)

... because it's explicit.  Alas it turns out to be disharmonious with 
the nature of the
thing, like teaching a cat to fetch.


> Finally, for Ray, you can for example replace your entire $fpath with
> a single ZWC file:

Marvelous:

6 HP-w5--5-Debian1 /aWorking/Zsh 2$ echo $fpath
/usr/local/share/zsh/site-functions /usr/share/zsh/vendor-functions 
/usr/share/zsh/vendor-completions /usr/share/zsh/functions/Calendar 
/usr/share/zsh/functions/Chpwd /usr/share/zsh/functions/Completion 
/usr/share/zsh/functions/Completion/AIX 
/usr/share/zsh/functions/Completion/BSD 
/usr/share/zsh/functions/Completion/Base 
/usr/share/zsh/functions/Completion/Cygwin 
/usr/share/zsh/functions/Completion/Darwin 
/usr/share/zsh/functions/Completion/Debian 
/usr/share/zsh/functions/Completion/Linux 
/usr/share/zsh/functions/Completion/Mandriva 
/usr/share/zsh/functions/Completion/Redhat 
/usr/share/zsh/functions/Completion/Solaris 
/usr/share/zsh/functions/Completion/Unix 
/usr/share/zsh/functions/Completion/X 
/usr/share/zsh/functions/Completion/Zsh 
/usr/share/zsh/functions/Completion/openSUSE 
/usr/share/zsh/functions/Exceptions /usr/share/zsh/functions/MIME 
/usr/share/zsh/functions/Misc /usr/share/zsh/functions/Newuser 
/usr/share/zsh/functions/Prompts /usr/share/zsh/functions/TCP 
/usr/share/zsh/functions/VCS_Info 
/usr/share/zsh/functions/VCS_Info/Backends /usr/share/zsh/functions/Zftp 
/usr/share/zsh/functions/Zle

... is deeply disturbing on principal, I don't want my shell searching 
the world for my functions, I want it to *know* where they are and 
$fpath is a study in obfuscation.  It is information that subtracts from 
knowledge.

>
>      # Assume starting here with the default $fpath
>      zsh_default_functions=~/.zsh-default-functions.zwc
>      if ! zcompile -t $zsh_default_functions >&/dev/null
>      then
>        # File is missing or out of date.  Rebuild it.
>        # Removes the file if any function cannot be compiled.
>        zcompile $zsh_default_functions $^fpath/*(N.:A)
>      fi
>      if [[ -f $zsh_default_functions ]]
>      then
>        fpath=( $zsh_default_functions )
>        autoload -w $zsh_default_functions
>      fi
>
>
Deep magic ...
Arigato sensei

Re: autoload

[Ray Andrews]

Some first adventures with Bart's method.  Proof of concept only, no 
checking yet.

The kosher method in .zshrc:

#autoload -U compinit && compinit -d $ZSHBOOT/zcompdump
#autoload -U colors && colors
#autoload -U select-word-style && select-word-style shell

... gives:

     $ time zsh -i -c exit  0.14s user 0.06s system 98% cpu 0.211 total

... now this, after having moved all asked for files into my private 
ZSHBOOT dir
and cooked them up with zcompile:

fpath=$ZSHBOOT
autoload -w $ZSHBOOT/zsh-boot.zwc
compinit -d $ZSHBOOT/zcompdump
colors
select-word-style shell

... my thinking being that functions which are certain to be called are 
a good place to
start experimenting.

... gives:

     $ time zsh -i -c exit  0.05s user 0.06s system 97% cpu 0.111 total

... so with just those three autoloads it's twice as fast, saving a 
whopping 1/10th of
a second.  All of it in the 'user' category, I don't know if that's 
significant.  Most
interesting anyway, and so far it seems to work, tho I'd not be 
astonished to hear
that I've broken something.  It might be DOSthink, but I like having 
everything I need to
fire up my zsh in one place thusly:

3 HP-w5--5-Debian1 /aWorking/Zsh/Boot 3$ l

Sorting All file types Backwards by Modification Time ():

drwxr-xr-x 2   4096 2015-09-11_12:03:21 Backup/
-rw-r--r-- 1   2934 2014-12-02_20:26:53 zbindkey
-rw-r--r-- 1   1371 2015-09-13_15:55:51 aliases
-rw-r--r-- 1   2375 2015-09-14_08:27:29 zstyle
-rw-r--r-- 1  11403 2015-09-15_19:51:07 zmv
-rw-r--r-- 1   2230 2015-09-15_19:51:07 select-word-style
-rw-r--r-- 1  16435 2015-09-15_19:51:07 compinit
-rw-r--r-- 1   3417 2015-09-15_19:51:07 colors
-rw-r--r-- 1   5667 2015-09-15_20:25:25 compaudit
-rw-r--r-- 1   4015 2015-09-15_20:25:25 compdump
-r--r--r-- 1  57984 2015-09-15_20:25:50 zsh-boot.zwc
-rw-r--r-- 1    484 2015-09-15_20:26:11 zcompdump
-rw-r--r-- 1   5464 2015-09-15_20:43:10 zshrc
-rw-r--r-- 1    878 2015-09-15_20:55:39 dirstack
-rw------- 1 441938 2015-09-15_20:55:41 histfile

... of course there's more needed stuff as well no doubt, but this at 
least gives me
a bit of focus, and fpath is a single directory :-)