Re: PM_TAGGED and PM_TAGGED_LOCAL being set simultaneously (functions -T -t f)

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Peter Stephenson wrote on Thu, Apr 15, 2021 at 19:38:28 +0100:
> On Thu, 2021-04-15 at 16:21 +0000, Daniel Shahaf wrote:
> > > > f() g
> > > > g() :
> > > > functions -T f
> > > > functions -t f
> > > > f
> > > > 
> > > > Should XTRACE be on or off when g is run?  Or should an error be raised
> > > > before g is called?
> > > > 
> > > > And if -t were set first and -T second?
> > > 
> > > The way the documentation is written:
> > > 
> > >   The flag -t turns on execution tracing for  this  function;
> > >   the  flag -T does the same, but turns off tracing for any named (not
> > >   anonymous) function called from the present one, unless  that  func‐
> > >   tion  also  has  the  -t  or -T flag.
> > > 
> > > makes it sound as if turning off for called functions is more
> > > powerful behaviour, in which case -T should always be used if
> > > specified.  But it doesn't actually *say* that and could be
> > > rewritten anyway, so it's not much of a steer.  Having one flag
> > > cause another to be ignored is pretty standard behaviour and
> > > relatively straightforward to implement, though.
> > 
> > So, to be clear, you're proposing that setting either flag should unset
> > the other?  Sounds good to me; just making sure we're on the same page.
> 
> Actually, the suggestion was even simpler --- leave them both set, but
> just allow the -T behaviour to be used if both are set.  I think this is
> how it's currently implemented, so it would just mean updating the
> documentation.

Yes, that's how it's currently implemented.

> However, actually unsetting the other one is entirely rational, too.
> Which is least surprising depends how you think of the options: whether you
> think of the option settings as strict alternatives, or you think of
> them as two separate options that happen to have an overlapping function
> of which you have to pick one.  So I can't really express a preference,
> except to say if there's no good reason to change we should just
> document what we have.

Personally, I think it's actually easier to sell the "last one wins"
semantics: there's no logical reason why the behaviour of «functions -Tt
foo» should depend on which of -T/-t was implemented in a later version
of zsh, but every reason for the behaviour to depend on whether the call
passed -Tt or -tT.

That would, however, be an incompatible change ☹

I figured I'd write a test to at least ensure we don't change the
behaviour by accident (it would be too easy to change the if/else chain
that tests the bitflags), but ran into another question along the way.
Look at the first added test:

diff --git a/Test/E02xtrace.ztst b/Test/E02xtrace.ztst
index 10e8b8886..520b7745f 100644
--- a/Test/E02xtrace.ztst
+++ b/Test/E02xtrace.ztst
@@ -225,3 +225,38 @@
 >the definition didn't execute it
 >runs
 
+ f() g
+ g() :
+ functions -t f
+ f
+0:functions -t smoke test #1
+?+f:4> g
+?+g:4> :
+
+ f() g
+ g() { () : }
+ functions -t f
+ f
+0:functions -t smoke test #2
+?+f:4> g
+?+g:0> '(anon)'
+?+(anon):0> :
+
+ f() g
+ g() :
+ (
+  functions -T f
+  functions -t f
+  f
+ )
+ (
+  functions -t f
+  functions -T f
+  f
+ )
+0:ensure the behaviour  of 'functions -Tt f' doesn't change surreptitiously
+?+f:6> g
+?+f:11> g
+F:If this test fails, the new behaviour may be 
+F:workers/48591.
+

PS4 at the time is at its default value, %N:%i:

       %i     The line number currently being executed in the script, sourced
              file, or shell function given by %N. […]

       %N     The name of the script, sourced file, or shell function that zsh
              is currently executing, whichever was started most recently. […]

Given this, isn't the output «g:4» (last line of the first new test) wrong?

Thanks for the answer, Peter.

Cheers,

Daniel