One of the rare things I dislike about Tcl/Tk is the error messages.
They pop up and I hate them.

Well, I've changed them a little. Larger, much better font, better key
bindings and automatic focus so it's easier to copy the error message,
which I like to do so I can dismiss the error and paste the message
elsewhere for reference.

OK.

But this really annoys me:

can't read "dir": no such variable
can't read "dir": no such variable
while executing
"set dir"
(procedure "p.RunTime.Navigate" line 141)
invoked from within
"p.RunTime.Navigate "Up""
(command bound to event)

I hate it because line 141 is pointed out, but 141 is counted within
the proc! It's very hard to find. That is another reason for me to make
copying more convenient, so I can copy the bad line and pray that I
can find it exactly.

[dict get [info frame 0] line] can give me an exact, absolute line
number in relation to the entire file so why can't Tk error messages?
What file do I hack to achieve that?

I made the changes I mentioned earlier in this file:
/usr/share/tcltk/tk8.6/bgerror.tcl

Every error message says "while executing" and "invoked from within".
But grep can only find those strings in /usr/share/tcltk/tcl8.6/init.tcl.
And when I change, say, "while executing" to "while dancing hula" the
changes are not reflected in the error messages. So I won't even waste
my time trying to understand that file. What I want is not there.

Where is it?

--
Luc
>>

On 1/6/2024 3:46 PM, Luc wrote:
> One of the rare things I dislike about Tcl/Tk is the error messages.
> They pop up and I hate them.
>
> Well, I've changed them a little. Larger, much better font, better key
> bindings and automatic focus so it's easier to copy the error message,
> which I like to do so I can dismiss the error and paste the message
> elsewhere for reference.
>
> OK.
>
> But this really annoys me:
>
> can't read "dir": no such variable
> can't read "dir": no such variable
> while executing
> "set dir"
> (procedure "p.RunTime.Navigate" line 141)
> invoked from within
> "p.RunTime.Navigate "Up""
> (command bound to event)
>
>
> I hate it because line 141 is pointed out, but 141 is counted within
> the proc! It's very hard to find. That is another reason for me to make
> copying more convenient, so I can copy the bad line and pray that I
> can find it exactly.
>
> [dict get [info frame 0] line] can give me an exact, absolute line
> number in relation to the entire file so why can't Tk error messages?
> What file do I hack to achieve that?
>
> I made the changes I mentioned earlier in this file:
> /usr/share/tcltk/tk8.6/bgerror.tcl
>
> Every error message says "while executing" and "invoked from within".
> But grep can only find those strings in /usr/share/tcltk/tcl8.6/init.tcl.
> And when I change, say, "while executing" to "while dancing hula" the
> changes are not reflected in the error messages. So I won't even waste
> my time trying to understand that file. What I want is not there.
>
> Where is it?
>
>
Part of the problem is that \<nl>'s are absorbed by the parser before the text is saved. The reporting of proc relative line numbers may not agree with those in a text editor. However, [info body] can be used to list the same line numbers that the error reporting outputs:

# heinrichmartin version from clt post, reconstruct proc(s) in a list
proc lp3 {{namepat *}} {
set ans [lmap p [uplevel 1 info procs [list $namepat]] {
set globp [uplevel 1 namespace which -command [list $p]]
set args [lmap arg [info args $globp] {
if {[info default $globp $arg val]} {
list $arg $val
} else {
list $arg
}
}]
list proc $p $args [info body $globp]
}]
return $ans
}

# puts proc(s) with line numbers arg= [info proc] pattern
proc lpn {arg} {
foreach p [lp3 $arg] {
puts "#--------- [lindex $p 1 ] ------------"
set lnum 0
foreach line [split $p \n] {
puts "[incr lnum]\t$line"
}
}
}

Try:

lpn lp?

Luc <luc@sep.invalid> wrote:
> One of the rare things I dislike about Tcl/Tk is the error messages.
> They pop up and I hate them.

If you wish to have the feedback, the information has to go somewhere.
Do note that you are going on about the "default" error popups, which
if they were not present would likely leave you with the basic C
equivalent of:

segmentation fault: process aborted

