Re: [Bug-apl] location of cursor on new apl session

[enztec]

On Sat, 4 Feb 2017 14:12:08 +0100
Juergen Sauermann <address@hidden> wrote:

> Hi,
> 
> as I said, the cursor is not moved down by the clear screen but by the 
> interpreter      <-- this is what i have been saying for days   and should 
> not happen
> requesting input. If you place your cursor anywhere on the screen in APL2 and 
> then enter    
> something, then the cursor will jump down to the bottom of the screen.       
> <- this should not happen


multiline editing   with ⎕pw 80
)host /usr/local/mariadb/bin/mysql --verbose --user=root 
--socket=/tmp/mysql.sock -p
comes back asking for password   if you have mariadb - just hit ^c
and then up arrow to get back the line to edit - your multiline editor fails   
you said this was the reason you activate the allocate_height code and moved 
cursor to end of page
the line is uneditable as i said 

is the cursor to end of page behaviro in the allocate_height?         with you 
current fix to the scripting -- behavior i am getting my code done with 
scripting but the apl workspace/calculator mode is what made apl to begin with

---

NO computer language doesn't respect a comment character 

---

> 
> It might be that this was different in 1.3, but then I suppose editing lines 
> that were longer than ⎕PW
> did not properly work at that time.      <----- still doesn't work
>  
> 2. reg. ⍝ ∇
> 
> again, compatibility with APL2. You may not like the way APL2 works, but for 
> me IBM
> compatibility is an important feature. Not because it is better than other 
> APLs, but because
> it simply saves me a lot of documentation work.
> 
> And - after entering the first ∇ you have entered the function editor and no 
> longer inside the APL interpreter.
> The comment of the APL interpreter means nothing to the editor, but ∇ does. 
> In other words, ∇ is an
> editor command while ⍝ is just an ordinary character like every other. If I 
> enter ⍝ in vi or emacs (both
> are APL-aware) and then :x in vi or ^X in emacs, then both editors will exit 
> despite of the ⍝ .
> 
> And the statement "all other lagnuages..." is obviously incorrect. It should 
> maybe read "all other
> computer languages execpt IBM APL2"
> 
> Regarding multi-line editing, it works fine on my machine. Not sure what you 
> mean by uneditable.
> Of course, after pressing ENTER, you need to scroll up in the history (cursor 
> up key) to recall the
> previous line(s) and then you can edit it.
> 
> /// Jürgen
> 
>  
> On 02/04/2017 01:40 AM, address@hidden wrote:
> 
> Hi
> 
> I'm replying to you and not the full list on this on a few things that are of 
> concern for me
> 
> 1.   clear screen
> 
> i am using the apl in an xterm and have output that i have at the initiation 
> of the apl workspace session - to have the screen scroll up with everynew 
> line - is really not good
> 
> in 1.3 when i developed my code the cursor started at the top of xterm - as i 
> called /usr/bin/clear  right before starting apl
> 
> i don't see why doing    a clear screen should move the cursot back to the 
> screen bottom
>       CSI←(⎕UCS 27),'['
>       ⍞←CSI,'10;10HHello'◊ ⎕DL 10
> 
> i have tested what you said that you do this for long line wraps - when i 
> tested this it failed - the line was uneditable after enter etc
> 
> ---
> 
> 2.  ⍝ ∇
> 
> the way you have it is contrary to the way EVERY other computer language 
> handles a comment
> nothing after the comment should be parsed or used by the interpreter 
> 
> the following of apl2 to me is a mistake - i have used EVERY apl in existance 
> except dyalog and apl2  they had to many things i didn't like in them 
> 
> ---
> 
> thanks for the work on the compiler empty string problem - it was fun to 
> follow along with your problem solving methods
> 
> 
> 
> 
> 
> On Tue, 31 Jan 2017 21:13:59 +0100
> Juergen Sauermann <address@hidden> wrote:
> 
> Hi,
> 
> it stays there as long as you let it:
> 
> 
>       CSI←(⎕UCS 27),'['
>       ⍞←CSI,'10;10HHello'◊ ⎕DL 10
> 
> The positioning of the cursor at the bottom happens for the following reason.
> 
> In APL2 there is a somewhat unfortunate behavior of the following combination 
> of
> ⍞ for input and output:
> 
>       PROMPT←"Please enter data: "
>       ⍞←PROMPT ◊ INPUT←⍞
> 
> The above prints PROMPT and collects the input from the user. Unfortunately, 
> in IBM APL2 the prompt
> is overridable. That is normally you enter data after the prompt:
> 
>             PROMPT←"Please enter data: "
>             ⍞←PROMPT ◊ INPUT←⍞
> Please enter data: 1 2 3
>       INPUT
>                    1 2 3
> 
> However, you can backspace right at the start of your input and override the 
> the prompt:
> 
>        T ◊ INPUT←⍞
> Please enter1 2 3 
>       INPUT
>             1 2 3
> 
> There is also a system variable ⎕PR (prompt replacement that complicated 
> things even more.
> 
> The above behavior is difficult enough to achieve and it requires that  
> ⍞←PROMPT is performed in the
> input area, i.e. at the bottom of the screen. This is because ⍞ cannot know 
> whether it is followed by a ⍞
> input or not (the ⍞-input and the-⍞ output can even be in different APL 
> functions.
> 
> So all this is for compatibility with APL2. And, BTW, APL2 also moves the 
> cursor to the bottom line for ⍞-input,
> no matter where the cursor sits.
> 
> /// Jürgen
> 
> 
> On 01/31/2017 03:07 PM, address@hidden wrote:
> 
> and does the cursor stay there? it shouldn't move back to the bottom of the 
> screen
> 
> 
> 
> 
> 
> 
> 
> On Tue, 31 Jan 2017 13:24:28 +0100
> Juergen Sauermann <address@hidden> wrote:
> 
> Hi,
> 
> I believe your ESCape sequence is wrong (it clears to end of screen from the
> current cursor position but does not move the cursor.
> 
> Try e.g.
> 
>       CSI←(⎕UCS 27),'['
>       ⍞←CSI,'10;10HHello'
> 
> which prints Hello at row 10/column 10 of my xterm.
> 
> /// Jürgen
> 
> 
> On 01/30/2017 06:43 PM, address@hidden wrote:
> 
> Hi,
> 
> In src/LineInput.cc   i changed 
> allocated_height = 42;   and played with rows =    and even set   
> allocated_height = 42000 and nothing changed??
> putting in shortcut returns  also didn't do anything ?
> 
> you have some tight code there ;)
> 
> the problem also affects    
> ⍞←(⎕UCS 27), '[2J'
> which should clear the screen and go to top of screen  but goes to the bottom 
> of the screen like on startup
> 
> thanks
> 
> 
> 
> 
> 
> On Mon, 30 Jan 2017 11:37:22 +0100
> Juergen Sauermann <address@hidden> wrote:
> 
> Hi,
> 
> yes. but there is a reason for it. It is very difficult to figure, in a 
> portable way, at which line
> your cursor sits when entering some input. I tried with curses, but that did 
> not work well.
> The cursor position is needed when an input wraps around at the right end of 
> the screen
> (for backspacing over the wrapping point).
> 
> For this reason, he GNU APL model is that your input area are the last 
> allocated_height lines
> counting from the bottom of the screen. allocated_height is initially 1, but 
> increases
> when input lines are wrapping around.
> src/LineInput.cc
> If you move the input are up (as you wish) then line editing of inputs longer
> than the screen width stops working properly.
> 
> If you set the initial allocated_height to 24, then your input will start at 
> the top of the
> screen, but, trust me, this is asking for trouble.
> 
> /// Jürgen
> 
> 
> On 01/30/2017 03:37 AM, address@hidden wrote:
> Hi
> 
> I don't think
> LineEditContext::adjust_allocated_height()
> affects where the cursor is places after 'apl'
> i commented out tons of lines and nothing was effected
> 
> i'd like to have the cursor just indented when apl starts in an xterm and no 
> lines entered - i can see the cursor in the xterm right after apl starts but 
> then it moves to last line
> 
> 
> 
> 
> On Sat, 28 Jan 2017 18:53:38 +0100
> Juergen Sauermann <address@hidden> wrote:
> 
> Hi,
> 
> I suppose it is somewhere around LineEditContext::adjust_allocated_height().
> 
> I wrote my own readline() because the official one caused too many problems 
> on some platforms.
> 
> If I remember correctly then LineEditContext::adjust_allocated_height() makes 
> sure that there
> are enough empty lines at the bottom of the screen for entering some 
> (line-wrapped) multi-line input.
> 
> I am not sure what you are after - if it is only not clearing the screen then 
> you can change the
> CLEAR-EOS-SEQUENCE setting in your preferences file accordingly.
> 
> /// Jürgen
> 
> 
> On 01/28/2017 05:59 PM, address@hidden wrote:
> 
> with the banner disabled - i don't see apl clearing the xterm screen - if i 
> invoke apl after using 20 lines (in a 28 line xterm) then apl just starts at 
> the bottom of the screen - (8 lines below) - i have to clear the screen 
> (/usr/bin/clear) myself before invoking apl
> 
> when i start apl after 'i clear the screen' i can see the cursor at the top 
> of the xterm (while the apl loads) and then it moves to the bottom
> 
> Could you give me an idea if you have it on the top of your head where the 
> code for this is in your code...  i will try to find it myself in the 
> meantime :(  
> 
> (i've always been amazed at the complex code you have in your apl just so my 
> simple apl code will run)   </enztec wipes his brown nose>
> 
> 
> On Sat, 28 Jan 2017 12:57:49 +0100
> Juergen Sauermann <address@hidden> wrote:
> 
> Hi,
> 
> what you see is the intended behavior.
> 
> When you start GNU APL then the terminal is being reset (clear screen) so 
> that we can print the
> welcome banner. After that all user input is entered at the bottom of the 
> screen.
> 
> This is more portable than grabbing the input at the middle of the screen 
> because you can do it
> without ESCape sequences for cursor positioning. Everything is based on the 
> ASCII characters
> CR, LF, and Backspace, wehich are more portable than ESC sequences.
>  It also works better in scripts and pipes, eg. for web interfaces, and with 
> virtual terminals like xterm.
> 
> /// Jürgen
> 
> 
> On 01/27/2017 11:56 PM, address@hidden wrote:
> In all my previous apl installations the cursor in an xterm was at the top of 
> the xterm -  it stays there for 1.3  but with 1.6 and now 863  i can see it 
> start at the top when first opened but then goes to the bottom and indents - 
> any ideas?
> 
> I have 1.3 1.6 and 863 all installed on same computer
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>