Tue 06 Sep 2011 01:55:48 PM UTC, comment #14:
lcurses release 7 contains your changes; thanks!
|
Fri 02 Sep 2011 11:01:09 AM UTC, comment #13:
Gah. Savannah email send failed. Here's a useless comment to let you know there is other new stuff attached to this bug for you attention.
|
Thu 01 Sep 2011 04:38:04 PM UTC, comment #12:
D'oh! #33891 is a luaposix issue, and orthogonal to this report.
I've cloned your github lcurses, made a changeset to wrap tigetstr and friends and sent a pull request -- please merge and be sure to release a new lcurses from luaforge before the next Lua Zile release.
With the new APIs in lcurses, I've now ported your 43a74b3 to the lua branch, so both branches are now back in sync with respect to any changes made since you deputised me on the Lua branch.
When you've merged my lcurses pull request, please go ahead and close this bug.
|
Sun 21 Aug 2011 11:17:33 AM UTC, comment #11:
Need to port 43a74b3 to lua branches...
But first we need to add a tigetstr() call to lua curses, and we need to fix #33891 before we can upgrade to that new lcurses.
|
Wed 17 Aug 2011 06:06:58 AM UTC, comment #10:
I think we've finally nailed this one.
I've left #33908 open to remind us to agree what to do with the splash screen in respect of pointing people at the FAQ or similar...
|
Wed 10 Aug 2011 11:55:22 PM UTC, comment #9:
This is fixed by setting TERM=nsterm.
|
Tue 02 Aug 2011 08:24:18 AM UTC, comment #8:
The Savannah error that caused you to double post earlier in this thread seems to be when it fails to send the email notifications rather than the comment update proper. Which sucks, because that means we have to keep manually checking in on open bugs to see whether the conversation has advanced - since we can't rely on an email being sent :(
|
Tue 02 Aug 2011 07:54:38 AM UTC, comment #7:
Ah, I found the FAQ in master (which has more text than the lua branch).
Anyway, I really don't think we should force users to remap their settings to workaround an issue that emacs is solving automatically out of the box - especially on an emulator as widely deployed as Apple Terminal.app. Why should we make the user jump through hoops and live with a substandard key mapping when a few lines of code can fix it for them? You can even remove the FAQ entry then saving more space in the distro tar ball ;)
|
Mon 01 Aug 2011 01:16:37 AM UTC, comment #6:
Yes, I pushed - but just before I did, I rebased onto your 'Remove unused variable' commit, so the SHA changed. The pushed SHA is now: v2.4.0alpha1-137-gba8dd42
I saw the last question in the FAQ about BS/C-h issues, but there's no mention of Mac OS in there. Am I looking in the right place? Anyway, that's only working around the problem - if Emacs is doing the right thing on this same terminal already, then Zile should be too IMHO.
|
Sun 31 Jul 2011 05:29:29 PM UTC, comment #5:
Sorry for the duplicate comment, I got an error from Savannah suggesting my comment hadn't been posted!
|
Sun 31 Jul 2011 05:28:24 PM UTC, comment #4:
Have you pushed this commit? I recently noted this problem in both C and Lua Zile in rxvt-unicode, but as xterm and gnome-terminal worked fine, I assumed it was a terminal emulator bug (also, previously I used rxvt-unicode all the time and didn't have this bug).
Also, have you noticed the Mac OS-specific FAQ about this? (The last question in the Zile FAQ.) If this is no longer a problem on Mac OS, it would be nice to know since when, as then the FAQ entry can be scheduled for removal. (Currently, it's listed as a problem up to 10.4, which leaves a gap of 2 versions of unknown status.)
|
Sun 31 Jul 2011 05:28:10 PM UTC, comment #3:
Have you pushed this commit? I recently noted this problem in both C and Lua Zile in rxvt-unicode, but as xterm and gnome-terminal worked fine, I assumed it was a terminal emulator bug (also, previously I used rxvt-unicode all the time and didn't have this bug).
Also, have you noticed the Mac OS-specific FAQ about this? (The last question in the Zile FAQ.) If this is no longer a problem on Mac OS, it would be nice to know since when, as then the FAQ entry can be scheduled for removal. (Currently, it's listed as a problem up to 10.4, which leaves a gap of 2 versions of unknown status.)
|
Sun 31 Jul 2011 04:05:01 PM UTC, comment #2:
I've fixed this in Lua Zile with commit v2.4.0alpha1-136-g16a770b.
(Unless if misunderstood how terminfo works?!)
|
Sun 31 Jul 2011 01:26:13 PM UTC, comment #1:
Also Emacs correctly notes that my delete key is DEL and \C-h as the \C-h prefix, so it is not a terminal limitation or bogus terminfo setting I am experiencing.
|
Sun 31 Jul 2011 01:13:55 PM UTC, original submission:
In my terminal (Mac OS 10.7 Terminal, claims to be xterm-color), at the shell (bash-3.2.48) I can insert distinct ^? and ^h by pressing \C-vDELETE and \C-v\C-h respectively.
I have no peculiar stty settings:
gary$ stty
speed 9600 baud;
lflags: -iexten echoe echok echoke echoctl pendin
iflags: -ixany iutf8 ignpar
oflags: onocr onlret
cflags: cs8 -parenb
Yet when I start Zile up, both \C-h and DELETE behave like backwards-delete-char. With both M-x describe-key \C-h and M-x describe-key DELETE, I get reference to <backspace> in both cases. However, C-q DELETE inserts a \177 into the current buffer (and C-q C-h is broken per the last bug I filed).
|