Looks good, thanks! On Mon, Oct 6, 2014 at 12:50 PM, David B. Lamkins <dlamk...@gmail.com> wrote:
> 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
