- To: emacspeak@xxxxxxxxxxx
- Subject: Emacspeak term mode errors
- From: Tim Cross <tcross@xxxxxxxxxxx>
- Date: Sat, 26 Aug 2006 16:41:24 +1000
- Delivered-To: emacspeak@xxxxxxxxxxx
- List-Help: <mailto:emacspeak-request@xxxxxxxxxxx?subject=help>
- List-Post: <mailto:emacspeak@xxxxxxxxxxx>
- List-Subscribe: <mailto:emacspeak-request@xxxxxxxxxxx?subject=subscribe>
- List-Unsubscribe: <mailto:emacspeak-request@xxxxxxxxxxx?subject=unsubscribe>
- Old-Return-Path: <tcross@xxxxxxxxxxx>
- Resent-Date: Sat, 26 Aug 2006 02:42:12 -0400 (EDT)
- Resent-From: emacspeak@xxxxxxxxxxx
- Resent-Message-ID: <xb5V5D.A.DoB.E1-7EB@xxxxxxxxxxx>
- Resent-Sender: emacspeak-request@xxxxxxxxxxx
I've spent a couple of hours looking at the errors occuring when you
run M-x term under emacspeak when running under X. I've located the
problem, but am unsure of the best fix.
Summary: Problem is with the use of last-input-event. The defadvice
for term-emulate-terminal is assuming last-input-event is always a
number. However, this is not always the case and under some systems,
such as X windows, the value in this variable can also be a symbol or
list (for mouse events) This causes a wrong-type-argument
number-or-marker-p error when numeric equality comparisons are used.
It should be noted also that I'm seeing the same error with
emacspeak-self-insert-command if I hit enter directly after a ). This
appears to be happening in all modes. I've not looked at this, but the
recent changes made to address the earlier problem not only don't
appear to work, but have made matters worse under X. I will have a
look at this once I've fixed the term-emulate-terminal defadvice as I
suspect its the same issue.
>From reading the elisp manual, I get the impression this is a problem
due to changes in emacs internals resulting from the need to support
other character sets. Originally, last-input-event was always a
number. "Special" characters were represented by setting the high end
bits. However, this becomes a problem when you move to different
character sets that either already use those high end bits or use
multibyte, so things were changed. Now, last-input-event uses symbols
to represent things like return, backspace, tab and function keys on
systems where this can be done. Under the console, the old behavior
seems to still be used, though this may just be a side effect of the
character set/encoding I'm using.
I can certainly fix this quite easily for my situation. However, I'm
not sure how this may impact on users of other character sets or that
we might not need a higher level abstraction to fix this in a
consistant manner (I've not yet done a grep to see how often
last-input-event is used).
The other area which I'd like some guideance on is the way
term-emulate-terminal's defadvice is testing for certain conditions.
To my naive eye, it looks like the test is somewhat over engineered
and we could simplify it a bit, but experience has tought me that
usually it is me who is missing some subtlety regarding what is going
on. As an example, the following test is performed to determine if the
user has hit backspace
((and (= last-input-event 127)
(= new-row emacspeak-eterm-row)
(= -1 (- new-column emacspeak-eterm-column))
current-char)
(....
I'm thinking that if we assume the only way the new column would be
one less than the previous column and we are on the same row, then the
user entered a backspace. Therefore, we cold simplify things by doing
((and (= new-row emacspeak-eterm-row)
(= -1 (- new-column emacspeak-eterm-column)))
(....
but maybe I'm missing some subtle issue, such as process line
filtering etc. Obviously, I can work this out through trial and error,
but why re-invent the wheel if it can be avoided.
Tim
-----------------------------------------------------------------------------
To unsubscribe from the emacspeak list or change your address on the
emacspeak list send mail to "emacspeak-request@xxxxxxxxxxx" with a
subject of "unsubscribe" or "help"