Changed and pushed. Blake, don't commit any syntax errors in origin-0 until you get the libemacs update. ;)
On Tue, 2014-10-07 at 01:18 +0800, Elias Mårtenson wrote: > I try not to make incompatible changes. I would love to completely > redesign it at some point but for now you can consider that part > stable. If I need to redesign that part I'll probably simply implement > a new command. > > Regards, > Elias > > On 7 Oct 2014 01:11, "David B. Lamkins" <dlamk...@gmail.com> wrote: > Did I? I guess it's a matter of interpretation. Emacs uses > origin-1 for > line numbers, while APL uses origin-0. > > Clearly it makes sense to maintain the Emacs sense of line > numbers. > > It's still proper to commit the fix (with the +1) since > otherwise > gnu-apl-mode will be wrong in the case where APL runs in > origin-0. > > This won't fix Blake's issue. I'll need to parse the wire > protocol and > adjust the result. Just how stable is the wire protocol...? > > On Mon, 2014-10-06 at 11:18 +0800, Elias Mårtenson 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
