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).

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'.

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

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.

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.

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 ...

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?

ESC
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.

TAB
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.

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
exit

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.

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?

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

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?

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.