bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Juergen Sauermann
Subject: Re: [Bug-apl] location of cursor on new apl session
Date: Mon, 30 Jan 2017 11:37:22 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

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.


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









reply via email to

[Prev in Thread] Current Thread [Next in Thread]