And absolutely no information on where.

> Well, I've changed them a little. Larger, much better font, better key
> bindings and automatic focus so it's easier to copy the error message,
> which I like to do so I can dismiss the error and paste the message
> elsewhere for reference.

If you catch your own errors you can have any form of error message you
want to code. But you have to catch the errors (via either [catch] or
[try]) and then handle the error conditions yourself. Such is more
work, but you can have very finely tuned, highly relevant, error
feedback that way. But complaining about the provided default, which
if not provided would give you a "process aborted" message instead, is
a bit disingenuous. The default message, if you don't bother to catch
your errors and provide your own message, necessarially needs to be
reasonably generic and generally useful (and, compare Tcl's messages
with what Python or [shudder] Java provides on an error one day, and
you'll praise Tcl's nice, clean, useful, messages instead).

> OK.
>
> But this really annoys me:
>
> can't read "dir": no such variable
> can't read "dir": no such variable
> while executing
> "set dir"
> (procedure "p.RunTime.Navigate" line 141)
> invoked from within
> "p.RunTime.Navigate "Up""
> (command bound to event)
>
>
> I hate it because line 141 is pointed out, but 141 is counted within
> the proc! It's very hard to find.

Not a all. I jump my editor to the first line of the proc mentioned,
then I command the editor to do "down arrow" 141 times, and I arrive at
the very line that Tcl has referenced. Nothing could be simpler to
find.

Do note that the above does require one's editor to have the ability to
"repeat" an edit operation some number of times. I use joe (Joe's Own
Editor, https://en.wikipedia.org/wiki/Joe's_Own_Editor) in the jstar
configuration.

> That is another reason for me to make copying more convenient, so I
> can copy the bad line and pray that I can find it exactly.

I should note here that on a modern windowing system with
multi-tasking, that you can keep the tk error message dialog up while
simultaneously switching to the other window where you editor is
running, so that you can move about in your editor while simultaneously
viewing the Tk error popup. I do this all the time when I'm writing
Tcl/Tk code. The dialog pops up for some syntax error or type error,
and unless it happens to be for the last 5-10 new lines I just wrote, I
simply leave it open, switch to my editor window, and go about finding
the issue while the Tk message box is visible.

> [dict get [info frame 0] line] can give me an exact, absolute line
> number in relation to the entire file so why can't Tk error messages?

Possibly no one thought to do so, or the default error handling was
setup long ago (possibly before the 'line' key of info frame 0 existed)
and no one's been bothered enough by it to bother with tweaking it?

> What file do I hack to achieve that?

Unfortunately I have no idea. I've never been bothered by the message
(and compared to Python or Java Tcl's messages are a dream of
usefulness) and so have never sought out what to change. And for
anything I write for consumption by others, I catch errors and provide
custom, domain specific, feedback, I don't expect others to want to see
the default popup.

> Where is it?

The default error popup window is provided by the default bgerror
handler proc provided by Tcl. On my Slackware system the default
bgerror proc is defined in /usr/lib64/tk8.6/bgerror.tcl.

If you want to make changes, start by copying that file into your code,
then make your changes locally, the source your local changed copy
sometime during your startup (which will then overwrite the default
with your new and improved one) and you'll have a different dialog (or
even no dialog at all if you so desire).

On Sun, 7 Jan 2024 04:06:26 -0000 (UTC), Rich wrote:

>if they were not present would likely leave you with the basic C
>equivalent of:
>
>segmentation fault: process aborted
>
>And absolutely no information on where.

Of course, I understand, you do have a point, but you also sound like
you could have added something like "in the snow uphill both ways." :-)

It just seems to me that the error message is showing its age and could
be improved. I have improved it myself a little already.

> If you catch your own errors you can have any form of error message
> you want to code. But you have to catch the errors (via either
> [catch] or [try]) and then handle the error conditions yourself.

That suggestion calls to my mind the image of a basement with a large
array of mouse traps strewn all over, one or two going SNAP! every now
and then.

I don't want to pepper my code with God knows how many catch statements
in every possible corner. I just want a better error message.

