Re: font-lock and autoload is broken

SJT> The point is moot unless somebody fixes the data loss bug I SJT> reported. mb> I don't see why your action regarding one bug depends on your mb> action regarding another bug. SJT> Because I don't want to rip out Matt's code if I can avoid it. It's SJT> easier to fix a bug if we get more reports. "Many eyes." If the SJT> release is going to get delayed because nobody fixes a showstopper, SJT> there's no good reason not to leave Matt's code in, and give it more SJT> time to get fixed, too. Anyways, Matt definitely has signed up to fix this, and he's gotten some more good bug reports from me offline... mb> You know, someone else could try to fix this bug too, before I mb> get around to it. SJT> I will take a look at it. And it would be nice if lots of people SJT> would look at this. But you said you would look at it. And it is a SJT> showstopper. (Matt's isn't, quite, since AFAIK you can QUIT out of it.) I don't remember saying that, but I shoot my mouth off a lot, yeah... I'm even too lazy to check in the archives. Anyways, I haven't claimed this bug as my very own yet. Go for it. You can't quit out of Matt's bug if you're running lazy-lock. Even if quit were always effective, it would still be a show-stopper. SJT> BTW, it strikes me that #define'ing INT_GCBITS to 2, and using bit 0 SJT> as a pointer/immediate flag, and bit 1 as a char/int flag when bit SJT> zero is set, would take you quite a ways toward the Holey Grale of SJT> Sun3 support. We have room for 2 30-bit data types and one 31-bit SJT> data type. Currently the 30's are pointers and chars and the 31 is SJT> int. I know swapping ints and chars works fine (I ran for about 3 SJT> months with #define BASKIN_ROBBINS_CHARS, but eventually gave up SJT> because Hrvoje vetoed the patch). Pointers are problematic, but SJT> maybe.... Hmmmmm. This is probably a good idea. Not worth doing just for m68k support. When I was complaining about loss of sun3 support, I was at least half teasing Olivier. If someone were to dead set on implementing this, I wouldn't stop them, but there are bigger fish to fry. SJT> I suppose you already thought of that, though? Not really.