bugGNU Octave - Bugs: bug #39822, Incorrect GUI terminal key...


bug #39822: Incorrect GUI terminal key mappings on Windows

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Mon 19 Aug 2013 09:20:17 PM UTC
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Philip Nienhuis Open/Closed:  * Closed
Release:  * dev Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Fri 06 Sep 2013 06:14:14 PM UTC, comment #24: 

Path works OK.

I'll close this report and soon open a new one for the Tab / Shift-Tab / Ctrl-Tab keys, + maybe for Esc (to get it to clear the current command line).

Philip Nienhuis <philipnienhuis>
Group Member
Tue 03 Sep 2013 08:26:52 PM UTC, comment #23: 

@John D:
Your patch (the TERM part) is merely the same as one I tried yesterday, so I'm confident it should work.

Apparently your systems are somehow set up differently than mine, that's the only explanation I have for the startup escape sequence.

I'll try by the end of his week, I'll close the bug then.
Thanks for fixing.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 03 Sep 2013 02:05:44 PM UTC, comment #22: 

Checked in http://hg.savannah.gnu.org/hgweb/octave/rev/afc3d47f7704

The patch sets the term now to Cygwin if it not already set, however it behaves the same for me in terms of the update of the prompt line when  running from double click as well.

If I set it to dumb instead of cygwin then it does work ok.

Let me know if it works for you. If not, we can try setting term to 'dumb'.

John Donoghue <lostbard>
Group Member
Tue 03 Sep 2013 02:44:37 AM UTC, comment #21: 

To answer Philip, yes, it's different to run ./run-octave and start octave from the Windows start menu. The former will have TERM variable defined, while the latter will not.

I suppose the closest way to use ./run-octave in a way similar to the start menu is like (untested):

env -u TERM ./run-octave

Michael Goffioul <goffioul>
Mon 02 Sep 2013 10:01:53 PM UTC, comment #20: 

On the OT, I do see it complain a lot about linking the LLVM libraries (which are static) to the octave libs. Not sure if that the whole reason, but makes some sense since the issue goes away when jit is disabled.

I was running ./run-octave from the build, not installed version. doing a make install and running the installed version from the msys window shows the same issue. 

Doing mk-dist fails with no rule to make native-gcc.

I will check in the current code where it sets the term to Cygwin if it not already set, since that seems to work best and then start a cross rebuild

John Donoghue <lostbard>
Group Member
Mon 02 Sep 2013 08:23:52 PM UTC, comment #19: 

True, configuring with --disable-jit makes the MXE-build succeed.
In later MXE versions --enable-jit is the default.

BTW I was wrong to surmise that Octave was already built, the "dlname is empty in dldfcn/__delaunayn__.la!" build error occurs half way.
I'll try to investigate further, but I have limited time for it this week.