>Not a all. I jump my editor to the first line of the proc mentioned,
>then I command the editor to do "down arrow" 141 times, and I arrive at
>the very line that Tcl has referenced. Nothing could be simpler to
>find.
>
>Do note that the above does require one's editor to have the ability to
>"repeat" an edit operation some number of times. I use joe (Joe's Own
>Editor, https://en.wikipedia.org/wiki/Joe's_Own_Editor) in the jstar
>configuration.

Ah. My first thought was, "Vi user detected."

I am familiar with joe, but I don't like it. I use geany. I like it
a lot.

>Unfortunately I have no idea. I've never been bothered by the message
>(and compared to Python or Java Tcl's messages are a dream of
>usefulness)

Yes, Tcl is better than Python and Java. And the sky looks blue unless
you're English. We can all agree on that.

>> Where is it?
>
>The default error popup window is provided by the default bgerror
>handler proc provided by Tcl. On my Slackware system the default
>bgerror proc is defined in /usr/lib64/tk8.6/bgerror.tcl.

Yes, and like I said, I have already made changes to it. But I don't
think the code I am looking for so I can change it is there. It
doesn't even contain the key words seen in the error messages.

--
Luc
>>

Luc <luc@sep.invalid> wrote:
> On Sun, 7 Jan 2024 04:06:26 -0000 (UTC), Rich wrote:
>
>>if they were not present would likely leave you with the basic C
>>equivalent of:
>>
>>segmentation fault: process aborted
>>
>>And absolutely no information on where.
>
> Of course, I understand, you do have a point, but you also sound like
> you could have added something like "in the snow uphill both ways."
> :-)

Yeah, I could have added that, and I've been there/done that (6502
assembly on an Atari 800, the feedback for a problem was the system
locking up and having to hit the reset key). Tcl's default is light
years better than that.

>> If you catch your own errors you can have any form of error message
>> you want to code. But you have to catch the errors (via either
>> [catch] or [try]) and then handle the error conditions yourself.
>
> That suggestion calls to my mind the image of a basement with a large
> array of mouse traps strewn all over, one or two going SNAP! every now
> and then.
>
> I don't want to pepper my code with God knows how many catch statements
> in every possible corner. I just want a better error message.

Understood, and for someting you are writing for yourself, yes, letting
the default error handler handle the errors beats adding in all those
catch and try statements. But sometimes there is value in catching
some of them yourself.

>>Not a all. I jump my editor to the first line of the proc mentioned,
>>then I command the editor to do "down arrow" 141 times, and I arrive
>>at the very line that Tcl has referenced. Nothing could be simpler
>>to find.
>>
>>Do note that the above does require one's editor to have the ability
>>to "repeat" an edit operation some number of times. I use joe (Joe's
>>Own Editor, https://en.wikipedia.org/wiki/Joe's_Own_Editor) in the
>>jstar configuration.
>
> Ah. My first thought was, "Vi user detected."

I know just enough VI to be able to edit files in it when it is all I
have available. But I use joe in jstar mode normally.

> I am familiar with joe, but I don't like it. I use geany. I like it
> a lot.

To each his own. Does geany have a "repeat function X times" feature
somewhere? That's all that is needed to find the line Tcl's
referencing from its default message.

>>> Where is it?
>>
>>The default error popup window is provided by the default bgerror
>>handler proc provided by Tcl. On my Slackware system the default
>>bgerror proc is defined in /usr/lib64/tk8.6/bgerror.tcl.
>
> Yes, and like I said, I have already made changes to it. But I don't
> think the code I am looking for so I can change it is there. It
> doesn't even contain the key words seen in the error messages.

The "error message" part of the popup is the Tcl generated stack trace.
It may be generated in the C code that makes up the Tcl interpreter
itself. If so then to change it you would have to recompile your Tcl
interpreter.

On 1/6/24 18:46, Luc wrote:
> One of the rare things I dislike about Tcl/Tk is the error messages.
> They pop up and I hate them.

Customize background error handling with [interp bgerror].

https://www.tcl-lang.org/man/tcl8.6.13/TclCmd/interp.htm#M55

--
| Don Porter Applied and Computational Mathematics Division |
| donald.porter@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|