Re: Comparison between integer and character is constant nil (?\; and 0)
SL Baur <steve(a)xemacs.org> writes:
More or less. The usual cause of an Ebola notice at the beginning
or
end of a buffer is due to use of preceding-char and following-char.
Those functions return integer 0 at the boundary. Since they really
want to return something that cannot be a character, this is O.K.
Kind of yucky, but O.K.
Well said -- "kind of yucky, but OK" summarizes it. The funny thing
is that this {following,preceding}-char are now actually *safer* than
they were in Emacs 19, where they would stop when encountering a ?\0
character!
In general, an Ebola notice of a comparison of a character and
integer 0 when generated from usage of preceding-char and
following-char is not Ebola and is safe usage.
Exactly.
Yes.
It is also _incorrect_ (and Ebola) to do something like (eq ?B (1+
?A)). Arithmetic on characters is allowed, but turns the characters
into integers. You would have to do (eq ?B (int-char (1+ ?A))) to
make it work right.
(= ?B (1+ ?A))
will work, but it's dirty. Still, it is arguably cleaner than
scattering the code with `int-char's.
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
aibohphobia (ay' bo fo beeya): n. The fear of palindromes.