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

[Reuben Thomas]

On 15 August 2011 17:03, Gary V. Vaughan <address@hidden> wrote:
>
> After half-a-day of experimentation and installing/uninstalling of
> various combinations of Zile, luacurses and ncurses to run under iTerm
> and Terminal.app, I realised everything is even simpler than the above
> after all!!

Good news!

>  2. C-h registers as a BACKSPACE in C Zile.
>
>     I see this only in C Zile but in all xterm variants, although
>     but not nsterm.  But, this is actually a bug in Zile, which I
>     fixed in Lua Zile some time ago with ba8dd42.  So Lua Zile
>     doesn't exhibit this problem anymore, and I think a port of
>     that fix to master would likely solve it there too.

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

Hence, this looks like a bug in the ncurses terminfo database, which
I'll report to Tom Dickey. (If I type Ctrl-V Backspace in
rxvt-unicode, I get ^?, just as in all the other terminals.)

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.

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.

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

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

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

-- 
http://rrt.sc3d.org