|
| From: | Blake McBride |
| Subject: | Re: [Bug-apl] aplwrap - editing functions with errors |
| Date: | Tue, 7 Oct 2014 11:46:27 -0500 |
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" <address@hidden> 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" <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
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
>
>
| [Prev in Thread] | Current Thread | [Next in Thread] |