As to the key mappings, I think working HOME and END keys + cygwin TERM setting made usability significantly better.
A 3.7.6+ dist target patched for that can be built with Anirudha's mxe tree, mxe-0.0.3 and mxe-0.0.11 (all cross-builds).
But I still do not see \e[K on startup of Octave with any of those mxe builds...

Do you build a complete installer and run octave from there, or do you just do ./run-octave? Could that be the cause of that startup \e[K echo?

Philip Nienhuis <philipnienhuis>
Group Member
Sun 01 Sep 2013 01:46:30 PM UTC, comment #18: 

I  tried both and saw similar results - mainly running a native windows build in this case though.

I beieve I have seen that issue (althought not 100% sure) and it saw it didnt occur if building without jit.

John Donoghue <lostbard>
Group Member
Sun 01 Sep 2013 12:07:50 PM UTC, comment #17: 

Do you build natively (Windows) or cross (on Linux)?

A build fresh MXE v.0.0.11 clone stops while (cross-)building Octave, complaining about
install.oct: "dlname is empty in dldfcn/__delaunayn__.la!"
AFAICS Octave had already been compiled, but installing it in the tree goes wrong.

A dist target I made yesterday has the same fate, while it got built flawlessly in MXE-0.0.3.

I think I'll ask on the maintainers list later today.

Philip Nienhuis <philipnienhuis>
Group Member
Sun 01 Sep 2013 11:25:35 AM UTC, comment #16: 

On mine, if I have TERM set to Cygwin from the start. If start with TERM=dumb and then in octave, change it to Cygwin, everything looks ok.

I am compiling the latest octave sources from hg. ./configure --prefix=themxepthbin --disable-jit

It fails the build of some of the documentation because of no tex, however has built up to the ./run-octave command.

John Donoghue <lostbard>
Group Member
Sun 01 Sep 2013 09:34:02 AM UTC, comment #15: 

Hmmm... I do not see that: no \e[K, Bksp works as-it-should.

<Maybe a bit OT:>
Intruiging, because MXE is meant to provide a standardized build environment. Maybe some blame for our different experiences lies at my side:
- I still use MXE v. 0.0.3 to cross-compile on my Linux box ("parent: 3106:6d580645fd22")
- MXE 0.0.11 doesn't work for me (using OpenBLAS; it gets stuck with complains about dllwrap, I haven't tried with traditional BLAS yet)
- My native MXE/MinGW build chain (also several months old) only allows Octave to be built with make => installer can't be built there => Octave can only be run with ./run-octave [1]

How do you build Octave?

OK, I just updated MXE-0.0.11 on my linux box and started anew; and if can find time today I'll update my native MXE on my other (WinXP) box as well. Maybe - but not hopefully ;-) - I get the same issues as you...

[1] which is no big deal as my whole motive for native MXE windows builds was just to be able to debug/experiment with them with minimum hassle.

Philip Nienhuis <philipnienhuis>
Group Member
Sun 01 Sep 2013 12:26:34 AM UTC, comment #14: 

of course when I set TERM to Cygwin prior to strting octave, then there are update issues with readline.
- the \e[K displayed, backspave doesn't update the rest of the text after the cursor correctly ...

John Donoghue <lostbard>
Group Member
Sat 31 Aug 2013 08:20:00 PM UTC, comment #13: 

Oh I could try that too (only setting TERM if it wasn't set). Easy fix, just copy from a stanza higher up in octave-gui.cc.

Maybe we can ask Anirudha to make the MXE Windows installer such that Octave is started with a batch file. After all, amending a batch file is much easier than hacking around in the code. As I wrote in an earlier comment, it also gives a chance to supply Octave with a somewhat cleaned-up environment (TERM, esp. PATH, perhaps others).

As to your last question:
Setting TERM to cygwin does fix the pager. Good catch!
xterm, octave, dumb, vt100, and "" (empty) cripple the pager.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 31 Aug 2013 07:15:49 PM UTC, comment #12: 

I saw the warning on terminal not functional if I set it to something other than a valid term name (or dumb)

Currently the patch sets the term to dumb no matter what the setting previously was - I will change that to only set it if it isn't set, however as I said on a previous post, some keys may/will act differently depending on the term setting.

If in octave, you run:
 setenv('TERM', 'cygwin')

and then try a long printout, does it work for you?

John Donoghue <lostbard>
Group Member
Sat 31 Aug 2013 06:41:46 PM UTC, comment #11: 

BTW, with your patch, on long printouts the pager (in the GUI) now gives me:

WARNING: terminal is not fully functional
-  (press RETURN)

and if I set
set TERM=
(or set it to xterm, cygwin, ...)
in the batch script I use to launch Octave, getenv ("TERM") still answers "dumb".

Philip Nienhuis <philipnienhuis>
Group Member
Sat 31 Aug 2013 06:30:56 PM UTC, comment #10: 

OK, I figured it would cancel the current command line. Not so then. Maybe later.

My previous post was about testing on Win7 64 bit. On XP (32b) the INS key merely inserts a tilde and beeps. It doesn't do anything else.
The other keys work like I described in comment #8.

TERM setting
On Octave 3.7.5 (MXE built) and all other builds before your patch, getenv ("TERM") gets me:

ans =

Setting TERM in a batch script before starting Octave returns the proper environment setting in getenv(), yet behavior at the terminal prompt is unchanged no matter what setting: cygwin, xterm, octave, whatever.

The TAB key already worked (in the sense of auto-completion of a few typed characters) before your patch. My "complaints" (see original post) were triggered by the untractable shifting of focus in case of an empty command line.

Anyway, HOME and END do work now, which -for me at least- is a great improvement, thanks.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 31 Aug 2013 12:21:03 PM UTC, comment #9: 

Esc is only going to do something after getting other characters to tell it what to do.
Ie: you can send your own esc codes to make things happen.

I didnt do anything with the INS key, however I think that may have to be decoded and sent to the console as a WIn32 console function call.

We can use the TERM settings (and it was prevously) however your previous issues were partly due to you having TERM set to octave? I had mine set to cygwin ......
And then at that point, the keys work for one terminal but not another.

For tab key, if you press 'l' and then tab, what happens?

John Donoghue <lostbard>
Group Member
Sat 31 Aug 2013 11:32:47 AM UTC, comment #8: 

Well the Del key does what it is supposed to do.

Esc doesn't work here; it just puts the cursor one char to the left, but not always. I haven't been able to pinpoint the exact pattern.

INS key: doesn't work as it should, it just advances two chars to the right and switches the underlying two chars to uppercase. After having used the INS key on a line, Backspace and DEL don't erase anymore, Backspace only works like left-arrow and DEL does nothing.
After <Enter> they works again on a new command line.

HOME and END do work. Nice! I use these keys a lot.

TAB when editing a command line only triggers the beeper. But Shift-TAB a few times puts focus on the main menu bar, the same number of TABs get me back to the command line and the next TAB beeps again.

As to the TERM environment setting: do we really need to set it in octave-gui.cc? Can't they be inherited from the environment?
Octave on Windows can also be started from a batch file. The ones I use look like:

@echo off
rem     Optionally clean up Windows PATH (antivirus, Powershell, etc
rem    Uncomment below for a clean PATH
rem set PATH= <cleaned up path>

rem    Add <OCTAVE_HOME>/bin to the PATH
set PATH=X:/Octave/Octave-3.7.6+_MXE/bin;%PATH%

rem    Spawn Octave
start octave.exe

Before the start command other environment vars can be set as well. I've experimented with TERM (with the settings in octave-gui.cc disabled) but admittedly I couldn't discern much differences in behavior in the terminal.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 30 Aug 2013 07:44:30 PM UTC, comment #7: 

How about this then (attached)
The one I don't like is the delete key.

(file #28964)

John Donoghue <lostbard>
Group Member
Tue 20 Aug 2013 12:29:28 PM UTC, comment #6: 

Somewhat related to the term settings, using the default TERM variable in mingw (TERM=cygwin), I get ESC[K printed to the screen before the first prompt.
After that things work fairly well with most of the current keycodes.

If I set it to TERM=octave, or something that I guess doesn't correspond to a valid term id, the ESC[K is not displayed, but then the keycodes work as per Philips issues.

I haven't done much with readline, but I am guessing that most of the issues we are seeing are because of readline settings?

John Donoghue <lostbard>
Group Member
Tue 20 Aug 2013 12:09:45 PM UTC, comment #5: 

If TERM is required for consistency, it should be added. FYI we are already doing this for all other systems:


Mike Miller <mtmiller>
Group Member
Tue 20 Aug 2013 12:01:57 PM UTC, comment #4: 

Just checked, my last build is from Aug. 17, so it includes your tabbing changeset.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 20 Aug 2013 11:38:42 AM UTC, comment #3: 

I think my last build is from before that changeset. Maybe tonight I can make a new build.

It may be wise indeed to set TERM for the Windows GUI.

ESC (forgot that key in previous post): can we invoke the ESC key? In Matlab's terminal that is used to cancel input at the command prompt (it wipes the command line clean).

Like you I'd prefer TAB for completion. But maybe it could be made such that TAB only works for completion if
- focus is in the terminal, and
- there's some text after the command prompt that can be completed at all?
If there's no or too little text at the prompt, TAB could be used instead to move focus to a next item.

In my original post I briefly referred to the seemingly endless list of items that TAB moves focus to with a next press. Currently that list is apparently so long, i.e. all items in the entire GUI?, that for most users the TAB key is less useful, if not plain useless.
I'd advocate to break up the lists per pane, to use Ctrl-TAB to move to the next pane/main window (editor, terminal, ...), and to use TAB to switch to the next item within one pane (button, toolbar, input sub-pane, list, ...), if applicable. This is the way it works in Matlab as well: Ctrl-TAB for switching between panes, TAB itself only works in the file browser AFAICS; if focus is somewhere in a pane, the color of that pane's title bar changes to blue.

In addition, the sequence of where a TAB press would move focus to should be much more logically structured, transparent for usera, and limited to a smaller number of items. (I'm afraid that the first could imply re-ordering some code blocks, right?)
E.g. if TAB moves focus to some toolbar, then it should be possible to navigate the toolbar buttons with left & right arrow keys.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 20 Aug 2013 01:25:38 AM UTC, comment #2: 

Tab works for me (tab completion).

I do see that it depends on the TERM environment variable as to whether INS,HOME etc work correctly.

So should we explicitly set the TERM variable within the GUI (when in Windows GUI mode) so we have a consistent reaction to key presses?

John Donoghue <lostbard>
Group Member
Mon 19 Aug 2013 11:24:42 PM UTC, comment #1: 

For tab issues, is this with the later changeset http://hg.savannah.gnu.org/hgweb/octave/rev/aa09b746fa16

If tabbing works as a standard Windows application (tab focuses the next window in the child window order) then tab for file/command completion would not work - I'd rather the tab completion :), which is also more consistant with the unix version.

I guess its all in do we want consistant actions between the unix version and windows version, or what would be consistant for the OS ?

For the other keys, currently it should be converting them to Ansi termianl codes and sending on which I thought was working - I will recheck as maybe I missed something.

John Donoghue <lostbard>
Group Member
Mon 19 Aug 2013 09:20:17 PM UTC, original submission:  

Admittedly something for the nitty-gritty department:

In the GUI terminal on Windows I find the following:

TAB char: takes focus away from terminal to... yes to what? After three TAB key presses I find focus in the file browser (path pane), next press on the "Browse your files" button, next  it is down in the directory tree. From then on it disappears, I can't trace it.
I'd expect focus to be back in the terminal pane after a finite number of TAB key presses, but after > 50-60 it still isn't clear where focus went.
(As to TAB, I hoped it would work as in Octave-CLI: to complete typed input. Currently Ctrl-TAB and Ctrl-Shift-TAB do this. No big deal)

Shift-TAB: if TAB works to shift focus elsewhere, Shift-TAB is supposed to revert one TAB key press, i.e. bring focus back to where it was before the previous TAB key press. OK, this works.

IIRC on Windows, Ctrl-TAB (& Ctrl-Shift-TAB) is used to switch focus from one application pane to the next (at least for the Multi Document Interface), TAB (Shift-TAB) to switch between elements on/in one pane, Alt-TAB to switch between application windows. The latter works OK.

END: while editing a line, supposed to shift the cursor to the first char position after the command string. Instead it inserts a tilde ('~') at the cursor position and beeps.

INS: I'd expect switching between insert and overwrite mode. However, like the END key, I get an inserted tilde and a beep.
In Octave-CLI it doesn't work either (in fact, in the cmd32.exe terminal).
BTW in a regular cmd32.exe terminal the INS key works as expected, so Octave apparently modifies its behavior.

DEL: Supposed to delete the character under the cursor. Instead it works as Backspace (deletes the char before the cursor).

All these keys / key combos (save INS) work fine in octave-cli.exe.

Philip Nienhuis <philipnienhuis>
Group Member


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #28964:  win_keys.patch added by lostbard (2KiB - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by philipnienhuis (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.


    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-09-06 philipnienhuis StatusNone Fixed
        Open/ClosedOpen Closed
    2013-08-30 lostbard Attached File- Added win_keys.patch, #28964

    Back to the top

    Powered by Savane 3.12.
    Corresponding source code