Well, it should. :-) It returns the error message and line number in separate fields. The Emacs mode uses it to highlight the line that has the error.
Regards, Elias On 7 October 2014 01:02, David B. Lamkins <dlamk...@gmail.com> wrote: > APLwrap doesn't actually interpret the wire protocol beyond looking for > 'error' in the first line. Additional lines, up to but not including the > terminating sentinel, are simply collected and displayed. > > On Mon, 2014-10-06 at 11:32 +0800, Elias Mårtenson wrote: > > That's a display issue. ☺ I'm sure aplwrap can provide an option to > > display it in that way for people who prefer that (most people > > probably don't care since one never actually interacts with jump > > indexes very often directly) > > > > What David's patch does is to harmonise the underlying wire protocol. > > It has no bearing on what is displayed in aplwrap. > > > > Regards, > > Elias > > > > On 6 Oct 2014 11:29, "Blake McBride" <blake1...@gmail.com> wrote: > > Conceptually different but significantly confusing if they are > > not displayed as the same number. > > > > On Sun, Oct 5, 2014 at 10:18 PM, Elias Mårtenson > > <loke...@gmail.com> wrote: > > 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. > > > > Regards, > > Elias > > > > On 6 Oct 2014 01:05, "David B. Lamkins" > > <dlamk...@gmail.com> 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 <da...@lamkins.net> > > > 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 > > > <mol...@mollerware.com> > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
