On Fri, Nov 06, 2015 at 02:28:15PM +0000, David Gee wrote: > In my view this is a bug in GCC SDK. It makes GCC all but useless for > porting command line programs—it shouldn't be necessary to change the mode > file just for this: Norcroft (unsurprisingly) works correctly—as does GCC > on other platforms. > > This has been a "feature" for a long time—it's in GCC 4.1.2 too—and > affects all task window managers that I've tried on RO 4.39 and 5.21. > Isn't it time it was fixed?
It's slightly complicated. There is a code for backspace (ASCII 8, aka Ctrl-H) and there is a code for Delete (127). There has been an eternal argument in Unix terminal circles which should be backspace and which should be delete: http://www.ibb.net/~anne/keyboard.html In Unix, you fix this in your termcap or with stty - ie you can configure it on a per-terminal basis. The reason you may wish to configure it is that if you set Backspace=Delete then you can no longer tell the difference: this might not be a problem for command line editing, but becomes more of an issue for full-screen console programs where you want to pass keypresses through unchanged and let the program deal with them. In RISC OS, most task window managers are fairly feeble and don't do proper terminal emulation, at best basic line editing. Nettle is the only one that emulates an actual named terminal (that I know about). Also, there is no equivalent of stty (to configure keystrokes on a per session basis), or .profile (a script that sets your preferences afresh for every session where you might put your stty settings), so you can't do per-session config, you have to configure it on a global basis. While it's possible to configure UnixLib with unix$something variables, they aren't per-session, they're the same for all sessions. The SharedCLibrary, of course, hasn't a clue about terminals so is unaffected by this. So the danger is that fixing this for command line programs you will make things worse for programs that do proper terminal handling. If it gets baked into UnixLib it's then impossible to disable if it does break something. I don't pretend to understand the UnixLib terminal code however, so reserve the right to be completely wrong, however. Theo _______________________________________________ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
