bug-guile
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 3 readline bugs: source positions, readline-options, endless loop on


From: Martin Grabmueller
Subject: Re: 3 readline bugs: source positions, readline-options, endless loop on error
Date: Thu, 25 Jan 2001 12:47:47 +0100

> Date: Thu, 25 Jan 2001 11:41:31 +0100 (MET)
> From: Dirk Herrmann <address@hidden>
> 
> On Thu, 25 Jan 2001, Martin Grabmueller wrote:
> 
> > The next problem is that with readline, you don't get source positions
> > in error messages.  The reason is that the readline port created by
> > `make-readline-port' (readline.scm) is not given a file name.  The
> > following patch fixes the problem for simple cases, but not when
> > calling `set-readline-input-port!', which should also copy the
> > filename; but I am not sure how to test this procedure.
> > 
> > Maybe this problem is not worth fixing anyway, because the filename is
> > always `standard input'.
> 
> I think the problem has to be solved differently:  Why should the output
> of source positions be dependent of the existence of a filename for an
> input port?  This does not make sense, for example for string ports.
> Thus, I suggest to display source positions independent of whether the
> port has an associated file name.  If no file name was given, the error
> message can use a default string like "<unnamed port>".  Or, rather one
> could think of storing the port with the source properties instead of a
> filename.

Your first suggestion is easy to implement and only requires hacking
display_header in backtrace.c.  I could provide a patch for that.

The second requires a bigger patch, at least a lot of functions in
read.c would have to change to either pass the port along where
currently the filename is passed, or to put the port into the source
property hash instead of the filename.  Also, srcprop.c would need to
be modified, because the allowed source properties are kindof
hardwired.

I think the effort for the second version is not justified, because we
would not gain much more information from storing the port with the
properties, as they have no name anyway.  Also, the source properties
would keep a reference to the port, which prevents it from getting
closed (unless I have not properly understood the weak hash thingy).

Regards,
  'Martin
-- 
Martin Grabmueller              address@hidden
http://www.pintus.de/mgrabmue/  address@hidden on EFnet



reply via email to

[Prev in Thread] Current Thread [Next in Thread]