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

[Dirk Herrmann]

On Thu, 25 Jan 2001, Martin Grabmueller wrote:

> > 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.

Yes, that would be nice.

> 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).

Even if a port has no name, you would still gain the information about
what kind of port it is.  If it is a string port, you currently don't get
any information about that fact, and a filename is also not printed :-(
And, keeping a reference to a port will not prevent it from getting
closed, but only from getting garbage collected.  However, I am not sure
whether guile bothers to actually close the input ports...

Best regards,
Dirk Herrmann