Re: [PATCH] TYPESET_TO_UNSET + misc.

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote on Tue, Apr 20, 2021 at 17:06:10 -0700:
> On Tue, Apr 20, 2021 at 3:01 PM Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> >
> > The typesettounset branch is also relevant; it has been merged into
> > declarednull.
> 
> Yes, but I committed to master branch by applying the patch, not by
> git wrangling.

Sure, but that pointer to that branch might still be useful to future
archaeologists, who'll find this thread by following the X-Seq in the
logs.

> > Worth an entry in NEWS?
> 
> Probably.  Pardon any gmail line wrapping below.
> 
> Is it worth attempting to explain that
> 
>   setopt no_typesettounset
>   source =(
>     setopt typesettounset
>     typeset something
>     typeset -p something
>   )
> 
> does NOT re-create "something" as an unset variable?

I suppose this is somewhat implied by the fact that there's no «typeset»
syntax to create an unset variable when no_typesettounset is in effect?

> diff --git a/NEWS b/NEWS
> index cf270ff51..ee97868f9 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -35,6 +35,12 @@ widgets.  This corresponds to long-standing
> behavior of other user ZLE
>  widgets.  Use the _complete_debug widget to capture XTRACE output, or
>  use "functions -T" to enable tracing of specific completion functions.
> 
> +With the new TYPESET_TO_UNSET option set, "typeset foo" leaves foo unset,
> +in contrast to the default behavior which assigns foo="".  Any parameter
> +attributes such as numeric type, sorting, and padding are retained until
> +the parameter is explicitly unset or a conflicting value is assigned.
> +This is similar to default behavior of bash and ksh.
> +
>  Changes from 5.7.1-test-3 to 5.8
>  --------------------------------
>