Thanks, Blake. This is best fixed in libemacs.
Elias: The attached patch makes a failed function definition report an
origin-independent line number.
On Sun, 2014-10-05 at 07:29 -0500, Blake McBride wrote:
> Looks good, but one very small problem - when it reports the line
> number with the error, it is off by one. In other words, line
> references in the editor (and in APL) start at 0, but when it reports
> the error it reports the line number as if they start at 1.
>
>
> Thanks.
>
>
> Blake
>
>
>
> On Sat, Oct 4, 2014 at 3:17 PM, David B. Lamkins <[email protected]>
> wrote:
> Fixed and pushed.
>
> On Sat, 2014-10-04 at 08:08 -0500, Blake McBride wrote:
> > This is still a problem. It can create a real loss of work.
> >
> >
> > Thanks.
> >
> >
> > Blake
> >
> >
> >
> > On Fri, Sep 12, 2014 at 6:18 PM, Chris Moller
> <[email protected]>
> > wrote:
> > Actually, saving shouldn't close the window in any
> event.
> > I'll poke at it. Right now, I'm looking at the
> open-function
> > problem.
> >
> >
> >
> > On 09/12/14 18:46, Blake McBride wrote:
> >
> > > Greetings,
> > >
> > >
> > > Let's say you create a large APL function using
> File / New.
> > > If just one line has an open quote that isn't
> closed, you
> > > lose all of your work. I think aplwrap should
> test the
> > > result of ⎕FX before it exits. If ⎕FX fails,
> display the
> > > line number with the error and remain in the
> editor so all
> > > of your work isn't lost.
> > >
> > >
> > > Thanks.
> > >
> > >
> > > Blake
> > >
> > >
> >
> >
> >
> >
>
>
>
>
diff --git a/native/DefCommand.cc b/native/DefCommand.cc
index 7b07986..bba2278 100644
--- a/native/DefCommand.cc
+++ b/native/DefCommand.cc
@@ -72,7 +72,8 @@ void DefCommand::run_command( NetworkConnection &conn, const std::vector<std::st
out << "error\n"
<< "parse error\n"
<< "Error parsing expression\n"
- << value->get_ravel( 0 ).get_int_value();
+ << value->get_ravel( 0 ).get_int_value() -
+ Workspace::get_IO();
}
else if( value->is_char_string() ) {
out << "function defined\n"
