display corruption with efte on LInux

[lanurmi]

When opening binary files in efte, running in X Windows under Debian Linux, the display gets corrupted. Attached is a screenshot that demonstrates the problem. Apparently, the line data is not displayed correctly after certain binary byte sequences.

Feel free to ask for more info if you need it.

Reported by: calvin

Original Ticket: "efte/bugs/30":https://sourceforge.net/p/efte/bugs/30

[lanurmi]

Original comment by: calvin

[lanurmi]

Logged In: NO

yes, noticed that too, with chars > 128. they caused the rest of the line to not show anymore, initially, but them - for unknown reason - the chars >128 displayed as white solid blocks, and the following text was displayed again.

one way to reproduce the problem is (which efte fromon around release 930) is:

- open an empty file

• type in: 255 emit
• press keypad Enter (i'll explain in a moment what that is food for...) you should see an [ok] prompt below the line "255 emit".
• move cursor 2 lines up, and to end of line.
• move cursor 1 to the left (there is the character 255 - you notice the cursor disappearing now). this is a good base for some interesting experiments: insert a few characters left of char 255, then append some at end of line, and insert again some chars left of char. notice pushing chars to the right on the right side of char 255 is messed up.

play a bit more, then cover the efte window with another window, and uncover it again. Now the vista has changed.

now what is that keypad Enter? new versions of efte come with an interactive shell for scripts. you can execute them by name, compile new scripts, and interpret lines of script "source". The keypad Enter has been assigned to a macro which reads input from current buffer (from cursor line), and interprets it. the shell is rather minimal, but can be extended by loading a set of tools: load <yourbuilddir>/efte/config/tools.f <keypad Enter>

this adds a bit of flow control and some niceties. it is not needed for compiling new macros, or execute existing macros and commands.

a few examples:

6 7 * . <keypad Enter> "myfile" fileopen <keypad Enter> cls <keypad Enter> "Hello, world" type$ <keypad Enter>

'A' emit <keypad Enter> 65 emit <keypad Enter>

and for the coders among you: %11010010 $a000 + . <keypad Enter> $ff00 binary . <keypad Enter> 1101 decimal . <keypad Enter>

hex <keypad Enter> ffff 2 + . <keypad Enter>

1023 . <keypad Enter>

well, you get the drift. both macro language as well as macro shell are heavily leaning on the Forth programming language, and even though the shell is still quite an end from being a complete Forth, many things are done (and working) identically. take a look at loops for example (tools.f must be loaded for loops):

decimal : foo 10 0 do i . loop ;

or flow control:

: reply if "yes" else "no" then type$ ;

true reply false reply

but before i get carried away ... this is a reply to a bug report. i simply meant to show a way to reproduce the bug, for easier fixing. documentation on firescript shell i should probably write somewhere else :)

but while showing features ... try to run efte from an xterm, keep it visible, and type into efte: 2 verbosity ! <keypad Enter>

play a bit with your keys, and enjoy the vista.

Original comment by: nobody

[lanurmi]

Logged In: NO

yes, noticed that too, with chars > 128. they caused the rest of the line to not show anymore, initially, but them - for unknown reason - the chars >128 displayed as white solid blocks, and the following text was displayed again.

one way to reproduce the problem is (which efte fromon around release 930) is:

- open an empty file

• type in: 255 emit
• press keypad Enter (i'll explain in a moment what that is food for...) you should see an [ok] prompt below the line "255 emit".
• move cursor 2 lines up, and to end of line.
• move cursor 1 to the left (there is the character 255 - you notice the cursor disappearing now). this is a good base for some interesting experiments: insert a few characters left of char 255, then append some at end of line, and insert again some chars left of char. notice pushing chars to the right on the right side of char 255 is messed up.

play a bit more, then cover the efte window with another window, and uncover it again. Now the vista has changed.

now what is that keypad Enter? new versions of efte come with an interactive shell for scripts. you can execute them by name, compile new scripts, and interpret lines of script "source". The keypad Enter has been assigned to a macro which reads input from current buffer (from cursor line), and interprets it. the shell is rather minimal, but can be extended by loading a set of tools: load <yourbuilddir>/efte/config/tools.f <keypad Enter>

this adds a bit of flow control and some niceties. it is not needed for compiling new macros, or execute existing macros and commands.

a few examples:

6 7 * . <keypad Enter> "myfile" fileopen <keypad Enter> cls <keypad Enter> "Hello, world" type$ <keypad Enter>

'A' emit <keypad Enter> 65 emit <keypad Enter>

and for the coders among you: %11010010 $a000 + . <keypad Enter> $ff00 binary . <keypad Enter> 1101 decimal . <keypad Enter>

hex <keypad Enter> ffff 2 + . <keypad Enter>

1023 . <keypad Enter>

well, you get the drift. both macro language as well as macro shell are heavily leaning on the Forth programming language, and even though the shell is still quite an end from being a complete Forth, many things are done (and working) identically. take a look at loops for example (tools.f must be loaded for loops):

decimal : foo 10 0 do i . loop ;

or flow control:

: reply if "yes" else "no" then type$ ;

true reply false reply

but before i get carried away ... this is a reply to a bug report. i simply meant to show a way to reproduce the bug, for easier fixing. documentation on firescript shell i should probably write somewhere else :)

but while showing features ... try to run efte from an xterm, keep it visible, and type into efte: 2 verbosity ! <keypad Enter>

play a bit with your keys, and enjoy the vista.

Original comment by: nobody

[lanurmi]

Logged In: NO

meant to write "endif" instead of "then" in this example: : reply if "yes" else "no" endif type$ ;

Original comment by: nobody

[lanurmi]

Logged In: NO

fromon around build 950, the method explained below doesn't work by default anymore, because the shell is not bound to the grey enter key anymore. you need to set that up in your local configuration now.

Original comment by: nobody