On 5/31/2009 10:15 AM, Ken Brown wrote:
On 5/31/2009 9:36 AM, Andy Koppe wrote:
Currently the code sends ^H for Alt+Backspace, which clobbers 'kill
word' in emacs, so that still needs to either move to Ctrl+Backspace
or be removed altogether.
Right. I forgot about that. Presumably there's no
On 5/31/2009 9:36 AM, Andy Koppe wrote:
Currently the code sends ^H for Alt+Backspace, which clobbers 'kill
word' in emacs, so that still needs to either move to Ctrl+Backspace
or be removed altogether.
Right. I forgot about that. Presumably there's no linux standard that
says Alt-Backspace
2009/5/31 Ken Brown:
> As I long-time emacs user, I have to say that I have never been tempted to
> type Ctrl-Backspace in emacs. But, as a result of this discussion, I just
> tried it in three different settings and got three different behaviors.
> (The three settings were: emacs under X, emacs
On 5/31/2009 5:13 AM, Andy Koppe wrote:
2009/5/30 Matt Wozniski:
On Debian, at least, the console sends ^H for Ctrl+Backspace and ^?
for Backspace; that is a pretty common convention among terminal
emulators that I've used. I vote against the ^_ suggestion; I for one
would be genuinely surprised
2009/5/30 Ken Brown:
> Now C-h and Backspace work as expected when I run emacs in a Cygwin console,
> provided I do stty erase ^? first. Am I right in assuming that this won't
> be necessary once the termios default is changed?
Yep.
2009/5/30 Matt Wozniski:
> On Debian, at least, the console se
On 5/30/2009 1:53 AM, Christopher Faylor wrote:
However, I have made the change to Cygwin to translate backspace to ^?.
It will be in the next snapshot.
Thanks!
Now C-h and Backspace work as expected when I run emacs in a Cygwin
console, provided I do stty erase ^? first. Am I right in assum
On Sat, May 30, 2009 at 2:35 PM, Andy Koppe wrote:
>>>The Linux console in Opensuse actually does the same thing, and two's
>>>a standard, right? ;)
>>
>> Actually, no. I emulated the linux console on my system. kterminal and
>> xterm also makes no distinction that I can see between CTRL-Backspac
>>The Linux console in Opensuse actually does the same thing, and two's
>>a standard, right? ;)
>
> Actually, no. I emulated the linux console on my system. kterminal and
> xterm also makes no distinction that I can see between CTRL-Backspace
> and Backspace.
As I said, I've seen the ^_ in the t
On Sat, May 30, 2009 at 07:00:46PM +0100, Andy Koppe wrote:
>> One more thing: with your change, Alt can be used to override ^? and
>> get ^H instead. Usually though, Ctrl is used as the modifier for this,
>> whereas Alt acts as Meta (i.e. it sends a ^[ prefix).
>
>Actually, we could take this one
> One more thing: with your change, Alt can be used to override ^? and
> get ^H instead. Usually though, Ctrl is used as the modifier for this,
> whereas Alt acts as Meta (i.e. it sends a ^[ prefix).
Actually, we could take this one step further. In MinTTY, if Backspace
is set to send ^?, Ctrl+Bac
Christopher Faylor wrote:
>>Now of course if emacs can translate low-level console I/O as it sees
>>fit, then the Cygwin DLL could also be able to translate Backspace into
>>^? characters rather than ^H, in CYGWIN=tty mode anyway. So I had a
>>look at fhandler_console.cc. It already uses ReadCon
On Fri, May 29, 2009 at 10:59:21PM +0100, Andy Koppe wrote:
>Now of course if emacs can translate low-level console I/O as it sees
>fit, then the Cygwin DLL could also be able to translate Backspace into
>^? characters rather than ^H, in CYGWIN=tty mode anyway. So I had a
>look at fhandler_consol
On 5/29/2009 5:59 PM, Andy Koppe wrote:
Now of course if emacs can translate low-level console I/O as it sees
fit, then the Cygwin DLL could also be able to translate Backspace
into ^? characters rather than ^H, in CYGWIN=tty mode anyway. So I had
a look at fhandler_console.cc. It already uses Re
>>> Actually, this holy war can be bypassed, without sacrificing Emacs
>>> correctly working on a console. What the console should send for that
>>> is the function key.
>>
>> Makes sense to me. Andy, is there any reason all cygwin terminals shouldn't
>> do this (including mintty)? This already
>> Actually, this holy war can be bypassed, without sacrificing Emacs
>> correctly working on a console. What the console should send for that
>> is the function key.
>
> Makes sense to me. Andy, is there any reason all cygwin terminals shouldn't
> do this (including mintty)? This already happe
On 5/29/2009 6:35 AM, Eli Zaretskii wrote:
Date: Thu, 28 May 2009 15:02:35 +0100
From: Andy Koppe
There's an ancient and pointless argument about whether the Backspace
key should send ^H (0x08) or ^? (0x7F).
Actually, this holy war can be bypassed, without sacrificing Emacs
correctly working o
> Date: Thu, 28 May 2009 15:02:35 +0100
> From: Andy Koppe
>
> Ken Brown:
> > A separate issue that has arisen in this thread is that when emacs runs
> > in a cygwin terminal [*], it sees C-h as DEL instead of as the help key.
> > Can someone familiar with cygwin terminals help with this? I'm sp
> Date: Thu, 28 May 2009 18:10:51 +0100
> From: Andy Koppe
>
> rxvt: invoke with -backspacekey DEC
> xterm: invoke with -xrm "*backarrowKey:false" (or untick "Backarrow
> Key" in the "Main Options" menu)
> mintty: Choose ^? as backspace keycode on the "Keys" page of the options
>
> As far as I k
On 5/28/2009 5:41 PM, Larry Hall (Cygwin) wrote:
Ken Brown wrote:
On 5/28/2009 5:14 PM, Andy Koppe wrote:
And then there's the problem that the Cygwin console can't be
changed to ^?.
Emacs doesn't work well in the Cygwin console anyway, for a variety of
reasons. I'll add that to the README
Ken Brown wrote:
On 5/28/2009 5:14 PM, Andy Koppe wrote:
And then there's the problem that the Cygwin console can't be
changed to ^?.
Emacs doesn't work well in the Cygwin console anyway, for a variety of
reasons. I'll add that to the README and to the announcement when I
release the next v
On 5/28/2009 5:14 PM, Andy Koppe wrote:
And then there's the problem that the Cygwin console can't be
changed to ^?.
Emacs doesn't work well in the Cygwin console anyway, for a variety of
reasons. I'll add that to the README and to the announcement when I
release the next version. (FWIW, I'
> Sorry, I guess I haven't been expressing myself very well. I wasn't
> suggesting any particular course of action, and I certainly don't want to
> break other applications.
No worries. I was just trying to explain why the proper and obvious
fix of switching the backspace defaults to ^? might be
On 5/28/2009 1:10 PM, Andy Koppe wrote:
Could the default for the terminals be changed? Yes, easily, but only
at the cost of breaking any applications that always expect ^H for
Backspace.
Sorry, I guess I haven't been expressing myself very well. I wasn't
suggesting any particular course of a
>> Can cygwin terminals be
>> configured so that emacs can tell the difference between the Backspace key
>> and "pressing h while holding down the control key"?
>
> "pressing h while holding down the control key" produces ^H (0x08).
> By default, this is also what backspace sends. As Andy says, ma
On Thu, May 28, 2009 at 11:00 AM, Ken Brown wrote:
> On 5/28/2009 10:02 AM, Andy Koppe wrote:
>>
>> There's an ancient and pointless argument about whether the Backspace
>> key should send ^H (0x08) or ^? (0x7F).
>
> I was asking something slightly different:
No, you were asking the same thing, y
On 5/28/2009 10:02 AM, Andy Koppe wrote:
There's an ancient and pointless argument about whether the Backspace
key should send ^H (0x08) or ^? (0x7F).
I was asking something slightly different: Can cygwin terminals be
configured so that emacs can tell the difference between the Backspace
key
Ken Brown:
> A separate issue that has arisen in this thread is that when emacs runs
> in a cygwin terminal [*], it sees C-h as DEL instead of as the help key.
> Can someone familiar with cygwin terminals help with this? I'm speculating
> again (bad habit), but it seems that the keycodes are being
On 5/28/2009 3:48 AM, Eli Zaretskii wrote:
What I can suggest at this point is send a formal bug report about
this with "M-x report-emacs-bug RET".
Tim,
You're probably in the best position to do this, since I've never used
tpu-edt. Alternatively, tell me precisely what steps to perform to
> Date: Wed, 27 May 2009 16:05:25 -0400
> From: Ken Brown
>
> On 5/27/2009 3:36 PM, Tim Adye wrote:
> > I just checked this on another machine that still had the old emacs 21.2
> > (and
> > had recently had a fresh Cygwin install, and I applied the latest changes
> > before testing). Before upda
On 5/27/2009 3:36 PM, Tim Adye wrote:
So this problem may be with tpu-edt.el as you suggested earlier.
I think that is indeed the case. I just took a closer look at
tpu-edt.el and found the following:
(defvar tpu-gold-map
(let ((map (make-keymap)))
;; Previously we used escape sequen
On 5/27/2009 3:36 PM, Tim Adye wrote:
I just checked this on another machine that still had the old emacs 21.2 (and
had recently had a fresh Cygwin install, and I applied the latest changes
before testing). Before updating emacs, it worked fine. I then installed
23.0.92-2 emacs, emacs-el, and ema
> In an xterm (with TERM=xterm) a few keypad keys do in fact have a (not very
> useful) definition: kp-f1, kp-f2, kp-f3, kp-f4 are (incorrectly) mapped to f1,
> f2, f3, f4 and kp-enter is correctly mapped.
With xterm's default config, F1 to F4 do actually send the keypad
codes ^[OP to ^[OS. That's
Hi Ken,
> But this doesn't seem to have anything to do with recent versions of
> emacs. I just reverted to cygwin's emacs-21.2-13 (in cygwin-1.5) and
> repeated several of my tests (all except the one in rxvt), and the
> results were identical to those I reported before.
Yes, I get the same k
On 5/27/2009 11:21 AM, Andy Koppe wrote:
xterm doesn't send those keycodes in its default configuration with
"PC-style Function Keys". Instead, with NumLock off, the numpad keys
send the same codes as the equivalent keys on the small cursor and
editing pads, so e.g. 1 (End) sends ^[OF.
See here
> As I understand the emacs documentation, the setting TERM=xterm should cause
> emacs to load term/xterm.el. In that file I find lines like
>
> (define-key map "\eOq" [kp-1])
> (define-key map "\eOr" [kp-2])
>
> This looks like the place where emacs should learn to interpret the keypad
> keys.
x
On 5/26/2009 9:11 PM, Tim Adye wrote:
In Cygwin 1.5 xterm (TERM=xterm), with "emacs -q -nw" (or also with "-f
tpu-edt") I get
ESC [ > 1 ; 2 4 2 ; 0 c ESC O q ESC O r ESC O s ESC
O t ESC O u ESC O v ESC O P l
The initial "ESC [ > 1 ; 2 4 2 ; 0 c" is just the response from xterm, asked
for its ve
On 5/26/2009 9:11 PM, Tim Adye wrote:
In Cygwin 1.5 xterm (TERM=xterm), with "emacs -q -nw" (or also with "-f
tpu-edt") I get
ESC [ > 1 ; 2 4 2 ; 0 c ESC O q ESC O r ESC O s ESC
O t ESC O u ESC O v ESC O P l
The initial "ESC [ > 1 ; 2 4 2 ; 0 c" is just the response from xterm, asked
for its ve
Hi Eli and Ken,
Thank you for all your investigations.
Ken Brown wrote on 26 May 2009 21:59:
>
> On 5/26/2009 4:03 PM, Eli Zaretskii wrote:
> > It would really help me to see the result of typing "C-h l" after
> > pressing the keypad keys, on Tim's machine, as I requested
> > earlier in this t
On 5/26/2009 4:03 PM, Eli Zaretskii wrote:
It would really help me to see the result of typing "C-h l" after
pressing the keypad keys, on Tim's machine, as I requested earlier
in this thread.
I can't help you with Tim's machine, but I tried it on my own. (I'm
currently running emacs-23.0.94 i
> Date: Tue, 26 May 2009 07:58:41 -0400
> From: Ken Brown
>
> On 5/25/2009 6:13 PM, Jon TURNEY wrote:
> > I would have said that this could be same problem as in [1], an X server
> > bug, but then I would expect the problem to be seen both in "emacs -nw
> > in an xterm under X" and "emaacs unde
On 5/25/2009 6:13 PM, Jon TURNEY wrote:
I would have said that this could be same problem as in [1], an X server
bug, but then I would expect the problem to be seen both in "emacs -nw
in an xterm under X" and "emaacs under X"...
I'm not yet convinced that there's a bug. The tpu-*.el files use
Hi Ken,
> I don't know the answer, but I can think of a couple things
> you could try. First, take a look at the news file for emacs
> 22. (C-u C-h C-n, then enter 22 when you're prompted for the
> version.) Search for 'keypad', and you'll find a discussion
> of a new keypad setup package.
Tim Adye wrote:
Thanks for the taking on the emacs maintenance. A new release after so long
is welcome and it looks very nice.
I have however found one problem with this experimental release 23.0.92-2:
when I run it in no-window mode (emacs -nw) in an xterm (or rxvt), the
keypad keys do not seem
> From: "Tim Adye"
> Date: Mon, 25 May 2009 19:23:28 +0100
> Keywords: Addressed to t.j.a...@rl.ac.uk
>
> I have however found one problem with this experimental release 23.0.92-2:
> when I run it in no-window mode (emacs -nw) in an xterm (or rxvt), the
> keypad keys do not seem to be defined or
On 5/25/2009 2:23 PM, Tim Adye wrote:
I have however found one problem with this experimental release 23.0.92-2:
when I run it in no-window mode (emacs -nw) in an xterm (or rxvt), the
keypad keys do not seem to be defined or mapped to emacs functions. I use
tpu-edt mode, which relies on those key
On 5/25/2009 2:23 PM, Tim Adye wrote:
I have however found one problem with this experimental release 23.0.92-2:
when I run it in no-window mode (emacs -nw) in an xterm (or rxvt), the
keypad keys do not seem to be defined or mapped to emacs functions. I use
tpu-edt mode, which relies on those key
46 matches
Mail list logo
