Re: int/Lisp_Object mixup

[Kim F. Storm]

Miles Bader <address@hidden> writes:

> address@hidden (Kim F. Storm) writes:
> > > I recommend that people compile with -DUSE_LISP_UNION_TYPE every once in
> > > a while to cach int/Lisp_Object mixups.
> > 
> > Maybe we could add this hint to etc/DEBUG as a way to catch otherwise
> > hard-to-find errors.
> 
> Is there any reason why developers shouldn't just _always_ use it?
> Does it slow down emacs greatly?
> 
> I think it would be great if there was a very easy way to turn on all
> the various debugging/error-trapping features of emacs at configure
> time, and even make it the default for developers if possible (maybe if
> AC_MAINTAINER_MODE is turned on?), or at least strongly urge people to
> do so.

Having such a flag would be great.

However, I think that normally the maintainers should use emacs
compiled in exactly the same way that it will be run by the users
eventually; generally turning on some maintainer mode which alters
both code flow and timing is a bad idea IMO.

> 
> Besides USE_LISP_UNION_TYPE, there's also GLYPH_DEBUGGING (which most
> importantly enables all the xasserts in the code).  The latter, at
> least, seems not to be a noticable speed problem.

But turning on GLYPH_DEBUGGING does make emacs unstable ...  It hits
spurious traps and asserts -- which I have been too busy to track
down (after all, emacs works fine without it).

My guess is that the GLYPH_DEBUGGING code is not up-to-date with the
changes that have happened since 21.1 was released.  Besides, in my
experience, the glyph debugging code isn't really that useful when
it comes to debugging redisplay related bugs.

But if you have the time to debug and clean it up, you are most
welcome to do that.

-- 
Kim F. Storm  http://www.cua.dk