Re: [Bug-apl] aplwrap: line counter should start at zero
This is still an issue. It is actually a lot worse now too. For example, if I just arrow up and down, the window thinks the file is modified. When arrowing up and down the line numbers sometimes go in the wrong direction and then jump to some other number. Thanks. Blake On Sun, Sep 21, 2014 at 3:42 PM, Blake McBride wrote: > Greetings, > > When you go into aplwrap File / New or File / Open the line counter starts > at line 1. This is a problem because the branches will be off by one. The > header line should be line 0. Then the branches will match the line > numbers. (Yes, I know branching to line numbers is bad form, but it should > still work.) > > Thanks. > > Blake > >
Re: [Bug-apl] aplwrap: line counter should start at zero
Fixed and pushed.
Re: [Bug-apl] aplwrap: line counter should start at zero
Dear David, Thanks a lot! Looks a lot better. I did find one small issue with it though. It displays the total number of lines. Nice. Problem is, it is one greater than the number of lines. I suppose there is a way of looking at it such that it is correct, but that logic only worked when the line numbers started at 1. It would be great if the total-number-of-lines number were reduced by one. i.e. given: X/Y, Z Y should be one less. Thanks. Blake On Fri, Oct 3, 2014 at 2:14 PM, David B. Lamkins wrote: > Fixed and pushed. > >
Re: [Bug-apl] aplwrap: line counter should start at zero
I know. I thought about that. I'm not convinced that adjusting the line count is the right answer. We actually do have N lines numbered 0 to N-1. I suppose we could display the largest line number rather than the number of lines. Then you'd have to remember to add 1 to get the line count... Maybe just display row and column...? Really: what use is the line count (or highest line number) while editing a function? On Fri, Oct 3, 2014 at 1:13 PM, Blake McBride wrote: > Dear David, > > Thanks a lot! Looks a lot better. I did find one small issue with it > though. > > It displays the total number of lines. Nice. Problem is, it is one > greater than the number of lines. I suppose there is a way of looking at > it such that it is correct, but that logic only worked when the line > numbers started at 1. It would be great if the total-number-of-lines > number were reduced by one. i.e. given: > > X/Y, Z > > Y should be one less. > > Thanks. > > Blake > > > On Fri, Oct 3, 2014 at 2:14 PM, David B. Lamkins > wrote: > >> Fixed and pushed. >> >> > -- "The secret to creativity is knowing how to hide your sources." Albert Einstein http://soundcloud.com/davidlamkins http://reverbnation.com/lamkins http://reverbnation.com/lcw http://lamkins-guitar.com/ http://lamkins.net/ http://successful-lisp.com/
Re: [Bug-apl] aplwrap: line counter should start at zero
Dear David, The problem is this: you open up a function with two lines (the header and one line) but the counter at the bottom says 3. The first thing you think is; what does that number represent? It is confusing. If you edit a function with 200 lines (God help us), it would be nice to know it is that large. Having that number is good. If that number is reduced by one, it is perfect. The other numbers are all good where they are IMO. Thanks. Blake On Fri, Oct 3, 2014 at 3:25 PM, David Lamkins wrote: > I know. I thought about that. > > I'm not convinced that adjusting the line count is the right answer. We > actually do have N lines numbered 0 to N-1. > > I suppose we could display the largest line number rather than the number > of lines. Then you'd have to remember to add 1 to get the line count... > > Maybe just display row and column...? Really: what use is the line count > (or highest line number) while editing a function? > > > On Fri, Oct 3, 2014 at 1:13 PM, Blake McBride wrote: > >> Dear David, >> >> Thanks a lot! Looks a lot better. I did find one small issue with it >> though. >> >> It displays the total number of lines. Nice. Problem is, it is one >> greater than the number of lines. I suppose there is a way of looking at >> it such that it is correct, but that logic only worked when the line >> numbers started at 1. It would be great if the total-number-of-lines >> number were reduced by one. i.e. given: >> >> X/Y, Z >> >> Y should be one less. >> >> Thanks. >> >> Blake >> >> >> On Fri, Oct 3, 2014 at 2:14 PM, David B. Lamkins >> wrote: >> >>> Fixed and pushed. >>> >>> >> > > > -- > "The secret to creativity is knowing how to hide your sources." >Albert Einstein > > > http://soundcloud.com/davidlamkins > http://reverbnation.com/lamkins > http://reverbnation.com/lcw > http://lamkins-guitar.com/ > http://lamkins.net/ > http://successful-lisp.com/ >
Re: [Bug-apl] aplwrap: line counter should start at zero
OK, I see. That's not quite the full fix, though. If you go to the last line and start typing, the line count doesn't change. Fixed and pushed. On Fri, Oct 3, 2014 at 1:37 PM, Blake McBride wrote: > Dear David, > > The problem is this: you open up a function with two lines (the header and > one line) but the counter at the bottom says 3. The first thing you think > is; what does that number represent? It is confusing. > > If you edit a function with 200 lines (God help us), it would be nice to > know it is that large. Having that number is good. > > If that number is reduced by one, it is perfect. > > The other numbers are all good where they are IMO. > > Thanks. > > Blake > > > On Fri, Oct 3, 2014 at 3:25 PM, David Lamkins wrote: > >> I know. I thought about that. >> >> I'm not convinced that adjusting the line count is the right answer. We >> actually do have N lines numbered 0 to N-1. >> >> I suppose we could display the largest line number rather than the number >> of lines. Then you'd have to remember to add 1 to get the line count... >> >> Maybe just display row and column...? Really: what use is the line count >> (or highest line number) while editing a function? >> >> >> On Fri, Oct 3, 2014 at 1:13 PM, Blake McBride >> wrote: >> >>> Dear David, >>> >>> Thanks a lot! Looks a lot better. I did find one small issue with it >>> though. >>> >>> It displays the total number of lines. Nice. Problem is, it is one >>> greater than the number of lines. I suppose there is a way of looking at >>> it such that it is correct, but that logic only worked when the line >>> numbers started at 1. It would be great if the total-number-of-lines >>> number were reduced by one. i.e. given: >>> >>> X/Y, Z >>> >>> Y should be one less. >>> >>> Thanks. >>> >>> Blake >>> >>> >>> On Fri, Oct 3, 2014 at 2:14 PM, David B. Lamkins >>> wrote: >>> Fixed and pushed. >>> >> >> >> -- >> "The secret to creativity is knowing how to hide your sources." >>Albert Einstein >> >> >> http://soundcloud.com/davidlamkins >> http://reverbnation.com/lamkins >> http://reverbnation.com/lcw >> http://lamkins-guitar.com/ >> http://lamkins.net/ >> http://successful-lisp.com/ >> > > -- "The secret to creativity is knowing how to hide your sources." Albert Einstein http://soundcloud.com/davidlamkins http://reverbnation.com/lamkins http://reverbnation.com/lcw http://lamkins-guitar.com/ http://lamkins.net/ http://successful-lisp.com/
[Bug-apl] APLwrap file editor functionality
I pushed an APLwrap update with file Open, Save and Save As functionality. -- "The secret to creativity is knowing how to hide your sources." Albert Einstein http://soundcloud.com/davidlamkins http://reverbnation.com/lamkins http://reverbnation.com/lcw http://lamkins-guitar.com/ http://lamkins.net/ http://successful-lisp.com/
