This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Suggestion for terminal package maintainers

> On 6/2/2009 9:28 AM, Ken Brown wrote:
> > On 6/2/2009 8:48 AM, Corinna Vinschen wrote:
> >> On Jun  1 17:03, Ken Brown wrote:
> >>> The Cygwin console, after some changes made this past weekend, now 
> >>> uses  ^? as the default erase character, and this is what is sent by 
> >>> the  backspace key instead of ^H  
> >>> [...]
> >>
> >> What makes me a bit concerned about this change is that, while we can
> >> change Cygwin's terminfo and termcap files, we can't do that for
> >> existing non-Cygwin installations.  Is it really safe to change the BS
> >> key to ^? now that the "cygwin" terminal type is known to return ^H for
> >> so many years?
> > 
> > Applications like emacs that use ncurses should have no problem.  Are 
> > there applications that rely on the historical behavior of the cygwin 
> > terminal type rather than querying terminfo?  Apart from cygwin, such 
> > applications would have problems with any terminal type that decides to 
> > change its behavior.

> Sorry, I think I misinterpreted what you meant by "non-Cygwin 
> installations".  But wouldn't the issue be resolved by pushing the 
> change to the cygwin terminal type in terminfo upstream?

If it were about termcap/terminfo, it must be expected that an upstream change 
would take years until it propagates to most actual installations, which means 
years of inconsistent default configuration for remote login from 
cygwin console...
On the other hand, with this specific setting, the dreadful backspace issue, 
it is more crucial that the setting of stty is consistent with what the terminal 
actually sends. So of course it needs to be made sure that this works 
within cygwin. -
About remote login, it should be noted that Linux systems (some at 
least) as well as SunOS seem to be assuming "stty ^?" on remote login, 
which is obviously not proper behaviour (especially if termcap says something 
different), but that's what I see. So in that respect, typical 
configuration is not consistent right now and would become consistent 
by this change.

2009/6/2 Corinna Vinschen:
> On Jun  2 11:39, Christopher Faylor wrote:
> > > On Tue, Jun 02, 2009 at 05:33:27PM +0200, Corinna Vinschen wrote:
> >> > >Maybe it is, that's why I'm asking.  But, if we do that, shouldn't
> >> > >Ctrl-Backspace return ^H as in xterm?  So far the Cygwin console
> >> > >returned ^H without and ^? with Ctrl, now it returns ^? in both
> >> > >variations.
While it is true that the xterm resource "backarrowKey" would set this 
to ^H by default, most actual Linux installation change it by common 

> > > IMO, cygwin's console == linux console.  On two of my systems (Fedora
> > > and Gentoo) CTRL-Backspace returns Backspace on the console.  Now that
> > > I'm at work, I see that CTRL-Backspace returns ^H on my Ubuntu system.
> > > But, so far, the CTRL-Backspace == Backspace contingent is winning.
> Uh, oh, hmm.  I was always under the impression we try to be as xterm
> compatible as possible, rather than the Linux console.
Checking escape sequences of function keys and keypad keys, there are 
many similarities (and common deficiencies) with Linux console and 
some weird differences:
* Linux console (SUSE, don't know if it's really consistent) defines 
  function keys F1...F12 and Shift-F1...Shift-F8 (very weird to stop here).
* Cygwin console Shift-F1 and Shift-F2 are identical to F11 and F12, 
  I don't think that's intended, I guess it should also be changed 
  on the occasion of revising the console.
* Cygwin console has shifted function keys up to Shift-F10, no F11/F12.
* No Control-/Alt-modified function keys (on either console).
* No Control-/Shift-/Alt-modified keypad keys (i.e. cursor keys, Home etc);
  I would very much appreciate if this gets improved, too.
* Cygwin console lacks one feature that is quite useful: cursor position 
  reports. On output of ^[[6n, the terminal should respond an escape 
  sequence encoding the current cursor position.

> 2009/6/3 Corinna Vinschen:
> > Even not knowing the sequence returned by Alt-Backspace, AFAICS, the
> > right thing to do is to send either ^[^? or \377, dependent on the
> > setting of dev_state->metabit.

> I think that's the right thing to do. I'd pointed out the problem with
> Alt+Backspace, but that got lost in the discussion about my suggestion
> to have Ctrl+Backspace send ^_.

> The keycode probably doesn't show up in od output because the pseudo
> terminal device interprets the ^? for line editing purposes.
Not quite the pseudo terminal. It's the readline function (of bash, cat, ...) 
so obviously ^? rubs out the ESC again as it should.
> Attached
> is a small program I use for echoing keycodes, which puts the terminal
> device into raw mode. Quit with ^D.
The following would also serve as a quick test:
stty raw; od -t x1

By the way, I've always wondered why I cannot use "cat" for a quick test 
of most keyboard escape sequences in cygwin. This works quite nicely in 
Linux (except for the case above, apparently). On cygwin, entering cursor 
keys to "cat" just lets the cursor wander around, while on Linux it echoes 
the escapes; if I rlogin to a Linux box from a cygwin console, it works as 
well so I am puzzled what the difference is. Just curious, in case someone 
has an explanation...

Ken Brown wrote:
> ... But it does seem that the release of 1.7 is a good time to decide 
> whether the cygwin console is emulating linux or xterm or something else 
> and then make this happen as much as possible.
I would suggest not to follow such a strong plan ("as much as possible");
xterm has a lot of features, not all are really useful, and it has some 
deficiencies, too. I've just had a lengthy discussion with Andy Koppe about 
various issues..., just a few examples:
* "Application Cursor and Keypad Modes" - a dreadful heritage of VT100/VT220 
  which raises much confusion and inconsistencies between terminals, although 
  properly used it also provides the opportunity to distinguish as many key 
  and modifier combinations as an application wishes, with some unfortunate 
  limitations, though.
* Advanced mouse modes. Actually, it would be nice for cygwin console to 
  support mouse wheel scroll reports (in current mode "1000"), plus mouse 
  movement reports (in mode "1002"), plus ...?
* VT100-mode line drawing graphics. These are used by many programs for 
  graphic lines and menu borders.
  Cygwin console supports VGA mode graphics instead (like Linux console) 
  with the problem, however, that the actual graphic symbols displayed 
  would change with the DOS codepage that you can set with e.g. the CHCP 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]