zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <p.w.stephenson@ntlworld.com>
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 19:38:28 +0100	[thread overview]
Message-ID: <2d162aaf0f19dfc18b6ee72d35b77d454307546c.camel@ntlworld.com> (raw)
In-Reply-To: <20210415162115.GB1002@tarpaulin.shahaf.local2>

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.

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.

pws



  reply	other threads:[~2021-04-15 18:39 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 [this message]
2021-04-15 20:58       ` Daniel Shahaf
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=2d162aaf0f19dfc18b6ee72d35b77d454307546c.camel@ntlworld.com \
    --to=p.w.stephenson@ntlworld.com \
    --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).