Hi,
yes. Every line Input starts at
LineInput::get_terminal_line()
You can generate the Doxygen documentation to generate call graphs
etc to browse through the code.
The cursor is most likely positioned in
LineInput::edit_line() through the LineEditContext
object (lec).
The function doing that is LineEditContext::set_cursor()
If you want to see who has been calling you (say, in set_cursor())
then simply insert the macro BACKTRACE
at the point of interest.
/// Jürgen
can you give me a specific thing in the source to look at so that 'enter' does not go to the end of page ? we went over allocate_height and it didn't seem to be the place
---
cut and pasted the following from your email
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaXXXXXXXXaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaENDaaaaaaaaaaaaaaaaaaaaaaaaaaaaXXXXX
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaXXXXXXXXaaaaaaaZZZZZaaaaaaaaaaaaaaaaaaaaaaE
DaaaaaaaaaaaaaaaaaaaaaaaaaaaaXXXXX N
No string end found+
up arrow here so i can edit the line and add the missing trailing " what if i wanted to change the END to EEEEND i couldn't
DaaaaaaaaaaaaaaaaaaaaaaaaaaaaXXXXX
thank you
On Sat, 4 Feb 2017 18:58:39 +0100
Juergen Sauermann <address@hidden> wrote:
Hi,
(only shows properly if your email client has the same ⎕PW) :
^
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaEND
bbbbbbbbbbbbbbbbbbbbbbb"
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaENDbbbbbbb
bbbbbbbbbbbbbbbb
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaXXXXXXXXaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaENDaaaaaaaaaaaaaaaaaaaaaaaaaaaaXXXXXXXXaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaENDbbbbbbb
bbbbbbbbbbbbbbbb
)host /usr/local/mariadb/bin/mysql --verbose --user=root --socket=/tmp/mysql.sock -p
sh: 1: /usr/local/mariadb/bin/mysql: not found
32512
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaXXXXXXXXaaaaaaaZZZZZaaaaaaaaaaaaaaaaaaaaaaENDaaaaaaaaaaaaaaaaaaaaaaaaaaaaXXXXXXXXaaaaaaaZZZZZaaaaaaaaaaaaaaaaaaaaaaENDbbbbbbb
bbbbbbbbbbbbbbbb
/// Jürgen
On 02/04/2017 06:25 PM, address@hidden wrote:
the fact that it is an external program is not important - it can a line of 100 a up arrow gives erroreous line to edit
this was the reason you said that you moved the cursor to the end of the page - but it doesn't work -
I have said other things in my email that you haven't responded to
i appreciate you are really the only dev on this and 'might' have a non-apl life :) <shudder>
On Sat, 4 Feb 2017 18:15:53 +0100
Juergen Sauermann <address@hidden> wrote:
Hi,
of course, if you start an external program (via )HOST) then you cannot expect that the editing
and/or input functions of that external program still work as if the program was started from a shell.
What I meant by multi-line input is input to APL (via ⎕ and ⍞) that spans more than one line due to its
length. So you can, for example enter 90 times X with ⎕PW←80 and then backspace (or cursor left) to the
previous line.
/// Jürgen
On 02/04/2017 05:39 PM, address@hidden wrote:
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
|