${(t!)nameref}; ${(t)${nested}}; Doc/zshall.1

["Daniel Shahaf" <d.s@xxxxxxxxxxxxxxxxxx>]

Several different issues, sorry.


A. Normally, ${(t)foo} == ${parameters[foo]}; for instance:

    % print -rl ${(t)parameters} ${parameters[parameters]}
    association-readonly-hide-hideval-special
    association-readonly-hide-hideval-special

however, with namerefs that doesn't hold:

    $ zsh -f
    % nameref nr=foo
    % foo=42
    % print -rl ${(t)nr} ${parameters[nr]} 
    scalar
    nameref-scalar

Not even with (!):

    % echo ${(t\!)nr} 
    nameref

Should ${(t!)foo} expand to "nameref-scalar" whenever ${parameters[foo]} does?

I.e., currently, namerefs are an exception to the rule that ${(t)foo} ==
${parameters[foo]}.  This exception is actually documented this way
under ${parameters} [Doc/Zsh/mod_parameters.yo:119].  Instead of having
a rule and an exception to the rule, we could make the rule that
${(t!)foo} == ${parameters[foo]} without exceptions.  (Assuming
zsh/parameter is loaded)


B. The documentation of ${(!)} [in Doc/Zsh/expn.yo:977] might want to
point out that in interactive use, the `tt(!)' has to be backslash-escaped
to prevent history expansion.

Tangentially, it's not particularly elegant to have a /de facto/ different
syntax for interactive use and for scripts, but I'm sure this has been
discussed at some point, so I'll say no more about it.


C. Here, a ${(t)…} expression expands to something not (t)-ey at all:

    % echo ${(t)${PATH}}
    /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

It would be reasonable for it to expand to the type of the nested
expansion (which might be either scalar or array).


D. While testing that, I also noticed that the inner braces are required:

    % echo ${(t)$PATH}
    zsh: bad substitution

That's the same thing as the previous example except for the inner
braces, so I had expected the two to be synonymous.


E. zshall.1 sources the other man pages by using the roff(7) directive
".so man1/zshexpn.1" [Doc/zsh.yo:73].  That works fine when
installed, but when one does «man Doc/zshall.1» in the build tree, those
directives pull in the /installed/ zshexpn(1) man page.

Mikael points out that «ln -s Doc man1» is a workaround.

Now, it would have been nice if we could change that directive to have
zshall.1's source say the moral equivalent of "source ${0:h}/zshexpn.1",
but unless there's a portable roff(7) syntax for that, I think having
the build system create that symlink would actually be a good idea,
since it'd make «man Doc/zshall.1» work as expected in the build tree,
rather than silently let the installed man pages follow the just-built
leading section.

This wouldn't affect the installed tree in any way.


Finally, thanks to Mikael on IRC for the good suggestions written up
above.  I'll take the blame for the lesser ones :-)


Cheers,

Daniel
(probably best to refer to each of this issues by "${X_seq}${letter}",
e.g., workers/42A)