Thanks. I'll integrate it once I get home. Although you missed a +1 there. The error is reported as a line number, not an APL jump index, which is conceptually different thing.
On 6 Oct 2014 01:05, "David B. Lamkins" <
address@hidden> wrote:
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 <address@hidden>
> 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
> <address@hidden>
> > 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
> > >
> > >
> >
> >
> >
> >
>
>
>
>