Thanks for fixing.

On Thu, Sep 18, 2008 at 8:13 AM, Peter Stephenson <pws@csr.com> wrote:

> On Wed, 17 Sep 2008 12:39:36 -0400
> "Rocky Bernstein" <rocky.bernstein@gmail.com> wrote:
> > On Tue, Sep 16, 2008 at 10:50 AM, Peter Stephenson <pws@csr.com> wrote:
> >
> > > Now we have logic for finding the source file and corresponding line
> > > number of executed code, this adds the prompt escapes %x and %I which
> > > are like %N and %i but for the file where the code was defined.
> >
> > Looks like this has problems when used inside trap DEBUG.
>
> What's happening here is that the current shell logic doesn't update line
> numbers when inside a trap, even inside nested functions.


Ok. Thanks for the explanation. I don't see how this gives a line number
that is larger than the number of lines in the entire program, but if the
problem is fixed this is moot.


> The idea is that
> you're interested in the line number of what triggered the trap; this is
> particularly true of a DEBUG trap where you might want to examine LINENO to
> see what's going on in the code you're debugging, and you're much less
> likely to be interested in the line number inside the trap itself.


If one wants the line number that triggered the trap, there are two simple
ways to get this:
1. Save the line number in the call
   trap 'int_handler $LINENO'  INT
2. Use funcfiletrace


>
> So the obvious fix is to make the prompt code I added take account of
> this.


Yes, I think this the best thing.


>
>
> Another possibility would be to make traps respect the EVALLINENO option,
> so that you would get the local line numbers.  However, I think that's less
> useful.
>
> It's possible the same problem affects some of the other new features.  In
> particular I think funcstack line number info for eval commands inside
> traps is going to get thoroughly confused.  I think the simplest fix would
> be not to add funcstack info for eval in this case; this is sort of
> plausible since it's like the case where eval isn't keep track of its own
> line numbers, where we don't add funcstack info, and we don't add funcstack
> info for a trap which is like an eval without its own line number.
> Otherwise it's not currently obvious to me what the fix would be.
>
> It might be a good idea to add special variables ZSH_SOURCE_LINENO and
> ZSH_SOURCE_FILE as more readable alternatives to ${(%):-%I} and
> ${(%):-%x}.
>
> Index: Src/prompt.c
> ===================================================================
> RCS file: /cvsroot/zsh/zsh/Src/prompt.c,v
> retrieving revision 1.54
> diff -u -r1.54 prompt.c
> --- Src/prompt.c        16 Sep 2008 15:07:16 -0000      1.54
> +++ Src/prompt.c        18 Sep 2008 11:55:04 -0000
> @@ -726,7 +726,8 @@
>                     stradd(Rstring);
>                break;
>            case 'I':
> -               if (funcstack && funcstack->tp != FS_SOURCE) {
> +               if (funcstack && funcstack->tp != FS_SOURCE &&
> +                   (!intrap || trapisfunc)) {
>                    /*
>                      * We're in a function or an eval with
>                     * EVALLINENO.  Calculate the line number in
> @@ -749,7 +750,8 @@
>                 bp += strlen(bp);
>                break;
>            case 'x':
> -               if (funcstack && funcstack->tp != FS_SOURCE)
> +               if (funcstack && funcstack->tp != FS_SOURCE &&
> +                   (!intrap || trapisfunc))
>                     promptpath(funcstack->filename ? funcstack->filename :
> "",
>                               arg, 0);
>                else
> --
> Peter Stephenson <pws@csr.com>                  Software Engineer
> CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
> Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070
>