9:53 a.m.
>>>> "viteno" == Norbert Koch
<nk(a)viteno.net> writes:
viteno> Hi! Could someone please remind me what's the objective
viteno> of binding RET to C-m instead of C-j unconditionally?
viteno> This reduces the usability within an xterm to some value
viteno> close to zero.
I don't understand. There are definitely serious keyboard issues (I
can't keep the region on at the same time the minibuffer is active,
which loses pretty badly), but for Return (a) the unconditional
binding in src/keymap.c and (b) the Lisp binding in lisp/keydefs.el
are as they've always been. Not to mention that RET is irrelevant in
an xterm; you only get to see the C-m.
Anyway, what I'm seeing is the opposite: CR is getting translated to
LF somehow in an xterm.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
2:46 p.m.
New subject: [Success] XEmacs 21.5-b12 "carrot" i386-unknown-freebsd4.8
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "viteno" == Norbert Koch
<nk(a)viteno.net> writes:
viteno> Hi! Could someone please remind me what's the objective
viteno> of binding RET to C-m instead of C-j unconditionally?
viteno> This reduces the usability within an xterm to some value
viteno> close to zero.
I don't understand. There are definitely serious keyboard issues (I
can't keep the region on at the same time the minibuffer is active,
which loses pretty badly), but for Return (a) the unconditional
binding in src/keymap.c and (b) the Lisp binding in lisp/keydefs.el
are as they've always been. Not to mention that RET is irrelevant in
an xterm; you only get to see the C-m.
Anyway, what I'm seeing is the opposite: CR is getting translated to
LF somehow in an xterm.
Maybe, I'm mixing things up. I seem to recall, someone said that RET
is bound to C-m in 21.5 contrary to 21.4 and prior.
If I use 21.5 in an xterm, RET too often has no effect at all, eg in
Gnus buffers. I've got to move the cursor (or do other things) to
pass the RET key-action to XEmacs, or so it seems.
norbert.
5:17 a.m.
New subject: RET ain't RET unless you tell RET it is RET (was: [Success] XEmacs 21.5-b12 "carrot" i386-unknown-freebsd4.8)
|--==> "SJT" == Stephen J Turnbull <stephen(a)xemacs.org> writes:
>>>>>"viteno" == Norbert Koch
<nk(a)viteno.net> writes:
viteno> Hi! Could someone please remind me
what's the objective
viteno> of binding RET to C-m instead of C-j unconditionally?
viteno> This reduces the usability within an xterm to some value
viteno> close to zero.
SJT> Anyway, what I'm seeing is the opposite: CR is getting translated
SJT> to LF somehow in an xterm.
Here's a really ugly ugly work around, and I have no idea why it
works, but it does so go figure...
- Fire up 'xemacs -nw'
- In scratch _before_ you do or touch anything else type:
(describe-key "\C-m") C-j
From then on RET behaves as RET. But you *must* do it *before* you go
anywhere near the return key.
BTW, Ben introduced this bug about a year ago with one of his
workspace commits. I have asked time and again to get this fixed.
Free beer to whoever fixes this.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - The only _______ you'll ever need. |
| Fill in the blank, yes, it's THAT good! |
|------------------------------------<youngs(a)xemacs.org>---|
5:57 a.m.
New subject: RET ain't RET unless you tell RET it is RET
>>>> "SY" == Steve Youngs
<youngs(a)xemacs.org> writes:
SY> Here's a really ugly ugly work around, and I have no idea why
SY> it works, but it does so go figure...
Thanks. That will probably help in figuring out wtf is going on here.
SY> BTW, Ben introduced this bug about a year ago with one of his
SY> workspace commits. I have asked time and again to get this
SY> fixed.
Can you be more precise? Maybe even point me to a patch? I've
already done 5 builds trying to narrow it down, I'd rather avoid doing
more.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
6:40 a.m.
New subject: RET ain't RET unless you tell RET it is RET
|--==> "SJT" == Stephen J Turnbull <stephen(a)xemacs.org> writes:
>>>>>"SY" == Steve Youngs
<youngs(a)xemacs.org> writes:
SY> BTW, Ben introduced this bug about a year
ago with one of his
SJT> Can you be more precise? Maybe even point me to a patch? I've
SJT> already done 5 builds trying to narrow it down, I'd rather
SJT> avoid doing more.
It was around about the time of "The Great Mule Merge". I can't
remember if that was the culprit, but if not it wasn't that long
afterwards.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - The only _______ you'll ever need. |
| Fill in the blank, yes, it's THAT good! |
|------------------------------------<youngs(a)xemacs.org>---|
3:07 a.m.
New subject: RET ain't RET unless you tell RET it is RET
|--==> "SJT" == Stephen J Turnbull <stephen(a)xemacs.org> writes:
SJT> Can you be more precise? Maybe even point me to a patch? I've
SJT> already done 5 builds trying to narrow it down, I'd rather
SJT> avoid doing more.
Look around 2002-03-15.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - The only _______ you'll ever need. |
| Fill in the blank, yes, it's THAT good! |
|------------------------------------<youngs(a)xemacs.org>---|
4:19 a.m.
New subject: RET ain't RET unless you tell RET it is RET (was: [Success] XEmacs 21.5-b12 "carrot" i386-unknown-freebsd4.8)
Steve Youngs <youngs(a)xemacs.org> wrote:
Here's a really ugly ugly work around, and I have no idea why it
works, but it does so go figure...
- Fire up 'xemacs -nw'
- In scratch _before_ you do or touch anything else type:
(describe-key "\C-m") C-j
From then on RET behaves as RET. But you *must* do it *before* you go
anywhere near the return key.
I think this is a bit of a red herring. I can get RET to behave as RET
by evaluating anything at all in the *scratch* buffer when XEmacs first
starts up. That is, this is sufficient:
(+ 0 1) C-j
I'm seeing what Norbert is seeing. It is as though the first RET you
type gets stuck in a pipe somewhere, then the next keypress makes the
RET take effect, as well as processing that next keypress.
--
Jerry James
http://www.ittc.ku.edu/~james/
6:10 a.m.
New subject: RET ain't RET unless you tell RET it is RET
|--==> "JJ" == Jerry James <james(a)xemacs.org> writes:
JJ> I think this is a bit of a red herring. I can get RET to behave as RET
JJ> by evaluating anything at all in the *scratch* buffer when XEmacs first
JJ> starts up. That is, this is sufficient:
JJ> (+ 0 1) C-j
() C-j
Seems to be sufficient.
JJ> I'm seeing what Norbert is seeing. It is as though the first RET you
JJ> type gets stuck in a pipe somewhere, then the next keypress makes the
JJ> RET take effect, as well as processing that next keypress.
That's only half the problem, it's also processing that RET as LFD
(which runs `eval-print-last-sexp' in scratch).
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - The only _______ you'll ever need. |
| Fill in the blank, yes, it's THAT good! |
|------------------------------------<youngs(a)xemacs.org>---|
5:55 p.m.
New subject: RET ain't RET unless you tell RET it is RET
Steve Youngs <youngs(a)xemacs.org> wrote:
|--==> "JJ" == Jerry James <james(a)xemacs.org>
writes:
[snip]
JJ> I'm seeing what Norbert is seeing. It is as though the
first RET you
JJ> type gets stuck in a pipe somewhere, then the next keypress makes the
JJ> RET take effect, as well as processing that next keypress.
That's only half the problem, it's also processing that RET as LFD
(which runs `eval-print-last-sexp' in scratch).
Aha, so it has something to do with EOL encodings! It looks like a TTY
has coding system 'undecided, at least on startup. Take a look at the
code at the top of convert_eol_convert, in file-coding.c. In
particular, look at the
if (data->actual == EOL_AUTODETECT)
part, which is taken initially. Basically, you have a race here. If
you type a C-j before a RET, then you take the branch on line 3144 of
current CVS, which sets data->actual to EOL_LF. On the other hand, if
you type a RET before a C-j, then you take the branch on line 3149 and
data->actual is set to EOL_CR. This matters because of the branch on
line 3177:
if (data->actual == EOL_LF || data->actual == EOL_AUTODETECT || (str->eof))
If you take the branch, data is copied unchanged with Dynarr_add_many.
If you don't, then you do RET->LFD translations in the block in lines
3183 to 3210.
This kind of autodetection may make sense for files, but it clearly
doesn't make sense for TTYs. We should set the TTY to the correct
coding system right away, instead of leaving it to blind chance whether
C-j or RET happens to get pushed first. Unfortunately, I don't actually
know how to do that at the moment....
--
Jerry James
http://www.ittc.ku.edu/~james/
1:52 a.m.
New subject: RET ain't RET unless you tell RET it is RET
>>>> "Jerry" == Jerry James
<james(a)xemacs.org> writes:
Jerry> Aha, so it has something to do with EOL encodings!
Good work!
Jerry> Unfortunately, I don't actually know how to do that at the
Jerry> moment....
Maybe I do. I'll take a look. Surely Ben does, though.
Ben? Check out thread starting at
<a
href="http://list-archive.xemacs.org/xemacs-beta/200304/msg00293.htm...
87r87r6jr6.fsf(a)tleepslib.sk.tsukuba.ac.jp
</a>
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
12:02 a.m.
New subject: RET ain't RET unless you tell RET it is RET
|--==> "SJT" == Stephen J Turnbull <stephen(a)xemacs.org> writes:
>>>>>"Jerry" == Jerry James
<james(a)xemacs.org> writes:
Jerry> Aha, so it has something to do with EOL
encodings!
SJT> Good work!
Indeed!
Jerry> Unfortunately, I don't actually know how to do that at the
Jerry> moment....
SJT> Maybe I do. I'll take a look. Surely Ben does, though.
Any progress with this one, guys? Steve, if you think you can fix it,
please do. I think Ben is too busy getting ready for his next
sabbatical to comment. :-)
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - The only _______ you'll ever need. |
| Fill in the blank, yes, it's THAT good! |
|------------------------------------<youngs(a)xemacs.org>---|
7659
days inactive
7672
days old
10 comments
4 participants
participants (4)
-
Jerry James -
Norbert Koch -
Stephen J. Turnbull -
Steve Youngs