[bug #57340] ekey goes into strange mode when reading shift-backspace

[Bernd Paysan]

Update of bug #57340 (project gforth):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57340] ekey goes into strange mode when reading shift-backspace

[Anton Ertl]

Follow-up Comment #9, bug #57340 (project gforth):

twm does not catch alt-tab.  LANC=C xterm produces 137 for alt-tab, while
LANC=C.UTF-8 xterm produces 194 137 (i.e., the same code point).

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57340] ekey goes into strange mode when reading shift-backspace

[Bernd Paysan]

Update of bug #57340 (project gforth):

  Status:   Confirmed => Fixed  

___

Follow-up Comment #8:

I added a fix for both problems (not recognizing shift-tab, sticking in
line-mode style when the unkeys buffer is not empty) to the v0-7 git branch. 
Both fixes are backports from the current development branch, so the
development branch has no problem.

Linux terminal has yet another escape sequence for shift/alt-tab, esc+tab; on
other terminals you can't enter alt-tab, because the window manager will catch
it.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57340] ekey goes into strange mode when reading shift-backspace

[Anton Ertl]

Update of bug #57340 (project gforth):

  Status:   Need Info => Confirmed  

___

Follow-up Comment #7:

I can reproduce this (shift-tab) in gforth 0.7.2 on an xterm in Debian 8, and
in gforth-0.7.3 on an xterm that's connected to an Ubuntu 18.04 system through
ssh, and on an lxterm running on the Ubuntu 18.04 system displaying through an
ssh connection.  So it looks like Gforth is at fault.

On Gforth 0.7.9_20191128, this works as it should.

I notice that 0.7.3 does not know the escape-sequence and only returns the
ESC, while 0.7.9_20191128 returns $901D, i.e., "k-tab k-shift-mask or". 
If I disable recognizing this escape sequence, 0.7.9_20191128 still does not
exhibit this line-mode-like behaviour.

So the bug is fixed in the development version.  Do we want to do anything
about the bug in 0.7.3?

A workaround is to define

get-current esc-sequences set-current
$901D s" [Z" esc-sequence
set-current

This will get you the proper behaviour for shift-tab.  I expect that for other
escape-sequences that Gforth does not know, Gforth will still show the
line-mode-like behaviour.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57340] ekey goes into strange mode when reading shift-backspace

[anonymous]

Follow-up Comment #6, bug #57340 (project gforth):

I'M SO SORRY -- I don't know why I typed shift-backspace

What I meant (really) was shift-tab

could you give that a try?

(again my apologies... some weird dissonance)

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57340] ekey goes into strange mode when reading shift-backspace

[Bernd Paysan]

Follow-up Comment #5, bug #57340 (project gforth):


[comment #3 comment #3:]
> On another machine (Ubuntu submodule of Windows 10) it is:
> lrwxrwxrwx 1 root root 15 Jun 1  2019 /etc/alternatives/x-terminal-emulator
-> /usr/bin/lxterm

But you likely aren't using that in the WSL, because there's no graphical
session in WSL, only a terminal session.  You are using the terminal from
Windows.  You can use it directly if you start an Xserver on Windows, and then
start lxterm on the WSL instance.

I have Windows 1909, and there, using the mintty based terminal Microsoft has
now (replacing the old cmd.exe-style terminal) works as it should.

> To further test, I also used termux on android to access the linux mint PC. 
It also shows the same ekey effect. I can't tell you the
etc/alternatives/x-terminal-emulator, because termux doesn't have that.

So you are using termux to access the PC, which means there's another remote
connection (ssh? what? please say) in between your termux and the PC, which
you don't mention.

> Next I did a fresh install of gforth on an Ubuntu VPS installed on vultr.com
(using sudo apt-get install gforth).  Tried ekey with shift-backspace there --
same effect from both PCs as well as Android termux.

You definitely don't sit in front of this cloud computer.  You have some
remote connection.  This is likely the interesting part.

> I also accessed the VPS from a browser based terminal. However, that
terminal did not seem to allow shift-backspace.  shift-backspace registered in
gforth as just backspace.

Yes, that's the normal way.  There is no shift-backspace on the normal
terminal.  It's not about “allow”, it's very likely that the remote
connection software you are using intercepts shift-backspace, and when you
press it, the terminal goes into line mode (without Gforth knowing about
this).

> Finally, I tried XTerm on Windows 10, connecting to the ubuntu LSM.  There,
keystrokes also don't show after ekey, but shift-backspace is captured as 27
(ESC).

Still, the interesting part is how you connect.

For us, Linux is on our PC right before us, not in a VM, not in the cloud. 
The terminal is running on our computer.

> Oh, I also tried xterm on the Mint 18 (Ubuntu xenial equiv), but same
effect.

So here you run an xterm locally and start gforth locally, or is there some
other program in between that might filter out shift-backspace?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57340] ekey goes into strange mode when reading shift-backspace

