line number reporting weirdnesses

["Rocky Bernstein" <rocky.bernstein@gmail.com>]

Some of odd the behavior I've noticed in how line numbers gets set (as
reported by funcfiletrace in trap DEBUG).

Consider this program:

#!/usr/local/bin/zsh -f
debug_hook() { print '====' ;  print $funcfiletrace[-1]; }
set -o DEBUG_BEFORE_CMD
trap "debug_hook" DEBUG
if [[ "$TERM" != bogus ]]; then  # line 5
[[ -z "$terminfo[kdch1]" ]] || bindkey -M emacs "$terminfo[kdch1]" delete-char
[[ -z "$terminfo[khome]" ]] || bindkey -M emacs "$terminfo[khome]"
beginning-of-line
[[ -z "$terminfo[kend]" ]] || bindkey -M emacs "$terminfo[kend]" end-of-line
fi
x='
line 11
line 12
line 13'
echo line 14

The output I get is:

====
./linebug2.sh:5
====
./linebug2.sh:5
====
./linebug2.sh:3920
====
./linebug2.sh:3920
====
./linebug2.sh:3920
====
./linebug2.sh:13
====
./linebug2.sh:14
line 14


There are two effects I think shown above.

First, the lines numbers of with [[ ]] inside if [[ ]] are weird -
there is no line 3920.

Second the line number in an assignment statement is basically the
line of the string token which spans several lines.  Possibly it might
be more helpful to give the line number of the LHS token.

What tends to happen say in a debugger is that someone will try to set
a breakpoint on one of the line numbers that most people would
associate with the weird line numbers (i.e. lines 6-8 or 10 above) and
lacking a way to report which line numbers are possible stopping
points as reported in funcfiletrace, people will get surprised when
none of those lines don't get reported or stopped at.

But of course the surprise is not limited to a debugger. Tools which
track code coverage, or tools to time scripts or just a program where
there is an error will also exhibit the weirdness.

(Ruby has this interesting feature too. No doubt it's an artifact of
LINENO getting set through a global variable tracking the the position
of the character previously read.)

- - -

Recently added to zshdb was the ability to "next" or step over
functions. It is possible way down the line stepping over functions
may be slow because there is tracing overhead inside a function. If
that's the case, more support in zsh might be warranted. Beforehand
though it's probably premature optimization which Knuth says is the
root of evil.