Emacspeak term mode errors

["T. V. Raman" <raman@xxxxxxxxxxx>]

the problems are related -- but what you say about
self-insert-char doesn't quite sound right.

If you look at the definition of self-insert-command (not
emacspeak's version which is emacspeak-self-insert-command)
you'll see that it is explicitly supposed to bitch at the user if
it is invoked with something other than a  character.

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

-- 
Best Regards,
--raman

      
Email:  raman@xxxxxxxxxxx
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@xxxxxxxxxxx
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

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