From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: zsh-workers@zsh.org
Subject: Re: PM_TAGGED and PM_TAGGED_LOCAL being set simultaneously (functions -T -t f)
Date: Thu, 15 Apr 2021 20:58:06 +0000 [thread overview]
Message-ID: <20210415205806.GD6669@tarpaulin.shahaf.local2> (raw)
In-Reply-To: <2d162aaf0f19dfc18b6ee72d35b77d454307546c.camel@ntlworld.com>
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
next prev parent reply other threads:[~2021-04-15 20:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-14 15:03 Daniel Shahaf
2021-04-14 15:22 ` Peter Stephenson
2021-04-15 16:21 ` Daniel Shahaf
2021-04-15 18:38 ` Peter Stephenson
2021-04-15 20:58 ` Daniel Shahaf [this message]
2021-05-16 14:50 ` Lawrence Velázquez
2021-05-18 1:57 ` Daniel Shahaf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210415205806.GD6669@tarpaulin.shahaf.local2 \
--to=d.s@daniel.shahaf.name \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).