bug-zile
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-zile] Mac Terminal.app problems: TERM=nsterm FTW


From: Gary V. Vaughan
Subject: Re: [Bug-zile] Mac Terminal.app problems: TERM=nsterm FTW
Date: Tue, 16 Aug 2011 10:21:45 +0700

Hi Reuben,

On 16 Aug 2011, at 03:37, Reuben Thomas wrote:
> I do not see this problem in xterm, uxterm, gnome-terminal or konsole,
> but only in rxvt-unicode (rxvt is fine). I have only had this problem
> in recent versions of rxvt-unicode. This turns out not to be a
> surprise, as infocmp | grep kbs shows that out of the above, only
> rxvt-unicode shows kbs=^H and the rest show kbs=\177. As far as I can
> see, this is a problem with the terminal type, which for some reason
> is rxvt-256color (not the standard default, which is rxvt-unicode,
> according to rxvt-unicode's man page, and which has the correct
> setting, and which is, I think, the setting of TERM I used to get when
> running rxvt-unicode).

I had no idea how persnickety terminal management really was until I
started to dig through this particular issue!

> To express the problem with Backspace vs Ctrl-H more succinctly, it
> seems that we're assuming we're working in a world where Backspace
> always returns \0177 (and never ^H), so we can always distinguish the
> codes, but, because of differing kbs settings in terminfo, we can't
> rely on KEY_BACKSPACE being \0177 (as we are warned by the ncurses
> documentation); it may be ^H instead.

Right.  I'd be surprised if anyone is deliberately running a shell
with `stty erase ^h` these days, and I haven't tripped over a terminal
which really produces kbs=^h since using dumb green-screen terminals
at college 20 years ago.

> Looking at your patch to the Lua branch, I therefore would not expect
> to see KEY_BACKSPACE anywhere, only the literal ^H and \0177 codes.
> So, in keytocode_map, I'd expect KBD_BS to map to 127, and I wouldn't
> expect to see a mapping for curses.KEY_BACKSPACE at all in
> codetokey_map. Certainly if I make those changes, both keys seem to
> continue to work fine.

Nice catch!  Actually this opens the door to a nice simplification of
the codetokey_map initialisation, see 12f17f1.

> Also, one of your comments is wrong: next to [127] = KBD_BS it says
> "-- Delete key", but that should be "-- Backspace key".

Well I meant that on modern keyboards, to generate a curses KEY_BACKSPACE
event (i.e. a zile KBD_BS), you have to press the key in the top right of
the keyboard marked 'Delete'.  Hopefully the comments in my refactoring
changeset 12f17f1 are clearer about that.

> Modulo those niggles, I'm happy to apply a similar patch to master.

Great! Please look at the refactoring too, I think it makes for simpler
and easier to understand code.

> After this patch is applied, it looks as though the only users who
> should experience a malfunction are those unlucky enough to use a
> terminal on which the Backspace key really does generate C-h. And I'm
> not sure we need worry about that these days (though for example it
> affected my EPOC port for the Psion PDAs). Hence, I could delete the
> corresponding FAQ, at least until someone on such a system
> complains...

+1

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]