[anonymous]

Follow-up Comment #4, bug #57340 (project gforth):

One more thing:  I have created a test account on the VPS that runs Ubuntu, in
case you would like to log onto that machine and test with your terminal.

Just let me know, and I'll email you the login details.

cheers.

RdR

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57340] ekey goes into strange mode when reading shift-backspace

[anonymous]

Follow-up Comment #3, bug #57340 (project gforth):

On one machine (Linux Mint 18) the output of ls -l
/etc/alternatives/x-terminal-emulator is:

lrwxrwxrwx 1 root root 31 Feb 16  2019 /etc/alternatives/x-terminal-emulator
-> /usr/bin/xfce4-terminal.wrapper

On another machine (Ubuntu submodule of Windows 10) it is:
lrwxrwxrwx 1 root root 15 Jun 1  2019 /etc/alternatives/x-terminal-emulator ->
/usr/bin/lxterm

To further test, I also used termux on android to access the linux mint PC. 
It also shows the same ekey effect. I can't tell you the
etc/alternatives/x-terminal-emulator, because termux doesn't have that.

Next I did a fresh install of gforth on an Ubuntu VPS installed on vultr.com
(using sudo apt-get install gforth).  Tried ekey with shift-backspace there --
same effect from both PCs as well as Android termux.  

I also accessed the VPS from a browser based terminal. However, that terminal
did not seem to allow shift-backspace.  shift-backspace registered in gforth
as just backspace.

Finally, I tried XTerm on Windows 10, connecting to the ubuntu LSM.  There,
keystrokes also don't show after ekey, but shift-backspace is captured as 27
(ESC).


Oh, I also tried xterm on the Mint 18 (Ubuntu xenial equiv), but same effect.



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57340] ekey goes into strange mode when reading shift-backspace

[Anton Ertl]

Follow-up Comment #2, bug #57340 (project gforth):

I also cannot reproduce this.  I tried it with gforth 0.7.3 on an xterm on
Ubuntu 18.04, and Shift-Backspace just produced 127 from EKEY, without any
other noticable effects.

My guess is that the terminal emulator used may play a role here.  If you use
the default one, then showing us the output of

ls -l /etc/alternatives/x-terminal-emulator

would help.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57340] ekey goes into strange mode when reading shift-backspace

[Bernd Paysan]

Update of bug #57340 (project gforth):

  Status:None => Need Info  
 Assigned to:None => paysan 

___

Follow-up Comment #1:

Can't reproduce at all.  Is this some key the terminal processes by itself? 
Which terminal do you use? If it's WSL, which version of Windows?  The earlier
versions of WSL had a very botched up terminal, before Microsoft switched to a
mintty-based terminal emulation.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57340] ekey goes into strange mode when reading shift-backspace

[anonymous]

URL:
  

 Summary: ekey goes into strange mode when reading
shift-backspace
 Project: Gforth
Submitted by: None
Submitted on: Mon 02 Dec 2019 06:02:49 AM UTC
Category: None
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

to duplicate issue: ekey (press enter, then shift-backspace)

gforth no long echoes key strokes.  For example, enter .S  and you'll not see
the .S while typing but you will see the it and the stack contents after
pressing enter.  Echoing of key strokes is only restored by exiting and
restarting gforth.

Also, after `ekey (enter) shift-backspace` subsequent ekey readings give
unexpected results (e.g. the backspace key doesn't return 9 but 91)

tested on gforth 0.7.2 and 0.7.3 on ubuntu 18




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/